Skip to main content

White-label end-user apps

Keyban ships three turn-key applications that cover the most common end-user journeys on the platform. Two of them — dpp and verify-dpp — form the consumer pair around a Digital Product Passport: dpp distributes the passport to the first buyer; verify-dpp lets any later holder verify it on-chain. The third, loyalty, runs the on-chain Loyalty journey end-to-end. Each app is a thin React shell on top of the WAAS SDK and the embedded wallet, so a customer never sees a seed phrase, an extension prompt or a network switch.

Every screen of these apps is white-label by default. From the Keyban Dashboard, five dimensions are yours to control — no Powered by Keyban watermark, your customers see your product:

  1. DomainDeploy under your own host — no keyban.com URL exposed to your customers.
  2. Look and feelLight/dark theme, primary and secondary colour palettes.
  3. AuthenticationToggle Email OTP, Phone OTP, Google or Auth0 per application.
  4. Your brandConfigured once from the Keyban Dashboard, propagated to every end-user app.
  5. IdentityYour name, logo and favicon.
  6. LocaleEnglish or French where the app supports it.
A hub showing the brand at the centre, surrounded by the five dimensions you control from the Keyban Dashboard: domain, identity, look and feel, locale, authentication methods.

You can deploy these apps as-is, customise their branding from the admin console, or treat them as a reference implementation for your own UI.

Compare the three apps​

  1. dpp

    DPP — first buyer

    • Claim flow for a passport's first owner
    • Magic-token or email gating
    • Mobile-first
    • Audience: engaged consumer
  2. verify-dpp

    DPP — secondary buyer

    • Verifies the same passport on-chain, no sign-in needed
    • Cryptographic signature check
    • Mobile-first, FR/EN
    • Audience: secondary buyer
  3. loyalty

    On-chain Loyalty

    • Wallet-native points balance
    • Reward catalogue and redemption
    • Mobile-first, FR/EN
    • Audience: in-store shopper
A three-column comparison: the first two columns (dpp, verify-dpp) are the consumer pair around a Digital Product Passport — first buyer then secondary holder — and the third (loyalty) covers the on-chain loyalty journey.

The three apps share the same authentication surface (Email OTP, Phone OTP, Google, Auth0 — verify-dpp is the only sign-in-less one), the same embedded wallet, and the same theming pipeline. Picking one over another is a matter of which journey you want to expose first; nothing prevents deploying several of them under different sub-domains.

dpp — claim a Digital Product Passport​

The dpp app is the first half of the consumer-side DPP journey. It implements the consumer side of the DPP four-step lifecycle: a buyer scans a QR code or follows a packing-slip URL, signs in with the email or phone the brand pre-registered, and receives the on-chain ERC-721 token bound to that physical item.

dpp.your-domain.com
dppFirst-buyer claim journey
  1. Scan or follow a link

    QR code on the packaging or a one-time URL on the packing slip.

  2. Sign in

    Email, phone, Google or Auth0 — gated to the address the brand pre-registered.

  3. Receive the passport

    ERC-721 minted to the user's embedded wallet, transaction hash shown.

What it covers:

  • Magic-token gating and email/phone claim gating.
  • Inline embedded wallet provisioning at the moment of claim.
  • Post-claim view of the certified attributes and the on-chain transaction hash.

Pair it with the admin-side configuration described in the DPP introduction, step 3. Once the passport changes hands (resale, gift, second life), the new holder uses verify-dpp below to check the same on-chain record.

verify-dpp — verify a product​

The verify-dpp app is the second half of the consumer-side DPP journey — the counterpart to dpp above. It is the only app of the three that does not require sign-in: a secondary buyer or a curious consumer pastes a passport URL or scans a QR code, and the app:

verify-dpp.your-domain.com
verify-dppSecondary-buyer verification
  1. Paste or scan

    A passport URL, a serial number or a QR code from the product.

  2. Read on-chain

    The app fetches certification events directly from the blockchain.

  3. See verified attributes

    Cryptographic signature is checked, attribute history is displayed.

  • Resolves the matching certifier contract on Starknet (mainnet or sepolia).
  • Reads KeybanPassportCertified events directly from the chain.
  • Fetches the certified IPFS payload and verifies the cryptographic signature.
  • Displays the attribute history across re-certifications and, optionally, checks a claim parameter against the certified values.

Because the verification path is fully on-chain, a buyer can audit a product even after the original brand's app is decommissioned. This is the structural property the on-chain DPP enables.

loyalty — earn and redeem points​

The loyalty app is the consumer surface of the On-chain Loyalty program. It shows a customer their points balance, the catalogue of rewards configured in the admin console, and confirms each redemption through the embedded wallet.

loyalty.your-domain.com
loyaltyEarn-and-redeem journey
  1. Sign in

    Email, phone, Google or Auth0 — same authentication surface as dpp.

  2. See live balance

    Points minted on-chain on every qualifying event (purchase, scan, claim).

  3. Pick a reward

    Catalogue defined in the admin console — discount, freebie, exclusive item.

  4. Redeem

    Points are burned on-chain; the voucher is delivered through your fulfilment channel.

What it covers:

  • Authentication through any of the four supported methods, with FR / EN locales.
  • Live points balance backed by the on-chain mint history.
  • Reward catalogue, redemption confirmation and burn signature.
  • Transaction history (issuance and redemption) sourced from the same on-chain log the dashboard reads.

This is the recommended starting point for in-store programs, including the Zelty-powered restaurant flow.

Build your own​

White-label customisation stays inside Keyban's UX guidelines so the resulting interface remains coherent across journeys. If those guardrails are too tight for your brand, the same SDK powers a fully custom build:

  • React — use @keyban/sdk-react to consume the same hooks the apps rely on. Reference: WAAS React SDK.
  • Vanilla JavaScript — use @keyban/sdk-base if you target a non-React stack. Reference: WAAS JavaScript SDK.
  • Mobile (React Native) — the same React surface works in a React Native shell; the embedded wallet supports both runtimes.

You keep the embedded wallet, the MPC infrastructure, the authentication providers and the on-chain settlement; only the UI is yours.

Where to go next​