The rule that moves a bridged asset is the bridge contract's quorum check, and it is public. You can look at the lock contract on the origin chain, the mint contract on the destination chain, and the list of signer addresses that must agree before either one changes state. The custody is the contract; the multisig is the condition it requires.
How a multisig move runs
A move runs through three steps: lock, quorum signature, and mint. The bridge contract on the origin chain locks your tokens — say, USDC on the source network. A set of signers, commonly 5-of-8 or 3-of-5, signs a message that names the recipient, the amount, the destination chain, and a nonce. A relayer submits that bundle to the destination contract, which verifies the quorum and mints the bridged representation. The return trip reverses it: burn on the destination, and the source contract verifies the burn proof against its own quorum rule, then releases the original token. What you end up with is a representation of your asset on another network; the original stays locked until the return trip.
The common explanation gets the trust direction wrong
The common explanation says a multisig bridge is safe when enough signer keys are spread around and unsafe when they are not. That is true, but secondary. What decides it is what the contract enforces around the quorum. If the mint contract accepts a signature without checking that the message came from the bridge's own verifier, no number of signers saves you. If the lock contract releases funds without verifying the burn proof, the quorum is a formality. The signers authorize; the contract executes.
This is also the point where discussions about bridges split. One side says more signers means more security; the other says key distribution matters more. You can settle it with what is checkable: the quorum threshold, the signer list, and the bytecode guarding the mint and unlock functions. A 3-of-5 with signers in separate jurisdictions running isolated hardware will move funds more soundly than a 9-of-12 whose keys sit behind one API. Quorum size decides coordination cost; the contract's guard logic decides custody strength. You can read both for a given bridge: Paraswap.
Where multisig custody does not apply
Not every bridge uses a quorum. Light-client bridges verify execution headers on-chain and authorize movement by proof, with no signer set at all. Atomic swaps use hashed timelock contracts, where the asset moves only if a preimage is revealed before a deadline. Intent-based systems hand the movement to solvers who compete to fulfill it. In those cases there is no multisig to read, and the trust model is a different question: a proof to verify instead of a quorum to watch.
The custody mechanism is what you are actually choosing when you route a swap across chains. On the destination, the bridged asset becomes usable in the venues you already know — an order on 0x Protocol, a pool on Uniswap Protocol, a position on Optimism Network — but the movement that put it there was either a multisig-gated contract action or one of the alternatives above. That difference is the thing to check before you move funds.
Top comments (0)