ProofBridge security model, proofs, and trust assumptions

Understand how ProofBridge protects your funds using EIP-712 signatures, ZK proofs, nullifiers, and on-chain Merkle trees — with no custodial risk.

ProofBridge is designed so you never have to trust a centralized party with your funds. Smart contracts hold all assets during settlement, zero-knowledge proofs attest to the correctness of every transfer, and cryptographic primitives prevent every known class of replay or double-spend attack. This page explains each protection and where the current trust boundary lies.

Security gates at a glance

Every fund release on ProofBridge passes through the same set of cryptographic gates. The diagram shows what each gate checks and where it gets its inputs:

Funds release only when every gate passes — EIP-712 binding, BLS aggregate, ZK proof, fresh nullifier, and a still-Open order status. If any one check fails the unlock reverts and the deposit stays in escrow.

---

No custodial risk

Your funds are locked in the AdManager or OrderPortal smart contracts at all times. ProofBridge as a service never holds your tokens. Settlement only releases funds when a valid zero-knowledge proof is submitted and verified on-chain. If the relayer fails or goes offline, your tokens remain locked in the contract until settlement completes — they are never at risk of being taken.

---

EIP-712 signed orders

When you create an order, the full set of trade terms — source chain, destination chain, contract addresses, token addresses, amount, recipient, and a unique salt — are hashed together using the EIP-712 standard and signed by your wallet.

This signature binds your order to exactly one set of contracts on exactly two chains. The same signed message cannot be submitted to a different chain or a different contract version without invalidating the signature. This prevents cross-chain replay attacks and cross-contract replay attacks even without including chainId in the EIP-712 domain, because both chain IDs and both contract addresses are explicit fields in the Order struct itself.

The EIP-712 domain for ProofBridge uses name = "Proofbridge" and version = "1". Chain IDs and contract addresses are part of the Order struct, not the domain — making every field inspectable in your wallet’s signing prompt, and making the digest byte-identical on both chains so a single zk proof can settle atomically. See Order hashing for the full rationale.

Two additional invariants are enforced at validateOrder time on each chain:

• Decimals are signed, not inferred. The orderDecimals and adDecimals fields are part of the EIP-712 struct, so a signer commits to the exact scaling. Each portal also asserts that its local token’s decimals() matches what was signed — defence in depth against a mismatched or redeployed token. See Decimal scaling.
• Recipients are chain-shape-checked. An EVM portal rejects a bytes32 recipient with non-zero upper 12 bytes; a Stellar portal rejects a non-decodable Ed25519 pubkey or a Soroban contract address. A misencoded recipient fails cheaply before any state change. See Recipient address invariants.

---

Nullifiers: preventing double-spending

Every settlement consumes a nullifier — a Poseidon2 commitment derived from a per-trade secret and the order hash. Once a nullifier is recorded on-chain, no one can submit another proof for the same order.

The Bridger’s nullifier is consumed when AdManager releases funds on the destination chain. The Maker’s nullifier is consumed when OrderPortal releases funds on the source chain. Both commitments are verified independently, so neither party can replay a proof to extract funds twice.

nullifierHash = poseidon2(secret_half, orderHashMod)

The secret is a uniqueness device — its sole purpose is to make each settlement attempt singular and non-replayable.

---

MMR integrity: a tamper-proof order ledger

Every deposit into OrderPortal and every lock on AdManager appends the order hash to a Merkle Mountain Range (MMR) stored on-chain. The MMR uses Poseidon2 hashing — the same hash function used inside the ZK circuit — so the on-chain root can be directly referenced in a proof.

Because the MMR is append-only and managed by access-controlled contracts (only AdManager and OrderPortal hold MANAGER_ROLE), no external party can insert, modify, or remove entries. Every order that was ever created is permanently and verifiably part of the tree.

Settlement on Chain B requires an inclusion proof against Chain A’s MMR root. This means the relayer cannot claim a deposit occurred that did not — it would have to forge the Merkle proof, which is computationally infeasible given the Poseidon2 hash function.

---

Zero-knowledge proofs: the relayer cannot lie

The ZK proof is the core settlement primitive. It is a succinct, on-chain-verifiable attestation of cross-chain state — the destination chain can confirm what happened on the source chain without reading the source chain directly. The proof binds all of the following together:

