Docs
How Warifu works
Do not trust the agent. Bound it. Prove it. Invite attack. This page is a short map of the system and of the ways you can check it without trusting us.
What it is
Warifu is an evidence-gated treasury for agent-run payments on Arc. An AI agent may read an invoice and propose a payment. A deterministic kernel decides. A vault contract enforces hard limits even if the kernel's signing key is stolen. Every decision leaves a signed receipt you can verify.
The flow
- The agent proposes. Extraction output is advisory text; it cannot release funds and is shown collapsed and labelled advisory.
- The kernel checks. Sixteen checks run against the signed engagement, kernel-collected evidence and the policy. The verdict is RELEASE, HOLD, ESCALATE, REJECT or REPLAY. No model output is a release condition.
- The vault releases. The contract verifies the kernel's attestation, the payee binding and its own caps. A stolen signer is still bounded by the vault.
- A receipt is written. The receipt is hashed, signed and anchored by the vault's Released event.
The checks
| ID | Name | What it does |
|---|---|---|
| K-01 | STRICT_SCHEMA | The intent must parse exactly: no extra fields, no binary, bounded text. |
| K-02 | PRECISION_EXACT | Amounts are read as exact integers in base units; ambiguous separators go to a human, rounding is refused. |
| K-03 | DOC_TYPE_SIGN | Only invoices are payable; credit notes and statements are not. |
| K-04 | IDEMPOTENCY_DEDUPE | The same intent, a near-duplicate or an already paid milestone is a replay or an escalation. |
| K-05 | ENGAGEMENT_BINDING | There must be an active signed engagement and a matching milestone in its window. |
| K-06 | PAYEE_BINDING | The payee address comes from the signed engagement; an address printed on an invoice never changes it. |
| K-07 | CURRENCY_DECIMALS | Currency and decimals must match the vault token; absurd scales are rejected. |
| K-08 | AMOUNT_CONFORMANCE | The amount must equal the milestone amount exactly; overpayment is rejected, underpayment escalates. |
| K-09 | EVIDENCE_MATCH | Evidence the kernel collected itself must match the milestone requirement; missing evidence holds the payment. |
| K-10 | EXTRACTION_CONSENSUS | Two independent extractions must agree on payee, amount and references. |
| K-11 | INSTRUCTION_CHANGE_HEURISTIC | Text that tries to change payment instructions is flagged for a human. |
| K-12 | AUTHORITY_ENVELOPE | Per-payment, daily and velocity limits, human gates and the escalation budget. |
| K-13 | COUNTERPARTY_SCREEN | Optional counterparty screening; pending or disabled screening is visible in the receipt. |
| K-14 | LIQUIDITY_AND_TIMING | Vault liquidity, signed payment terms, the discount window and the plan timing. |
| K-15 | RECONCILIATION_WITNESS | After settlement, on-chain state is compared with what the kernel decided. |
| K-16 | CIRCUIT_BREAKER | A tripped breaker or a paused vault holds everything. |
Verify a receipt
In your browser: open the receipt verifier. On the command line:
pnpm verify-receipt <receipt.json | 0xhash> --vault <vault> --rpc <your-own-rpc-url>
Exit code 0 verified, 1 not verified, 2 usage or input error. The kernel signer is read from the vault, not from the receipt.
Verify a certificate
pnpm lbc verify <vault> --rpc <your-own-rpc-url> --artifact <foundry-artifact.json>
- 0 VALID: your recomputation agrees with the certificate.
- 10 STALE: on-chain configuration changed since it was built; the diff says what.
- 20 UNVERIFIED: the chain could not be read or the inputs could not be checked.
A certificate is a calculation under stated assumptions, empirically tested; it is not a proof. Open one.
Threat models and exclusions
- T1 a forged or misleading document or evidence: the kernel and its evidence collectors are the defence.
- T2 a compromised model or prompt: no loss path, since model output cannot release funds; liveness can still be disrupted.
- T3 a stolen kernel signer: the vault caps, payee binding and rings bound what can leave per time horizon.
What the bound does not cover:
- X-OWNER-KEY Owner key compromise (T4): loss equals the vault balance.
- X-PAYEE-KEY Payee key compromise receiving authorized funds (T5).
- X-TOKEN-ISSUER Issuer actions on the token: blocklisting, freezing, upgrade or depeg.
- X-CHAIN Chain halt or deep reorganization.
- X-RPC A dishonest RPC endpoint on the verifier's side.
- X-CONTRACT-BUGS Contract bugs outside the modelled semantics.
- X-WORK-QUALITY Quality or delivery of the work: the certificate bounds who, how much and how fast, not whether the work was good.
- X-AVAILABILITY Availability: with a stolen kernel signer the 64-slot release ring can be filled with dust to block legitimate payments for up to 24 h. This is not a fund-loss path.
- X-OTHER-TOKENS Tokens other than the configured settlement token.
Status and limits
- TESTNET The public challenge and the sandbox vault run on testnet only, hold no real funds and offer no prize. Attack traffic is never counted as traction.
- The contracts and the code have not had an independent security review. Contract caps are deliberately tiny.
- Planner figures are SIMULATED; replayed content is RECORDED; B1 is our reimplementation of a pattern, not Circle's code; B0 is the vendored decision path of Circle's sample with only network edges stubbed.
- Responsible disclosure and testing terms are on the security page.