Alexander Lawson · May 2, 2026
Daniel Olshansky published "The Missing Key to x402" last week, and he got the diagnosis right. The x402 payment primitive works. Settlement is clean. But the infrastructure sitting on top of it is missing entire floors, and his article is the most precise breakdown I have read of what sits between "agent pays $0.01" and "agent operates safely at scale."
I talked to his team at Grove back in April (they have 2,776 users on BASE and are building a data quality index), so I have some context on where their thinking lands. My goal here is to extend the argument, not push back on it. There is an orthogonal problem that persists even after every one of his proposals is implemented, and I think he would agree it belongs one layer up.
His four structural gaps in x402 as it exists today:
No scoped access control. An agent that can pay can do anything the endpoint allows. There is no permission boundary between "read my balance" and "transfer my funds."
No key rotation or revocation. If an agent's signing key leaks, there is no protocol-level way to invalidate it without migrating to a new wallet entirely.
No hierarchical key management. A parent agent cannot delegate a time-bounded, scope-limited credential to a sub-agent. Every agent holds the same root key.
Hot key exposure. Agents that sign transactions hold live private keys in memory. The blast radius of a compromise is total.
His six proposed capabilities follow logically from these gaps. He wants persistent session auth, granular scope authorization, key rotation with revocation, and credential delegation to sub-agents. He also argues for usage metering and integration with traditional billing, which bring the pattern closer to how Stripe and AWS already handle API access.
The scale makes all of this urgent. The Castle Labs dashboard shows 50 million x402 transactions and $48 million in volume as of late April, with 98,000 ERC-8004 registered agents. The validation registry, which should indicate how many of those agents have been verified, remains sparsely populated. Agents are transacting at scale without the session management infrastructure that traditional APIs have had for two decades. OAuth, scoped API keys, token refresh, and rate limiting are table stakes for any REST API. The x402 ecosystem has none of them at the protocol layer.
Here is where I think the conversation needs to expand. Olshansky's proposals solve the question: "Is this agent authorized to act?" They do not touch the question: "Should I transact with this agent at all?"
Walk through a concrete scenario. An agent presents a valid session token, scoped to the correct permission set, signed by a properly rotated key, delegated from a verified parent. Every one of Olshansky's six capabilities is satisfied and the agent is authenticated, authorized, scoped, and metered.
Now: is the operator on a sanctions list? Has the wallet been used in previous exploits? Is the agent's infrastructure running through a jurisdiction that makes the transaction non-compliant? Was this wallet minted yesterday specifically to drain a new protocol?
None of those questions have anything to do with key management. You can have perfect session infrastructure and still route funds to a sanctioned entity because nobody checked.
Authentication answers "who." Trust answers "should I."
Anthropic's research on human oversight in agentic systems found that 93% of permission prompts are auto-approved, which means the assumption that a human verifies each agent interaction has already failed in practice. When oversight is automated away, the only remaining check is whether the counterparty is actually trustworthy before value moves.
One of Olshansky's implicit concerns is the friction of per-request signing. Every x402 call requires a fresh cryptographic signature, which keeps the private key hot and available for every single interaction. That creates a UX problem (latency on every call) and a security problem (the key is always exposed).
Circle launched nanopayments on April 29 and it addresses this directly. The mechanism uses EIP-3009 off-chain authorizations that batch into periodic on-chain settlements. An agent pre-authorizes a spending ceiling, individual requests draw from that ceiling without new signatures, and settlement happens in aggregate. The hot key signs once at session start rather than on every single request.
That solves the re-signing friction entirely. Stripe's Link CLI already does something similar for traditional credentials, delegating short-lived tokens to sub-processes that spend against a pre-authorized budget. Circle brings the same pattern to on-chain settlement, and the two approaches together cover most of what Olshansky describes as the "persistent session" problem.
But batched authorization does not tell you whether the counterparty deserves a spending ceiling in the first place. You have reduced signing overhead. You have not reduced counterparty risk.
Revettr is counterparty risk scoring for agentic commerce. One endpoint, one cent, one verdict. An agent or gateway calls /v1/score before initiating a transaction and receives a 0-to-100 risk score with a per-signal breakdown. The signals cover sanctions screening, wallet history, domain hygiene, IP reputation, and infrastructure posture.
The scoring runs across five signal categories in parallel. OFAC, EU consolidated, and UN Security Council sanctions lists. WHOIS age and DNS configuration. GeoIP jurisdiction and VPN/Tor detection. Wallet age, transaction history, and balance patterns. TLS posture and hosting classification.
The result comes back as a signed attestation envelope in compact JWS format, verifiable against a published JWKS endpoint at revettr.com/.well-known/jwks.json. Gateways can cache it, verify it independently without calling us again, and compose it with other trust signals from other providers. The attestation expires after one hour and refreshes on upstream list updates (OFAC publishes irregularly, so time-based TTLs alone are not sufficient for compliance signals).
This is live today at revettr.com/v1/score, paying $0.01 USDC via x402 on Base. The same API also supports MPP on Tempo and Stellar, because the trust question is protocol-agnostic even though the payment rails are not.
The full trust stack for agentic commerce is not one product or one protocol. It is four independent layers that compose together:
ERC-8004 provides identity. An agent registers on-chain with a verifiable identifier. This is the "who are you" layer that 98,000 agents have already completed through Castle Labs.
Olshansky's session/key management layer provides authorization. Scoped permissions, rotatable keys, hierarchical delegation, and metering. This is the "what can you do" layer that does not exist yet but his article defines precisely.
Revettr provides trust attestation. Pre-transaction risk scoring that answers "should I transact with you" based on compliance, behavioral, and infrastructure signals. This is the "are you safe" layer, and it runs before any payment ceiling is set.
Circle nanopayments and x402 provide settlement. Batched off-chain authorization with periodic on-chain finality. This is the "how do we pay" layer that already works.
None of these layers depend on each other's internals. An agent can have a valid ERC-8004 registration, proper session credentials, a clean Revettr score, and still fail at settlement because the payment channel is underfunded. Conversely, an agent with perfect settlement infrastructure can fail at trust if the wallet got flagged yesterday by OFAC.
A gateway can enforce any subset it wants. The minimum viable trust check is a single Revettr score call before authorizing a payment ceiling, and that alone filters out a surprising amount of bad traffic.
A pre-transaction risk check in practice:
Response:
You integrate this into your gateway's decision logic however you want. Score above 70 means authorize the session. Below 40 means reject. Between 40 and 70, you might require additional verification or reduce the spending ceiling. The threshold is yours to set and we do not enforce policy on what counts as "safe enough."
Olshansky's article gives the ecosystem a clear implementation target for session management, and Circle's nanopayments give it batched settlement. ERC-8004 gives it identity. Revettr fills the trust layer that sits between identity and payment, and all four compose without requiring any single vendor to own the full stack.
The risk_check_url specification lives at revettr.com/blog/rfc-risk-check-url and the discovery endpoint resolves at /.well-known/risk-check.json. Revettr is the reference implementation for compliance_risk within the Composable Trust Evidence Format (A2A RFC #1734).
If you are building session management, key delegation, or gateway infrastructure for x402 agents, I would genuinely like to talk about how trust attestation composes with what you are building. We are also co-founders of the trust-evidence-format organization, which is formalizing the multi-provider attestation envelope so that different trust providers can interoperate without vendor lock-in. The endpoint is live and the spec is open for anyone to implement against.
I am at alexander@revettr.com and @revettr_x402 on X.