How to plan your network environment

The blockchain ledger an application uses is set by the product (DPP, Loyalty, Embedded Wallet) — not by you. The only environment dimension you control is mainnet vs testnet. This guide:

• States the product → ledger mapping so you don't expect it to be a choice.
• Frames the only real arbitration: mainnet vs testnet.
• Walks through the testnet → mainnet promotion (which is per-application and not a flag flip).
• Lists what doesn't carry over.

1. The ledger is fixed by the product

Each Keyban product is engineered around a specific blockchain family. Provisioning an application of that product implicitly picks the family — there's no override.

Product	Ledger family	Why
DPP (Digital Product Passport)	Starknet	High throughput at low cost, deterministic finality, ZK-rollup security. Optimised for the high-volume, low-value passport-write workload.
Loyalty (points)	Stellar	Sub-cent transaction fees, sub-second finality, native asset issuance. Optimised for the high-frequency micro-incentive workload.
Embedded Wallet (full surface)	Base (EVM)	Coinbase L2 settled on Ethereum; full ERC-20 / ERC-721 / contract surface for non-Keyban-product use cases.

If you're integrating multiple products, you'll provision multiple Keyban applications, each on its own ledger. Keyban does not bridge writes between ledgers — your back-office multiplexes by domain.

2. The only choice you make: mainnet vs testnet

Each family ships with a public testnet and a mainnet. They differ on three axes that matter for planning.

Axis	Mainnet	Testnet
Real value	Yes — token transfers, NFTs, certifications cost real money.	No — gas paid in faucet tokens.
Audience	Production users, billable.	Your dev team, automated tests.
Reversibility	Mistakes are public, on-chain, permanent.	Reset-friendly — re-create at will.

The recommended path is to build and verify everything against the testnet first, then promote a fresh application to the mainnet equivalent when you're ready (Section 4 below).

3. Account access modes

Two access modes exist for partner accounts:

• Standard account — both mainnets and testnets are enabled. You build against the testnet, then provision a mainnet application when you're ready to go live.
• Trial account — testnets only. Useful during a paid evaluation phase before a contract is signed. Upgrading to a standard account unlocks the mainnets without re-provisioning the testnet applications you already have.

The Admin Console reflects which networks your account can pick from when creating a new application.

4. The promotion is per-application, not a flag flip

network is set at application creation and is immutable. Going from testnet to mainnet means:

1. Provision a fresh Keyban application with the mainnet identifier of the target family.
2. Re-issue API keys for the new application.
3. Re-create the catalogue (DPP), the reward tiers (Loyalty), or whatever business artefact your testnet was carrying — testnet data does not flow to mainnet.
4. Switch your client code's applicationId (or feature-flag the cutover).
5. Disconnect or archive the old testnet application once verified.

This is by design: testnet artefacts are throwaway, mainnet artefacts are permanent. Treat the two applications as completely separate.

Plan the cutover deliberately

Customers who scanned a testnet DPP QR code or who hold a testnet loyalty pass will not see mainnet data when you flip the storefront. Coordinate the storefront cutover, the email-template URLs, and the buyer communication accordingly.

5. What doesn't carry over

Going from testnet to mainnet means re-creating, not migrating:

• Passports (DPP) — the id, tokenId, IPFS CID and on-chain certification of a passport are testnet-specific and have no mainnet equivalent.
• Loyalty accounts and balances — minted on a different chain.
• Apple/Google Wallet pass URLs — bound to the testnet account and its testnet chain. Buyers will need a fresh install URL.
• Wallet addresses — TSS shares are bound to the application; new application = new wallet derivation.

Partner-side artefacts do carry over because they're not chain-bound:

• Webhook receivers and HTTP clients (you only swap the applicationId and the API key).
• Brand assets (loyaltySettings.appleWallet/googleWallet URLs in the application config) — re-attach them to the new application.
• The Admin Console layout and your members' roles.

Reference

Product	Ledger family	Mainnet identifier	Testnet identifier
DPP	Starknet	StarknetMainnet	StarknetSepolia
Loyalty	Stellar	StellarMainnet	StellarTestnet
Embedded Wallet	Base (EVM)	— (testnet only today)	BaseSepolia

The human catalogue lives in Supported Blockchains and the SDK type alias in /api/sdk-base/TypeAlias.Network.

Related

• PHP integration — Create a passport — uses StarknetSepolia in its examples.
• Tutorial — Automate Loyalty via API — Stellar by default.
• Permissions — API key permissions — issue a separate key per application (one per environment).
• Concepts — Certification & Trust Chain — what the on-chain commit guarantees.