Ridera Oracle Design

Global Mobility Verification Engine

Ensuring Real, Tamper-Resistant, and Standardized Earnings Data

🚀 Introduction

The Ridera Oracle is the verification backbone of the Ridera Protocol. It validates global mobility earnings submitted by riders, gig workers, couriers, and fleet operators.

The Oracle ensures all submitted earnings are:

  • authentic

  • consistent with platform rules

  • regionally accurate

  • non-duplicated

  • fraud-resistant

Only verified earnings can be used for SRU generation.

🎯 Purpose of the Oracle

The Oracle solves the biggest challenge in mobility RWA:

How do we prove global earnings are real, unedited, and trustworthy?

Ridera’s Oracle introduces a multi-layered verification engine that works across:

  • screenshots

  • PDF statements

  • platform summaries

  • multi-platform logs

  • bulk fleet submissions

It handles different regions, languages, currencies, and platforms.

🧱 Oracle Workflow

🔷 1. Input Layer — Data Ingestion

The Oracle accepts multiple formats:

1.1 Screenshots (OCR Parsing)

Supports multi-language OCR:

  • English

  • Hindi

  • Arabic

  • Indonesian

  • Spanish

  • Portuguese

  • Filipino

  • Vietnamese

Extracted fields include:

  • payout amount

  • base + bonus + tip

  • date/time

  • task count

  • platform metadata

1.2 PDF Statements

Direct parsing from:

  • Uber

  • Bolt

  • Grab

  • Deliveroo

  • iFood

  • DoorDash

1.3 Multi-Platform Merging

Most workers use 2–4 apps. Oracle merges them into a unified earnings record.

1.4 Metadata Enrichment

Adds:

  • region code

  • currency

  • submission timestamp

  • device signature

  • optional GPS signal

🔷 2. Verification Layer — Core Engine

This is where the Oracle performs all critical checks.

There are 7 total validation stages:

2.1 Timestamp Validation

Checks include:

  • screenshot timestamp vs device clock

  • payout date → must match daily cycle

  • no backdated/forward-dated entries

2.2 Region Consistency Modeling

Every region has different:

  • expected earnings range

  • peak-hour patterns

  • surge behavior

  • delivery/ride density

Oracle checks if earnings align with known regional models.

2.3 Platform Structure Validation

Each platform has a unique payout structure:

  • Uber = base + time + distance + surge

  • DoorDash = base + tip + bonus

  • Swiggy/Zomato = base pay + incentives

  • Grab = surge multiplier + bonus

If the structure doesn’t match → flag.

2.4 Duplicate Submission Detection

Oracle performs:

  • perceptual image hashing

  • metadata fingerprint comparison

  • sequence detection

  • repeated screenshot detection

Duplicates → automatic rejection.

2.5 ML-Based Anomaly Detection

Machine learning identifies:

  • edited screenshots

  • inflated payouts

  • impossible earnings patterns

  • inconsistency across history

Models used:

  • CNN image anomaly detector

  • Payout prediction model

  • Regional clustering model

2.6 Reputation Scoring

Each user receives a dynamic trust score based on:

  • valid submissions

  • rejections

  • anomaly flags

  • validator reviews

  • consistency over time

Reputation does not affect rewards, only:

  • audit frequency

  • submission batch size

  • auto-approval likelihood

2.7 Proof Batching

Approved proofs are grouped into:

  • 24-hour cycle

  • region buckets

  • platform buckets

The batch is forwarded to the SRU Engine.

🔷 3. Validator Layer — Decentralized Auditing (v2+)

While Oracle v1 is semi-centralized, Ridera progressively decentralizes verification.

Validator Responsibilities

  • review flagged proofs

  • verify large fleet submissions

  • approve/reject anomalies

  • maintain regional thresholds

  • vote on Oracle rule updates

Slashing Conditions

Validators lose rewards for:

  • approving fraudulent proofs

  • repeated errors

  • inactivity

  • incorrect audits

🔷 4. Output Layer — Oracle → SRU Engine

The Oracle does not compute SRU.

It outputs structured, verified earnings data:

This data flows into:

  • SRU Engine → standardizes into SRU

  • Batcher → creates Merkle tree

  • Proof Registry → stores Merkle root

🔥 Why Ridera’s Oracle Is Unique

✔ Multi-platform, multi-region, multi-language

✔ Fraud-resistant with ML detection

✔ Structured, transparent verification

✔ Validator oversight built in

✔ Optimized for RWA + mobility workloads

✔ First Oracle designed specifically for Real-World Work (RWW)

📄 Next Section

Continue to Proof Registry to learn how verified SRUs are stored on-chain using Merkle proofs.

Document Version

v1.0 — Oracle Design

PreviousSRU EngineNextProof Registry

Last updated