> ## 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.

# 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](/architecture/overview) 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.

<Info>
  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.
</Info>

## The five phases

<Steps>
  <Step title="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](/architecture/current-state).
  </Step>

  <Step title="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](/architecture/phase-2-bls-auth).
  </Step>

  <Step title="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](/architecture/phase-3-agents-disputes).
  </Step>

  <Step title="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](/architecture/phase-4-mainnet).
  </Step>

  <Step title="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](/architecture/phase-5-followups).
  </Step>
</Steps>

## 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

<CardGroup cols={2}>
  <Card title="Architecture — overview" icon="diagram-project" href="/architecture/overview">
    Per-phase architecture diagrams and contract-level details.
  </Card>

  <Card title="How it works (today)" icon="circle-info" href="/how-it-works">
    The current 12-step cross-chain flow as it actually runs on
    testnet.
  </Card>

  <Card title="Security model" icon="shield" href="/reference/security-model">
    Trust assumptions in the current phase and how they shrink
    through Phases 2–5.
  </Card>

  <Card title="Why ProofBridge" icon="lightbulb" href="/why-proofbridge">
    The problem space and why the peer-consensus design solves it.
  </Card>
</CardGroup>