Every bridge into Canton has to answer a question: 'how do we know the assets are actually locked on the source chain before minting the wrapped version on Canton?' That answer is the attestation method. Different bridges use different methods, and the method determines who has to fail for your money to disappear.
This article walks through three common attestation families (threshold signatures, oracle networks, issuer-direct), their trust assumptions, their failure modes, and how to read a bridge's attestation before sending size through it.
01Threshold Signatures (FROST and friends)
A committee of N signers each holds a share of one signing key. To authorize a mint or a release, at least M of the N must sign, and their partial signatures combine into a single signature that the chain or contract checks. The full key is never rebuilt in one place to sign. FROST, a threshold Schnorr signing protocol published as RFC 9591, is one such scheme.
Used by: BitSafe's CBTC on Canton. BitSafe's documentation says the Bitcoin behind CBTC is held through FROST threshold signing across independent Attestor Network operators, and that the threshold is configurable and the operator set can change.
Failure mode: enough signers (M or more) collude or are compromised. With M = 7 of 10, you need 7 independent compromises before the bridge fails, and if 4 of the 10 stop signing, transfers stop until enough of them return. The signer set's composition matters: a 10-signer committee drawn from one organization is less robust than one spread across independent organizations and jurisdictions.
Strength: no single point of failure for compromise of any one signer. The math forces collusion or large-scale compromise.
Weakness: committee selection is everything. A poorly-distributed committee defeats the math.
02Oracle Networks (Chainlink CCIP, LayerZero)
A separate network of operators watches the source chain and reports what happened to the destination, which mints based on that report. The network has its own operators and its own rules for who has to agree.
Used by: Chainlink CCIP, which by default relies on a Chainlink decentralized oracle network, and LayerZero, where each application chooses the verifier networks (DVNs) that must confirm its messages.
Failure mode: the network is compromised, or it attests a deposit before the source chain has finalized it. If the source chain then reorganizes, the wrapped asset exists without its backing. The same risk applies to every family, and the defense is to wait for finality before attesting: the Canton Foundation's steps for moving USDC into Canton through xReserve include waiting about 15 minutes for Ethereum finality.
Strength: leverages an existing security set; works across any pair of chains the oracle covers.
Weakness: external trust assumption that's bigger than the bridge itself. You're trusting the oracle network, not just the bridge.
03Issuer-Direct (Circle xReserve)
The asset's own issuer attests the deposit or burn, and the destination mints only against that attestation. Trust collapses to the issuer.
Used by: Circle's xReserve, the route behind USDCx on Canton. USDC is locked in a Circle xReserve contract on Ethereum, and USDCx represents it on Canton (Digital Asset docs). The xReserve attestation service signs the deposit, and the token contract on Canton checks that signature before it mints USDCx. On the way out, a Canton-side attestation service signs the burn of USDCx, and xReserve verifies it before the USDC is released.
Failure mode: issuer risk. If the issuer is compromised, frozen, or insolvent, the bridge is too. Issuer-attested bridges are exactly as safe as the issuer behind them, no more.
Strength: simplest trust model, aligned incentives (issuer is the canonical authority on their own asset).
Weakness: single-point-of-failure if you don't already trust the issuer. Holding USDCx already means trusting Circle for the USDC behind it, so this route leans on a party you already trust. For an asset whose issuer you don't trust, the same design concentrates the risk in one party.
04Picking the Right Method for the Job
There is no universally-best attestation method. The right pick depends on what's being bridged and who you trust:
For USDC: issuer attestation, which on Canton means Circle's xReserve for USDCx. The issuer is canonical; a committee would add a second party to trust without removing the need to trust Circle.
For an asset with no issuer, such as BTC: threshold signatures, judged by who holds the key shares. That is the model BitSafe describes for CBTC.
For apps that pass messages across many chains: oracle networks (Chainlink CCIP, LayerZero), which standardize those messages.
For large transfers: splitting a transfer across two routes with different attestation methods means one failure cannot reach the whole amount. The cost is paying fees twice and holding two wrapped tokens that may not be interchangeable.
05How to Read a Bridge Before Using It
Before sending size through a bridge, three questions:
What's the attestation method? It should be documented prominently. If it's not, that's a red flag.
Who's on the committee (if threshold) or who runs the oracle (if CCIP-style)? The committee/operator list should be public. Look for diversity (different jurisdictions, different organizations) not just headcount.
What's the failure history? Look for published audits, past exploits and any upgrades made after them. Search the bridge's name + 'exploit' + 'audit' before sending. Recent successful exploits without a transparent post-mortem are a warning sign.
CCTools' bridges page lists the routes into Canton we track, with the asset and the attestation method for each. The list is curated by hand, so check each method against the operator's own documentation before relying on it.