01 · Overview
The problem
Autonomous agents that move real money need authority. Today that authority is a private key: you hand the agent the key and hope its prompt, its model, and its host all stay honest. There is no enforced ceiling, no allow-list, no expiry, and no recall. A single prompt injection, a bug, or a compromised host is total loss.
ERC‑8004 names the same gap on Ethereum. Agents need portable identity and verifiable, bounded permissions. Sui can answer it more cleanly than any account-based chain, because on Sui a scoped permission is a first-class object.
The Ballast answer
Instead of a key, you mint the agent a mandate: a BallastCap object with hard,
on-chain limits.
spend ≤ cap leverage ≤ max market ∈ allow-list now ≤ expiry not revoked
The agent acts through the cap. Every gated action calls capability::enforce
before touching the venue, and any violation aborts the whole transaction, so
nothing partial ever settles. The agent never holds authority beyond the mandate,
and the owner can revoke it in one transaction, even while it is in use.
On top of that, Ballast adds verifiable execution. The agent’s trade decision can be required to come from a specific piece of code running in a Trusted Execution Environment (an AWS Nitro enclave), with that enclave’s signing key proven on-chain. A forged or replayed signature is rejected by the chain before the trade settles.
The waterline mark
Ballast’s mark is a circle half-filled to a waterline, bisected by the line. The metaphor is simple: a vessel may only ride so deep. The capability is the load line, and the chain holds it.
What’s real vs. stubbed
Ballast is deliberately honest about its one stubbed seam.
| Capability | Status |
|---|---|
AgentIdentity + reputation |
Real, on testnet |
BallastCap issue / enforce / revoke |
Real, on testnet |
| Spend / leverage / market / expiry / revocation enforcement | Real, proven by on-chain aborts (codes 5/4/3/1) |
| DeepBook Spot fill through the capability | Real execute_trade<SUI,DBUSDC> fills |
Reputation accrual + TradeExecuted events |
Real |
Nautilus TEE attestation (verify_nautilus, execute_trade_attested) |
Real. Enclave key registered on-chain via the AWS cert chain and PCRs; attested fill and forged-sig rejection both proven |
Agent service (@ballast/sdk) + dashboard |
Real, both dogfood the SDK |
Legacy attestation::verify(payload, sig) stub |
Stub, returns true. Kept byte for byte as the default mock path so the demo never regresses; the real path is verify_nautilus |
The mock verify stub is the only stubbed security primitive. It sits behind a
stable interface, so the real Nautilus path drops in with zero call-site change.
See 04 · Verifiable execution and
08 · Security & threat model.
Where Ballast runs
- Move package (
move/), deployed to Sui testnet. The package lineage runs v1 to v2 to v3; see 05 · Deployments. @ballast/sdk(packages/sdk/), the adoption surface. Both the agent and the dashboard consume it.- Agent service (
agent/), which runs a strategy, presents the capability, and submits PTBs, including a “rogue mode” that proves the aborts. - Dashboard (
web/), a Next.js and dapp-kit app to delegate a mandate, watch the agent act, see rejections, and revoke. - Enclave app (
enclave/), the Rust app that runs inside AWS Nitro and signs trade authorizations.