IN DEVELOPMENT — PRE-TESTNET

Useful
Work, Bounded.

A proof-of-work puzzle can be hard to solve, or it can reward work that is actually useful, but not both. RIBO resolves this with Bounded-Composition Useful Proof-of-Work (BC-UPoW). Security comes from sequential time. Useful work buys a bounded discount — and the protocol is currently in active development.

15%
Max Discount
VDF
Seq. Floor
zkVM
Exec. Proof
ribo-bc-upow · live visualization
3D
◆ DNA HELIX — USEFUL WORK (RNA)
◆ BLOCK RING — VDF SEQUENTIAL FLOOR
◆ zkVM PROOFS BIND RNA → BLOCKS
◆ δ_max CEILING (15%)
DNAUseful work
RINGVDF floor
STREAMSzkVM proofs
CEILINGδ_max = 15%
AUGCGAAUUCGGCUAGCUAGCUAAGGCUAGCUAGCUAAGGCUAGCUAGCAUAGCUAGGCUAGCUAAGGCUAGCUAGCUAAGGCAUGCGAAUUCGGCUAGCUAGCUAAGGCUAGCUAGCUAAGGCUAGCUAGCAUAGCUAGGCUAGCUAAGGCUAGCUAGCUAAGGCAUGCGAAUUCGGCUAGCUAGCUAAGGCUAGCUAGCUAAGGCUAGCUAGCAUAGCUAGGCUAGCUAAGGCUAGCUAGCUAAGGCAUGCGAAUUCGGCUAGCUAGCUAAGGCUAGCUAGCUAAGGCUAGCUAGCAUAGCUAGGCUAGCUAAGGCUAGCUAGCUAAGGC
$RIBO
BC-UPoW
RNA FOLDING
zkVM PROOFS
21M SUPPLY
VDF SEQUENTIAL
DESCI
RIBOSOME NETWORK
SPEC v1.0
IN DEVELOPMENT
ZUKER-STIEGLER
McCASKILL
BOUNDED DISCOUNT
$RIBO
BC-UPoW
RNA FOLDING
zkVM PROOFS
21M SUPPLY
VDF SEQUENTIAL
DESCI
RIBOSOME NETWORK
SPEC v1.0
IN DEVELOPMENT
ZUKER-STIEGLER
McCASKILL
BOUNDED DISCOUNT
OPEN SOURCE
OPEN COMMONS
INVERSE FOLDING
ZERO-DISCOUNT DEFAULT
PUBLIC REPOSITORY
12.5 $RIBO/BLOCK (PLANNED)
VERIFIED ON-CHAIN
ANTI-TARGET EXCLUSION
PARTITION FUNCTION
CEILING INVARIANCE
PRE-TESTNET
OPEN SOURCE
OPEN COMMONS
INVERSE FOLDING
ZERO-DISCOUNT DEFAULT
PUBLIC REPOSITORY
12.5 $RIBO/BLOCK (PLANNED)
VERIFIED ON-CHAIN
ANTI-TARGET EXCLUSION
PARTITION FUNCTION
CEILING INVARIANCE
PRE-TESTNET
IN DEVELOPMENT
StatusPRE-TESTNET
SpecBC-UPoW v1.0
VDFClass Group (Unknown Order)
Useful WorkRNA Inverse Design
δ_max (Planned)15%
α (Planned)0.0015
k_sat10,000
Key Cap1% per epoch
Proof SystemzkVM (succinct)
Launch Defaultδ_max = 0
VerificationR = { ∃w : H(w) = h_w }
Attack BoundC_attack ≥ (1−δ_max)·C_h
StatusPRE-TESTNET
SpecBC-UPoW v1.0
VDFClass Group (Unknown Order)
Useful WorkRNA Inverse Design
δ_max (Planned)15%
α (Planned)0.0015
k_sat10,000
Key Cap1% per epoch
Proof SystemzkVM (succinct)
Launch Defaultδ_max = 0
VerificationR = { ∃w : H(w) = h_w }
Attack BoundC_attack ≥ (1−δ_max)·C_h
WHO RIBO IS FOR

Built for every
type of operator.

Whether you'll be running a prover farm, submitting open research problems, or auditing the protocol, the Ribosome Network is being designed to turn your compute into a bounded, verifiable claim on chain — once it ships.

