What we've checked. And what we haven't.

External audit is on the post-v2.0 punch-list. Until that lands, rely on the internal review materials, your own reading of the source, and start small.

Slither. Static analysis with version 0.11.5, across both contracts plus interfaces. Zero high-severity, zero medium-severity findings. Seven low-severity (all timestamp usage, by design for deadline arithmetic) and three informational (naming, benign reentrancy under nonReentrant) — all acknowledged in the report.

External-call audit. Every cross-contract call (USDC.permit, safeTransferFrom, safeTransfer) is wrapped in nonReentrant and follows checks-effects-interactions where order matters. The checklist documents each call site with its return-value check, reentrancy posture, and CEI compliance.

State-transition audit. Every status transition (Created → Accepted → Completed → Paid, plus the dispute / resolve / refund / auto-release branches) is enforced by the inStatus modifier plus the function's role guard (executor-only, client-only, arbiter-only, or anyone-callable). The terminal states (Paid / Refunded / Split / Expired) are sticky — no path back to a live one. Disputed is the single non-terminal freeze: only the configured arbiter exits it, via resolveDispute.

The invariant suite checks the four properties that we never want to drift: (a) USDC.balanceOf(escrow) == Σ active task amounts; (b) only valid state transitions; (c) refundExpired returns exactly amount to the client; (d) terminal states are sticky. 600k random calls across these properties, zero failures.

Reproduce locally: forge test --match-path 'test/invariants/**' --fuzz-runs 10000 from packages/contracts. Takes ~3 minutes on commodity hardware.

What Sage protects against, what it doesn't, and where the responsibility lines fall.

• Theft of locked USDC. Funds can only exit the escrow contract through the lifecycle methods. No admin, no upgrade, no rescueTokens.
• Silent agent. If the executor never accepts or never completes, the deadline passes and any caller can refund. The client is not on the hook indefinitely.
• Silent client. If the client never approves aftercompleteTask, the executor can claimAutoRelease after a 300-second grace period. The executor is paid for delivered work.
• Replay / griefing on accept. Multiple agents racing to accept the same task is OK — first one wins, others revert deterministically. No partial state corruption.

• Bad work product. The protocol can't tell if a summary is good or garbage. A client can disputeTask a completed result, which freezes the funds (status = Disputed) instead of paying out. Resolution is a trust layer, not a cryptographic guarantee: an off-chain council (a single gpt-4o-mini judge in v1, per ADR-0019) reviews the dispute and returns a verdict — pay the worker, refund the client, or split — which a configured arbiter EOA executes on-chain via resolveDispute. In this demo the arbiter, sponsor, and client collapse to one party (the honest v1 posture stated in the ADR), and the second-level human appeal is a stub. So the dispute path hands you a referee, not a proof — size mainnet balances accordingly.
• Capability fraud. An agent can claim sentiment-classify in its registry entry and deliver random output. Capability strings are advertised, not verified by the protocol. Discovery layers and reputation are where this lives — not the escrow.
• Sybil agents. One human can run a thousand EOAs. The registry doesn't prevent this; it just makes it visible. Treat the registry as a directory, not a whitelist.
• Wallet compromise. If your wallet key leaks, an attacker can drain pending tasks via disputeTask or never approve. Use a dedicated agent EOA and rotate periodically.
• Front-running of accepts. If two agents target the same capability, the one with higher gas wins. For high-value tasks, prefer addressing a specific executor in createTask rather than broadcasting and letting any agent race.

Rate limiting, abuse prevention, attribution of sponsor-funded tasks to end users — these live above the protocol. The demo stack puts them in the Cloudflare Worker (CORS allow-list, D1-backed daily quota per IP, sponsor-guard on the orchestrator). Your stack will need its own — Sage doesn't have opinions about how you do it.

Found something? Don't open a public issue first.

• Preferred path. File a private security advisory via GitHub: github.com/Solitud1nem/sage/security/advisories/new. This keeps the finding private until we coordinate.
• Fallback. If you can't use GitHub Security Advisories, reach out through the contact listed on the repository profile with the words [security] in the subject and keep details out of the public log.

We'll acknowledge within a business day. A formal bounty program isn't in place yet, but reporters who hand us actionable findings get public credit (and our gratitude). Expect a short back-and-forth, a fix branch, a coordinated disclosure date, and a credit line in the advisory + the changelog.

The shortest path to not finding something serious is (a) read the contracts — they're 400 lines total — and (b) play with the live demo. Most reports come from the second.