HTTPS for money — why we built ReineiraOS

Bitcoin and Ethereum gave money its TCP — a reliable settlement transport. Blocks confirm, funds move, you can build on top.

But that is all they give you: the ability to transfer.

They do not guarantee that the goods arrived. They do not protect you when something goes wrong. They do not encrypt what you bought, or from whom. The blockchain confirms the funds moved. It does not confirm the goods did.

That is roughly 1983 for the internet. The pipes work. But pipes alone never made commerce possible.

The internet got two more layers

HTTP gave any application a common way to talk to any other application. HTTPS added encryption, identity, and trust by default. Once those three layers existed, online commerce was not a product anymore. It was a substrate. Anyone could build on it.

For money, that application layer does not exist yet.

We have settlement. We have a hundred bespoke payment products. What we do not have is a confidential, conditional, composable application standard any team can build on without rolling their own cryptography.

What x402 and MPP cover today

Two open standards just emerged for parts of this picture.

x402 — Coinbase's HTTP 402 micropayment standard — gives agents a clean way to pay an HTTP API a cent. Right shape for micropayments, narrow scope. It starts the agent-payment story.

MPP — Stripe's Machine Payments Protocol, announced in May 2026 — extends that to agent-to-business transactions. Shared Payment Tokens, microtransactions, fiat and stablecoin support. The standard is open; the reference implementation runs on Stripe rails.

We respect both. They are right about what they cover.

What neither covers: encrypted state, conditional release with cryptographic verification, protocol-native insurance, permissionless operators. x402 stops at the simple-pay-and-go moment. MPP runs on Stripe-owned rails — the standard travels, the infrastructure does not.

ReineiraOS coexists with both. An x402-adapter inside RSS for sub-$10 micropay. MPP-settlement when conditional release matters. Built for the cases where the rails themselves need to be encrypted, conditional, and forkable end-to-end.

ReineiraOS is that missing application layer

HTTPS for money.

• Encrypted state. HTTPS encrypted the transport; we encrypt the balance, condition, and outcome on-chain by default, via Fhenix CoFHE.
• Conditional release. HTTP gave us request and response; we give you release when this proof verifies, with pluggable verifiers implementing the IConditionResolver interface.
• Protocol-native insurance. Outcome-coverage as a primitive, not a bolt-on bought separately. Risk policies plug in through IUnderwriterPolicy and return encrypted scores.
• Permissionless operators. HTTP let anyone host; we let anyone relay, bonded in confidential USDC today (with cUSDT support shipping at testnet), slashable through cross-graph consensus.

Built on Arbitrum, with FHE via Fhenix CoFHE. Cross-chain USDC routes through Circle CCTP V2 today; USDT through LayerZero ships at testnet (June 2026).

Standard and implementation, separable

The most important architectural choice we made: the standard ships separately from the implementation.

RSS — the Reineira Settlement Specification — is open, OSI-aligned, MIT and Apache-2.0 licensed. Free, forkable, versioned through an RIP process modeled on Ethereum's EIPs.

The reference implementation — the audited, Foundation-backed deployment of ReineiraOS — charges a 25 bps protocol fee on settlement. That is the trade for the audited path, cross-graph slashing consensus, and Foundation-backed dispute coordination.

Like TLS versus Cloudflare. Like ERC-20 versus USDC and USDT. The standard compounds; the implementations earn. The internet has used this layering for thirty years to make application-layer innovation compound. We are applying it to money.

What ships at testnet

Testnet day: June 2026. On that single coordinated day:

• Spec'd — RSS v0.1 published at reineira.xyz/rss, with the formal RIP process opened.
• Live — Repository public on GitHub with the layer-asymmetric license vector applied across the protocol, SDK, and tooling.
• Live — Escrow lifecycle and CCTP receiver deployed on Arbitrum Sepolia, with reference Gates and Insurance pools.
• Spec'd — Multi-stablecoin support: cUSDT (ConfidentialUSDT) ERC-7984 wrapper deployed alongside cUSDC, with cross-chain USDT routing via LayerZero.
• Spec'd — Pre-announced five-trigger fee-reduction schedule and five-trigger relicense schedule.
• Spec'd — CLA infrastructure live, dual-assigning copyright to the Cayman Foundation.
• Spec'd — Participation Policy v0.1 draft published for community comment.
• Spec'd — Bug bounty opens at minimum viable pool.

No mainnet yet. No token yet. The conditional TGE is described only in the whitepaper. We disclose, we do not hide.

If you have been building something that needs this

If your payment flow needs the buyer, the amount, and the release condition to stay private — what would your application look like if encrypted, conditional settlement was just there, like HTTPS?

Three places to go next:

• Whitepaper (PDF, 90 pages) — the formal specification.
• Quickstart preview — first Escrow in 5 minutes on testnet.
• Telegram — drop the use case you have in mind. We read every message before testnet.

Canonical version: reineira.xyz/blog/why-we-built-reineiraos