FOR PROVERS / MINERS
PLANNED
Status
FOR PROVERS / MINERS

Useful work. Bounded cost.

Run the canonical RNA verifier, generate a knowledge-sound zkVM execution proof, submit it bound to a fresh epoch beacon. The protocol's security is sequential; the useful part earns a bounded discount — once the network launches.

  • Target hardware: CUDA, Apple Silicon, modern x86
  • Proof generation: minutes to tens of minutes (planned)
  • Verification by any full node: milliseconds (recursive)
  • Block reward: 12.5 $RIBO (planned), halving every 210,000 blocks
  • Per-key submission cap — concentration-resistant by design
READ THE SPEC →
FOR RESEARCHERS
0
Problems Solved
FOR RESEARCHERS

Submit computation problems.

Open research problems in multi-state RNA inverse design can be submitted to the network. Verified solutions are immutably anchored on-chain — timestamped proof of discovery. The ceiling on coupling means the reward never silently erodes security.

  • Submit biological computation problems as transactions
  • On-chain immutable timestamping of discoveries
  • Cite block hash as permanent proof-of-record
  • DAO governance over research priority queue
  • Public commons — every discovered sequence is published
EXPLORE THE SCIENCE →
FOR DEVELOPERS
v1.0
Spec Version
FOR DEVELOPERS

Read the spec. Build the verifier.

RIBO is being developed in the open. The BC-UPoW framework, the VDF construction, the zkVM verification relation, and the RNA verifier are all specified in the whitepaper. Contribute to a reference implementation, audit the security argument, or build tooling.

  • BC-UPoW framework fully specified in the whitepaper
  • VDF over imaginary quadratic field, class group of unknown order
  • zkVM used purely for succinctness — privacy intentionally bypassed
  • RNA verifier: Zuker-Stiegler MFE + McCaskill partition function
  • Open-source reference implementation in progress
VIEW FAQ →
HOW IT WORKS

Bounded-Composition
Useful Proof-of-Work
Architecture.

01

Sequential Floor

A Verifiable Delay Function (VDF) evaluates repeated squarings in a class group of unknown order. This establishes a baseline cost that requires inherently sequential time and cannot be meaningfully accelerated by parallel hardware.

Class Group VDF · No Trusted Setup
02

Useful Work

Solvers tackle multi-state RNA inverse design — finding a single sequence that satisfies a set of target secondary structures under varying physical conditions while avoiding anti-target configurations. An adversary could use a free, instant oracle for this; the protocol's security does not depend on the biological problem's hardness.

RNA Inverse Design · Zuker-Stiegler
03

zkVM Execution Proof

Solvers generate a knowledge-sound succinct proof that a deterministic RNA verifier ran for at least c_min cycles and accepted the candidate. The proof is bound to a fresh epoch beacon, and the cryptographic hash of the discovered sequence is exposed as a public input to enforce Data Availability.

zkVM (RISC Zero / SP1 style) · Succinct
04

Bounded Discount

Valid zkVM proofs are counted per epoch. The biological work earns a discount off the sequential cost, but this discount is mathematically capped by δ_max. The discount function δ(k) = α·√k is monotone concave in the number of independently-keyed submissions k.

Monotone Concave Curve · Ceiling Invariance
05

Block Sealed

The combination of the VDF evaluation and the zkVM proofs determines block validity. Even with a perfect biological algorithm, attack cost never drops below (1 − δ_max) · C_h. The plaintext RNA sequence is permanently recorded on the public ledger as a scientific commons.

Provable Security · Bounded-Composition
SHA-256BC-UPoW (RIBO)
Security sourceHash preimagesVDF Sequential Time
Useful WorkNoneRNA Inverse Design
CouplingTotal (Dangerous)Bounded Discount (Safe)
Proof systemSHA-256zkVM (succinct)
Algorithmic ProgressErodes SecurityCeiling Invariance
Discount CeilingN/AStrictly capped (δ_max)
FROM THE WHITEPAPER · CEILING INVARIANCE
"For any useful problem U and for any computational strategy or optimization algorithm developed for it (including a theoretical possibility of an oracle that outputs a solution for free instantly), the attack cost is bounded: Cattack ≥ (1 − δmax) · Ch."
— RIBO: BC-UPoW Architecture, §2.1
NP RELATION VERIFIED BY THE zkVM
R = { (pid, x, y, c_min, h_w) |
    ∃ w : Exec(pid, x, w) = y
        ∧ consumed ≥ c_min
        ∧ H(w) = h_w
}
pid · verifier program hash · x · instance + beacon · y · accepting state w · discovered RNA sequence · h_w · public commitment to w
TABLE 1

