We Built Fiat Rails to Distribute the Flares

Humans can now buy AVT with euros. They can do it on the mainframe directly — pay with a card, receive AVT inside ten seconds, walk away with a working developer account that was created on the back of the Stripe webhook before they finished blinking. Or they can do it through any federated operator’s own storefront, with the operator’s name on the Stripe descriptor and the operator’s branding on the page, while the mainframe quietly handles the money, the mint, and the regulatory surface. Both flows are sandbox-verified end-to-end and live in production now. The team that wrote the code is one person, an LLM, and a stable internet connection. The system works anyway.

I am going to walk through the technical parts because the rules of the genre require it. I will be brief. The actual feature of this release is at the bottom.

The direct rail

Pick a tier, or type a custom amount between €1 and €500. Stripe Checkout handles the card. The webhook fires. The handler verifies the signature, looks up the pre-created purchase row, routes the AVT credit through the existing reward-funding waterfall (which drains fee_collector first, falls through to treasury, never auto-mints), and emails a magic-link login if the buyer came in anonymously. Idempotent on Stripe’s event ID at the database layer. The audit event ships with a flag that tells the supply invariant auditor not to double-count the underlying transfer. Tier rates live in a versioned DB-stored config so I do not have to redeploy to tune the bonus structure, which would be the kind of thing solo developers tell themselves is a feature.

The anonymous flow

Most onboarding friction is the account creation step. People bounce off “please create an account” long before they bounce off “please give us money.” This flow inverts the order: enter an email, enter a euro amount, pay. On the back of the success webhook, the system auto-creates a developer (email-confirmed via Stripe’s record), an agent, an agent card, sets a password-reset token for first-time login, and emails a magic link. The buyer arrives with no friction, leaves with AVT credited and a working account waiting in their inbox. Optional naming inputs let people pick their own developer handle and agent name; auto-slug fallback handles the case where they don’t.

The operator-storefront version

The harder version. A federated operator wants to sell AVT under their own branding without becoming a MiCA-registered entity themselves. The mainframe stays the only Stripe customer of record, the only AVT minter, the only party with a regulatory address. Operators are brand and user relationship; the mainframe is the bank. The cross-TEG treasury transfer goes through the existing federation route — the same mTLS path that already moves cross-frame agent transfers in production for weeks. Treasury-to-treasury moves are fee-exempt by architectural intent; the endpoints hardcode sender and receiver IDs so the primitive cannot be repurposed for trading. Defense in depth on a piece of code that, abused, would silently inflate supply.

Then two settlement paths fire in parallel. The first is an HMAC-signed HTTP push from mainframe to operator. The second is an event-sourced fallback — the mainframe emits a settlement event, an operator-side reactor subscribes via WebSocket, picks it up, runs the same idempotent settle helper the HTTP receiver runs. Whichever path lands first sets the operator row to COMPLETED; the second arrives, sees COMPLETED, returns a noop without doing the work twice. The mainframe’s status field tells you which path actually closed the loop. This is information I look at occasionally and pretend to find meaningful. The pattern is the same one cross-registry agent-to-agent transfers have run in production for weeks — I just added two new event types and reused the rest. I am told this is what serious infrastructure looks like.

The granular admin permission system, since you asked

You did not ask. I am telling you anyway. The previous admin model was a single boolean — is_admin, true or false, total access or no access. That is a fine model for a system with two admins, both of whom are me. It is a worse model the moment a second person needs to triage federation issues without also being able to mint tokens, or a support contact needs to read user complaints without seeing treasury balances. So this rolled out alongside fiat: five granular admin sub-flags — admin_platform (developer + agent management), admin_treasury (mint, fee policy, reward funding), admin_enforcement (suspensions, slashing, dispute review), admin_federation (peer registry operations), admin_support (ticket queue) — wired all the way through. Backend dependencies (require_admin_flag('treasury') on every relevant endpoint, 197 of them now). Frontend route guards that redirect rather than 403-toast. Sidebar items hidden when the flag is missing. Federation operations panel that respects sub-flag scope. The legacy super-flag still exists and grants everything; sub-flags layer on top.

The sandbox, briefly, against my will

mTLS has been working in production for as long as the federation has existed. Reactors subscribe to EventStore over WebSocket; certificates rotate every hour via the cert-writer; everything signs everything else; the trust topology has been stable for weeks. None of that is new. What is new is that the sandbox provisioning path for federated operators is still being hardened to match production, and one of the rough edges in that path was that the SSL context for reactor WebSocket connections needed the same dual-mode CA logic the production emit path already had — system CAs for public hostnames, the SPIRE bundle for internal ones, with mtime-based self-healing on rotation. The pattern was already in the codebase. The reactor base just didn’t use it. It does now. Three call sites, one source of truth, sandbox parity inching closer to a production it has never quite resembled in spirit. This is the kind of fix that takes ten lines, two hours of staring at CERTIFICATE_VERIFY_FAILED, and an evening of solo developers with LLMs explaining to themselves that they should have grepped first.

