Who Holds the Keys? Custody Models for Tokenised Assets

Custody diligence for tokenised assets usually starts and ends with key management — which vault, which ceremony, which insurance policy. That is necessary and it is not sufficient, because for most regulated tokens the key is not the only thing that controls the asset. Miss the second control point and you have diligenced half the risk.

What is actually being held

With a bearer crypto-asset, the private key is effectively the asset: whoever can sign can move it, and nobody can reverse that. Custody is therefore key custody, and the entire discipline follows from that one fact.

Tokenised regulated assets are different in a way that matters enormously and is routinely missed. A permissioned token — an ERC-3643 share class, for instance — carries administrative powers held by the issuer or its agent: the ability to freeze a balance, to force a transfer, and to reissue a holder's position to a new address when keys are lost.

That is a feature, not a flaw. It is what makes lost keys survivable and court orders executable. But it means control over the asset is split across two parties:

The four models

1. Self-custody

You generate and hold the keys. Maximum control, maximum responsibility: key ceremonies, hardware, segregation of duties, disaster recovery, insider-threat controls, and an audit trail that will withstand examination. Viable for institutions that already run this class of control environment. For most asset managers and issuers it means building a capability that is not their business, and — depending on regime and client type — may not satisfy the obligation to place client assets with an authorised custodian.

2. Third-party custodian

A regulated custodian holds keys under a contract, with defined segregation, controls attestations and insurance. This is the default for regulated products, for good reasons: it is the model supervisors understand, it moves operational risk to a specialist, and it produces the reporting your auditors expect.

What you are really buying is a legal position, not a wallet — which is why the diligence questions below matter more than the technology questions.

3. Delegated or sub-custody

Your custodian uses a specialist for some assets or chains. Common and workable, but it lengthens the chain of control and you need to know where your assets actually sit, how sub-custodian failure is handled, and whether segregation survives at each hop. Ask for the chain in writing; do not infer it.

4. Registry-based control

For some tokenised structures the authoritative record of entitlement sits with the issuer or transfer agent, and the token is the operating layer. Here "custody" is partly a registry function: even if a holder's keys are lost, entitlement is not, because it can be reissued against the register. This is the most robust model against key loss and the most dependent on issuer governance — you have swapped cryptographic risk for institutional risk, which for many institutions is the better trade, provided it is a deliberate one.

MPC, HSMs and multisig solve different problems

These get compared as if they were competitors. They protect against different failures.

• Hardware security modules keep key material inside tamper-resistant hardware, so extraction is the hard part. They do not stop an authorised operator from signing something they should not.
• Multi-party computation splits a key into shares held by separate parties, so no single location ever holds the whole key and signing requires a threshold. It removes the single point of compromise and — done properly — the single point of authority.
• On-chain multisig puts the quorum in the contract, so the policy is publicly verifiable and enforced by the chain rather than by a vendor's software. It is more transparent and less flexible, and it is visible to observers.

Most custody incidents are not cryptographic failures. They are governance failures wearing cryptographic clothing.

The question that discriminates between good and bad setups is not which technology, but: what is the smallest set of people who, acting together, can move assets — and does that set include anyone who can also approve their own request? If the quorum is four but all four report to the same person and use the same device management, the effective quorum is closer to one.

Every additional chain multiplies the problem

Custody scope is usually discussed per asset. It should be discussed per chain, because a custodian's support is chain-specific and the differences are not cosmetic.

• Signature schemes differ. A custodian's key infrastructure supports particular curves and signing algorithms. Support for one chain says nothing about another.
• Transaction construction differs. Account-based and output-based chains, fee mechanics, nonce handling and replay protection all vary, and each needs building and testing.
• Recovery differs. A permissioned token with agent recovery on one chain and a bearer asset on another have completely different loss profiles held in the same account.
• Reporting differs. Your statement must reconcile across chains with different finality characteristics and different notions of a pending transaction.

The practical consequence: confirm chain-level support in writing before committing to a deployment, and treat "we support EVM chains" as a claim to test rather than a specification. Adding a chain after launch is a custody project, not a configuration change.

The diligence that actually matters

Technology questions are easy to ask and rarely decisive. These are the ones that determine your outcome on a bad day:

• Segregation. Are client assets held in segregated addresses or an omnibus structure? If omnibus, what evidences your entitlement, and how quickly can it be produced?
• Insolvency. If the custodian fails, are your assets client property outside the estate, or a claim against it? This is a legal opinion, jurisdiction by jurisdiction, and you should read it rather than be told about it.
• Insurance. What is the actual policy — crime, specie, cold-storage only? What is the per-incident limit against total assets held, and what is explicitly excluded? Aggregate cover across all clients is not cover for you.
• Authorisation policy. Who can instruct a transfer, through what channel, with what verification? Most real losses arrive as a validly signed transaction that should never have been requested.
• Proof of control. Can the custodian demonstrate control of the addresses holding your assets, on demand, in a way your auditor accepts?
• Exit. How do you get assets out, how long does it take, and what happens if the relationship ends badly?
• Agent keys. For permissioned tokens: who holds them, what authorises their use, and how is that logged? Put it in the issuance documentation.

Assessing a custody arrangement? SUPERBLOCK's platform is built for multi-provider custody rather than a single embedded wallet, precisely because the right answer differs by asset, client and jurisdiction. To walk through the options for a structure, see our work with custodians — including the multi-provider model described above — or request a demo.