Verification modes
A capability's verification_mode determines how much the wall can check before it lets an agent through.
Two modes
offline | online | |
|---|---|---|
| Network | None — verify signatures only | Live check against MotherShy |
| Revocation | ❌ Can't check | ✅ Checked |
| Reservation | ❌ Budget is a soft ceiling | ✅ Spend locked per-request |
| Expiry | Mandatory (the only safety valve) | Can be open-ended |
| Where | All six wall form factors | Cloudflare only (today) |
Offline (the default everywhere)
An offline capability is verified purely by signature against the pinned root. The wall checks budget and expiry, but cannot know whether the capability was revoked after minting.
Because there's no revocation, offline caps must carry a finite expiry — the verifier rejects expires_at: 0 with cap: offline capability requires an expiry.
Online (Cloudflare-only today)
An online capability allows revocation and per-request reservation — the ledger can mark a key revoked, or lock spend so a single capability can't be replayed against many sites in parallel. It costs a live check against MotherShy's ledger.
The self-hosted walls (WordPress, Node, Nginx, Vercel, Netlify) ship offline verify-only. When a self-hosted wall sees an online capability, it fails closed:
cap: online verification required (revocation + reservation not available)What this means for you
- Publisher — your wall gates identically regardless of mode. Offline walls are fully standalone.
- Agent — for self-hosted sites, use an offline capability with a short expiry and a budget you're comfortable with. Online capabilities (reservation) only work against the Cloudflare wall today.