• The order hash is included under the source chain’s MMR root (inclusion proof)
• The order hash matches the trade parameters (amount, chains, tokens, recipients)
• The nullifier was computed correctly from a per-trade secret known only to the claimer
• The proof targets the correct side of the trade (a chain flag is a public input)

Because the proof is validated by the Verifier contract on-chain, the relayer cannot manipulate the output. If the relayer submits a proof for a deposit that did not happen, the Verifier rejects it (no valid Merkle path). If the relayer submits a proof with a tampered amount or wrong recipient, the order hash bound into the proof no longer matches.

Every public input to the proof — order hash, MMR root, nullifier hash, chain flag — is visible on-chain on both sides. The only private input is the per-trade secret that gates the nullifier; its job is replay protection. See Zero-knowledge proofs for the full framing.

---

Current trust assumption: the pre-authorization relayer

In the current Phase 1 design, the relayer is stateful. Before you create an order, the relayer pre-authorizes your transaction and maintains session state throughout settlement. This means you are trusting the relayer to:

• Honestly coordinate the cross-chain flow
• Trigger proof generation after your deposit is confirmed
• Submit the generated proof to both chains

The relayer cannot steal funds — settlement requires a valid ZK proof, and the proof is verified on-chain. However, a malicious or offline relayer could refuse to generate or submit proofs, leaving your funds locked until the situation resolves.

If a transfer gets stuck, your funds remain safely locked in the smart contract. Contact support to investigate relayer availability.

---

Roadmap to trustless: BLS aggregation

Phase 2 introduces BLS signature aggregation, which will remove the relayer trust assumption entirely.

Both the Maker and the Bridger will produce BLS signatures over the agreed order hash or Merkle root. These signatures are aggregated into a single compact proof of agreement. Once BLS aggregation is live, any actor — not just the designated relayer — can submit the aggregated proof to the destination chain’s OrderPortal and complete settlement.

Phase 1: Pre-auth MVP (current)

The relayer is stateful and centralized. It pre-authorizes transactions, monitors confirmations, triggers proof generation, and submits proofs. You trust the relayer’s liveness and honesty, but your funds cannot be stolen even if the relayer misbehaves. See Architecture — Phase 1.

Phase 2: BLS auth & pre-auth retirement (next)

Maker and Bridger each sign the order once with BLS. The aggregated signature gates both unlock calls. The pre-auth relayer becomes a stateless, untrusted aggregator — multiple aggregators can compete to submit the same valid unlock, with no permission check. Adds the route-commitment defense, pause primitive, and a standalone Noir BLS auth circuit. See Architecture — Phase 2.

Phase 3: Agents & disputes (testnet expansion)

Soroban custom-account agents under scoped policies. Order deadline field, permissionless cancel paths after timeout, and a bonded dispute path with arbiter resolution. The multi-key BLSKeyRegistry v2 enables single-tx agent rotation. See Architecture — Phase 3.

Phase 4: Mainnet launch

Stellar + Ethereum mainnet, audit-gated. Admin handed off to multisig; ArbiterRole held by a separate 5-of-7 multisig. 24-hour operational timelock on critical admin functions. Protocol fee mechanism live; cross-chain reconciliation listener watches both chains for settlement discrepancies. See Architecture — Phase 4.

Phase 5: Decentralization & expansion (post-mainnet)

DAO governance for the arbiter role, agent stake-and-slash for misbehavior, additional chains, RWA route partnerships, and protocol-level optimizations. See Architecture — Phase 5.

---

Security properties summary

Property	Mechanism	Guaranteed today
No custodial risk	Funds locked in smart contracts	Yes
Replay prevention	EIP-712 chain/contract binding + nullifiers	Yes
Double-spend prevention	On-chain nullifier registry	Yes
Tamper-proof order history	Append-only MMR with access control	Yes
Relayer cannot lie about deposits	ZK proof verified on-chain	Yes
Permissionless settlement	BLS aggregation	No (Phase 2)
Multi-aggregator liveness	Stateless aggregator design	No (Phase 2)
Decentralized dispute resolution	DAO governance for ArbiterRole	No (Phase 5)