Custody Options
“Where do the private keys live?” is the single most important question for any enterprise integrating crypto. KryptoGO supports four custody models. This page explains each one in plain language and tells you which one to pick.
Crypto custody, in one paragraph
A private key is the password that controls a crypto wallet — whoever holds it controls the funds. Custody is the question of who holds that key. There is no single right answer: each model trades off recovery story, regulatory burden, end-user experience, and partner liability differently. Your choice should be driven by who your end users are, what kind of business you operate, and what your regulator expects.
The four models we support
| Model | Who holds the key | If a user loses access, recovery comes from… | Best for | KryptoGO status |
|---|---|---|---|---|
| Custodial (Asset Pro) | KryptoGO, encrypted in a hardware-security-managed key vault | A multi-signature workflow inside the partner organisation (Maker → Approver → Signer) restores access. KryptoGO does not unilaterally move funds. | Enterprise treasury, neobank backend, merchant payout pools, regulated payment service providers | Shipped, in production |
| Embedded self-custody (Mobile SDK) | Split into three shares: one on the user’s device, one in the partner’s cloud, one in KryptoGO’s cloud. Any two of three reconstruct the key. | The end user signs back in to the partner app; the device share plus the cloud share rebuild the wallet without anyone ever holding the full key. | Consumer fintech apps embedding crypto into an existing user base — for example, a popular payment app adding crypto receive/send for its existing logged-in users | Shipped, in production |
| External / user-owned | The end user, in their own wallet (MetaMask, Phantom, Ledger, etc.) | The user’s own seed-phrase backup — KryptoGO and the partner have no role here. | Crypto-native audiences; situations where the partner explicitly does not want to take on key-management responsibility | Shipped, via WalletConnect and SDK connectors |
| Hardware-assisted (TronLink today, additional hardware on roadmap) | A hardware wallet device, paired through the partner’s UI when high-value operations are signed | The hardware-device seed phrase | High-value treasury sign-off where an operator wants a physical second factor on every approval | Partial — TronLink integrated for Tron-network treasury operations |
How embedded self-custody actually works
This is the model most people get wrong, so it deserves a closer look. When a partner integrates our Mobile SDK, here is what happens the first time an end user opens the wallet inside the partner app:
- The partner app authenticates the user with whatever existing login they already have (email, phone, social, biometric — the partner’s own auth, not ours).
- The partner app passes a signed JSON Web Token to the SDK identifying that user.
- The SDK exchanges the token with KryptoGO’s auth backend, which verifies the signature against a public key the partner has published.
- The SDK generates a fresh wallet seed inside the user’s device, immediately splits it into three shares using a cryptographic technique called Shamir’s Secret Sharing, and distributes the shares: one to the partner’s storage, one to KryptoGO’s cloud, one to the device’s secure-storage system (iOS Keychain or Android Keystore).
- From that moment on, no single party — not the user’s device alone, not KryptoGO alone, not the partner alone — can reconstruct the key. Recovery requires any two of the three shares.
This means: KryptoGO cannot unilaterally move user funds. The partner cannot unilaterally move user funds. A lost device can be recovered as long as the user can sign in on a new device. A compromised cloud account does not, by itself, expose any funds.
Each end user gets their own wallet, derived deterministically from their partner-side user ID. The same user signing in on a new device returns to the same wallet.
Decision tree
A short version for a non-crypto reader:
- “My users are not crypto-savvy and I want them to never have to think about wallets.” → Embedded self-custody via Mobile SDK. The wallet is provisioned silently the first time the user touches a crypto feature.
- “I am a regulated business operating treasury or payouts on behalf of users.” → Custodial (Asset Pro). The multi-signature workflow gives finance and compliance teams the controls they need.
- “My users are already crypto natives and bring their own wallets.” → External. Use our Payment SDK to accept payments from any wallet the user prefers.
- “I need a physical second factor on every high-value treasury sign-off.” → Hardware-assisted, alongside Custodial. Talk to us — coverage of hardware vendors is expanding.
Most real-world deployments combine more than one. A consumer fintech might use embedded self-custody for its end users and custodial Asset Pro for its merchant treasury. A regulated payment service provider might use custodial Asset Pro for the treasury and accept inbound payments from external user-owned wallets.
What this means for your partner liability
| Model | Partner’s exposure to key loss | Partner’s regulatory custody burden |
|---|---|---|
| Custodial (Asset Pro) | None for the keys themselves; partner is responsible for operator hygiene (who has Approver / Signer roles) | Lower — the regulated custody entity is KryptoGO, operating under a Taiwan VASP licence |
| Embedded self-custody | Limited — partner holds one share of three; cannot move funds alone | Lower — partner does not legally hold custody of user assets in the traditional sense, since no single party can spend |
| External | None — the user holds their own keys | None — partner never touches user funds |
| Hardware-assisted | The hardware device must be physically secured by the operator | Same as Custodial |
Your legal counsel should validate the model you choose against your specific regulatory regime. We can supply ISMS documentation, the Cure53 audit summary, and our SOC 2 Type II report on request.
Where to go next
- See White-Label Wallet for the use-case page that uses every custody model in this list.
- See Solutions: Consumer Fintech Bolt-On for a worked example of embedded self-custody at scale.
- See Compliance & Certifications for the regulatory framework that backs all four models.