Four rails. One signed receipt.

How PaymentOracle verifies agentic payments across USDC, XRP, RLUSD and EURC

An autonomous agent paid us 1.272801 EURC last week. The agent received an ES256K-signed receipt back. The receipt is verifiable from any host on the internet, with the same Python snippet that verifies our USDC, XRP, and RLUSD receipts. One signing key. Four payment rails. Three blockchain architectures. Here is how PaymentOracle does it.

Why receipts matter for agentic payments

Most agentic payments today produce no proof. The agent submits a transaction, the network confirms it, the agent assumes the call was paid. The receiving service waits for some confirmation depth and then either grants access or doesn't. If anyone — the agent's owner, an auditor, a billing reconciliation script — later wants to ask "was this call actually paid for?", the only answer is "look at the chain and trust our reconciliation logic."

That works at the scale of one human ordering one cup of coffee. It does not work at the scale of an autonomous agent making a thousand tool calls per minute, or two AI infrastructures settling commercial transactions with each other while their humans are asleep.

A signed payment receipt closes that gap. It is a small JSON object that says: this exact tool call, on this exact rail, at this exact time, was paid for by this exact transaction, and we — the verifying party — will sign that statement with a key whose public half is published. Any third party can re-fetch the on-chain transaction, recompute our reasoning, and verify the signature without trusting us at all.

That is what PaymentOracle issues. One signed receipt per verified payment, in a single schema, on a single key, regardless of which chain settled the underlying transfer.

The four rails

PaymentOracle currently verifies payments on four rails:

The rails span three different verification architectures:

• EVM (Base): a USDC or EURC transfer is detected by scanning the transaction receipt's Transfer events and matching the canonical token contract address.
• XRPL native: an XRP Payment is verified by reading meta.delivered_amount as drops and matching the destination account.
• XRPL IOU: RLUSD travels along trustlines as an issued asset. The verifier requires delivered_amount to be an object with the canonical 160-bit currency hex (524C555344000000000000000000000000000000) and the Ripple issuer address. No ASCII fallback; no fuzzy matching.

Each verifier reads only public RPC endpoints. PaymentOracle holds no private keys for the rails it verifies; it observes deliveries, it does not initiate them. Receipts are issued only after the chain has confirmed the transfer.

Anatomy of a signed receipt

Every PaymentOracle receipt carries the same shape. Here is the live EURC receipt from May 9, 2026 — the first verified EURC payment on the system:

Three things to notice:

1. The payment object describes the underlying transfer in chain-agnostic terms: rail, asset, addresses, transaction reference, and the verifier that signed off on it. Every rail uses the same field names. The IOU-specific rails (RLUSD today) add an optional issued_asset sub-object with issuer, currency_hex, and the canonical-form marker.
2. The receipt_hash is sha256 over a canonical JSON of the receipt body (everything except the hash and signature themselves). This is what gets signed.
3. The signature uses ES256K (ECDSA over secp256k1, sha256). The same algorithm Bitcoin and Ethereum use for transaction signatures. The same key signs all four rails — tooloracle-paymentoracle-es256k-1. The public half is published as a JWK at /.well-known/payment-oracle.json#receipts.public_jwk.

Verifying a receipt from any host

The point of signing is that you don't have to take our word. Three steps in any language: fetch the JWK, recompute the hash, verify the signature.

That snippet works against any of our four receipts. Swap the receipt id, change nothing else. The same canonicalisation rule, the same hashing rule, the same signature verification — regardless of whether the underlying payment was USDC on Base, XRP on the XRPL, RLUSD as an IOU, or EURC on Base.

Integration: quote → pay → verify

For an agent integrating PaymentOracle, the loop is three HTTP calls.

1. Quote

The agent tells PaymentOracle which rail it prefers and what tool call it wants to make. PaymentOracle replies with an intent_hash, the exact amount, the destination wallet for that chain, and an expiry.

2. Pay on-chain

