Non-custodial Wrapping
Custodial wrapping solutions require a trusted custodian to coordinate actions between the chains (e.g., minting wrapped tokens or releasing reserve tokens). In these situations, the custodian serves two roles. First, it relays messages between chains. Second, it serves as the sole source of truth as to the state of the other chain, i.e., if the custodian authorizes the minting of wrapped assets, those assets will be minted regardless of whether reserves were deposited.
Although blockchains cannot communicate directly with each other, in some situations, the custodian can be replaced by an untrusted relayer, whose sole job is to pass messages between the chains. This is non-custodial wrapping.
The core idea of non-custodial token wrapping is that each chain runs the other chain "light-client" directly on-chain. In other words, if it is possible to generate succinct “state proofs” that encode the current state of the source chain, and an efficient verifier (that can run inside a contract on the destination chain), an untrusted relayer can “prove” that an action happened on the source chain, and this action can be verified by a contract on the destination chain.
Suppose an on-chain contract can validate transactions for the other. In that case, an untrusted relayer can simply forward the state of the source chain to the verifier contract on the destination chain, where it can be verified. In this case, both the reserve contract on the source chain and the wrapped token contract on the destination chain can be keyless, eliminating the need for a custodian to safeguard the keys. This type of non-custodial wrapping is only possible when the source chain has a light client that is simple enough to be executed within a smart contract on the destination chain. The inter-blockchain communication (IBC) protocol allows Cosmos-based blockchains to interact in this way¹.
Almost all blockchains built using the Cosmos SDK can wrap tokens this way, including several large-market-cap chains such as the Cosmos Hub, crypto.org, Thorchain, Axelar, the Secret Network, Binance Chain, and many others².
In addition to the IBC-enabled chains, several other layer-1 blockchains have been built to enable efficient light clients, e.g., Mina³ and Algorand⁴.
It is possible to build light clients for existing blockchains (e.g., Bitcoin), but this is an extremely challenging task and typically requires a complete redesign for each supported blockchain. The job of a light client on the destination chain is to verify that a given transaction occurred on the source chain. This task would be easy if the light client had access to block headers from the source chain. Users could issue simple Merkle Proofs that a given state balance was consistent with the (known) block header. LayerZero uses this technique to provide cross-chain interoperability and trusted Chainlink oracles push block headers onto the chain⁵. Once these block headers are stored on the destination chain (untrusted), users can easily prove that deposits occurred on the source chain. This solution is efficient but crucially relies on the honesty of the oracles providing the block headers. Malicious oracles could provide invalid block headers, allowing them to certify non-existent deposits and make real withdrawals.
¹https://ibcprotocol.org/
²https://cosmos.network/ecosystem/tokens/
³Joseph Bonneau, Izaak Meckler, Vanishree Rao, and Evan Shapiro. Mina: Decentralized cryptocurrency at scale. Technical report, O(1) labs, 2020. ⁴Noah Grossman. Algorand state proofs.https://medium.com/algorand/algorand-state-proofs-707d64038e35, 2022.
⁵Ryan Zarick, Bryan Pellegrino, and Caleb Banister. Layerzero: Trustless omnichain interoperability protocol. LayerZero:TrustlessOmnichainInteroperabilityProtocol, 2021.
Last updated