TL;DR
If you resell wallet infrastructure to business clients — exchanges, PSPs, stablecoin fintechs — you need a shape that most wallet providers do not ship: tenants that are genuinely isolated from each other, and from you. This is a requirements checklist, not a product tour. The load-bearing requirement is key isolation: many platforms sold as multi-tenant share signing material down the hierarchy, which makes the parent account a single point of failure for every tenant's funds. The other four are tenant-scoped administration, programmatic deposit address issuance, rule-based sweeping, and policy-bounded withdrawals. Each has a question that separates a real implementation from a relabelled one.
Most wallet infrastructure is sold one layer too shallow. The standard pitch — embed wallets in your app, brand them, ship in days — assumes your users are people. For a growing class of companies, the users are companies.
You are a white-label provider. Your clients are crypto exchanges, payment service providers, stablecoin fintechs. Each needs wallets for their users. You need to give each of them an isolated environment, under your brand, without becoming the operations team for all of them.
That shape is multi-tenant wallet infrastructure, and very little of what is marketed under that name actually implements it. This is a requirements checklist: five things the architecture has to do, and for each, the question that separates a real implementation from a relabelled one.
The three tiers
An embedded wallet has two tiers: your app, and your users. A multi-tenant platform has three.
| Tier | Who | What they need |
|---|---|---|
| Platform | You — the white-label provider | Provision tenants, aggregate visibility, one commercial relationship with the provider underneath |
| Tenant | Your business client (exchange, PSP, fintech) | Own administration, own credentials, own key material, own policies, own gas budget, no visibility into other tenants |
| End user | The tenant's retail customers | Deposit addresses, balances, withdrawals — usually never sees a dashboard |
The tier that gets neglected is the middle one. Providers build for tier one and tier three, then give the tenant either full access to everything or no self-service at all. The first is a security problem; the second turns you into a ticket queue.
Requirement 1: key isolation
This is the load-bearing requirement, and the one most often missing, so it goes first.
A great many platforms sold as multi-tenant are built on a parent-and-child project hierarchy that shares signing material down the tree. The parent holds a wallet secret; every child inherits it. The account tree looks like multi-tenancy. The isolation is not there.
That design is not an oversight — it is the correct design for a different product. Cross-app wallets, sometimes sold as ecosystem or global wallets, exist so that one end user carries one wallet across many applications. Shared key material between those apps is the entire point. When a provider extends the same hierarchy to serve business clients, the sharing comes along with it.
The consequences are concrete:
- Blast radius. A compromise of the parent account reaches every tenant's funds. Tenants have no cryptographic protection from each other, only administrative separation.
- Custody perimeter. If you can construct a valid signature over a tenant's wallet, you are inside the custody perimeter, whatever the contract says. That determines who needs a licence.
- Legal reachability. A subpoena, a court order, or an insolvency proceeding against the platform reaches keys the platform can technically use.
The question to ask, in these words: "Can the parent account produce a valid signature over a child tenant's wallet?" Not "are tenants isolated" — every provider says yes to that. The signature question has one true answer and no comfortable way to dodge it.
Both models are legitimate. A platform offering managed operations needs enough access to operate, and shared material makes that straightforward. A platform selling to regulated exchanges usually needs the opposite. What is not acceptable is not knowing which one you bought.
Requirement 2: tenant-scoped administration
Each tenant needs its own environment — ideally on your domain, with your branding — where it administers itself.
Scoped to the tenant:
- Team membership and roles. An invitation lands the member inside one tenant. They do not see the tenant list, the other tenants, or platform-level analytics.
- API credentials. Separate publishable and secret keys, so the tenant's engineers work without routing through you.
- Policies and governance. Spending limits, allowlists, approval thresholds — authored by the tenant, for the tenant.
- Gas budgets. Each tenant funds and spends its own, with its own consumption report. Shared gas budgets create a denial-of-service vector between tenants.
- Authentication and funding configuration. If end users log in or on-ramp, the tenant picks its own methods and rails.
Retained by the platform: tenant provisioning, aggregate analytics, billing, and the relationship with the provider underneath.
The question: "Is an invitation scoped to a tenant, or to the account?" Providers that bolted tenancy on late usually have account-global membership with a filter applied in the UI.
Requirement 3: programmatic deposit address issuance
Tenants create addresses through an API and hand them to their retail customers at signup. Two properties matter.
Volume. An exchange with a hundred thousand users needs at least that many addresses, often several per user — one per chain, sometimes one per asset. Per-wallet pricing or provisioning ceilings get hit almost immediately. Confirm creation is unlimited and is a single API call, not a workflow.
Many addresses under one identity. The retail user is one customer of the exchange holding several deposit addresses across chains. The data model has to express that — one user identifier, many wallets beneath it. If wallets are modelled as flat and unrelated, the tenant rebuilds that mapping in its own database and owns reconciliation forever.
The question: "Can one user identity own many wallets across chains, natively?"
Requirement 4: rule-based sweeping
Deposits land on thousands of addresses. They need to end up in one.
Sweeping sounds like a checkbox and is where most of the operational engineering lives:
- Trigger rules. Threshold-based, scheduled, or asset-specific — authored by the tenant, not by you.
- Gas economics. Every sweep is a transaction. Sweeping a $3 stablecoin deposit where the fee is $2 destroys value. Thresholds exist for this reason, and the right threshold is chain-dependent.
- Native gas on token-only addresses. An address that has only ever received USDT has nothing to pay a fee with. Either the sweeper funds each address first — another transaction, more gas — or the chain supports fee abstraction and someone sponsors it.
- Idempotency and reorg awareness. A sweep fired twice on one balance, or fired on a deposit that later reorgs out, is a reconciliation incident. This logic must be confirmation-aware.
Be realistic about what infrastructure provides here. Sweeping is usually a pattern you compose — server-side wallets, a balance watcher, policy rules — rather than a managed feature. What to require underneath: programmatic wallets, reliable webhooks on incoming transfers, batched transactions, and per-tenant gas sponsorship.
The question: "What are the delivery guarantees on transfer webhooks?" At-least-once with replay is workable. Best-effort is not.
Requirement 5: policy-bounded withdrawals
The reverse leg, and the highest-risk automated path in the system. A tenant funds a hot wallet from its vault; when a retail user requests a withdrawal, the tenant's backend signs and broadcasts a payout.
Requirements:
- Per-transaction and per-period caps
- Destination allowlists or screening
- Approval thresholds above a value, with a human in the loop
- Rate limits per end user and in aggregate
- An audit trail recording what was approved, by which rule, when
The critical property is where the policy is evaluated. Policies enforced by the infrastructure before signing are the difference between a leaked tenant API key costing one transaction and costing the hot wallet. Policies enforced in the tenant's application code are documentation.
The question: "Are policies evaluated server-side before signing, or client-side before the request?"
The exit path
A tenant is putting its balance sheet on infrastructure it reaches through you — a company that in turn reaches it through a provider the tenant never signed with. The disaster-recovery question is reasonable and should be settled first.
A defensible exit has three parts:
- Key export by the tenant, using the tenant's own credentials.
- Recombination outside the platform — those shares reconstruct a working signing key in infrastructure the tenant controls, without the platform participating.
- No on-chain migration. Addresses keep working, funds do not move. For smart-account wallets, owner rotation gives the same continuity without touching balances.
The test: if the exit requires the provider to still be operational and cooperative, it is not an exit path. Ask for the runbook, not the contract clause.
Note the coupling with Requirement 1 — a tenant cannot meaningfully export key material it never exclusively held.
Chain coverage is the usual blocker
More of these deals stall on chains than on any requirement above.
EVM chains and Solana cover most stablecoin payment flows and most fintech tenants. Exchange-facing platforms routinely need more: Tron, which carries an enormous share of USDT settlement in emerging markets; Bitcoin; and Stellar for remittance corridors. These are not EVM chains with different IDs — different account models, different fee mechanics, different signing schemes.
Ask about two levels separately, because providers frequently have the first without the second:
- Key and address support — the provider can generate and sign for addresses on that chain
- Gas abstraction — the provider can sponsor or abstract fees there
Most tenants need both. Realistic timelines run one to two months of engineering per chain, usually priced as a one-time integration fee. Put the chain list in the first conversation; discovering in month two that your largest tenant settles USDT on Tron is an expensive way to learn this.
The checklist
Fourteen questions to put to any provider before signing a multi-tenant deal.
Isolation
- Can the parent account produce a valid signature over a child tenant's wallet?
- Is key material generated per tenant, or inherited down the hierarchy?
- Can a tenant export its key shares and operate them elsewhere without your cooperation?
Administration 4. Is a team invitation scoped to a tenant, or to the account? 5. Does each tenant get its own API credentials? 6. Can a tenant configure its own policies, gas budget, authentication and funding rails unaided? 7. Can tenant environments carry our domain and branding? 8. What does the platform tier see — aggregates, or every tenant's transactions?
Operations 9. Is wallet creation unlimited, and is it one API call? 10. Can one end-user identity own many wallets across chains? 11. What are the delivery guarantees on transfer webhooks? 12. Are policies evaluated server-side before signing?
Coverage and commercials 13. Which chains have key support, and which have gas abstraction? 14. How is billing structured — per tenant, per wallet, or per operation?
A provider that answers all fourteen cleanly is rare. A provider that answers question 1 with a straight yes or no, rather than a paragraph, is telling you something useful either way.
Where this leaves most evaluations
The honest state of the market: cross-app wallet infrastructure is mature and widely available. Genuine multi-tenant wallet infrastructure — with per-tenant key material, not just per-tenant administration — is much rarer, and several vendors will describe the former using the language of the latter.
That is not always disqualifying. If you are offering managed operations and your tenants expect you to hold the keys, a shared-material hierarchy may be exactly right, and it is simpler to run. The failure mode is architectural surprise: building a compliance story, a security model, and a set of tenant contracts on an isolation guarantee that turns out to be administrative rather than cryptographic.
Ask question 1 first. Everything else is easier to change later.
If you are scoping this for a platform with named tenants and a specific chain list, get in touch — the chain question in particular is worth settling before anything else.
