x402: Sei’s Proposal For Fee Transparency

Facilitators are the gateway in x402: they greatly simplify blockchain UX by settling valid payments onchain on behalf of servers. 

With broad support from major facilitators, including PayAI, Dexter, and x402rs, Sei Labs submitted a proposal for the x402 repo that aims to establish transparency for facilitator fees.

The underlying assumptions for this proposal are fairly straightforward: 

• Facilitator fees may be optional in theory, but they are common in practice. 
• In its current design, x402 transactions settled in stablecoins will always require facilitators. 
• With agentic AI, the volume of facilitator fees are likely to grow exponentially.

Currently, servers can’t reliably route across multiple facilitators based on cost, and users can’t easily audit what they’ve paid in fees.

To address this, Sei is proposing adding an extension called facilitatorFees. The goal is not to pick a best fee model, but to standardize disclosure. 

To achieve this, we’ve proposed adding four things to the x402 protocol:

1. A quote endpoint so servers can ask facilitators, “what will you charge for this settlement?”
2. A settlement receipt so users can see what fee was actually charged
3. An optional configuration that would allow a cost-sensitive user to express soft constraints like “try not to exceed X in facilitator fees”
4. A routing mechanism for servers to route to facilitators based on fee mechanics

What is x402, and why does it matter?

The original architects of the Internet predicted that money would, one day, move like information. And so in 1997, they included the HTTP 402 error code as a placeholder for a future digital payments protocol that could be baked directly into the browser. 

x402’s original pitch was almost deliberately boring. It resurrected the long-unused code path and made payments look like standard HTTP retry behavior:

1. User requests a paid resource
2. Server replies 402 with payment requirements
3. User signs a payment payload and retries with a header
4. Server verifies/settles and returns the resource with a payment response header

This HTTP-native shape is partially why x402 is a good fit for AI agents and machine-to-machine commerce.

What are facilitators, and why do their fees matter? 

In x402, a facilitator is a service that can:

• Verify payment payloads against a server’s declared requirements, and
• settle valid payments onchain on behalf of servers.

Facilitators are optional in the protocol, but they’re common in real deployments because they remove a lot of operational burden and abstract away the complexity of settling on different underlying chains. You don’t need to run RPC infra or build bespoke signing/settlement logic for each chain, and in many setups the facilitator can sponsor gas so that users don’t need native tokens.

Facilitators are not free to run, but, until recently, they were free to use. That changed early this year. The convenience of facilitators becomes relevant the moment fees enter the picture because facilitators will now have the power to direct some (non-trivial) revenue-generating activity. 

Since this change, facilitator pricing models have started to diverge. Two examples include:

• A flat-fee model after a free tier
• A percentage-based fee from other facilitators

That’s not inherently a problem. Markets are (generally) good, after all. The problem is that x402 has multi-facilitator routing in v2, but no standard way to express facilitator fees. This is likely to lead to fragmentation.

Without a standard,

• servers can’t compare facilitators deterministically,
• “fee-sensitive routing” becomes more complex to implement, and
• clients can’t reliably log or audit the fees they paid. 

Optional configuration: facilitatorFeeBid

The facilitatorFee extension allows for an optional, lightweight preference. With our proposal, users can express soft constraints like:

• maxTotalFee
• preferred fee asset

The server is not required to honor these preferences and the canonical payment amount remains authoritative. The proposal intentionally keeps this configuration as advisory, not binding. This is important because binding bids would create new failure modes that would require additional engineering. 

The case for doing this now

This proposal isn’t hypothetical future-proofing. Fee models are already diverging, and v2 has already pushed the ecosystem toward multi-facilitator routing.

Today, we are still within a narrow window where the tech is still young enough to standardize before additional integrations ossify. Our proposal is a bet that it’s better to standardize disclosure early, while adoption is still fluid, than accept fragmentation and, in two years, try to unwind a vastly more complex protocol.