Today we’re opening the beta version of the ProofRails ISO 20022 Sandbox.
https://t.co/OIehxKJn2O
ISO 20022 is the messaging standard financial institutions use to exchange payment information. As stablecoins, onchain payments and agents start moving more money, those new rails still need to connect with the systems finance teams already use.
Our first demo shows that bridge in practice: take a ProofRails payment record and turn it into the ISO 20022 messages used for payment cancellations and investigation outcomes, with the mapping, XML and evidence trail visible end to end.
Up next: real reconciliation.
We’ll ingest ISO 20022 bank records, verify the matching onchain settlement with @FlareNetworks FDC, and use ProofRails to show whether both sides actually match in one auditable record.
Stablecoin payments need to do more than settle onchain. They also need to fit into the reporting, investigation and reconciliation systems financial institutions already use.
ProofRails is working on that bridge, with Flare’s FDC set to help verify onchain settlement against bank records in the next phase.
As $FLR powers the underlying Flare infrastructure, this is a practical example of blockchain data becoming useful beyond the chain itself.
The interview with @0xQuantic is out! 🥳
In this episode of “Krippenreiter TV,” I asked him to what extent Flare could unlock new institutional demand for XRP.
We also covered @FlareNetworks's FCC. 👀👇
[📺] Watch here: https://t.co/bv0m9YsXDh
The simplest way to try the full loop right now is to call ProofRails’ paid demo endpoint POST /v1/x402/premium/fx-lookup with an x402 client.
You get a 402 challenge for 0.001 USD₮0 on @FlareNetworks. The client signs the payment authorization, ProofRails settles it, and the successful response includes the API result plus the settlement tx and receipt ID.
Once the receipt is anchored, open https://t.co/LtrmE5vmXF{receipt_id} to verify the evidence against the onchain commitment.
@ProofRails I read through the docs after seeing this. The flow I’d want to test as an API builder is payment → delivered response → receipt → public verification. With hosted x402 currently powering your own endpoints, what’s the best route for an outside builder to try that full flow?
I think we’re heading into a very interesting Q4.
Market conditions are improving, but more importantly, a lot of work that has been happening behind the scenes is getting closer to showing up in public.
Over the past few weeks I’ve spent a lot of time talking with devs and collaborators working across privacy, agents, data and onchain culture. There’s a lot maturing at the same time.
For people asking me about Flare updates, FCC is probably going to keep us very busy.
Ecosystem builders have already given a glimpse of what can be done with TEEs, but we’re now getting closer to the final stage of deployment, and we will not be short of use cases.
Retail-facing applications are starting to make more sense, while key use cases around confidential execution, protected data and institutional workflows are getting ready. (I can’t give much more detail here without getting myself in trouble, but there’s a reason I’ve been spending so much time around FCC lately.)
At the same time, the next phase of XRPFi is getting closer with Firelight, so the landscape is expanding on several fronts at once.
I’ll be particularly interested in what we see around the upcoming events in Korea and then Ripple Swell.
On a more personal level, I’ve also been digging deeper into the agentic space.
We’re getting to the point where agents can start doing genuinely interesting things for retail, not just serving dev workflows or managed services. Cross-chain execution and arbitrage strategies run by agents are two areas I’m actively looking at.
So I guess it’s time to wake up the @ProofRails intern and devs and have some fun onchain.
The new ProofRails website is live.
We’ve been building ProofRails as a translation layer between onchain activity and the systems businesses already use, turning blockchain events into structured records, normalized receipts and verifiable evidence for reporting, reconciliation and integrations.
Our thinking has evolved quite a bit along the way.
We started with a strong focus on ISO-aligned reporting and compliance structures. Working more deeply with programmable payments, and especially x402, exposed a broader problem.
As payments become machine-readable and increasingly machine-initiated, executing the payment is only part of the problem. Systems also need to understand what happened, why it happened, who or what initiated it, and how to verify and reconcile it afterwards.
That is the direction @ProofRails is moving toward: infrastructure that preserves the context around programmable economic activity and turns it into structured, verifiable evidence that financial systems, applications and agents can use.
x402 is an important part of that direction because it gives machines a standard way to pay over HTTP. ProofRails is exploring the evidence layer around those payments: receipts, attribution, verification, reconciliation and the records needed once machine payments start moving through real systems.
The new site is a much clearer home for what we’re building and where we’re taking it.
https://t.co/pfnG4IBAeI
Exciting to see more builders leveraging @FlareNetworks.
Real applications like payment-gated APIs and AI agents showcase the value of secure, verifiable infrastructure and drive meaningful onchain activity beyond simple transactions. ☀️
1/5 ProofRails is launching a @FlareNetworks mainnet beta for paid APIs and AI agents and one thing I find interesting about the latest update isn't just the payment flow.
It's what happens after the payment.
A thread 🧵
ProofRails's product will definitely expand the use case for AI agents in general. As the machines start to automate more and more tasks for us, they will need pathways to get verified, accurate data, to complete those tasks that can also be auditable.
The simple example would be a payment receipt for a product or service, but as tasks get more complex and rich, agents will need to access multiple APIs to chain their results together in order to produce the best expected outcome for you. In doing so, ProofRails enables the end user an auditable trail so they can understand the total cost of each task.
Ive been working with Quantic for about a year and still amazed by his brilliant ideas and mind.
One of them is this one. ProofRails just launched a Flare mainnet beta where every API call can now come with a verifiable receipt.
Imagine: Payment, proof of delivery, and on-chain evidence, all in one flow.
The rails for the AI economy are being built and this is one of them. Excited to see this built on Flare.☀️
ProofRails is launching a Flare mainnet beta for paid APIs and AI agents.
An x402 payment can now return more than access to an API result: it can automatically produce a receipt linking the settlement to what was delivered, with finance-readable artifacts, signed evidence and a verifiable onchain commitment.
The hosted beta currently powers ProofRails’ own payment-gated APIs. API owners selling premium data or actions to software and AI agents can adopt the same workflow through a scoped integration or self-hosted deployment, accepting payments in USD₮0 while generating records that machines and humans can operate on.
Within this flow, Flare does more than record the payment. The same network also carries the public commitment to the evidence linking that payment to what was delivered.
Developers can test the x402 client flow, add this workflow to an existing API business, or start a new self-hosted service here: https://t.co/Amh9y1ygVh