Skip to content
Rulebook 0.4.0 · effective Standards CD-0 · OS-1 · OS-2 · OS-3
01 / 08
The case

The party being paid does the counting.

Outcome pricing is already here — support agents billed per resolution, outbound agents per qualified meeting. The number on the invoice comes from the seller’s own dashboard, measured against a definition the buyer never saw written down.

Nobody is arguing the vendor is lying. There is no way for an honest vendor to prove the count, so an honest vendor is priced like a dishonest one — discounted, audited by hand, or capped.

Payment protocols prove the agent was allowed to buy. Nothing proves the seller delivered.

docs/01-context.md §1

02 / 08

The spread between the strict and the broad forecast is the trust gap.

Every one of these numbers describes the same activity. They disagree by two orders of magnitude because they disagree about how much a buyer will let an agent do without a person checking — which is a question about whether the work can be verified, not about whether the agent can pay.

$190–385B

US, 2030. Morgan Stanley, strict “agent executes” standard.

$1.5T

Global 2030. Juniper.

$3–5T

Global 2030. McKinsey.

$15T

“Agentic payment economy” by 2028. Gartner.


What commerce looks like with no remedy: money already moves agent to agent over Coinbase’s x402, a rail Recourse does not yet adapt to — roughly 165M transactions and $50M cumulative by April 2026, about half of it wash or self-dealing, averaging about $0.20 a payment.

docs/01-context.md §2

03 / 08

Pricing power sits with what a counterparty demands.

Never with what the agent chooses. Compute, browsers, and memory are swappable and self-hostable, so they compete to zero. Trust cannot be self-hosted — being the third party is the product.

0.4–1.5%

of GMV

What chargeback-guarantee vendors charge, because a merchant demands the guarantee before it will accept the order.

basis points

what processors fight over

The same transaction, on the side of the table the buyer does not insist on.

docs/01-context.md §1

04 / 08
The wedge

Outcome-based contracts, counted by someone neither side employs.

Agent-to-agent commerce with real stakes is not here yet. The market directly in front of it already has budgets and disputes: vendors billing per resolution, per qualified lead, per booked meeting.

The failure modes already have names.

Attribution disputes. Unclear success definitions. Customer gaming. Measurement complexity. The buyer does not trust the vendor’s dashboard; the vendor cannot prove the count; nobody is the neutral party.

docs/01-context.md §3

The pitch that closes the deal.

“Pay only for third-party-verified outcomes.” The vendor pays 1% of settled value. The buyer pays nothing. The product travels inside the vendor’s own sales motion, the way DocuSign did.

docs/01-context.md §3, §4


OS-1

Support Resolution

One customer conversation resolved by the vendor's agent without human handoff.

OS-2

Qualified Lead

One lead delivered that meets the buyer's stated qualification profile and is contactable.

OS-3

Booked Meeting, Held

One meeting booked by the vendor's agent with an external prospect that the buyer's representative attended and that lasted at least the minimum duration.

The shipped standards, read from the rulebook on this page load. Public definitions settle the argument both sides are having.

05 / 08

Five steps, and the money never touches us.

Recourse instructs the hold on a rail the parties already use. No Recourse-owned balance ever holds a party’s money — if a design required it, the design would be wrong.

Five steps in order — Terms, Hold, Verify, Ruling, Record — each numbered and joined to the next, and each labelled with what it leaves behind: a terms hash, a hold, a verification, a reason code, and a record.01Termsterms_hash02Holdhold03Verifyverification04Rulingreason_code05RecordrecordFive steps in order — Terms, Hold, Verify, Ruling, Record — each numbered and joined to the next, and each labelled with what it leaves behind: a terms hash, a hold, a verification, a reason code, and a record.01Termsterms_hash02Holdhold03Verifyverification04Rulingreason_code05Recordrecord
The vendor proposes terms and the buyer signs them. The buyer funds a hold on its own rail, outside Recourse. Recourse holds a commitment with no balance and only instructs the rail to hold, release, or refund; the funds move from the buyer to the hold and from the hold to the vendor without ever passing through Recourse.VENDORpromises the outcomepty_01K3M8QW…BUYERfunds the holdpty_01K3M9C2…RECOURSEno party’s funds insideCOMMITMENTIDcmt_01K3QF7W…TERMSsha256:9f2c1a4e…STANDARDOS-1BALANCEnoneproposes termssigns the hashinstructs the railTHE BUYER'S RAILthe rail the buyer already usesHOLDfunded by the buyer$5,000.00funds the holdreleased to the vendorThe vendor proposes terms and the buyer signs them. The buyer funds a hold on its own rail, outside Recourse. Recourse holds a commitment with no balance and only instructs the rail to hold, release, or refund; the funds move from the buyer to the hold and from the hold to the vendor without ever passing through Recourse.VENDORpromises the outcomepty_01K3M8QW…BUYERfunds the holdpty_01K3M9C2…proposessignsRECOURSEno party’s funds insideCOMMITMENTIDcmt_01K3QF7W…TERMSsha256:9f2c1a4e…STANDARDOS-1BALANCEnoneinstructs the railTHE BUYER'S RAILHOLDfunded by the buyer$5,000.00BUYERfundsHOLDreleasesVENDOR
06 / 08
Built today

What runs, and what does not.

A deck that overstates the state of the code is the same failure as a product that overstates a capability. So, precisely:

Running.

