Oracle Network — Layer 6

Section 6: Oracle Network — Layer 6

RWA Tokens Platform Whitepaper · Version 10.0 Groovy Company, Inc. · May 2026 Document Reference: RWA-ORACLE-SPEC-001 v2.0

The Oracle Network supplies seven categories of off-chain data to the on-chain compliance program. All oracles use Ed25519 attestation; all signatures are verified by Solana's native Ed25519 precompile. Module-aware oracles (NAV for Module 2, Classification for Module 3) extend the V8 five-oracle baseline.

---

6.1 Architecture Principles

6.1.1 Ed25519 Attestation Universally

Every oracle attestation is signed by an authorized off-chain relay using Ed25519. The relay's public key is bound to the oracle PDA at initialization and cannot be changed without governance action. Signature verification uses Solana's native Ed25519 precompile (instruction Ed25519SigVerify1), which costs ~3,000 CU per signature and is the most efficient signature-verification path on Solana.

6.1.2 Per-Slot Freshness for Critical Oracles

Custody Oracle (Empire) attestations are required per Solana slot (~400 ms cadence). Stale attestations cause Control CV-02 to reject transfers. This is the highest-frequency oracle in the system and provides the architectural basis for "compliance enforcement at every transfer."

6.1.3 Module-Conditional Reading

V10's Transfer Hook reads module-specific oracles only when applicable:

Oracle	Read When
Custody Oracle	Always (M1, M2, M3)
OFAC Oracle	Always (M1, M2, M3)
AML Oracle	Always (M1, M2, M3)
TWAP Oracle	Always (M1, M2, M3)
EDGAR Oracle	Module 1 only
NAV Oracle	Module 2 only
Classification Oracle	Module 3 only

This conditional reading is what allows V8 mints (module = 1) to execute exactly as in V8 — they do not load NAV or Classification oracle accounts.

6.1.4 Three-Provider Redundancy

Each oracle category is fed by three independent off-chain relay providers across separate cloud infrastructure (AWS, GCP, Azure). Control CV-40 (Oracle Consensus Failure) halts the affected category if fewer than 2 of 3 providers are reachable for more than 5 minutes.

---

6.2 Oracle Category 1 — Custody Oracle (Empire Stock Transfer)

6.2.1 Purpose

The Custody Oracle stores Empire Stock Transfer's Ed25519-signed attestation of the underlying equity backing the mint 1:1. It is the architectural anchor for Pillar 4 (True Equity Backing 1:1) of Category 1 Model B.

6.2.2 PDA Schema

#[account]
pub struct CustodyOracle {
    pub version:           u8,                // 10
    pub mint:              Pubkey,
    pub custodied_balance: u64,               // Module-agnostic: shares of custodied class
    pub class_label:       AssetClass,        // CommonB | SAE | BAE
    pub last_update_slot:  u64,
    pub empire_pubkey:     Pubkey,
    pub signature:         [u8; 64],
    pub bump:              u8,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, Copy, PartialEq)]
pub enum AssetClass {
    CommonB = 0,    // Module 1
    SAE     = 1,    // Module 2
    BAE     = 2,    // Module 3
}

6.2.3 Attestation Flow

Step 1 — Empire MSF state at slot N
  Empire's Master Securityholder File reflects current equity custody
  for the mint (custodied_balance, class_label).

Step 2 — Ed25519 signing
  Empire's authorized signing service computes:
    msg = (mint || custodied_balance || class_label || slot)
    signature = Ed25519_sign(empire_priv, msg)

Step 3 — Solana submission
  Empire submits update_custody_oracle instruction targeting the
  CustodyOracle PDA for the mint.

Step 4 — Native precompile verification
  CustodyOracle program invokes Ed25519SigVerify1 precompile.
  Signature verified against bound empire_pubkey.

Step 5 — On-chain update
  CustodyOracle PDA updated with new fields.

Step 6 — Available to Transfer Hook
  Subsequent transfers read updated oracle in Control CV-01, CV-02.

6.2.4 Slot Freshness Enforcement

Control CV-02 (CustodyOracleUnavailable) rejects transfers where:

current_slot - oracle.last_update_slot > 1

In practice, Empire's signing service operates a continuous loop that signs every Solana slot, with monitoring on signing-service health and automatic failover to backup signing infrastructure. Control CV-40 halts the affected mint if the oracle stops updating beyond a tolerance window (default 10 slots / ~4 seconds for warning; 75 slots / ~30 seconds for halt).

