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

# Follow-ups

> Post-mainnet roadmap: DAO governance for the arbiter, agent slashing, additional chains, RWA route partnerships, and protocol-level optimizations.

<Note>
  📅 **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.
</Note>

Phase 5 collects everything that comes after a successful mainnet
launch — two foundational follow-ups plus several scoped iterations.

## Architecture diagram (foundational follow-ups)

<img src="https://mintcdn.com/proofbridge/1ew08pldeeuBKd_p/architecture/_diagrams/phase-5-followups.png?fit=max&auto=format&n=1ew08pldeeuBKd_p&q=85&s=c319e26350368ef273ebff9fdf50dc0c" alt="Phase 5 architecture — DAO governance and agent slashing" width="1800" height="851" data-path="architecture/_diagrams/phase-5-followups.png" />

## Delta from Phase 4

What changes vs [Phase 4](/architecture/phase-4-mainnet):

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

<CardGroup cols={2}>
  <Card title="Token launch" icon="coins">
    Governance token: supply design, vesting, allocation between team
    / ecosystem / community / treasury. Distribution mechanism and
    regulatory + legal review of the structure.
  </Card>

  <Card title="Staking + voting contracts" icon="layer-group">
    Token contract on each chain. Staking contract — token holders
    stake to vote. Governance contract for the proposal lifecycle
    (propose → discuss → vote → queue → execute).
  </Card>

  <Card title="`ArbiterRole` transition" icon="arrows-cross">
    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).
  </Card>

  <Card title="Treasury management" icon="building-columns">
    The `protocol_fee_pool` (admin-controlled in Phase 4) transitions
    to DAO-controlled. Fee revenue funds the DAO's operations + future
    development.
  </Card>
</CardGroup>

**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".

<CardGroup cols={2}>
  <Card title="Stake contract" icon="vault">
    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.
  </Card>

  <Card title="Slashing logic" icon="gavel">
    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.
  </Card>

  <Card title="Withdrawal cooldown" icon="hourglass-half">
    14-day cooldown between unstake request and withdrawal. A pending
    slash blocks withdrawal until the dispute resolves. Prevents
    grief-then-flee patterns.
  </Card>

  <Card title="Reentry" icon="arrows-rotate">
    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.
  </Card>
</CardGroup>

**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:

<CardGroup cols={2}>
  <Card title="Additional chains" icon="link">
    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.
  </Card>

  <Card title="RWA route partnerships" icon="briefcase">
    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.
  </Card>

  <Card title="Cross-token dispute bonds via oracle" icon="scale-unbalanced">
    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.
  </Card>

  <Card title="Per-route fee bps" icon="sliders">
    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.
  </Card>

  <Card title="Auth + deposit combined ZK proof" icon="layer-group">
    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.
  </Card>
</CardGroup>

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