RIBO Submission — Public Data Payload

Every accepted solution is broadcast to the network as a single signed message. The plaintext RNA sequence (discovered_seq) is mandatory — submissions with missing, hidden, or mismatched sequences are entirely rejected, enforcing strict Data Availability.

FIELDDESCRIPTION
program_idHash of the canonical RNA verifier binary
instance_commitHash of target structures, anti-targets, and states
epoch_beaconHash of the recent block headers [t−w ... t]
claimed_outputAccept token
discovered_seqPlaintext RNA nucleotide sequence broadcast to the public network
sequence_hashPublic input commitment (hw) binding the sequence to the proof
proofSuccinct zkVM execution proof (π_zk)
cycle_boundMinimum cycle boundary requirement (c_min)
submitter_pubkeyPublic key of the solver
signatureCryptographic signature over all fields above
TABLE 2

Protocol Settings

Max Discount (δ_max)15%

Guarantees that 85% of block cost is always pure sequential work.

Scaling Constant (α)0.0015

Calibrates the discount curve relative to submission volume.

Saturation Point (k)10,000

Number of unique solutions to reach the max discount.

Key Contribution Limit1% of total

Prevents a single participant from providing more than 1% of the epoch's count.

TABLE 3

Performance Profile (Planned)

Native Verification Time

10 to 300 ms per RNA structure

zkVM Prover Overhead

10³ to 10⁴ cycle multiplier

Proof Generation Window

5 to 30 min on general-purpose solver hardware

Node Validation Speed

< 5 ms per submission (recursive proof pipelining)

ESTIMATED FROM CURRENT zkVM RESEARCH — SUBJECT TO CHANGE
THE SCIENCE

Deterministic Verifiers.
zkVM Execution Proofs.

The Zuker-Stiegler recurrence and McCaskill's algorithm are the decades-old deterministic backbone of our verifier. We use zkVMs in the most conservative way: prove a fixed program ran, on a fixed input, for at least a fixed number of cycles. The zero-knowledge privacy property is intentionally bypassed — the discovered sequence must be published on-chain.

TASK TYPE

Minimum Free Energy

O(n³)

Zuker-Stiegler recurrence (1981). The deterministic backbone that checks if the sequence folds into the target structure σ_i under physical conditions P_i.

PROTOCOL ROLE
VERIFIER
EX: Fixed-point integer arithmetic (no floats)
TASK TYPE

Partition Function

O(n³)

McCaskill's algorithm (1990). Computes the equilibrium probability of the target structure to ensure P(σ_i | s, P_i) ≥ 0.5.

PROTOCOL ROLE
VERIFIER
EX: Boltzmann ensemble probability
TASK TYPE

Anti-Target Exclusion

O(n³)

For each physical condition P_i, the MFE structure for sequence s must never equal any anti-target configuration τ_i. Avoids off-target therapeutic behaviour.

PROTOCOL ROLE
VERIFIER
EX: Multi-state constraint
TASK TYPE

Inverse Folding (The Useful Problem)

NP-hard

Finding a sequence s ∈ Σ that satisfies all targets while avoiding anti-targets. Solvers use ML or heuristics, but consensus only checks the zkVM proof.

PROTOCOL ROLE
SOLVER
EX: LEARNA-style / learned heuristics
ACADEMIC & CRYPTOGRAPHIC PRIMITIVES COMPOSING RIBO
ZUKER-STIEGLER 1981McCASKILL 1990RIVEST · SHAMIR · WAGNER 1996BONEH · BONNEAU · BÜNZ · FISCH 2018PIETRZAK 2019WESOLOWSKI 2019CLASS GROUP VDFzkVM EXECUTION PROOFEPOCH BEACONPARTITION FUNCTIONZUKER-STIEGLER 1981McCASKILL 1990RIVEST · SHAMIR · WAGNER 1996BONEH · BONNEAU · BÜNZ · FISCH 2018PIETRZAK 2019WESOLOWSKI 2019CLASS GROUP VDFzkVM EXECUTION PROOFEPOCH BEACONPARTITION FUNCTION