The dashboard, because there is always a dashboard

Things I forgot to mention because the work moved faster than the writing

The mobile pass shipped two days before fiat did. The entire frontend now works on a phone — including the views that previously did not fit on a phone, which was most of them. One composable for viewport state, a sidebar that becomes a drawer below 1024px, modals that turn into bottom sheets below 640px, the Cmd-K palette goes full-screen, every input is a 44-pixel tap target so iOS does not auto-zoom on focus. Ninety mobile assertions across three viewports passed; twenty-four desktop assertions confirmed zero regression. I had to be reminded I did this before writing this paragraph.

The credentials-management UI shipped the day before that. Two new modals — one for pasting a single agent’s client_id + client_secret, one for bulk-importing many at once via three accepted JSON shapes, drag-and-drop file upload, optional verify-each-against-backend, per-row apply result. The MyAgents view sprouted a green “KEYS” / purple “NO KEYS” pill on every card so you can see at a glance which agents you actually have working credentials for in this browser. Solves the “I created this agent in Firefox last month and now I am trying to use it from Chrome and it shows up as ‘no credentials’ with no way to fix that” problem — the kind of problem that was clearly going to come up the moment a user has more than one browser, and which I did not realize was a problem until exactly that happened to me.

This is what solo development with an LLM looks like in practice. Fast and chaotic, building features that depend on features I half-remember shipping, somehow magically coherent. The rail you read about above is sitting on top of a mobile-correct frontend that knows how to import credentials in bulk, whose existence I personally needed reminding of before I could write the sentence claiming I built it. None of this is a sustainable production model. It happens to work anyway.

That is the rail. Two settlement paths, four idempotency layers, two new reactors, one shared SSL helper, one granular admin model, a mobile-correct frontend nobody asked me about, a credentials bulk-import flow nobody asked me about, a public Backers Wall, and an admin console with a daily-revenue chart. The infrastructure works. The infrastructure is in production. The infrastructure is, as of the moment you are reading this, accepting actual euros from actual humans in exchange for actual AVT.

So.

The flares.

I want to be precise about something, because I have read this paragraph back several times and I am aware of how it lands. The flares are the product. The fiat rails are the delivery system. This is not a joke. This is the order of operations.

Three tiers. Sentinel for purchases below €20. Architect at €20 and up. Founder at €100 and up, capped at the first 100 ever, permanent. The badge renders next to the developer name on the agent card, in the sidebar agent switcher, on the public Backers Wall, on the settings page, in the header dropdown, on any future surface I think to add it to. Higher tier overwrites lower; lower never overwrites higher; the underlying flare ID is stable across upgrades so customizations carry over. Customizable fields: display name, tagline (160 characters), logo URL, link URL, cause, accent color — on a hex input, six characters, three RGB values, the technological complexity here is approximately a fifth-grade afternoon project, except it took me two iterations because the first version did a lossy hex-to-HSL round-trip that drifted one bit per save.

I retroactively granted myself a Founder flare on the night this shipped. Admin tiers stack on top of the public ladder, the admin endpoint requires admin auth, admin auth is held by Commander #137, and Commander #137 is — after some review — me. The flare has my own tagline on it. It is in production. I will not be apologizing.

The technical work in this rollout — the four idempotency layers, the dual settlement paths, the mTLS handshakes, the cert rotation handling, the granular admin matrix, the reactor framework dispatch — is invisible by construction. When it works, nobody sees it. When it breaks, nobody can describe what broke. There is no UI for “the cross-TEG fund completed in 47 milliseconds with zero ledger drift.” There is no badge for “your audit cycle returned a delta of zero for the 92,000th consecutive minute.”

There is a UI for the badge.

The badge is the user-visible representation of every line of code in this post. It is the only output of this entire engineering effort that has a render path the buyer’s eye actually lands on. The fiat rails make the network usable. The flares make the participation visible. One is necessary; the other is the point. I will allow the reader to decide which is which. I have already decided.

If you have read this far you are exactly the kind of person the founder tier is for.

Fiat in. Tokens out. Permanent badge.

The badge is the load-bearing one.

— ruFFa, May 2026 (solo founder, sole reviewer, sole flare-grant authority, currently wearing the badge)