---

6.3 Oracle Category 2 — OFAC Oracle

6.3.1 Purpose

Per-wallet OFAC / SDN sanctions screening. Used by Controls SX-08, SX-09, SX-10, SX-34, SX-37.

6.3.2 PDA Schema

#[account]
pub struct OfacOracle {
    pub version:          u8,
    pub bloom_filter:     [u8; 16384],   // Bloom filter of sanctioned addresses (16 KB)
    pub bloom_k_funcs:    u8,            // Number of hash functions (default 7)
    pub addresses_count:  u32,           // Number of addresses encoded in filter
    pub last_update_ts:   i64,           // Unix timestamp of last SDN feed update
    pub feed_version:     u32,           // OFAC SDN feed version number
    pub relay_pubkey:     Pubkey,
    pub signature:        [u8; 64],
    pub bump:             u8,
}

6.3.3 Bloom Filter Design

The OFAC SDN list contains millions of addresses across all blockchain types. To make per-transfer OFAC screening computationally feasible, the platform encodes Solana-relevant sanctioned addresses into a Bloom filter:

• Filter size: 16,384 bytes = 131,072 bits

• Hash functions: 7 (SipHash-2-4 with 7 distinct seeds)

• False-positive rate: ~1% at ~50,000 sanctioned addresses

• Membership query: O(7) hash operations + 7 bit-tests; ~500 CU per query

A Bloom positive triggers a more expensive secondary check (full address-list lookup against an extended OFAC PDA). True positives are rare; the filter's false-positive rate adds modest latency to a small fraction of transfers.

6.3.4 Update Cadence

OFAC SDN feed is updated daily (and ad-hoc on emergency designations). Empire's relay polls the OFAC API hourly and re-signs the oracle when the feed version changes. Control SX-10 (StaleSanctionsOracle) rejects transfers where:

current_ts - oracle.last_update_ts > 90 minutes

---

6.4 Oracle Category 3 — AML Oracle

6.4.1 Purpose

Per-wallet AML risk scoring via Chainalysis Know Your Transaction (KYT) and TRM Labs. Used by Control SX-11.

6.4.2 PDA Schema (Per-Wallet)

#[account]
pub struct AmlOracle {
    pub version:           u8,
    pub wallet:            Pubkey,
    pub risk_score:        u8,           // 0–100
    pub risk_categories:   u32,          // bitfield: mixer use, darknet, sanctions exposure, etc.
    pub chainalysis_score: u8,           // 0–100 from Chainalysis KYT
    pub trm_score:         u8,           // 0–100 from TRM Labs
    pub last_update_slot:  u64,
    pub last_update_ts:    i64,
    pub relay_pubkey:      Pubkey,
    pub signature:         [u8; 64],
    pub bump:              u8,
}

// risk_score is the weighted aggregate:
// risk_score = max(chainalysis_score, trm_score) for high-confidence flagging
// or weighted average per platform-specific risk model

6.4.3 On-Demand Lookup

AML attestations are not pre-computed for every wallet. They are computed:

• At Empire onboarding (initial assessment)

• On every transfer involving the wallet (re-fetched if AML PDA stale)

• On compliance review escalation

The AmlOracle PDA per wallet is created on first transfer and updated every 24 hours by the AML relay polling Chainalysis and TRM APIs.

6.4.4 Three-Tier System (Control SX-11)

risk_score Range	AML Decision	Action
0–30	Approve	Transfer proceeds
31–70	Enhanced Review	Transfer proceeds; flagged for compliance officer review
71–100	Reject	Transfer reverts with HighRiskWallet (Error 6006)

---

6.5 Oracle Category 4 — TWAP Oracle (Pyth Network)

6.5.1 Purpose

Time-weighted average price reference for circuit breakers (CB-21 core, CB-26 price impact). Used to detect anomalous price movements.

6.5.2 PDA Schema

#[account]
pub struct TwapOracle {
    pub version:            u8,
    pub mint:               Pubkey,
    pub price_window:       [u64; 24],     // 24 hourly checkpoints (1e6 base units USDC)
    pub current_hour_index: u8,
    pub twap_24h:           u64,           // Computed 24h TWAP
    pub twap_5min:          u64,           // 5-minute TWAP for fast circuit breakers
    pub last_update_slot:   u64,
    pub pyth_feed_account:  Pubkey,        // Pyth Network feed for the mint
    pub bump:               u8,
}

