Agentic commerce records

Payment rails prove value moved. Signed records prove what it was for.

AI agents call paid APIs, buy data, trigger usage charges, settle invoices, and delegate work. A payment confirmation shows value moved. It rarely shows what the agent was allowed to do, which policy applied, or what result came back. Originary turns those events into signed records another party can verify without your logs.

payment-eventverified offline
Issuer
https://api.vendor.example
Event
authorized
Action
POST /v1/market-data/search
Signature
Ed25519 30cf81d6...
observation record - not a payment instruction
Payment contextObserved settlementCounterparty acknowledgmentVerifies offline
Two different facts

The rail proves the payment. The record proves the context.

The payment rail proves
Value moved.

A charge was authorized, captured, or settled between two parties.

The signed record proves
What it was for.

The action, the policy or mandate, the result, the issuer, and the time, bound into one verifiable artifact.

The real questions

When an agent pays, "did money move?" is the easy part.

  • What was requested, and which policy or mandate applied?
  • Who or what authorized the action?
  • What result did the vendor return?
  • Was the action allowed, denied, captured, refunded, or disputed?
  • Can a customer, auditor, or partner verify the record later, without your systems?
Worked example

A research agent calls a paid market-data API.

The payment rail shows a charge was authorized. The signed record shows the endpoint, the terms that applied, the payment reference, the result digest, the issuer, the time, and the signature a counterparty can check.

The record preserves the payment artifact as evidence: a signed settlement receipt travels in the record's proofs, and settlement metadata is carried as a digest by default so raw payment headers never enter the signed payload.

x402 owns the payment flow and its payment-native signed artifacts. Originary preserves those artifacts inside portable records and evidence bundles that verify offline.

Verify it
npx -y @peac/cli verify ./payment-event.jws --public-key ./jwks.json
Expected
Signature valid (offline)
event: authorized - bound to POST /v1/market-data/search
payment-eventverified offline
Issuer
https://api.vendor.example
Event
authorized
Action
POST /v1/market-data/search
Agent
research-agent-v3
Policy
terms:v3 sha256:81af2c...
Ref
rail reference - x402-style
Result
200 sha256:9a3c1d...
Time
2026-06-12T14:08:12Z
Signature
Ed25519 30cf81d6...
observation record - not a payment instruction
Where it fits

Records can sit around commerce workflows you already run.

x402 paid API callsUsage-billed API eventsAP2 or MPP payment flowsGateway allow, deny, route, or throttle decisionsAgent-to-agent commerce handoffsRefunds, disputes, and settlement observationsMandate and terms-version bindingProcurement and audit-review bundlesCounterparty acknowledgment recordsAgent spend attribution for finance and audit review

Examples are interoperability surfaces, not partnership claims. Originary composes with payment rails, identity systems, and agent protocols.

Boundaries

What Originary does not do.

  • It does not custody funds.
  • It does not process payments.
  • It does not replace your ledger or accounting system.
  • It does not decide tax treatment.
  • It does not require a chain, or another company to use Originary.

It issues, inspects, and verifies signed records from commerce workflows you already run.

What v0.16.2 adds

Broader evidence coverage, same wire format.

PEAC v0.16.2

Portable evidence beyond single signed records: the wire format stays stable while evidence coverage broadens.

Paid resource recordsPaid MCP tool recordsLinked counterparty acknowledgmentsMerkle commitment helpersExternal evidence anchoringAgent spend attributionAgent run lineage recordsConsented action recordsRuntime lineage exports

Broader evidence coverage, not a new payment rail, gateway, or policy engine.

Start with one paid workflow where another party asks what happened.

A paid API call, an MCP tool that triggers a charge, a gateway decision, a payment authorization, or a dispute review.

Logs stay local. Signed records travel.