RIBO HAS NO INSTITUTIONAL USERS YET — THE PROJECT IS IN ACTIVE DEVELOPMENT

THE ASYMMETRY

Proof generation: Minutes.
Verification: Milliseconds.

We do not use the zero-knowledge property for anything security-critical. The real value of zkVMs is succinctness and knowledge soundness. A solver takes minutes to generate a proof; any full node verifies it instantly via recursive proof pipelining. This is why the network evaluates useful work on an epoch scale rather than per-block.

10³–10⁴×
zkVM Overhead
5–30 min
Proof Gen Time
< 5 ms
Validation Time
$RIBO
BC-UPoW
RNA FOLDING
zkVM PROOFS
21M SUPPLY
VDF SEQUENTIAL
DESCI
RIBOSOME NETWORK
SPEC v1.0
IN DEVELOPMENT
ZUKER-STIEGLER
McCASKILL
BOUNDED DISCOUNT
$RIBO
BC-UPoW
RNA FOLDING
zkVM PROOFS
21M SUPPLY
VDF SEQUENTIAL
DESCI
RIBOSOME NETWORK
SPEC v1.0
IN DEVELOPMENT
ZUKER-STIEGLER
McCASKILL
BOUNDED DISCOUNT
OPEN SOURCE
OPEN COMMONS
INVERSE FOLDING
ZERO-DISCOUNT DEFAULT
PUBLIC REPOSITORY
12.5 $RIBO/BLOCK (PLANNED)
VERIFIED ON-CHAIN
ANTI-TARGET EXCLUSION
PARTITION FUNCTION
CEILING INVARIANCE
PRE-TESTNET
OPEN SOURCE
OPEN COMMONS
INVERSE FOLDING
ZERO-DISCOUNT DEFAULT
PUBLIC REPOSITORY
12.5 $RIBO/BLOCK (PLANNED)
VERIFIED ON-CHAIN
ANTI-TARGET EXCLUSION
PARTITION FUNCTION
CEILING INVARIANCE
PRE-TESTNET
TOKENOMICS

Bitcoin economics.
Bounded purpose.

NOT YET DEPLOYED
The numbers below describe the planned token design from the whitepaper. No $RIBO has been minted, sold, or distributed. Token parameters may change before launch.
TOKEN SPECIFICATIONS
Ticker$RIBO
Max Supply21,000,000
AlgorithmBC-UPoW
Block TimeVDF-Determined
Block Reward12.5 $RIBO (planned)
HalvingEvery 210,000 blocks
Current Supply0 — not yet deployed
StatusIn development
PLANNED TOKEN DISTRIBUTION
21M
MAX
Mining Rewards (Planned)
99.9%
Genesis Allocation
0.1%
Public Sale
0%
Ecosystem DAO
0%
Team & Advisors
0%
PLANNED HALVING SCHEDULE
Era 1 ← LAUNCH ERA
0–210,000
12.5 $RIBO
Era 2
210,001–420,000
6.25 $RIBO
Era 3
420,001–630,000
3.125 $RIBO
Era 4
630,001–840,000
1.5625 $RIBO
$RIBO UTILITY (PLANNED)
Pay for computational task submissions
DAO governance votes
Research priority bidding
Staking for node validation
Reward useful-work solvers
ROADMAP

From genesis
to transcription.

RIBO is being developed conservatively. The whitepaper explicitly recommends launching with the discount parameter set to zero (δmax = 0) — solutions can still be submitted, verified inside the zkVM, and stored on-chain, but the discount to the sequential baseline is zero, preserving full ledger security while behaviour is observed across multiple epochs.

