Skip to main content
Most cross-chain bridges share the same structural trade-offs: funds flow through a central pool, validators approve transfers, and users wait for off-chain consensus. ProofBridge takes a different approach — users hold their own assets, the two parties on a trade are the only signers, and settlement is proof-based. The table below compares the design choices across the protocols we are most often measured against.

Feature comparison

FeatureProofBridgeHashportWormhole / Stargate / LayerZero
User controls assets always
No external validators
Peer-to-peer consensus (BLS)
Zero-knowledge proof verification
User-facing security model
Faster settlement / processing

What each row means

User controls assets always

On ProofBridge, a Bridger’s deposit lives in the OrderPortal contract on the source chain and a Maker’s liquidity lives in their own ad inside AdManager. Neither is a pooled vault. A compromise of one account does not spread to other users. Traditional bridges route every transfer through a shared pool or multisig — a single compromise drains everyone.

No external validators

ProofBridge does not depend on a third-party validator set to attest to transfers. In the BLS end-state, the only signers on a trade are the two counterparties themselves. Hashport, Wormhole, Stargate, and LayerZero all route transfers through an external validator set (guardians, relayers, or oracles) that must sign off before funds move. Those validators are a trust assumption and a target.

Peer-to-peer consensus (BLS)

ProofBridge settles because the Maker and Bridger co-sign the trade with BLS signatures, aggregated into a single compact proof of agreement. Consensus is between the two parties on the trade — no external quorum.

Zero-knowledge proof verification

Every settlement on ProofBridge includes a ZK proof that the counterparty’s deposit is genuinely recorded on-chain (MMR inclusion), that the order hash matches the agreed terms, and that the nullifier has not been used. The on-chain Verifier checks the proof before any funds move. Other bridges rely on validator attestations rather than cryptographic proofs of deposit.

User-facing security model

ProofBridge applies the principle that each user is responsible for their own funds. The protocol itself has no privileged ability to move assets — there is no custodian, no admin key that can release funds, no operator who can redirect flows. Custodial bridges invert this: protocol operators have full authority over issuance and release, and users trust that authority won’t be abused or compromised.

Faster settlement / processing

Traditional bridges wait for multi-validator consensus plus confirmations on both source and destination chains. That is hours to finality on busy networks. ProofBridge removes the validator round-trip entirely — a trade settles as soon as both deposits are proven and both unlock calls confirm.

Where each approach makes sense

No bridge design is universally best. The table above is specifically about the security and trust model, which is what ProofBridge was built to fix.

Use ProofBridge when

You want to retain custody, you cannot accept a shared-pool honeypot in your threat model, and you need proof-based settlement rather than validator attestation.

Validator-based bridges make sense when

You need an extremely broad chain coverage today, and your threat model accepts a validator set as a trust anchor. Those bridges ship on more chains faster because adding a validator is cheaper than deploying a full proof system.

Further reading

Why ProofBridge

The problem statement and the protocol’s response to it.

Security model

Exact trust assumptions under the current pre-auth phase and under BLS.

Roadmap

The path to the BLS end-state and the AI automation layer.

How it works

The architecture and 12-step cross-chain flow.