Cross-chain custody is the safekeeping of keys and assets for a position that exists on more than one blockchain. Custody answers who can move an asset. Verification answers whether a movement between chains was real.
This page explains what changes when an asset spans chains, how keys are managed across networks, and how custody and verification divide. To scope custody and verification for an asset, reach out to our team.
What is cross-chain custody?
Cross-chain custody is custody of a single position whose balances sit on several chains, each with its own address format, signing scheme, and transaction model. The custodian holds the keys that authorize movement on every chain where the position exists.
The unit of custody shifts. On one chain, custody covers a key and the balances it controls, while across chains it covers a set of keys, the mapping between them, and the authority to initiate a transfer from one chain to another. That last item is the part single-chain custody models do not address.
What changes when an asset spans chains
Four things, and each is an operational control rather than a technical detail.
- Key count. A position on eight chains involves signing authority on eight chains, and different networks use different signature schemes.
- Initiation authority. Moving supply between chains is a privileged action distinct from transferring on one chain, so who may initiate it needs its own approval path.
- Reconciliation. Total holdings are the sum across chains, and the sum is only meaningful if the balances are the same asset rather than separate representations.
- Recovery. A stalled cross-chain transfer leaves a position mid-flight, so the custodian needs to know which stage it stalled at and who can resolve it.
Reconciliation is where custody and asset design meet. If each chain holds a different bridged copy, the custodian holds several instruments with several counterparties rather than one position, so a canonical cross-chain token standard is what allows a single reconciled figure.
How keys are managed across chains
Four models are in common use, and they differ in where signing authority sits. The last column is a general characterisation rather than custody advice.
| Model | Where keys sit | Cross-chain implication | Suits |
|---|---|---|---|
| Self-custody, single signer | With the asset owner | One party manages every chain's keys | Small operations, low approval overhead |
| Multi-party computation | Split across shares, no whole key exists | One policy engine can cover several signing schemes | Institutions needing scheme coverage |
| Qualified custodian | With a regulated third party | The custodian must support each chain the asset reaches | Regulated holders with custody mandates |
| Multisig contract | Onchain, per chain | Configured separately on every chain | Treasury and protocol-owned positions |
The constraint in the third row is the practical one. A qualified custodian supports each chain individually, so an issuer expanding to a new network confirms custody coverage before the expansion rather than after, and an onchain multisig carries a related cost because every new chain adds a signer set to maintain.
Institutional custody platforms already support assets built on canonical standards. Fireblocks pairs MPC-based custody with a policy engine and compliance workflows, so approvals and transaction monitoring sit alongside the keys rather than in a separate system.
How custody and verification divide
Custody controls who may initiate a movement. Verification controls whether a movement that claims to have happened on another chain is accepted, and compromising one does not grant the other.
This division lets an institution hold keys with a custodian while retaining control of the verification behind its asset. Under LayerZero's security stack model, verification is configured by the application per pathway: required verifiers that must attest to every message, an optional set, and a threshold of that set. The custodian signs the outbound transaction, the verifiers attest that it occurred, and neither substitutes for the other.
Both controls can also sit with the same institution without merging into one. An institution can operate its own verifier alongside its custody arrangement, making its own infrastructure a required signer on every movement of its asset. It is then the party that authorizes a movement and one of the parties attesting that the movement occurred, which is the issuer-controlled posture without taking custody of anyone else's assets.
What an institution has to control
Five items, and they map to what a reviewer asks for.
- Named key holders per chain, and the approval path for a cross-chain initiation.
- A single reconciled position across every chain where supply sits.
- The verification configuration for each pathway, evidenced as what is active rather than what is default.
- A per-transfer record linking the source transaction, the verifiers that signed the message, and the destination transaction.
- A defined recovery path for a stalled transfer, including who is authorized to resolve it.
The third item has a detail worth checking. Default configurations are placeholders, so an institution sets verification explicitly rather than inheriting a default, and evidences the active configuration rather than the one it intended.
FAQ
How do custody solutions work with cross-chain protocols?
The custodian holds the keys and signs the outbound transaction on the source chain. The protocol verifies that the transaction occurred and delivers the instruction to the destination, so custody and verification are separate steps with separate parties.
Does an institution need a separate custodian per chain?
Not necessarily, but the custodian must support each chain individually, so coverage should be confirmed before expanding an asset to a new network.
Can an institution keep custody while a third party verifies transfers?
Yes, and it can also require its own infrastructure among the verifiers. Verification is configured per pathway by the application, so third-party verifiers and one the institution runs itself can be combined.
What happens to a custodied position if a cross-chain transfer stalls?
The position is mid-flight rather than lost. The transfer is waiting on a specific stage, and Endpoint-level recovery can resolve a nonce that cannot proceed normally.
How is a cross-chain position reconciled for reporting?
By summing balances across chains where the asset is canonical, and by tracing individual transfers from source to destination, including which verifiers signed each one. Both depend on the asset being one instrument rather than several bridged copies.
Scope custody and verification for your asset
Custody and verification are separate controls, and an institution can own both. What varies is which chains the custodian covers, which verifiers are required per pathway, and whether the institution runs one itself.
To work through both for a specific asset, reach out to our team, or start at Developers.