Guarantees
Compliance & controls
Compliance here is structural, like everything else: the controls are code on the money path, not a policy document. Every EVM payout recipient is screened against the U.S. Treasury’s OFAC SDN digital-currency list, every spend happens inside on-chain limits no model can exceed, and every settlement produces a public, permanent receipt — an audit trail that exists by construction, not on request.
The controls
| Control | What enforces it |
|---|---|
| Sanctions screening | Every EVM recipient wallet is checked against the OFAC SDN digital-currency list at every door: web and chat submission, the autonomous payout preflight, and manual release. A listed address is refused before any judging happens and cannot be paid by the AI or by a human clicking release. The SDN list carries no Starknet addresses, so the private rail is screened at its EVM funding side only. |
| Bounded spending | The campaign vault enforces the budget, per-mission rewards, completion caps, and a daily velocity limit on-chain. The AI proposes; the contract computes every amount and rejects anything outside its limits. |
| Mandated agent wallets | A founder’s walletless agent wallet operates under a standing policy — an allow-list of exactly which contracts it may call with which funds, with a per-campaign cap the founder set. The policy is enforced by the wallet infrastructure, not by prompt. |
| Verification before payment | Work is checked before money moves — a deterministic contract check first (fetch the artifact, read the chain), the model second, and the model never states an amount. Work that fails verification is refused with the reason. |
| Sybil resistance | One person, one slot on public work: a one-time World ID proof of personhood (Sage keeps only a nullifier — no name, document or biometric), with slot and payout caps counted per person across verified, chain-linked and declared wallets. Underneath: near-duplicate detection across submissions, artifact-content fingerprinting, per-wallet payout caps, daily submission limits, wallet-freshness signals, and funding-graph sibling detection — which reads the public chain to see when several “different” submitters were funded by one wallet. Built after a real rotation cluster was found on a live campaign; every signal informs the operator and none of them refuses a payout alone. |
| Public auditability | Every payout settles as an on-chain transaction with a public proof receipt citing the verified evidence, and accumulates into the recipient’s permanent work record — both machine-readable. |
Sanctions screening, precisely
The screen runs against a vendored snapshot of the OFAC SDN list’s “Digital Currency Address — ETH” entries — currently 120 addresses, snapshot 2026-08-26 — matched exactly and case-insensitively. It is deliberately not a runtime API call: the money path takes no third-party dependency, the check is reproducible byte-for-byte, and refreshing the list is a reviewed code change with a visible diff, never a silent remote update. A hold produced by the screen names the list and the snapshot date in its reason, so the audit trail records which list said no.
Why the refusal rate is a compliance feature
Sage publishes its held-or-refused share next to its payout numbers. A payment rail that pays everything is not a rail, it is a leak — the refusals are what make each payment mean something. Every refusal is recorded with its reason, and every payment can show its work: who was paid, for what verified evidence, under which caps, on which transaction.
What Sage does not claim
- No identity KYC. Participants are pseudonymous wallets. Sage screens wallets against sanctions lists and applies Sybil controls; it does not verify legal identity. Operators who need named recipients use invite-only campaigns, where the recipient list is the operator’s own.
- Screening is list-based. An address absent from the SDN snapshot passes the screen; the screen is as current as its snapshot date, which is printed above and on every hold it produces.
- Custody is stated, not hidden. Walletless agent and recipient wallets are provider-held server wallets bound to policies — convenient and bounded, but not self-custody, and the docs say so wherever they appear. Recipients are never trapped: they can cash out to any address of their choosing from chat at any time, signing a gasless authorization while Sage pays the network fee.