ORIEN
Post-quantum payment protocolFrom the Latin oriens, rising

No blocks. No miners. No waiting in line.

ORIEN is a quantum-proof payment network with no blocks and no global ordering. A payment is final in a fraction of a second and never waits behind other people's payments. Everything rests on one cryptographic assumption: the BLAKE3 hash function.

25–55 ms
Local finality · 162 ms wide-area

Two round trips to > 2/3 stake; ~115 ms of 162 ms is wire travel.

950–1,500/s
Payments/s on one laptop

4 validators syncing votes & confirmations to a single disk.

BLAKE3
One assumption, quantum-proof

Hash-based one-time account keys, Merkle key trees & batch roots.

100M · 0%
100M cap · zero genesis coins

4-year half-life, released via contention-free epoch work shares.

The idea

Three simple rules replace blocks and global consensus

1. Accounts order themselves

A payment says “account A, payment #7, send 5 to B.” Each validator votes for it if it has never seen a different #7 from A. Votes from validators holding more than two thirds of the stake make a certificate, and two conflicting payments can never both get one because any two such groups share an honest validator.

The payment is final once as many validators confirm they recorded the certificate. The receipt holds both sets of signatures.

2. One-time keys, ledger-counted

Every payment is signed with a hash-based one-time key and names the key for the next payment. “Never sign two different #7s” and “never use a key twice” are the exact same rule, and validators enforce it.

Every address also commits upfront to a Merkle tree of sixteen spare keys, used after a checkpoint if a key ever gets burned by signing twice.

3. Validators sign in batches

Hash-based signatures are larger than elliptic-curve ones, so signing one by one would waste keys and CPU. Instead, a validator collects every vote and confirmation requested over the last few milliseconds into one Merkle tree and signs its root once.

One validator signature covers the whole batch — 10 to 28 concurrent payments in local load tests — and each receipt carries only its short Merkle branch.

Interactive protocol trace

How a payment reaches finality — and what happens if someone cheats

Order broadcast directly to validators

Account A signs payment #7 with one-time key k₇

The signed order says: "account A, payment #7, send 250 to Carol, next key is k₈, spare root is S." No mempool orders it against strangers; only A's own sequence number matters.

alice · payment #7 · balance 10,000 → 9,750
Signs with k₇ (1,248 B BLAKE3 OTS) → commits next key k₈
v1Laptop · local
Waiting

Last seen from alice: #6

v2Desktop · LAN
Waiting

Last seen from alice: #6

v3VPS · +57 ms
Waiting

Last seen from alice: #6

v4VPS · +57 ms
Offline

Asleep (1 of 4 may be down)

Step 1 of 4

Once an hour, validators agree on one small snapshot

Payments never wait for blocks, yet a payment network still needs to rotate validator keys, onboard and slash stakers, pay out fees and released coins, prune old receipts, and free any account locked by a split double-signature.

About once an hour, validators pause for a few seconds and agree on a checkpoint — a Merkle root of all account balances. Interrupted payments survive checkpoints untouched and remain finishable by any copy of the wallet via orien resume.

What checkpoints unlock
  • Frees double-signed accounts onto their pre-committed 16-key spare tree (built in Stage 3)
  • Replaces validator Merkle key trees cleanly before keys run out (built in Stage 3)
  • Staking, fee distribution, and proportional work-share coin payouts (Stages 4–6)
Read the full checkpoint & safety rules
Measured

Real numbers, disk syncs included

Every validator forces its votes and confirmations to disk before replying. No in-memory-only benchmark shortcuts.

One Apple M5 laptop

4 validators + all clients
Time to finality, 1 payment
25 to 55 ms
Throughput, 50 clients at once
500 to 600 payments/s
Throughput, 100 to 250 clients
950 to 1,500 payments/s
Throughput, 500 clients at once
750 to 1,000 payments/s
Payments per validator signature under load
10 to 28
One-time owner signature
1,248 bytes
Full receipt (3/4 votes + 3/4 confirmations)
12,086 bytes

Two-step finality waits for two disk syncs in series, and here all four validators contend on one SSD. Before confirmations were added, the same test ran at 1,400–1,650 payments/s.

Three machines across the internet

Rehearsal layout

Four validators spread across a laptop (v1), a home desktop on the same LAN (v2), and a VPS 57 ms away holding two (v3, v4) so the network stays up while either home machine sleeps.

