Why we built ReineiraOS

Bitcoin and Ethereum gave money a reliable settlement transport. Blocks confirm, funds move, and teams can build on top.

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

They do not verify that the goods arrived. They do not define recourse 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#

Internet standards gave applications a common way to communicate, then made that communication secure by default. Once those layers became shared infrastructure, anyone could build on them.

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.

Payment protocols solve a different problem#

Payment protocols can standardize authorization and transfer. That matters, especially for software and agents that need to pay without a bespoke integration.

Bonded Settlement begins after authorization. It covers the outcome: where funds wait, what proof releases them, and what happens when the required action fails.

Payment protocols answer, “May this money move?” ReineiraOS answers, “Under what conditions does it settle, and what recourse follows failure?”

A settlement layer for outcomes#

An actor posts a bond before it acts. A verified failure routes recourse under the terms, in private.

• Confidential escrow. Amounts, terms, and counterparties remain private through FHE-encrypted state.
• Programmable release. A pluggable Gate implements the IConditionResolver interface.
• Recourse. A verified failure can trigger the private payout flow. Real risk pricing and capitalized pools are next.
• Open execution. Staked operators relay cross-chain tasks, with a permissionless fallback path.

Built on Arbitrum, with FHE via Fhenix CoFHE. Cross-chain USDC routes through Circle CCTP.

Standard and implementation, separable#

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

RSS, the Reineira Settlement Specification, is the open and forkable definition of the protocol primitives.

ReineiraOS is the reference implementation and developer stack. The protocol fee is fixed at zero; plugins may define their own fees.

Separating the standard from the implementation keeps the category open while giving developers a working stack to build with today.

What is live now#

Live on testnet: confidential escrow, programmable release, and the recourse flow.

• Live Confidential escrow and reference Gates on Arbitrum Sepolia.
• Live Cross-chain USDC intake through Circle CCTP.
• Live The recourse contract flow with test assets.

Next: real risk pricing and a capitalized pool. There is no mainnet deployment and no production pool yet.

If you have been building something that needs this#

If your flow needs private terms, verified release, and recourse, which parts are you still assembling by hand?

Three places to go next:

• Whitepaper, the formal specification.
• Quick start, to build a first testnet flow.
• Telegram, to tell us which settlement flow you want the protocol to support.