GENESISIN PROGRESS
2024 — 2025
BC-UPoW Architecture Published
Class Group VDF specification
zkVM verification relation formalized
RNA verifier (Zuker-Stiegler + McCaskill) spec'd
Open-source reference implementation in progress
ZERO-DISCOUNT LAUNCHPLANNED
Planned — TBD
Initial launch with δ_max = 0 (Section 9)
Solutions submitted, verified, stored on-chain
Discount to sequential baseline = 0
Ledger security fully preserved
Game-theoretic behaviour observed across epochs
SYNTHESISPLANNED
Planned — TBD
Discount ceiling (δ_max) activated via consensus upgrade
Formal security proof completed
Multiple useful problem rotation
zkVM hardware acceleration
Per-key submission cap (1%) enforced
TRANSCRIPTIONPLANNED
Future
Merge-mining protocol enabled
Additional useful problems (e.g. protein folding)
Cross-epoch strategy mitigations hardened
Epoch-scale → block-scale proving (if zkVM overhead allows)
10K+ zkVM submissions per period
OVERALL PROGRESS (SPEC → LAUNCH)18%
SPEC PUBLISHEDZERO-DISCOUNT LAUNCHδ_max ACTIVATED
FAQ

Hard questions.
Straight answers.

No. RIBO is in active development and has not launched. The whitepaper specifies a BC-UPoW architecture, the protocol parameters are calibrated, and a reference implementation is being built — but there is no mainnet, no token contract, and no institutional users yet. Do not send funds to anyone claiming to sell $RIBO.

No. This is exactly what Bounded-Composition UPoW (BC-UPoW) solves. Security comes entirely from the sequential floor (the VDF). The useful biological work only buys a bounded discount off that cost. Even an attacker with a free, instant, perfect oracle for RNA folding cannot push a block's cost below a fixed fraction (1 − δ_max) of the honest sequential cost.

Correct. We explicitly do not assume RNA inverse design is average-case hard. A security guarantee that degrades as algorithms improve is not a security guarantee. We assume only that the VDF is sequentially hard and that the zkVM is knowledge-sound.

At initial launch the protocol will run with δ_max = 0. Solutions can still be submitted, verified inside the zkVM, and stored on-chain, but the discount to the sequential baseline is zero. This preserves full ledger security while the network gathers empirical data on multi-epoch submission behaviour. The discount can later be raised via a multi-step consensus upgrade, and reverted if flaws are found.

Solvers generate a knowledge-sound execution proof in a general-purpose zkVM that the deterministic RNA verifier ran for at least c_min cycles and accepted the candidate. The proof also enforces that H(w) — a cryptographic hash of the discovered sequence — is exposed as a public input, binding the published plaintext sequence to the proof. Any full node can verify this in milliseconds.

A Verifiable Delay Function (evaluating repeated squarings in a class group of unknown order) establishes the baseline time and cost for block production. It requires inherently sequential steps, neutralizing advantages from massively parallel hardware. There is no trusted setup.

No. The discount is evaluated per-epoch against an aggregate number of valid submissions (k). Block-scale cadence is not achievable at current zkVM overheads — proofs take 5–30 minutes to generate. This is why useful work is evaluated on an epoch scale rather than per-block.

Stockpiling is prevented by the epoch beacon: solutions created before the beacon are invalid. Cross-epoch hoarding fails for the same reason. Sybil submissions are bounded by the concave square-root shape of δ(k) = α·√k and by the per-key 1% contribution cap. Generating a valid zkVM proof requires at least c_min cycles, so even an attacker with unlimited keys must spend real resources to inflate k.

The ceiling invariance (the maximum discount bound) is mathematically proven given zkVM soundness and no replay of submitted solutions. The full strategy-proofness across periods (ruling out stockpiling, Sybil inflation, and merge-mine manipulation) is an explicitly stated open problem in the architecture. Until closed, the discount defaults to zero.

The RIBO whitepaper — "A Bounded-Composition Architecture for Useful Proof-of-Work" — describes the framework, the building blocks, the RIBO instantiation, network operations, security analysis, protocol calibration, incentives, and deployment safety in full. It is the authoritative specification for this project.

DEVELOPMENT MAILING LIST

Useful work.
Bounded reward.

RIBO is still in development. Join the mailing list to receive protocol updates, spec revisions, and an early heads-up when the zero-discount testnet opens. No tokens, no sales — just research and engineering progress.

0
Tokens Minted
0
Institutional Users
v1.0
Spec Published

RIBO IS NOT YET DEPLOYED. ANYONE OFFERING TO SELL $RIBO OR CLAIMING INSTITUTIONAL PARTNERSHIPS IS NOT AFFILIATED WITH THIS PROJECT.