Specialist engagement · From $15,000 · 4–8 weeks
Bridge & Cross-Chain Security Audit
Bridges hold the largest single-exploit losses in this industry, and almost none of them lost money to a bug in a token contract. They lost it at the verification boundary — a forged proof, a replayed message, a compromised signer set, or an assumption about finality that did not hold.
A bridge is not one system. It is two or more chains, a set of contracts on each, an off-chain relay layer, and a trust model that ties them together. Auditing only the Solidity is auditing a third of the attack surface.
We start at the boundary: what exactly does the destination chain believe, why does it believe it, and what would it take to make it believe something false? Every bridge answers this differently — light clients, optimistic windows, multisig attestation, ZK proofs — and each answer has its own failure geometry.
Then we work outward: replay across chains and across epochs, reorgs on the source chain, message ordering, liquidity accounting on both sides, upgradeability of the verifier, and what happens when one chain halts while the other keeps running. The last one has broken more bridges than any cryptographic flaw.
Scope of review
What we look at, and what we're looking for.
Message verification
The proof or attestation path in full: what is signed, what is checked, what is assumed. Signature malleability, domain separation, chain-ID binding and nonce handling.
Replay & reorg protection
Cross-chain and cross-epoch replay, message uniqueness, and behaviour when a source-chain block containing a burn is reorganised after the mint has already executed.
Relayer & validator trust
Who can submit, who can censor, what a threshold of compromised signers achieves, key rotation safety, and the liveness assumptions the design depends on.
Finality assumptions
Confirmation depths per chain, probabilistic vs deterministic finality, and what the contract does when a chain it depends on halts, forks or reverts.
Liquidity & accounting
Mint-and-burn vs lock-and-release invariants, supply reconciliation across chains, and whether a failure on one side can leave the other permanently unbalanced.
Off-chain components
Relayer implementation, watcher and challenger logic, key management, and the operational runbook for pausing a bridge under attack.
In practice
The check that separates a bridge from an incident
Code on this page is written to illustrate a technique or a finding class. It is not taken from any client engagement.
// ILLUSTRATIVE — the anatomy of a replay/forgery bug
// VULNERABLE: no chain binding, no nonce consumption ordering,
// signer set read after the loop.
function receiveMessage(bytes calldata payload, bytes[] calldata sigs) external {
bytes32 h = keccak256(payload);
require(_countValidSigners(h, sigs) >= threshold, "threshold");
(address to, uint256 amount, uint256 nonce) = abi.decode(payload, (address, uint256, uint256));
processed[nonce] = true; // set, but never checked
token.mint(to, amount);
}
// FIXED: domain-separated, chain-bound, nonce checked before effects,
// signer set snapshotted at message creation.
function receiveMessage(bytes calldata payload, bytes[] calldata sigs) external {
bytes32 h = keccak256(abi.encode(DOMAIN, srcChainId, block.chainid, payload));
(address to, uint256 amount, uint256 nonce, uint64 epoch) =
abi.decode(payload, (address, uint256, uint256, uint64));
require(!processed[nonce], "replay");
require(_countValidSigners(h, sigs, signerSetAt[epoch]) >= thresholdAt[epoch], "threshold");
processed[nonce] = true; // effects before interaction
token.mint(to, amount);
}Because a bridge is several systems and the attack surface is the seam between them. You are paying for a threat model per chain, review of the off-chain relay layer, and analysis of failure modes — halts, reorgs, forks — that do not exist in a single-chain audit. Starting price is $15,000 and scope is quoted per chain pair.
Four to eight weeks depending on the number of chains, the verification mechanism and whether the off-chain components are in scope. Light-client and ZK-verified bridges take longer than multisig attestation because the proof system itself needs review.
The EVM side is fully in-house. For a Solana, Aptos, Sui or Starknet counterpart we bring in vetted partner researchers for that chain, and we tell you who they are before you sign. We stay responsible for the cross-chain threat model and the integration between the two sides.
Yes, when it is in scope — and we recommend it is. A large share of bridge incidents involved compromised keys or a relayer that could be induced to sign something it should not have. Reviewing only the contracts leaves that untouched.
Verification that does not verify what it appears to: missing chain-ID or domain binding, a proof check that can be satisfied by a crafted payload, a signer set read at the wrong time, or a nonce recorded but never checked. Almost every large bridge loss traces to the verifier accepting a message it should have rejected.
Yes, and it is often the right sequence: we review the source chain and the message format first, then the destination side when it is ready. Phasing it that way catches design problems in the message schema while changing it is still cheap.
Related
Often scoped alongside this.
From $15,000
Send the repo. Scoping is free.
Under two working days to a written scope, a fixed quote and a review plan.