Why Flare specifically
It does not port by find-and-replace
Three Flare-native pieces are load-bearing. Swap the chain and the design stops working rather than merely moving.
FAssets / FXRP
FAssets gives XRP a way onto Flare; almost nothing gives it a reason to move once there. This is a demand-side use for the bridged asset.
FTSO pricing
Invoices are denominated in USD and settled in FXRP at Flare's enshrined onchain feed, so the oracle is load-bearing rather than decorative.
EIP-2612, not EIP-3009
FXRP implements permit, not
transferWithAuthorization. Every x402 implementation
written for USDC assumes the latter, so the signing path was built
against Flare's actual token.
New
An assistant that can spend
An MCP server puts the rail inside a conversation. An assistant can ask what a resource costs, say so in plain language, and pay for it - holding FXRP and no gas token, like every other payer here.
Four tools that cannot spend
price, quote, wallet and
facilitator only read. A price can always be checked
before a single signature exists.
One that can
pay settles a 402 and returns the resource with the
transaction that paid for it. It is the only tool that moves money,
and it is the reason for the two limits beside it.
Caps the model cannot raise
A per-call ceiling and a session budget, both checked against the quote's USD price. A tool argument can lower them for one call and never lift them.
The caps are enforced in the client, because a cap the server sets is not a cap. The payer's own balance is the hardest limit of the three: it holds no gas token, so the worst case for a key that leaks is the FXRP sitting in it. The status page has the transaction from a payment an assistant made this way.
The facilitator is deployed and source-verified on Coston2, and the settlement path is exercised against that deployed contract - including the attacks it is meant to resist. Each claim on the status page has the transaction behind it, and what is planned next is listed as what comes next.