Proof Registry

On-Chain Commitment Layer for Verified SRU Data

Immutable Storage of Mobility Work Proofs (Base Chain)


🚀 Introduction

The Proof Registry is Ridera’s on-chain truth layer.

It stores cryptographic commitments (Merkle roots + metadata) for every 24-hour global earnings cycle after the Oracle and SRU Engine validate and standardize worker earnings.

The Proof Registry does not store raw earnings. Instead, it stores lightweight, immutable proofs that represent thousands of global mobility submissions in a highly efficient way.

This makes Ridera:

  • transparent

  • verifiable

  • censorship-resistant

  • audit-ready

  • globally scalable


🎯 Purpose of the Proof Registry

The Proof Registry provides four essential guarantees:

1. Immutability

Once a cycle is committed on-chain, it can never be modified.

2. Verifiability

Anyone can verify user SRU inclusion using Merkle proofs.

3. Transparency

All cycle-level data is publicly accessible on Base.

4. Trust Minimization

Yield Vault uses on-chain values instead of off-chain assumptions.


🧱 High-Level Flow

The Proof Registry is the bridge between off-chain verification and on-chain yield.


🔷 1. What the Proof Registry Stores

Each daily cycle produces a compact record stored on Base:

Stored On-Chain:

  • cycleId

  • merkleRoot

  • totalSRU

  • timestamp

  • batchHash

  • proofMetadata

Not Stored On-Chain:

  • raw earnings

  • user screenshots

  • local payout statements

  • personal information

Ridera maximizes transparency without compromising privacy or gas costs.


🔷 2. Why Merkle Trees?

The Proof Registry uses Merkle trees to compress thousands of SRU entries into a single 32-byte root.

Benefits:

  • minimal on-chain storage

  • fast verification

  • allows anyone to prove inclusion

  • prevents tampering

Simplified Merkle Example:

Every worker’s SRU value becomes part of the Merkle tree.


🔷 3. Registry Write Process (Step-by-Step)

Step 1 — Oracle verifies earnings

All data must pass fraud checks.

Step 2 — SRU Engine standardizes earnings

Using region + platform + category weights.

Step 3 — Batcher creates Merkle tree

Hashes all SRU entries and produces:

  • merkleRoot

  • batch metadata

Step 4 — Proof Registry Commit

The Batcher calls:

Step 5 — Yield Vault reads cycle

When rewards must be distributed, Yield Vault reads:

  • totalSRU

  • cycleId

and applies the emission formula.


🔷 4. Smart Contract Interface (Simplified)

This ensures:

  • trusted write access

  • public read access

  • immutable state


🔷 5. Responsibilities of the Proof Registry

✔ Ensure transparency

All cycles and totals are publicly queryable.

✔ Provide verifiable proofs

Stakers and third parties can validate inclusion.

✔ Feed data into the Yield Vault

Only on-chain values determine emissions.

✔ Prevent manipulation

Cycle data cannot be overwritten or altered.


🔷 6. How the Yield Vault Uses the Registry

The Yield Vault reads:

Then applies the emission model:

The Proof Registry ensures that emissions are backed only by verified SRU.

No SRU → No emission → No reward.


🔥 Why the Proof Registry Matters

The Proof Registry makes Ridera:

✔ verifiable

All SRU cycles are publicly accessible.

✔ secure

Merkle roots ensure cryptographic integrity.

✔ scalable

Thousands of earnings proofs → one 32-byte hash.

✔ trust-minimized

Yield Vault trusts only on-chain proofs.

✔ RWA-compatible

Essential for institutional transparency and audits.


📄 Next Section

Continue to Yield Vault to understand how Ridera converts SRU into daily RDR emissions.


Document Version

v1.0 — Proof Registry

Last updated