Roadmap

How ProofBridge rolls out — from the pre-auth MVP to BLS auth, agent-managed liquidity, mainnet, and post-mainnet decentralization.

ProofBridge ships in stages. Each phase tightens the trust model and expands what the protocol does without changing its core peer-to-peer-with-ZK-proof foundation. This page is the chronological / when-does-what view; see the Architecture pages for the contract- level changes and architecture diagrams per phase.

Where we are now

We are at Phase 1: Pre-auth MVP. The full bridge architecture is live on Sepolia ↔ Stellar Testnet, with real bridge transactions settling end-to-end through the contracts. The pre-auth relayer sits in front of every state-changing call as transitional scaffolding while the BLS-based end-state is being built.

The pre-auth relayer is transitional. Treat it as scaffolding — the protocol’s security model is anchored on BLS peer consensus

• ZK proof verification, not on the relayer. Phase 2 retires the pre-auth path entirely.

The five phases

1. Phase 1: Pre-auth MVP (live on testnet)

   • Stateful relayer with pre-authorization to bootstrap trust.
   • On-chain Poseidon2 MMR per chain, ZK deposit proof at unlock.
   • AdManager, OrderPortal, MerkleManager, Verifier, and wNativeToken deployed on both chains.
   • Real bridge transactions settling end-to-end on Sepolia ↔ Stellar Testnet.

   See Architecture — Phase 1.

2. Phase 2: BLS Auth & Pre-auth Retirement (T1)

   • Both Maker and Bridger sign the order once with BLS; one aggregated signature gates both unlock calls.
   • Pre-auth manager-signing path removed entirely; relayer becomes a stateless off-chain aggregator.
   • Standalone Noir BLS auth circuit shipped as a building block for proof-backed off-chain auth.
   • MMR proof generation back to ≤30s on a reference machine.
   • Route-commitment defense (existing ads survive admin compromise), pause primitive, two-step admin transfer.

   See Architecture — Phase 2.

3. Phase 3: Agents & Disputes (T2)

   • Soroban custom-account agents (per-maker) with policy-gated authorization. EVM mirror via per-maker Safe Module.
   • Multi-key BLSKeyRegistry v2 with single-tx agent rotation.
   • Order deadline field added; permissionless cancel paths after expiry.
   • Bonded dispute path with arbiter resolution (MutualRefund / TradeProceeds / BridgerForfeit / MakerForfeit outcomes).
   • 14-day public testnet stability run with proof-gen, settlement, and dispute metrics on a public dashboard.

   See Architecture — Phase 3.

4. Phase 4: Mainnet Launch (T3)

   • Audit-gated mainnet deployment on Stellar + Ethereum.
   • Admin handed off to multisig on each chain; ArbiterRole held by a separate 5-of-7 multisig (3 team + 4 ecosystem signers).
   • 24-hour operational timelock on critical admin functions (route changes, fee parameters, role grants).
   • Protocol fee mechanism live (0.2% to fee pool, 0.3% maker LP profit, deducted destination-side).
   • Single launch route — USDC ↔ USDC between Circle’s existing Ethereum ERC-20 and Stellar SAC. No ProofBridge- issued wrapped assets.
   • HA relayer infrastructure, public per-service status page, cross-chain reconciliation listener.
   • Developer SDK + OpenAPI spec.
   • 4-week post-launch operational hardening window.

   See Architecture — Phase 4.

5. Phase 5: Decentralization & Expansion (post-mainnet)

   Two foundational follow-up tranches plus several scoped iterations, each separately funded and timed against post- launch operational data:

   • DAO governance for ArbiterRole — moves dispute resolution from the multisig to community-elected stake- weighted voting.
   • Agent slashing — stake-and-slash penalty layer beyond the existing dispute outcomes, calibrated against observed mainnet misbehavior.
   • More chains — Arbitrum, Base, Optimism, Polygon, Starknet, Solana — each is a contract deployment + (for non-EVM) circuit work using the existing T1+T2 contract suite.
   • More routes — RWA-specific (BENJI, CETES) and additional stablecoin pairs, as ecosystem partnerships land.
   • Protocol-level optimizations — per-route fee bps, cross-token bonds via price oracle, auth + deposit combined ZK proof for L2 batching.

   See Architecture — Phase 5.

What changes phase to phase

Phase	Trust model change	Capability change
Phase 1	Single-key admin + trusted relayer	Bridging works; relayer is a liveness bottleneck
Phase 2	Pre-auth retired; aggregator becomes untrusted	One signed message per user, used on both unlocks
Phase 3	Agents act under policy; arbiter resolves disputes	Automated maker liquidity ops; stuck orders recoverable
Phase 4	Admin = multisig; arbiter = separate multisig; 24h timelock	Mainnet-ready; protocol fees live; USDC route active
Phase 5	Multisig → DAO governance; agents post stake	Decentralized arbitration; slashable misbehavior

SCF Build Award funding

Phases 2, 3, and 4 are funded as the three tranches of the SCF Build Award (T1, T2, T3). Phase 5 items are out of scope for the current Build Award and are pursued as separate follow-up tranches.

Further reading

Architecture — overview

Per-phase architecture diagrams and contract-level details.

How it works (today)

The current 12-step cross-chain flow as it actually runs on testnet.

Security model

Trust assumptions in the current phase and how they shrink through Phases 2–5.

Why ProofBridge

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