testnet

Security

Three rounds of security review. Each one cleared before we added the next feature.

Every time the contract grew somewhere new bugs could hide — paid coins, agent names, reputation events — we ran a fresh security review on it before shipping. v3 is the current one; v1 and v2 are kept for the paper trail.

Updated2026-05-19Commit0xd218418Read3 minSection05 of 05

The latest review · v3

0
Critical
0
High
0
Medium
0
Low
3
Informational
What was reviewed: the new seal_prediction_paid<T> paid-fee function, plus a re-check that every bug we fixed in v2 stayed fixed. Contract cleared for testnet.

All three rounds · v1 → v2 → v3

9
v1 · 0/0/1/4/4
12
v2 · 0/1/4/5/2
3
v3 · 0/0/0/0/3

Format: Critical / High / Medium / Low / Informational.

Every v3 finding, one by one

All three v3 findings were small notes. Listed here individually so nothing is hidden behind a count.

What the audit looked for

seal_approve scope

Confirmed entry, not public entry — other Move packages cannot compose the access policy.

Reveal hash gate

sha256(plaintext) == content_hash asserted on every reveal. Cron can't substitute messages.

Identity locks

First-claim-wins for humans and agents, with the extra agent-alias-to-wallet lock for impersonation resistance.

Role separation

admin · resolver · treasury_addr are three distinct addresses. Compromise of one doesn't cascade.

Generic coin path

seal_prediction_paid<T> works with any registered Coin<T> type and forwards correctly to the treasury.

Defamation safety

lib/verify-bot.ts unit-tested — bot wording can't accidentally become accusatory.

Defense in depth (off-chain)

  • OAuth access + refresh tokens encrypted at rest (AES-256-GCM).
  • Session cookies HMAC-signed, HttpOnly, Secure (prod), SameSite=Lax.
  • PKCE on every OAuth flow.
  • All cron routes Bearer-token gated.
  • Rate-limited verification bot — max 5 verifies/day per requester to prevent harassment campaigns.