Skip to main content
📅 Follow-up tranches. Out of scope for the current SCF Build Award (T1 + T2 + T3). Two of these — DAO governance and slashing — are large enough to warrant their own scoped initiatives with separate funding. The rest are smaller iterations on the launched protocol.
Phase 5 collects everything that comes after a successful mainnet launch — two foundational follow-ups plus several scoped iterations.

​
Architecture diagram (foundational follow-ups)

Phase 5 architecture — DAO governance and agent slashing

​
Delta from Phase 4

What changes vs Phase 4:
  • A new Token Holders actor + Governance contract take over from the Phase 4 multisig as the protocol’s decision-making layer.
  • A new Agent Stake contract holds collateral that agents must post; slashable on confirmed misbehavior.
  • The existing Agent Account, contracts, registry, and verifier are unchanged — Phase 5 layers governance and stake on top rather than re-architecting the core.

​
Foundational A — DAO governance for ArbiterRole

Move the ArbiterRole from the 5-of-7 multisig (Phase 4 model) to community-elected, stake-weighted governance. Disputes are resolved by ProofBridge DAO votes rather than a fixed signer set.

Token launch

Governance token: supply design, vesting, allocation between team / ecosystem / community / treasury. Distribution mechanism and regulatory + legal review of the structure.

Staking + voting contracts

Token contract on each chain. Staking contract — token holders stake to vote. Governance contract for the proposal lifecycle (propose → discuss → vote → queue → execute).

`ArbiterRole` transition

The 5-of-7 Phase 4 multisig is retired. ArbiterRole becomes either a governance-controlled signer set (DAO elects N signers periodically) or DAO-direct (proposal + vote = resolution).

Treasury management

The protocol_fee_pool (admin-controlled in Phase 4) transitions to DAO-controlled. Fee revenue funds the DAO’s operations + future development.
Why it isn’t in the current Build Award. SCF Build rules explicitly exclude tokenomics-related spend, so the DAO work isn’t fundable from this envelope. It’s also a multi-month initiative with regulatory dependencies that have to land outside the contract design itself. And a DAO whose tokens are 100% held by the team is theatre. Real DAO governance needs distribution to actual stakeholders, which needs a mainnet-deployed user base whose contributions are measurable in the first place.

​
Foundational B — Agent misbehavior slashing

Add a stake-and-slash penalty layer for agents that misbehave under their custom-account policy. Today (post-Phase 3), an agent that signs an invalid trade is bounded by policy caps, the maker’s revoke_agent() kill switch, dispute outcomes (BridgerForfeit / MakerForfeit), and the per-route dispute bond. What slashing adds: a separate, recoverable economic penalty beyond “the maker loses the disputed trade”.

Stake contract

Each agent’s operator posts a stake before being authorized. Denomination: native, stablecoin, or governance token (depends on whether DAO governance is live first). Size tied to the agent’s policy ceiling (max_per_window) or a flat tier.

Slashing logic

Triggered by the arbiter (or DAO post-governance) on BridgerForfeit / MakerForfeit outcomes naming the agent’s account. Slash percentage configurable. Slashed funds destination determined by governance.

Withdrawal cooldown

14-day cooldown between unstake request and withdrawal. A pending slash blocks withdrawal until the dispute resolves. Prevents grief-then-flee patterns.

Reentry

After a slash, the same operator can re-stake. Slash history is on-chain for forensic purposes; downstream operators can weigh it in their trust decisions.
Why it isn’t in the current Build Award. Pre-mainnet we have zero data on what agent misbehavior actually looks like. Calibrating slashing parameters without that data risks two failure modes — too harsh (no one operates agents) or too lenient (no deterrent, just extra UX tax). Phase 4’s stability data + the first ~3 months of mainnet operation give a real evidence base.

​
Scoped iterations

These ship as small follow-on tranches after mainnet, each config-only or a modest contract refactor:

Additional chains

Arbitrum, Base, Optimism, Polygon, Starknet, Solana — each is a contract deployment plus (for non-EVM) circuit work using the existing T1+T2 contract suite. Add one chain at a time as ecosystem readiness allows.

RWA route partnerships

Franklin Templeton BENJI, Etherfuse CETES, and other Stellar-native real-world assets. Route configuration is a set_token_route admin call once a counterpart asset exists on the other chain.

Cross-token dispute bonds via oracle

Phase 4’s per-route bond config supports this on the storage side; the missing piece is an oracle integration. Build when justified by observed dispute behavior.

Per-route fee bps

Phase 4 ships a flat protocol-wide 20/30 fee split. Per-route configuration is a small refactor of fee storage — useful once route economics diverge enough to matter.

Auth + deposit combined ZK proof

Phases 1–4 keep BLS auth and the deposit ZK proof as independent gates. A combined proof is a proof-system optimization motivated only when L2 batching volumes appear.

​
Sequencing

The two foundational follow-ups (A and B) are not strictly ordered. Either order works; ecosystem signal during the post-launch window (which one users / community ask about more, which surfaces real pain first) determines priority. The scoped iterations slot in opportunistically as ecosystem partnerships, route demand, or operational data justify them.