Skip to main content
ProofBridge ships in stages. Each stage hardens the protocol and shrinks the scope of the backend relayer, moving the trust model closer to pure peer consensus between the two counterparties on a trade.

​
Where we are now

We are in Phase 2 — Proof System Expansion & Automation. The protocol is live on testnet with a stateful pre-authorization relayer that bootstraps trust during early testing. BLS signature aggregation is the next milestone and the end-state design the protocol is being rebuilt toward.
The pre-auth relayer is transitional. Treat it as scaffolding — the protocol’s security model is anchored on BLS peer consensus, not on the relayer.

​
Release phases

1

Phase 1 — Foundation & Core Design (shipped)

  • Base protocol architecture and cross-chain design complete.
  • Merkle Mountain Range (MMR) implemented for deposit tracking on each chain.
  • AdManager and OrderPortal contracts deployed and integrated.
  • Relayer-driven proof submission pipeline working end-to-end.
  • Proof aggregator layer established for cross-chain verification.
  • Internal documentation and component-level specs finalized.
2

Phase 2 — Proof System Expansion & Automation (in progress)

  • Integrate BLS authorization signatures for Maker + Bridger trade validation.
  • Build the AI automation layer for intelligent relayer selection and proof coordination.
  • Extend the proof relay pipeline for batching and fault tolerance.
  • Optimize the ProofBridge SDK and API for external developers.
  • Finalize node and relayer configuration for public testnet rollout.
3

Phase 3 — Public Testnet & Developer Rollout

  • Launch a public testnet with the full cross-chain proof relay pipeline.
  • Release the developer SDK, CLI tools, and complete documentation.
  • Ship a dashboard for proof tracking and relayer performance metrics.
  • Launch a bug bounty program and gather developer feedback.
  • Establish early ecosystem partnerships with wallets and explorers.
4

Phase 4 — Mainnet Preparation & Incentive Layer

  • Finalize and optimize contracts for mainnet deployment.
  • Deploy the Relayer Incentive Module for decentralized proof submissions.
  • Run an incentivized testnet campaign to simulate real-world activity.
  • Tune system parameters and optimize proof latency.
  • Prepare mainnet migration scripts and a release candidate build.
5

Phase 5 — Mainnet Launch & Decentralization

  • Launch ProofBridge mainnet.
  • Activate the Proof Registry and open the Relayer Network.
  • Launch the ProofBridge DAO for governance and upgrade management.
  • Introduce liquidity and proof-submission incentives.
  • Expand integrations across additional L2 and cross-chain ecosystems.

​
Protocol milestones

The phases above describe when things ship. The milestones below describe what the protocol becomes as they ship.

​
1. Pre-authorization relayer — MVP (shipped)

A stateful relayer pre-authorizes each trade to bootstrap trust during early testnet. The relayer:
  • Maintains pre-auth state for pending orders.
  • Detects on-chain deposits via user-triggered callbacks.
  • Fetches MMR inclusion proofs and triggers the deposit proof circuit.
  • Submits proofs to the destination AdManager and source OrderPortal.
Single-relayer model during early testing, with MMR trees maintained per chain and ZK proof circuits for inclusion and trade-constraint validation.
This is a transitional stage. The relayer’s role shrinks as BLS aggregation comes online in the next milestone.

​
2. BLS signature aggregation (next)

The end-state authentication model. The Maker and Bridger co-sign each order with BLS signatures. A relayer aggregates both signatures into a compact proof of agreement and submits it on-chain. Authentication moves from relayer state to cryptographic signatures, which unlocks:

Stateless relayer

No per-order state to maintain. Any relayer can submit a proof as long as it has both signatures.

Permissionless submission

Anyone can operate a relayer. Proof submission becomes an open-market role with no allowlist.

Multi-relayer competition

Multiple relayers can race to submit the same proof. The first valid submission wins, improving liveness.

Shrinking trust scope

The protocol no longer depends on a trusted relayer to validate trades. Validity is cryptographic, not operational.

​
3. AI automation layer

AI-driven agents run continuously on behalf of Makers and Bridgers under scoped, programmable authority. Agents never hold custody of user funds — they operate within explicit policy limits set by the user. What agents do:

Real-time monitoring

Watch open ads, incoming orders, and proof status across chains. Surface activity to the account owner as it happens.

Anomaly detection

Flag suspicious activity, stale liquidity, or misrouted orders before they cause losses.

Automated matching

Match incoming orders to open ads under the Maker’s policy rules and trigger settlement automatically.

Adaptive fee optimization

Adjust quoted rates in response to network conditions, competing ads, and gas costs.

Predictive liquidity provisioning

Rebalance liquidity across chains and token pairs ahead of anticipated demand.

Co-pilot relayer

Assist human relayer operators during the permissioned phase, then run autonomously once BLS aggregation removes the trust gate.
Scoped authority model. Each agent gets explicit, narrow permissions rather than full custody. For example:
“This Maker agent may execute up to 100 USDC of settlement against orderHash 0xabc…, and nothing else.”
Authority is bounded by token, amount, and order hash. Policies can be revoked at any time, and the underlying funds remain in the user’s own contracts throughout. This is the difference between an autonomous operator and a custodial service — the agent acts, but the user still owns. Why this works on ProofBridge. Agent-driven automation depends on chains that expose account-abstraction primitives: scheduled execution, scoped signing authority, and programmable policy checks at the account layer. ProofBridge’s current EVM (Sepolia) and Stellar integrations both support these primitives — EVM via ERC-4337-compatible account abstraction, Stellar through its native account model. Additional chains will be added as they mature.
The AI automation layer is on the roadmap, not in production. See Phase 2 for the current integration work.

​
Further reading

How it works

The architecture and the 12-step cross-chain flow today.

Security model

Trust assumptions in the current phase and under the BLS end-state.

Why ProofBridge

The problem space and why the peer-consensus design solves it.

Contribute

Run the full stack locally and start shipping.