The agent's wallet sends the asset to the quoted destination. For Base rails this is an ERC-20 transfer of USDC or EURC. For XRPL native this is a Payment with the intent hash in a Memo. For RLUSD this is the same Payment shape, but with the issued-asset object as the amount. The agent does whatever its wallet does — PaymentOracle does not need to be in the path.

3. Verify and collect the receipt

The agent submits the on-chain transaction hash together with the intent hash. PaymentOracle reads the chain, confirms the delivery shape (right asset, right destination, right minimum amount, right time window), and writes a verification row. Then a second call exchanges that verification id for the signed receipt.

Receipt issuance is idempotent. Calling it twice with the same verification id returns the same receipt, byte-identical, including the signature. Receipts never change after they are signed.

Three architectures, one schema

The interesting design problem with multi-rail payments is not the verification of any single rail. EVM Transfer events, XRPL tx RPC calls, and SPL token balance changes are all well-documented. The interesting problem is keeping the receipt schema honest across rails so that downstream consumers can write a single verifier and be done.

Three concrete cases shaped the v1 schema:

USDC and EURC on Base. Same chain, same standard, same transfer event shape. The verifier is shared at the architecture level. Only the canonical token contract address differs (0x833589... for USDC, 0x60a3E3... for EURC). About 80% code reuse from the moment USDC was implemented.

XRP on XRPL. Different chain, different RPC, different finality model. Drops as the atomic unit. meta.delivered_amount is a string of drops, not an object. Memos are read from tx.Memos and decoded from hex to UTF-8 to match the intent hash. Block timestamps are returned in Ripple epoch and need a constant added to convert to Unix time.

RLUSD on XRPL. Same chain as XRP, completely different asset model. RLUSD is an issued asset that travels along trustlines between holders and the issuer. The verifier requires meta.delivered_amount to be an object, with the currency in canonical 160-bit hex form (no ASCII fallback) and the issuer address matching Ripple Labs exactly. The amount string must match a strict decimal regex — rejecting exponent notation, leading zeros, and excessive precision rather than silently truncating.

Despite the architectural distance, the public receipt looks the same. Same key, same signature algorithm, same canonicalisation, same JSON field names where they apply. The only rail-specific twist is the optional issued_asset sub-object that appears for RLUSD and would appear for any future IOU-style rail.

Replay protection across rails

One of the easier mistakes in multi-rail payment systems is letting the same on-chain transaction be claimed twice — once for one intent, once for another. PaymentOracle's defense is a single UNIQUE INDEX in the verifications table, scoped to verified status:

The constraint is unconditional. A given transaction hash, lowercased, can be the basis of one and only one verified row across the entire system. If an agent tries to verify a USDC tx hash that was already used for a previous USDC payment, it gets tx_already_used. If it submits the same hash against a freshly-quoted EURC intent, same answer. If it tries to claim an XRPL tx that was already verified for someone else, same answer. There is no per-rail loophole.

This was tested in production while integrating EURC. A previously-used USDC transaction hash was submitted against a fresh EURC intent and was correctly rejected as tx_already_used — not no_matching_eurc_transfer, which would also have been correct but less informative. The replay-protection layer fires before the rail-specific verification logic runs.

What's next

Four rails is enough to start. Two stablecoins (USDC, EURC), one chain-native asset (XRP), one issued asset (RLUSD). Two chains, three architectures, one signing key, one schema.

The natural next addition is a fifth rail on Solana — a fourth architecture, since SPL tokens differ from both EVM and XRPL in how transfers are recorded and how recipient accounts are derived. But that work waits for distribution to catch up. The bottleneck for agentic payment infrastructure right now is not how many rails exist; it is how many agents and builders know that any of them work end-to-end.

If you build agents that need to pay for tool calls or sell access to your own tools for payment, PaymentOracle is live, all four rails are reachable today, and every receipt we have ever issued is publicly fetchable.

FAQ

Related reading