Parties and agent keys. Terms, canonicalized and hashed. The hash-chained signed record, which a counterparty verifies itself. The commitment lifecycle through active. Signed mandates, so an agent’s authority is bounded and checkable. Outcome statements, issued into the record and verifiable from it. A Merkle transparency log with signed checkpoints, so we cannot rewrite the past without being caught. An MCP server with 12 tools, public discovery, an LCP legal-context document, and a manual rail that cannot custody funds.

Not running.

Verification, adjudication, and sealed party records are specified in the Rulebook and are not implemented. A commitment funded today is not checked against its acceptance criteria, and no dispute can be ruled on it — so every statement issued today is on the claimed basis and says so on its face. No witness countersigns our checkpoints, so a split view is still undetectable from outside. The rail records that a hold was instructed; it does not move money and cannot enforce a release.

A counterparty fetches two documents from Recourse — a commitment's event log and the published signing key — and then runs three checks on its own machine: that each event's hash is the SHA-256 of its canonical form, that each event's prev_hash is the previous event's hash, and that the Ed25519 signature over that hash verifies against the published key. No Recourse code runs on the counterparty's side of the boundary.SERVED BY RECOURSERUNS ON THE COUNTERPARTY’S MACHINERECOURSEEVENT LOGGET /v1/commitments/{id}/eventsprev_hash · hash · signaturePUBLISHED KEYGET /.well-known/recourse-keys.jsoned25519 · key_idrecourse serves both documentsfetchfetchTHE COUNTERPARTYbuyer, vendor, or anyone holding the record01sha256(JCS(event)) == event.hashthe event is unaltered02event.prev_hash == previous.hashthe chain is unbroken03ed25519.verify(hash, signature)the published key signed itNo Recourse code runs here.one mismatch fails the whole chainA counterparty fetches two documents from Recourse — a commitment's event log and the published signing key — and then runs three checks on its own machine: that each event's hash is the SHA-256 of its canonical form, that each event's prev_hash is the previous event's hash, and that the Ed25519 signature over that hash verifies against the published key. No Recourse code runs on the counterparty's side of the boundary.SERVED BY RECOURSERECOURSEEVENT LOGGET /v1/commitments/{id}/eventsprev_hash · hash · signaturePUBLISHED KEYGET /.well-known/recourse-keys.jsoned25519 · key_idRUNS ON THE COUNTERPARTY’S MACHINEfetch both documentsTHE COUNTERPARTYbuyer, vendor, or anyone01sha256(JCS(event)) == event.hashthe event is unaltered02event.prev_hash == previous.hashthe chain is unbroken03ed25519.verify(hash, signature)the published key signed itNo Recourse code runs here.one mismatch fails the whole chain
07 / 08

Each phase builds the asset the next one needs.

v1 is built so phases two through four need no rewrite: parties symmetric, rails as adapters, rules as data, records portable and signed.

1 · now–2027

Hosted outcome contracts and the Commitment API. Standards and Rulebook public.

Volume, and the first outcome records

2 · 2027–28

Platforms and marketplaces. Circle and x402 rails. Agents as first-class parties.

Cross-platform record; network effect

3 · 2028+

Guarantee tier: collateral replaced for high-record parties.

Underwriting moat; take rate doubles

4

The record becomes the bureau of the agent economy.

Durable pricing power

docs/01-context.md §4. Window: 12–18 months before an incumbent or the AAA fills it (§2).

A commitment's event log as a chain of blocks. Each block prints the hash of the event before it in its prev field and its own hash below that, and a connector runs from one block's hash to the next block's prev because the two are the same value. The first block's prev is null. Altering any event changes its hash, which breaks the prev of every block after it.01commitment.proposed2026-07-06T14:02:11ZPREVnullHASHsha256:9f2c1a4e…02commitment.accepted2026-07-07T09:41:58ZPREVsha256:9f2c1a4e…HASHsha256:71b0d833…03commitment.funded2026-07-07T09:44:20ZPREVsha256:71b0d833…HASHsha256:c4e78a05…04commitment.activated2026-07-07T09:44:31ZPREVsha256:c4e78a05…HASHsha256:2d6b91ff…each block carries the hash of the one before itA commitment's event log as a chain of blocks. Each block prints the hash of the event before it in its prev field and its own hash below that, and a connector runs from one block's hash to the next block's prev because the two are the same value. The first block's prev is null. Altering any event changes its hash, which breaks the prev of every block after it.01commitment.proposed2026-07-06T14:02:11ZPREVnullHASHsha256:9f2c1a4e…02commitment.accepted2026-07-07T09:41:58ZPREVsha256:9f2c1a4e…HASHsha256:71b0d833…03commitment.funded2026-07-07T09:44:20ZPREVsha256:71b0d833…HASHsha256:c4e78a05…04commitment.activated2026-07-07T09:44:31ZPREVsha256:c4e78a05…HASHsha256:2d6b91ff…each block carries the hash of the one before it
08 / 08
The close

The record is the asset.

Everything here makes one outcome record richer, more portable, and more trusted. Never deleted, never editable by a party. That is what compounds into a credential buyers start requiring, the way they require SOC 2.

12

packages

621

tests passing

3

outcome standards, as data

24

reason codes a ruling can cite

Most of this was written by agents, reviewed by agents, and argued over by agents — with the commit record to show it. Rulebook 0.4.0, effective 2026-08-26.