Skip to main content
🔨 Planned for T2. Builds on Phase 2’s BLS-only auth model. Lands the agent-account model and dispute-handling paths on testnet, plus the multi-key BLSKeyRegistry upgrade.
Phase 3 adds two capabilities held back from earlier phases: automated maker liquidity ops under a scoped policy, and dispute paths for stuck or contested orders. Both build on the Phase 2 BLS foundation and introduce new on-chain primitives.

​
Architecture diagram

Phase 3 architecture — Agents and disputes

​
Delta from Phase 2

What changes vs Phase 2:

Agent Account (Soroban + EVM)

Maker deploys their own contract — Soroban custom account with __check_auth, or per-maker Safe Module on EVM. Stores a policy table per agent (allowed actions, token whitelist, per-order cap, rate limit, expiry, revocation flag).

Multi-key `BLSKeyRegistry` v2

Replaces Phase 2’s single-key registry. Each address can hold up to 5 active key slots with stable monotonic IDs and a valid_until timestamp per slot. unlock takes a slot hint so pairing-check cost stays at one attempt.

`OrderData` gains `deadline`

The Order struct expands from 15 to 16 fields — a signed deadline set per route. Both parties sign the deadline; each chain validates it’s within bounds at create / lock time.

Cancel paths

cancel_order (OrderPortal) and cancel_lock (AdManager) are permissionless after deadline. Refunds via pull-payment escrow, unwinds maker ad.locked back into ad balance.

Dispute lifecycle

dispute() posts a bond and moves the order into Disputed. respond_to_dispute() lets the counterparty add evidence. resolve_dispute() pays out per a discrete DisputeOutcome enum.

`ArbiterRole` actor

A new role holds dispute-resolution authority. In T2 this equals the protocol admin; the role moves to its own multisig in Phase 4.

​
How agents work

A maker who wants automated liquidity operations:
1

Deploy an Agent Account

Soroban: deploy a custom-account contract that implements __check_auth. EVM: deploy a per-maker Safe + Safe Module. Either way, the maker is the owner.
2

Set the agent's policy

Owner calls set_policy(agent_pubkey, policy) with allowed actions, token whitelist, per-order cap, rate limit, expiry, and revocation flag.
3

Register the agent's BLS pubkey

Owner registers the agent’s BLS public key against the Agent Account’s address. The agent becomes the maker’s BLS-signing identity for trades within policy.
4

Point ads at the Agent Account

Maker creates ads with ad_creator = agent_account_address. The agent can call lock_for_order and produce BLS signatures within policy bounds — without ever holding the maker’s wallet key.
5

Rotate keys in one tx

To replace an agent (compromise, software change), the maker adds a new BLS key slot and sets valid_until on the old slot. No need to close ads or migrate liquidity.
Agents cannot initiate disputes, modify their own policy, touch funds outside the maker’s ads, or operate beyond valid_until / rate-limit ceilings.

​
How disputes work

The order lifecycle expands from None → Open → Filled to include two new branches: 
None → Open → Filled                    (happy path, unchanged from Phase 2)
       Open → Cancelled                 (timeout-based unwind after deadline)
       Open → Disputed → Resolved       (challenge path before deadline)
Disputes are raisable on either chain while the order is Open and before the route’s deadline. After deadline, the cancel path takes over — no arbiter needed. The bond + arbiter judgement deters frivolous disputes; the system self-regulates on incentives. DisputeOutcome covers the four real-world resolutions:
OutcomeSource side (OrderPortal)Destination side (AdManager)
MutualRefundBridger refundedad.locked -= ad_amount (back into ad balance)
TradeProceedsBridger’s deposit → maker’s recipientMaker’s locked balance → bridger’s recipient
BridgerForfeitBridger’s deposit → maker (forfeit)ad.locked -= ad_amount
MakerForfeitBridger refundedMaker’s locked balance → bridger’s recipient
The arbiter is responsible for issuing matching outcomes on both chains. Off-chain coordination keeps the two halves consistent.

​
Using the BLS auth circuit in disputes

The standalone Noir BLS auth circuit from Phase 2 finds its first real use here. A counterparty defending a dispute can submit a ZK proof attesting “I had a valid aggregated BLS authorization for this trade” without publishing the raw aggregated signature off-chain. The existing UltraHonk verifier checks the proof on-chain, and the arbiter sees a portable cryptographic claim instead of asking for screenshots.

​
What ships next

Phase 4: Mainnet Launch

Stellar + Ethereum mainnet deploy, admin and ArbiterRole both hand off to multisigs, 24-hour timelock on critical admin actions, protocol fee mechanism, USDC ↔ USDC launch route, cross-chain reconciliation listener.