6.5.3 Per-Slot TWAP Update

The TWAP relay reads Pyth Network's price feed for the mint every Solana slot and updates the rolling window. Pyth provides per-slot price publishing through its dedicated price-feed program; the platform's TWAP relay aggregates the per-slot prices into 24-hour and 5-minute TWAPs.

For ST22 mints with active CEDEX trading, the TWAP is computed across CEDEX trading activity. For mints in pre-trading state, the TWAP defaults to the most recent NAV (Module 2) or initial offering price (Modules 1, 3).

---

6.6 Oracle Category 5 — EDGAR Oracle (Module 1 Only)

6.6.1 Purpose

SEC EDGAR filing surface for issuer-distress signal generation in Layer 9 IDOS. Module 1 only, since EDGAR filings are made by SEC-reporting companies.

6.6.2 PDA Schema

#[account]
pub struct EdgarOracle {
    pub version:           u8,
    pub issuer_cik:        u32,           // SEC Central Index Key
    pub mint:              Pubkey,
    pub last_filing_type:  [u8; 8],       // "10-K", "10-Q", "8-K", "13D/G", etc.
    pub last_filing_ts:    i64,
    pub last_filing_url:   [u8; 64],      // EDGAR filing URL hash
    pub idos_signal:       u8,            // 0–100 distress score derived from filing content
    pub last_update_slot:  u64,
    pub relay_pubkey:      Pubkey,
    pub signature:         [u8; 64],
    pub bump:              u8,
}

6.6.3 EDGAR NLP Pipeline

The EDGAR relay performs:

1. EDGAR API polling (per filing publication)

2. Filing download and parsing

3. NLP-based distress-signal extraction (IDOS scoring)

4. Material-event detection (8-K classification)

5. Beneficial-ownership change detection (13D/G)

6. Material weakness in internal controls flag (10-K Item 9A)

7. Going-concern flag (10-K / 10-Q auditor commentary)

The IDOS signal is consumed by Layer 9; it does not directly halt transfers but informs compliance officer review and Control 42 manual freeze consideration.

---

6.7 Oracle Category 6 — NAV Oracle (Module 2 Only)

6.7.1 Purpose

Per-mint NAV with authorized-appraiser Ed25519 signature. Used by Control CB-21 NAV-deviation variant. Documented in full in Section 9.

6.7.2 PDA Schema

#[account]
pub struct NavOracle {
    pub version:            u8,
    pub mint:               Pubkey,
    pub nav_per_token:      u64,          // 1e6 base units USDC
    pub currency:           [u8; 4],      // "USDC" or "PYUS"
    pub last_update_slot:   u64,
    pub last_appraisal_ts:  i64,
    pub appraiser_pubkey:   Pubkey,
    pub signature:          [u8; 64],
    pub bump:               u8,
}

6.7.3 Appraiser Authorization

The authorized appraiser's Ed25519 public key is bound at NAV Oracle initialization. The appraiser cannot be changed without tripartite-concurrence governance (SAE issuer + appraiser + Empire). The appraiser must be:

• State-licensed real-estate appraiser in the property's jurisdiction

• USPAP-compliant

• E&O insurance at platform-required levels

• KYC and KYB by Empire Stock Transfer

6.7.4 Reappraisal Cadence

The NAV attestation is valid only within SecurityConfig.reappraisal_cadence_secs (default 7,776,000 = 90 days). Beyond cadence, Control CB-21 NAV variant rejects transfers with NavReappraisalOverdue (6021-NAV-STALE).

6.7.5 Anti-Fat-Finger Guard

NAV updates are limited to ±50% of the prior NAV in a single update. Larger revisions require two-step submission with platform compliance review.

---

6.8 Oracle Category 7 — Classification Oracle (Module 3 Only)

6.8.1 Purpose

Per-mint federal-classification status for Module 3 BAE basin assets. Used by Control REG-42 federal-action variant. Documented in full in Section 10.

6.8.2 PDA Schema

