> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pfbridge.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/concepts/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](/concepts/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](/reference/recipient-addresses).
***
## 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.
```text theme={null}
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](/concepts/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.
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](/architecture/current-state).
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](/architecture/phase-2-bls-auth).
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](/architecture/phase-3-agents-disputes).
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](/architecture/phase-4-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](/architecture/phase-5-followups).
***
## 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) |