🔮 Section 6: Oracle Network — Layer 6
🔮 The real-time data backbone feeding every Transfer Hook decision — custody verification, sanctions screening, AML scoring, price discovery, and SEC EDGAR intelligence.
🔮 SECTION 6: ORACLE NETWORK — LAYER 6
🏗️ 6.1 Oracle Network Architecture Overview
🔹 6.1.1 The Critical Role of Real-Time Data in a Compliant Exchange
Unlike permissionless DeFi protocols where smart contracts execute without reference to off-chain state, OTCM Protocol's Transfer Hook enforcement model requires continuous, verified, real-time feeds from external data sources. Every ST22 token transfer triggers six Transfer Hooks — and five of those six require live oracle data to render their compliance decisions. A custody verification hook cannot function without real-time Empire Stock Transfer balance data. An OFAC screening hook cannot function without a current SDN list. An AML hook cannot function without live blockchain analytics scores. The Oracle Network is therefore not an auxiliary component — it is load-bearing infrastructure upon which the entire security architecture depends.
🔹 6.1.2 Four Oracle Categories
Oracle Category | Layer 2 Hook Dependency | Update Frequency |
|---|---|---|
Custody Verification | Hook 1 — backing ratio check | Every Solana block (~400ms) |
Compliance & Sanctions | Hook 2 — OFAC / Hook 3 — AML | OFAC: hourly |
Price Discovery | Hook 5 — circuit breaker / TWAP | Continuous (Pyth Network) |
SEC EDGAR Intelligence | Hook 4 — issuer eligibility + Layer 9 AI | Real-time RSS + daily batch |
🔹 6.1.3 Byzantine Fault Tolerance Model
No single oracle source constitutes a single point of failure. For each oracle category, OTCM operates a primary feed, a secondary verification node, and a tertiary public audit feed. Transfer Hook execution requires 2-of-3 oracle consensus before approving a transaction. If two oracles agree and one is unavailable or returns a discrepant value, the majority consensus governs. If oracle consensus cannot be reached, the affected Transfer Hook defaults to rejection — the conservative fail-safe posture — until consensus is restored.
🏦 6.2 Custody Verification Oracle — Empire Stock Transfer Integration
🔹 6.2.1 Oracle Architecture
The Custody Verification Oracle provides the real-time backing ratio data that Hook 1 requires to confirm that circulating ST22 token supply never exceeds custodied Series M share count at Empire Stock Transfer. This oracle is the foundational guarantee of the 1:1 backing model.
Feed Parameter | Specification |
|---|---|
Primary source | Empire Stock Transfer API — cryptographically signed balance feed |
Secondary source | OTCM Protocol internal verification node |
Tertiary source | Quarterly third-party audit published on-chain |
Update cadence | Every Solana block (~400ms); event-triggered on any custody change |
Signature standard | Ed25519 — EST private key signs each balance attestation |
Latency SLA | < 200ms from custody change to oracle update confirmation |
Discrepancy threshold | Any discrepancy > 0 triggers circuit breaker (Error 6001) |
🔹 6.2.2 Discrepancy Detection and Response
If the custody oracle detects a discrepancy between circulating token supply and custodied share count — regardless of cause — Hook 1 rejects all transfers with Error 6001. The circuit breaker activates automatically. OTCM Protocol operations and Empire Stock Transfer are simultaneously notified. Trading resumes only after the discrepancy is resolved and dual oracle confirmation received. This mechanism has never triggered in production.
🔍 6.3 Compliance Oracles — Sanctions & AML Intelligence
🔹 6.3.1 OFAC/SDN Sanctions Oracle
The OFAC oracle provides Hook 2 with a continuously updated, indexed copy of the U.S. Treasury Department's Specially Designated Nationals (SDN) list. The oracle implements fuzzy name matching and address clustering analysis to catch wallets attempting to transact through proxies of sanctioned entities.
Parameter | Specification |
|---|---|
Source | U.S. Treasury OFAC SDN list via official API |
Update frequency | Hourly full refresh; immediate push on emergency SDN additions |
Matching method | Exact wallet address match + fuzzy entity name match + address clustering |
Reject behavior | Hook 2 returns Error 6002; transaction reverts atomically |
False positive protocol | Manual review pathway; OTCM compliance team notified within 5 minutes |
🔹 6.3.2 Blockchain Analytics Oracle — Chainalysis KYT & TRM Labs
The AML oracle aggregates machine-learning risk scores from Chainalysis Know Your Transaction (KYT) and TRM Labs for every wallet address participating in ST22 transfers. Risk scores are computed on a 0–100 scale and mapped to three disposition tiers:
- Score 0–30: Automatic approval — transaction proceeds
- Score 31–70: Enhanced review — transaction proceeds but flagged for compliance team audit
- Score 71–100: Automatic rejection — Hook 3 returns Error 6003; transaction reverts Risk scores are refreshed every six hours and on-demand for new wallet addresses encountered for the first time. The oracle caches scores locally to ensure sub-400ms hook execution even during high transaction volumes.
⚡ 6.4 Price Discovery Oracles — TWAP & Circuit Breaker Data
🔹 6.4.1 Pyth Network Integration
OTCM integrates Pyth Network's high-frequency, pull-based price oracle for SOL/USD and ST22/SOL price data. Pyth operates a network of first-party data publishers (market makers and trading firms) who publish price attestations directly on-chain, providing manipulation-resistant price feeds with sub-second update cadence. This data feeds CEDEX's displayed prices and the TWAP oracle used by Hook 5.
🔹 6.4.2 Time-Weighted Average Price (TWAP) Calculation
Hook 5 (Price Impact Circuit Breaker) enforces a maximum 2% price movement per transaction against a rolling TWAP. The TWAP is calculated using a configurable window (default: 30 minutes) of on-chain price observations, making it resistant to single-block price manipulation attacks that could otherwise trigger false circuit breaker activations. The TWAP window is a DAO-governable parameter.
TWAP Parameter | Default Value | Governance |
|---|---|---|
Calculation window | 30 minutes | DAO-adjustable (15–60 min range) |
Maximum price impact | 2% per transfer | DAO-adjustable (1–5% range) |
Circuit breaker reset | Automatic after TWAP normalizes | N/A |
Oracle manipulation guard | Outlier rejection (>3σ from median) | Fixed in Transfer Hook code |
🔮 6.5 SEC EDGAR Intelligence Oracle
🔹 6.5.1 Dual Consumers: Transfer Hooks and Layer 9 AI Module
The EDGAR oracle serves two distinct consumers in the OTCM stack. For Layer 2 (Transfer Hooks), it provides issuer eligibility data — confirming that a company's SEC registration is current and no regulatory actions have suspended trading. For Layer 9 (Predictive AI Module), it provides the real-time filing intelligence that drives issuer distress scoring and outreach prioritization. A single EDGAR data pipeline serves both consumers, eliminating redundant API calls.
🔹 6.5.2 EDGAR Data Pipeline
Filing Type | Transfer Hook Consumer | AI Module Consumer |
|---|---|---|
Form D | Issuer registration verification | Capital raise timing + urgency scoring |
10-K / 10-Q | Current information status | Liquidity Distress Index NLP scan |
Form 8-K | Regulatory action detection | Real-time distress trigger alerts |
DEF 14A | Active reporting verification | Shareholder count extraction |
15c2-11 status | Trading eligibility (Hook 4) | Tier degradation scoring input |
⚡ 6.6 Oracle Fault Tolerance & Performance Specifications
Oracle | Primary Source | Fallback Behavior | SLA |
|---|---|---|---|
Custody Verification | Empire Stock Transfer API | Reject all transfers (fail-safe) | < 200ms |
OFAC/SDN | U.S. Treasury API | Use last confirmed list (< 24h old) | < 50ms |
AML Risk Score | Chainalysis KYT + TRM Labs | Use cached score (< 6h old) | < 400ms |
TWAP / Price | Pyth Network on-chain | Use last confirmed price | < 100ms |
EDGAR Intelligence | EDGAR RSS + EFTS API | Continue with last batch | < 60s (batch) |