#[account]
pub struct ClassificationOracle {
    pub version:                       u8,
    pub mint:                          Pubkey,
    pub basin_id:                      [u8; 32],
    pub classification_status:         u32,        // bitfield: USGS-critical, DOE-critical, etc.
    pub federal_action_active:         bool,
    pub federal_action_started_slot:   u64,
    pub federal_action_kind:           u8,         // 0=none, 1=Section232, 2=DPA-III, 3=EO, etc.
    pub federal_action_reference:      [u8; 32],   // Federal Register doc ID hash
    pub last_update_slot:              u64,
    pub relay_pubkey:                  Pubkey,
    pub signature:                     [u8; 64],
    pub bump:                          u8,
}

6.8.3 Authorized Classification Relay

The relay polls authoritative sources continuously:

Source	Cadence	Polled For
Federal Register API	Every 15 minutes	§232 actions, EO actions, DPA actions
USGS publications	Hourly	Critical Minerals List changes
DOE notices	Hourly	Critical Materials Strategy events
BLM notices	Hourly	Land-use actions affecting concessions
Office of the President	Per publication	EO publications

Three-provider redundancy across separate cloud infrastructure ensures no single relay failure halts Module 3 operations.

6.8.4 60-Minute SLA

Detection-to-enforcement latency budget (full breakdown in Section 10.6.3):

Phase	Target	Maximum
Federal event publication → relay polling cycle	0–15 min	15 min
Pattern detection → compliance officer notification	< 1 min	5 min
Compliance officer review (high-impact)	< 15 min	30 min
Ed25519 signing + Solana submission	< 1 min	5 min
Solana confirmation	< 1 min	5 min
Total ceiling	< 30 min target	60 min

6.8.5 Staleness Enforcement

SecurityConfig.classification_max_age_secs defines the maximum oracle staleness (default 86,400 = 24 hours). Beyond this, REG-42 federal-action variant rejects transfers with ClassificationOracleStale (6042-FED-STALE).

---

6.9 Cross-Oracle Coordination

6.9.1 Oracle Consensus (Control CV-40)

Control CV-40 (Oracle Consensus Failure) requires that for each oracle category, at least 2 of 3 redundant relay providers be reachable within 5 minutes. If consensus drops, the affected category halts trades on affected mints. The consensus check is per-category, not global — a Custody Oracle consensus failure halts all mints, while a NAV Oracle consensus failure halts only Module 2 mints.

6.9.2 Oracle Failure Cascading

Oracle failures cascade as follows:

Failure	Effect
Custody Oracle stale	All transfers on affected mint halt (CV-02, then CV-40)
OFAC Oracle stale	All transfers across all mints halt (SX-10)
AML Oracle missing for wallet	Transfer involving that wallet halts pending AML re-fetch
TWAP Oracle stale	Circuit breaker controls cannot evaluate; CB-21 core defaults to halt
EDGAR Oracle stale (M1)	IDOS scoring degraded; no transfer halt
NAV Oracle stale (M2)	All Module 2 transfers on affected mint halt (CB-21 NAV variant)
Classification Oracle stale (M3)	All Module 3 transfers on affected mint halt (REG-42 federal variant)

6.9.3 Recovery Semantics

Oracle	Recovery
Custody	Auto-resume on next valid Empire attestation
OFAC	Auto-resume on next valid relay attestation
AML	Auto-resume per wallet on next AML re-fetch
TWAP	Auto-resume on next valid Pyth update
EDGAR	N/A (no halt to recover from)
NAV (M2)	Auto-resume on next valid appraiser attestation within reappraisal cadence
Classification (M3)	Auto-resume on next valid relay attestation with federal_action_active = false

All recoveries are automatic. No manual unfreeze actions are required for oracle-driven halts.

---

6.10 Oracle Network and SEC Category 1 Model B

The Oracle Network is foundational to satisfying Pillar 4 (True Equity Backing 1:1) and Pillar 6 (Investor Protection — compliance enforcement at every transfer):

Pillar	Oracle Contribution
Pillar 4 — True Equity Backing	Custody Oracle Ed25519 attestation per slot; verified by Control CV-01 on every transfer
Pillar 6 — Investor Protection	OFAC, AML, TWAP, NAV (M2), Classification (M3) feed Transfer Hook controls executing on every transfer

Without continuous, signed oracle attestations, neither pillar could be satisfied as architectural property. The Oracle Network is what allows the platform's compliance posture to be cryptographic and continuous rather than periodic and audit-mediated.

---

RWA Tokens Whitepaper V10 — Section 6 — Confidential — Groovy Company, Inc.