Median time to finality (40 payments)
162 ms
Fastest & slowest of the 40
138 ms – 240 ms
Network travel time (2 RTTs to quorum)
~115 ms (71%)
Where the 162 ms goes115 ms wire + 47 ms batch, disk & BLAKE3
~115 ms two round trips (votes + confirmations)~47 ms node work
Reproduce the local throughput figure:
cargo test --release -p orien-net --test devnet throughput -- --ignored --nocapture
Monetary rules · accepted 2026-11-14

Zero genesis allocation. Earned by contention-free work shares.

How coins come into existence

  • Nothing pre-allocated. The genesis file creates zero coins. Total supply is capped at 100,000,000 coins, each divisible to 9 decimal places.
  • Four-year half-life. Coins release along a smooth exponential curve — about 1,977 coins in the very first hour, halving every four years.
  • Work shares, not block lottery. A work share is (account, epoch, number) whose BLAKE3 hash with the epoch's seed falls below a target. Validators accept shares throughout the epoch and pin them in their closing statements just like payment certificates, so no proposer can tilt the tally.
  • Every valid share gets paid. Each checkpoint splits the coins released since the last checkpoint in exact proportion to pinned shares, adjusting difficulty to keep share volume steady.
  • Public, unbiasable launch seed. Epoch 0's seed will be the hash of a Bitcoin block at a height announced in advance; every later seed comes from the previous checkpoint. Launch validators hold non-spendable voting seats that earn zero released coins and fade out.
Release curve

100M cap · 4-year half-life · 0 at genesis

~1,977 coins in hour 1
100M50M0Y050MY475MY887.5MY1293.8MY16

Coins release by elapsed wall-clock time between checkpoints rather than checkpoint count, so closing an epoch early or late never changes total issuance.

Still open in design: whether the first 90 days ramp up from near zero (“slow sunrise”), and tying the fade-out of launch validator seats to real staked coins so a third of voting weight is never cheap to buy.
Engineering status

What works today, and what isn't built yet

Stage 0Built

State roots & snapshots

Merkle state root over accounts in address order, short account proofs, atomic per-epoch storage folders, double-sign evidence retention, balance check on every vote, validator key reserves.

ledger/state · crypto/merkle · net/store

Stage 1aBuilt

Two-step finality

Epoch numbers on votes and certificates, owner signatures preserved on certificates, signed confirmations after disk sync, 12 KB receipts carrying both quorums, proof-verified wallet advances.

ledger · net · cli

Stage 1bBuilt

Order format fixed once

Signed orders carry kind (payment, stake, unstake), maximum fee ceiling, next ordinary key and the 16-key spare root so future stages never strand an unfinished order.

ledger · net/keys · crypto/hash

Stage 2Built

Checkpoint agreement & simulator

Pure-logic Tendermint-style close with deterministic checkpoint validity and scripted adversarial simulators covering split votes, silent proposers and withheld decisions.

ledger/agree · ledger/close

Stage 3Built

Live epoch close & spare-key recovery

Validator freeze, WAL journal forced to disk before any signed message leaves, checkpoint chain, automatic validator key-tree rollover at 50% use, and stuck accounts freed onto spare keys.

net/closer · net/node · net/client

Stage 4Planned

Staking & changing validator set

Stake and unstake orders locking coins against a validator key-tree root and address, epoch-boundary validator set updates, and stake slashing for double-voting or key reuse.

Designed · next to build

Stage 5Planned

Per-payment fees

Flat fee taken from the sender (bounded by the order's fee ceiling) and paid out at each checkpoint to active validators in proportion to stake.

Designed · crates/ledger, crates/net

Stage 6Planned

Work-share coin creation

Zero-allocation genesis anchored to a future Bitcoin block hash, 100M cap on a 4-year half-life curve, and proportional checkpoint payouts to pinned BLAKE3 work shares.

Rules accepted 2026-11-14

Plain-spoken caveats right now

No outside cryptographic review yet. The building blocks — BLAKE3 one-time signatures, Merkle trees and Tendermint-style checkpoint agreement — are standard published constructions, but this composition is new. It must be reviewed by cryptographers before holding value.
Basic networking & unencrypted disk keys. Node traffic uses one thread per connection without transport encryption or rate limits yet (forged messages are rejected by signature, but rehearsal validators run strictly on private Tailscale addresses).
Fixed validators & zero fees until Stages 4–5. Validators come from genesis.json today, and spam protection via per-payment fees arrives in Stage 5.
Signed orders are irrevocable unless double-signed. Once signed, an order can be finished by any copy of the wallet (orien resume) across checkpoints, never silently replaced.

Want the full protocol rules or to try breaking a local devnet?

Every safety rule, adversarial failure found in simulation, and CLI fault-injection command is documented.

Epoch designTry the CLI