AP2 for Ethereum Settlement | Rialto research project

Summary

This research is organized around five questions

What is the problem? AP2 authorization and Ethereum settlement do not yet have a common, testable handoff.
What is missing today? Artifact binding, replay and cap policy, trust resolution, custody rules, and shared tests.
What could Rialto provide? A narrow optional profile, not another payment protocol.
What needs to be tested? Known-answer vectors and negative cases before more architecture is frozen.
What does the industry need to work on together? Binding rules, trusted attesters, evidence, disputes, and the right standards venue.

Who this is for: AP2 implementers, Ethereum payment and wallet teams, and institutional architects evaluating agent payments.

Authorship and status. This is an individual research contribution by Redwan Meslem, published with his EEA affiliation. It is not an EEA standard, position, member work product, or statement of member consensus. It is also not an adopted AP2, FIDO, EAS, or Ethereum standard.

1. What is the problem?

The authorization and the payment can become disconnected

Imagine that a company authorizes an AI agent to pay a supplier. AP2 can carry evidence of what the agent was allowed to do. If the supplier wants payment on Ethereum, a smart contract or wallet must still know which AP2 authorization applies to which transfer.

AP2 authorization

Who approved the purchase, what was approved, and under which conditions?

Ethereum settlement

Which chain, account, recipient, token, amount, contract, and deadline?

There is no agreed AP2-to-Ethereum profile that binds these two records and tells independent implementations how to verify the result.

Without that shared profile, each wallet, agent, payment provider, or smart contract team may make different choices. A technically valid payment could exceed the intended amount, go to the wrong address, be repeated, or fail to preserve enough evidence for audit and dispute handling.

2. What is missing today?

Six practical gaps stand between authorization and settlement

A common reference

Ethereum needs an exact, versioned way to reference the AP2 authorization that was verified.

Transaction boundaries

The authorization must be tied to the correct chain, contract, payer, payee, asset, amount, and expiry.

Replay protection

The same authorization must not be reused or counted twice. Spending limits need a defined accounting scope.

Trust policy

An institution needs to know who vouched for an agent or counterparty, what they vouched for, and whether that claim is still valid.

Delivery and disputes

Payment authorization does not prove that a service was delivered. Some transactions may need escrow, evaluation, or an appeal path.

Proof that systems agree

Published test cases are needed so implementations in different languages produce and verify the same result.

3. What could Rialto provide?

A small interoperability profile, not another payment protocol

Rialto asks whether a limited set of rules can connect existing AP2 and Ethereum components. The goal is to reuse the work already underway, make the handoff testable, and identify which questions remain outside the technology.

Reference the AP2 artifact

Preserve the selected AP2 version, artifact type, and digest rules instead of inventing a second interpretation of the authorization.

Authorize one Ethereum settlement

Bind the transfer to its chain, contract, parties, asset, amount, nonce, deadline, and spending scope.

Apply optional trust requirements

Let an institution check attestations from authorities it recognizes without pretending that an on-chain claim is automatically trustworthy.

Use escrow only where needed

Explore ERC-20 service-job escrow for transactions that require conditional release, while keeping simple settlement simple.

What Rialto would not solve

It would not decide which institutions are trustworthy, prove that a physical or digital service was delivered, create a universal cross-chain spending limit, replace consumer protection or court processes, or turn draft Ethereum proposals into standards.

4. What needs to be tested?

The work should begin with evidence, not a standards claim

The first deliverable is a fixture and negative-test suite. A narrow prototype can then settle one verified AP2 authorization as one ERC-20 payment on one EVM test network. The work should answer the following before any wire format is frozen.

Can Solidity, TypeScript, and Python independently produce and verify the same AP2 reference and settlement signature?
Do nonce, expiry, amount, payee, asset, chain, and contract checks fail safely?
Can the same authorization be replayed through another contract, chain, wallet, or payment path?
What information becomes public on-chain, and can commitments reveal or link sensitive commercial activity?
How are expired, revoked, replaced, or stale trust attestations handled?
If escrow is used, what happens when the evaluator is conflicted, unavailable, or challenged?
Can independent implementers pass shared conformance tests without coordinating private assumptions?
Does an external security review confirm the composition and its failure modes?

The threshold is simple: two independent implementations should reach the same result from the same inputs, reject the same invalid transactions, and produce evidence that an auditor can reconstruct.

5. What does the industry need to work on together?

The difficult questions cannot be answered by Rialto alone

Several of these questions are already visible in the AP2 repository. The proposals differ, but together they show demand for a common answer at the boundary between authorization, settlement, trust, delivery, and evidence.

AUTHORIZATION TO SETTLEMENT

What must an Ethereum transaction verify?

Which AP2 data should be bound to the on-chain payment, and should the contract, wallet, or payment facilitator enforce it? Raised in AP2 issue #255.

CONFORMANCE

Which exact bytes should every system hash?

Can any independent implementation derive the same mandate reference without relying on an undocumented assumption? Raised in AP2 issue #265 and discussion #262.

TRUST

Who may vouch for a counterparty agent?

What qualifies an attester, which claims should institutions accept, and how should revocation and stale data be handled? The counterparty question appears in AP2 issue #280.

DELIVERY AND DISPUTES

When is payment final?

When is direct settlement sufficient, when is escrow needed, who confirms delivery, and what happens if the parties disagree? The delivery gap is raised in AP2 issue #224.

AFTER THE PAYMENT

What did the agent actually do?

A payment receipt can show that money moved without showing whether the agent booked, delivered, or completed the authorized task. Raised in AP2 issue #290.

TIME AND EVIDENCE

How can a reviewer prove when authorization existed?

A signature shows who signed and what was signed. Should stronger evidence show that the mandate existed before a payment, price change, or revocation? Raised in AP2 issue #293.

Three decisions require the right participants

Minimum common rules: payment providers, agent developers, wallets, smart contract teams, security reviewers, and institutions need to agree on what every implementation must verify.
Trust and accountability: institutions, identity and attestation providers, risk teams, and consumer-protection experts need to define who can make trusted claims and how disputes and liability are handled.
The right standards venue: the industry must decide what belongs in AP2 or FIDO, what belongs in an Ethereum standard, what should remain implementation guidance, and where joint conformance tests should live.

Rialto is not intended to answer these questions unilaterally. Its purpose is to make the gaps concrete enough for the relevant communities to decide what should be standardized and what should remain implementation-specific.

Research material

Technical detail and primary references

For the data structures, open decisions, test gates, and security requirements, read the canonical technical specification. The illustrative demo shows the proposed flow. Contributions and criticism are welcome in the GitHub repository.

Primary references

Practical publication sequence

Publish the evidence before proposing a standard

The research should progress from corrections and test evidence to institutional coordination. A formal profile should be the result of that work, not the starting assumption.

Five things people get wrong when connecting AP2 to EthereumPublish the recurring technical corrections as a short standalone article.
AP2 for Ethereum settlement: vectors and negative testsPublish known-answer vectors, cross-language verification, replay, expiry, cap, revocation, and failure cases.
FIDO implementation reportDocument what happened when AP2 was composed with EVM settlement, including where the specifications aligned and where implementation assumptions diverged.
Institutional trust resolution for agent paymentsDevelop attester authorization, registered-UID resolution, staleness policy, and finality assumptions as a separate research draft.
Decide whether a formal profile is justifiedUse implementation evidence and industry feedback to determine what belongs in AP2 or FIDO, an Ethereum standard, implementation guidance, or a combination.