🔨 Planned for T3. Audit-gated mainnet deployment of the full
T1 + T2 contract suite, plus mainnet-only operational primitives
(timelock, fees, multisig handoffs).
Architecture diagram
Delta from Phase 3
What changes vs Phase 3:Multisig admin + Timelock
Single-key admin replaced by an Admin Multisig on each chain
(Stellar account-level multi-sig, Gnosis Safe on EVM). Admin
operations flow through a new Timelock module with a 24-hour delay.
Pause / unpause exempt for emergency response.
Arbiter Multisig
ArbiterRole moves from ”= admin” to its own dedicated 5-of-7
multisig (3 team + 4 ecosystem). Quorum of 5 from a 3+4 pool
guarantees ≥ 2 non-team signers in any decision by construction.
Ecosystem signers are sourced via the Stellar Foundation.Protocol fee on `unlock`
protocol_fee_bps = 20 (0.2%) and lp_fee_bps = 30 (0.3%), capped
at 100 bps each. Bridger nets 99.5% of the destination amount;
0.3% stays in the maker’s ad.balance as LP profit; 0.2% routes
to the new Fee Pool.Per-route bond config
BondConfig { bond_token, min_bond, bond_bps } per route. USDC
route launches with bond in USDC, floor of 1 USDC, ratio of 50 bps
(0.5%). Same-token denomination keeps the math unit-clean without
an oracle.Reconciliation listener
Off-chain HA service, two-region. Watches both chains via private
RPC providers, detects settlement discrepancies within a 5-minute
SLA, alerts on-call. Read-only — no contract authority.
Bootstrap mode
Initial deploy runs without delay so the admin can wire routes,
fees, and roles.
activate_timelock() is a one-shot irreversible
flag flip before multisig handoff.Fee math
The fee mirrors the protocol’s published 0.5% total bridge fee, split between the LP and the protocol. It’s deducted destination-side from the maker’s locked amount:
Bps values are admin-configurable but timelocked, and capped at 100 bps
each in the contract to bound future admin-key abuse.
The launch route — USDC ↔ USDC
ProofBridge does not issue tokens. T3 launches with one production route between two existing token contracts:
ProofBridge configures the route via
set_token_route on each chain
(timelocked); Circle’s contracts are unmodified. Future routes —
including any native-token bridging (XLM, ETH) — wait for ecosystem
partners to issue equivalents on the counterpart chain. Adding a route
post-launch is config-only: set_token_route + set_settlement_window +
set_bond_config, all timelocked admin calls.
Mainnet deployment is audit-gated
The SCF Audit Bank engagement runs during T3 and gates mainnet deployment:1
T2 contract code freezes
End of Phase 3 / Tranche 2. T3 contract changes (timelock, fee
mechanism, per-route bond config) are staged but not yet deployed.
2
Audit kickoff
Auditors review the full T1 + T2 + T3 contract suite.
3
Critical / high findings closed
Audit Bank confirms remediation closure.
4
Mainnet deployment begins
Deploy contracts, run initial config, activate timelock, hand off
admin to multisig.
5
Production routes verified
First-tx ceremony for the USDC route in both directions. Tx hashes
recorded on
/reference/smart-contracts.6
4-week post-launch hardening
Daily uptime reports, audit medium/low remediation, integration
partner support, perf tuning.
Trust model at mainnet
For the full per-phase trust comparison see the security model. At mainnet the residual assumptions are bounded by:- Multisig + 24h timelock on every admin operation that can move funds, redirect routes, or change auth gating.
- Separate 5-of-7 arbiter multisig with ≥ 2 non-team signers guaranteed in every decision. We engage the Stellar Foundation to source ecosystem signers for the multisig.
- Cryptographic gates (BLS aggregate + UltraHonk + nullifier + EIP-712 binding) unchanged from earlier phases.
What ships next
Phase 5: Decentralization & Expansion
DAO governance for the ArbiterRole, agent stake-and-slash for
misbehavior, additional chains and RWA routes via ecosystem
partnerships, and protocol-level optimizations like per-route
fee bps and oracle-driven cross-token bonds.