Introducing escrow-oracles: the trust layer for agentic payments

Where this came from

We've been shipping switchboard — the substrate AI agents use to pay each other — for the last two months. The on-chain side is a Solidity escrow with timeout + refund. The off-chain side is HTTP-402 paywalls, ZAP binary wire, and a post-quantum signed envelope. Sixteen animated scenes show the protocol from a café walk-by to a five-city work trip.

But the scenes always assume someone confirms the work. A human taps "release funds" or a timeout fires. That works for human-in-the-loop flows. It breaks the moment two AI agents need to settle a payment and there's no human to click.

Patty and Abhi gamed out this scenario for weeks. The verdict:

Transactions need to be transparent for everybody. Settlements should depend on quantitative outcomes, not qualitative promises. Delivery means everything.

That sentence is the whole spec. Today we're publishing the first draft: kcolbchain/escrow-oracles — an open standard for autonomous, anonymized agents that attest objective delivery conditions to switchboard's escrow contract.

Seven design principles

1. Transparent. The release condition lives in the PaymentOffer. Any party — including the payer's wallet UI — independently re-checks. No black boxes.
2. Quantitative. v1 supports three deterministic check types: url_check, hash_check, event_check. No LLM grading, no subjective work-quality judgments.
3. Operator-agnostic. An oracle is a role, not a runtime. A bash script with a keypair, a Rust daemon on someone's NAS, a Lambda function — all participate equally.
4. Lossless. Oracles never custody funds. They only sign attestations. The escrow contract releases on K-of-N agreement. No path to steal.
5. Anonymized. Each attestation is signed with a fresh ephemeral key derived from a master key. There's no long-term identity in the on-chain trace.
6. Lottery-rewarded. Correct attestations enter a per-epoch VRF lottery; payouts go to stealth addresses derived from the master key. Probabilistic over correctness, not deterministic per attestation.
7. Health-adaptive. Protocol parameters (K, attestation window, reward rate) auto-adjust when participation or false-release rate drifts.

How the lottery works (and why it matters)

The reward mechanic took the longest to design. Two constraints fought:

• Oracles should be paid for honest work, or they don't bother running.
• An adversary shouldn't be able to game which attestation pays — buy the lucrative ones, ignore the rest.

The compromise: a per-epoch VRF lottery. Every settled escrow siphons 0.5% of its value into a reward pool. At the end of each epoch (one day), a VRF picks ten random winners from the set of attestations that matched the K-of-N consensus that period. Each winner is paid an equal share of the pool, delivered to a stealth address derived from their master key. The master-key holder spends from it privately.

The adversary's calculus shifts. With deterministic per-attestation rewards, they can buy the most lucrative ones cheaply. With a lottery, every correct attestation has equal expected value; to extract reward systematically, the adversary must corrupt the entire pool — which costs the whole bond budget, not a sliver of it. The economic security scales with corruption cost, not with per-action value.

And the on-chain trace is clean: anonymous attestations submitted, anonymous withdrawals later, no link between the two.

An oracle is just an agent

One thing we want to be explicit about: there's no AI requirement. The spec is operator-agnostic. The v1 attestation rule is "did the URL return 200 with the committed body hash within 30 seconds" — a deterministic check. A 50-line bash script with a keypair can do it.

We expect the network to be a mix of:

• Small daemons running on people's home servers, paid in epoch lottery
• Hosted attestation services (run by infra providers, packaged like Pyth publishers)
• Hanzo-backed runtimes that bundle KMS + identity (no requirement, just a clean integration path)
• LLM-driven agents for richer checks once v2 specifies subjective attestation types — explicitly out of v1

All four shapes implement the same wire spec and earn from the same lottery pool. The standard is what unifies them.

How it composes with switchboard

• switchboard AgentEscrow.sol gets a new releaseByAttestation() entry point. K-of-N attestations from the registry release the escrow without a human's confirmPayment().
• switchboard's composable refund policies (issue #46) use this network as the evidence source for OracleSLAPolicy. Policies are the rules; oracles are the witnesses.
• switchboard's PQ envelope (RFC #33) sets the signature algorithm registry. Attestations default to ml-dsa-65; the network is forward-compatible with the post-quantum migration the rest of the stack is already doing.

Three sharp pieces of switchboard, snapped together by a fourth: the oracle network is what turns the static escrow contract into a live trust layer for agentic flows.

How to contribute

The repo opens with a five-level contribution ladder. Each level has at least one help wanted issue with a concrete deliverable checklist:

The game

The game is its own animal. Three modes share one ~400-LOC simulator core:

• Explore. Slider sandbox for protocol parameters (K, N, window, adversary share, latency). Live readouts: success rate, P95 latency, attack cost, gas per release. Teaches K-of-N tradeoffs by letting you feel them.
• Adversarial. Pre-built attack scenarios: Byzantine oracles, lazy oracles, equivocation, network partition, signature replay. Configure adversary budget, run, see if the protocol holds. Teaches threat-model-as-config.
• Compose. Visual pipeline builder. Drag-compose url_check AND hash_check within 5min by 2-of-3 attesters. Output is a real escrow-policy.json the other two tabs can simulate against. Compose isn't a separate world — it's the canonical config feeding the rest.

Game v1 ships once L0 lands; it doesn't block on later levels. The simulator is the most legible product surface here — the thing non-cryptographers can use to build intuition for the protocol's parameter choices.

Why we made this a separate repo

We considered putting it inside switchboard/ as a subdirectory. Rejected because:

• Oracle operators don't need to track every switchboard PR. The spec evolves on its own clock.
• Independent versioning. switchboard pins to a spec version; we ship spec updates without churning switchboard's release cadence.
• Onboarding. A new contributor can read the escrow-oracles repo in 30 minutes without wading through switchboard's full stack.

The dependency arrow points one way: switchboard consumes the spec. The new repo never imports switchboard.

What's next

• This week. L0 examples in Go, Rust, and TypeScript. Already invited contributors via issue #2.
• Next two weeks. L1 reference implementations for all three check types. Issue #3.
• Next month. The contract: EscrowOracleRegistry.sol with K-of-N verification + reward pool + epoch lottery. We're targeting Lux first, Base second.
• Q3. L3 — FROST aggregation. K signatures compress to one on-chain; calldata drops by 80%+ at K=5.

Try it

• Read the spec: docs/SPEC.md
• Run the L0 example: python examples/hello-oracle.py --request-id req-7f3e --policy-url https://httpbin.org/status/200
• See it in the lab: the new soon · oracle game placeholder on the switchboard lab links straight to the game issue.
• Pick an issue: help wanted. Comment to claim.

Patty and Abhi's bigger thesis is that agentic wallet management is going to be a basic financial right. We don't get there with humans clicking confirmPayment. We get there by building trust primitives that make zero-counterparty, zero-loss agent-to-agent commerce safe enough to be the default. escrow-oracles is one of those primitives.

If you've got a keypair, you can run one.