Section 6: Oracle Network — Layer 6

OTCM PROTOCOL

Comprehensive Technical Whitepaper — Version 7.0

ST22 Digital Securities Platform | March 2026 | Groovy Company, Inc. dba OTCM Protocol

Section 6: Oracle Network — Layer 6

The real-time data backbone feeding every Transfer Hook compliance decision — custody verification, sanctions screening, AML scoring, price discovery, and SEC EDGAR intelligence. Layer 6 feeds Layer 2 directly, ensuring that compliance decisions are based on authoritative external data rather than data that has passed through OTCM's own application stack.

6.1 Architecture Overview

6.1.1 The Critical Role of Real-Time Data

Unlike permissionless 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 five distinct external data sources. Every ST22 Digital Securities transfer triggers 42 Transfer Hook controls — and the most consequential of those controls depend entirely on live oracle data to render their compliance decisions:

• Custody verification (Control 1) — Cannot function without real-time Empire Stock Transfer balance attestation — the foundational guarantee of 1:1 backing

• OFAC/SDN screening (Controls 8–10) — Cannot function without a current SDN list — stale data creates regulatory exposure for every trade

• AML risk scoring (Control 11) — Cannot function without live blockchain analytics scores — cached scores older than 6 hours must be refreshed

• Holding period enforcement (Control 24) — Reads on-chain HoldingPeriodAccount directly — no oracle dependency, but depends on accurate jurisdiction flag set by Empire at onboarding

• Price impact circuit breaker (Control 25) — Cannot function without a current TWAP — requires a minimum of 60 price observations across a 30-minute window

The Oracle Network is therefore not an auxiliary component. It is load-bearing infrastructure upon which the entire Digital Securities compliance architecture depends. An oracle failure is a compliance failure — which is why the Oracle Network is designed with Byzantine fault tolerance at every level.

6.1.2 Four Oracle Categories

Oracle Category	Layer 2 Hook Dependency	Update Frequency	Fail-Safe
Custody Verification	Control 1 — 1:1 backing ratio check	Every Solana block (~400ms) + event-triggered	Reject all transfers
Compliance & Sanctions	Controls 8–10 (OFAC) · Control 11 (AML)	OFAC: hourly · AML: every 6 hours	OFAC: use last list (<24h) · AML: use cached (<6h)
Price Discovery	Control 25 — TWAP circuit breaker	Continuous (Pyth Network sub-second)	Use last confirmed price
SEC EDGAR Intelligence	Control 12 — issuer eligibility + Layer 9 AI	Real-time RSS + daily batch	Continue with last batch

6.1.3 Byzantine Fault Tolerance Model

No single oracle source constitutes a single point of failure. For each oracle category, OTCM Protocol 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:

• 2-of-3 majority consensus governs — If two oracles agree and one is unavailable or returns a discrepant value, the majority consensus governs and trading continues

• Consensus failure defaults to rejection — If oracle consensus cannot be reached, the affected Transfer Hook defaults to rejection — the conservative fail-safe posture — until consensus is restored

• No single-oracle compromise vector — An attacker compromising one oracle feed cannot influence Transfer Hook decisions — they would need to simultaneously compromise two of three independent sources

6.2 Custody Verification Oracle — Empire Stock Transfer Integration

Oracle 1: Custody Verification

Hook dependency: Control 1 — 1:1 backing ratio check on every transfer | Update frequency: Every Solana block (~400ms) + event-triggered on custody change

6.2.1 Architecture and Role

The Custody Verification Oracle provides the real-time backing ratio data that Control 1 requires to confirm that circulating ST22 token supply never exceeds custodied Series M share count held by Empire Stock Transfer. This oracle is the foundational guarantee of the 1:1 backing model — the mechanism that makes ST22 tokens Digital Securities backed by real equity rather than unbacked on-chain instruments.

Empire Stock Transfer is the authoritative source for this data. As the SEC-registered transfer agent and qualified custodian holding all Series M preferred shares under irrevocable custody arrangements, Empire holds the definitive record of how many shares exist in custody at any moment. The oracle publishes this count cryptographically signed with Empire's Ed25519 private key on every Solana block.

Feed Parameter	Specification
Primary source	Empire Stock Transfer API — cryptographically signed balance attestation per block
Secondary source	OTCM Protocol internal verification node — cross-references Empire data against on-chain token supply
Tertiary source	Quarterly third-party audit published on-chain — independent institutional confirmation
Update cadence	Every Solana block (~400ms); event-triggered immediately on any custody change
Signature standard	Ed25519 — Empire's private key signs each balance attestation; public key registered on-chain
Latency SLA	< 200ms from custody change to oracle update confirmation
Discrepancy threshold	Any discrepancy > 0 tokens triggers circuit breaker (Error 6001) — zero tolerance

6.2.2 Discrepancy Detection and Response

If the custody oracle detects any discrepancy between circulating token supply and custodied share count — regardless of cause — the following automated sequence executes:

• Immediate transfer rejection — Control 1 rejects all subsequent ST22 transfers with Error 6001 (CustodyDiscrepancy) — trading halts for all ST22 tokens on the affected mint

• Circuit breaker activation — The global circuit breaker activates, flagging the affected mint across all 42 Transfer Hook controls

• Dual notification — OTCM Protocol operations and Empire Stock Transfer compliance are simultaneously notified via automated alert — P0 severity, 15-minute response SLA

• Resolution required before resumption — Trading resumes only after the discrepancy is resolved and 2-of-3 oracle consensus confirms the custody count matches token supply

Production Record

The Custody Verification Oracle discrepancy mechanism has never triggered in production. Across three beta issuers and $7M+ in processed liquidity, the 1:1 backing ratio has been maintained at every block with zero discrepancy events. This record reflects the integrity of Empire Stock Transfer's custody operations and the reliability of the attestation oracle architecture.

6.3 Compliance Oracles — Sanctions and AML Intelligence

Oracle 2: OFAC/SDN Sanctions Screening

Hook dependency: Controls 8–10 — sender and receiver SDN check on every transfer | Update frequency: Hourly full refresh + immediate push on emergency SDN additions

6.3.1 OFAC/SDN Sanctions Oracle

The OFAC oracle provides Controls 8–10 with a continuously updated, indexed copy of the U.S. Treasury Department's Specially Designated Nationals (SDN) list. The oracle implements multiple matching layers to catch wallets attempting to transact through proxies of sanctioned entities — not just direct address matches:

Parameter	Specification
Primary source	U.S. Treasury OFAC SDN list via official API
Update frequency	Hourly full refresh; immediate push notification on emergency SDN list additions
Matching method 1	Exact Solana wallet address match against known sanctioned addresses
Matching method 2	Fuzzy entity name match for entity investors — catches slight variations in registered entity names
Matching method 3	Address clustering analysis — identifies wallets receiving funds from or sending funds to sanctioned addresses within 2 hops
Rejection behavior	Controls 8–10 return Error 6003 (SenderSanctioned) or 6004 (ReceiverSanctioned); transaction reverts atomically
False positive protocol	Manual review pathway; OTCM compliance team notified within 5 minutes; Empire Stock Transfer notified for investor record annotation
Oracle staleness threshold	SDN data older than 24 hours uses cached fallback; data older than 48 hours triggers transfer halt pending refresh

Continuous Re-Screening — Not Just Onboarding

Empire Stock Transfer screens investors against the OFAC SDN list during initial onboarding (KYC/KYB). Controls 8–10 re-screen every wallet on every subsequent transfer. A wallet that was clean at onboarding but later added to the SDN list — through a Treasury emergency designation or routine list update — is blocked immediately on its next transfer attempt. This continuous re-screening is architecturally impossible to replicate in an application-layer compliance system.

Oracle 3: AML Blockchain Analytics

Hook dependency: Control 11 — ML risk scoring on every transfer | Update frequency: Refreshed every 6 hours + on-demand for first-time wallet encounters

6.3.2 Blockchain Analytics Oracle — Chainalysis KYT and TRM Labs

The AML oracle aggregates machine-learning risk scores from two independent blockchain analytics providers — Chainalysis Know Your Transaction (KYT) and TRM Labs — for every wallet address participating in ST22 Digital Securities transfers. Dual-provider aggregation eliminates single-provider failure as a compliance gap and provides cross-validated risk assessments for high-stakes transactions.

Risk scores are computed on a 0–100 scale reflecting the aggregate risk profile of a wallet address based on transaction history, counterparty risk, darknet market exposure, ransomware activity, exchange sanctions, and mixing service usage. Scores are mapped to three disposition tiers:

Score	Risk Tier	Disposition	Transfer Status
0–30	Low	Automatic approval — transaction proceeds without additional review	✓ Allowed
31–70	Medium	Enhanced review — transaction proceeds but flagged for compliance team audit within 24 hours	⚠️ Flagged
71–100	High	Automatic rejection — Hook 3 returns Error 6006; transaction reverts atomically	✗ Rejected 6006

Risk scores are refreshed every six hours for all active wallets and on-demand for new wallet addresses encountered for the first time — ensuring new participants receive a fresh score, not a default. The oracle caches scores locally to ensure sub-400ms hook execution even during high transaction volumes. Stale scores older than 6 hours trigger a mandatory on-demand refresh before the transfer is permitted to proceed.

6.4 Price Discovery Oracles — TWAP and Circuit Breaker Data

Oracle 4: Price Discovery Hook dependency: Control 25 — TWAP circuit breaker on every transfer \| Update frequency: Continuous sub-second updates via Pyth Network

6.4.1 Pyth Network Integration

OTCM Protocol 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 — institutional market makers and trading firms — who publish price attestations directly on-chain. This architecture provides manipulation-resistant price feeds with sub-second update cadence, sourced from entities with direct market access rather than derived from other on-chain markets.

Pyth price data serves two consumers within the OTCM Protocol stack: real-time price display in the CEDEX trading interface, and the TWAP oracle that Control 25's price impact circuit breaker enforces on every transfer.

6.4.2 TWAP Calculation and Circuit Breaker Parameters

Control 25 enforces a maximum 2% price movement per transaction against a rolling Time-Weighted Average Price. The TWAP is calculated across a configurable window (default: 30 minutes) of on-chain price observations, making it resistant to single-block manipulation attacks that could otherwise trigger false circuit breaker activations or, conversely, allow sustained manipulation to move the reference price.

TWAP Parameter	Default Value	Governance	Rationale
Calculation window	30 minutes	DAO-adjustable (15–60 min range)	Balances manipulation resistance against responsiveness to genuine market movements
Minimum observations	60 observations	Fixed in Transfer Hook code	Prevents TWAP calculation from a statistically insufficient sample
Maximum price impact	2% per transfer	DAO-adjustable (1–5% range)	Blocks individual transactions from creating dislocations while permitting normal large trades via order splitting
Circuit breaker reset	Automatic on TWAP normalization	N/A — automatic	No manual intervention required — system self-heals as price stabilizes
Outlier rejection	Observations > 3σ from rolling median excluded	Fixed in Transfer Hook code	Prevents a single manipulated price publication from distorting the TWAP

6.5 SEC EDGAR Intelligence Oracle

Oracle 5: SEC EDGAR Intelligence

Hook dependency: Control 12 — issuer eligibility + Layer 9 AI Module | Update frequency: Real-time RSS feed + daily batch EDGAR full-text search

6.5.1 Dual Consumers: Transfer Hooks and Layer 9 AI Module

The EDGAR oracle is unique in serving two distinct consumers within the OTCM Protocol nine-layer stack. A single data pipeline serves both, eliminating redundant API calls and ensuring consistent data across compliance and intelligence functions:

• Layer 2 (Transfer Hooks) — Provides issuer eligibility data through Control 12, confirming that an issuer's SEC registration is current, no regulatory actions have suspended trading, and Rule 15c2-11 compliance status is maintained. If an issuer's registration lapses or an SEC enforcement action is detected, Control 12 halts transfers of that issuer's ST22 tokens immediately.

• Layer 9 (Predictive AI Module) — Provides the real-time filing intelligence that drives the Issuer Distress and Opportunity Score (IDOS) and the issuer acquisition pipeline. The same EDGAR filings that Control 12 uses for eligibility verification are processed by the AI module's NLP pipeline for distress scoring and tokenization readiness assessment.

6.5.2 EDGAR Data Pipeline — Filing-Level Detail

Filing Type	Control 12 Consumer (Layer 2)	AI Module Consumer (Layer 9)
Form D	Issuer Reg D registration verification — confirms offer is properly filed within 15 days of first sale	Capital raise timing + urgency scoring — early Form D filing indicates active raise
10-K / 10-Q	Current information status — annual/quarterly filings confirm issuer is not delinquent	Liquidity Distress Index NLP scan — financial statement analysis for distress indicators
Form 8-K	Regulatory action detection — SEC enforcement, bankruptcy, officer changes	Real-time distress trigger alerts — material events flagged for immediate IDOS score update
DEF 14A	Active SEC reporting verification — proxy filing confirms ongoing reporting compliance	Shareholder count extraction — feeds into IDOS scoring and issuer prioritization
Rule 15c2-11 status	Trading eligibility — non-compliant issuers halted at Control 12	Tier degradation scoring — tracks degradation path for outreach prioritization

6.5.3 Pipeline Architecture

• Real-time RSS feed — EDGAR's RSS feed monitors all new filings across approximately 15,000 OTC companies. New filings trigger immediate processing — Control 12 eligibility status updates within minutes of a new 8-K regulatory action filing.

• Daily full-text search batch — EDGAR Full-Text Search (EFTS) API processes the complete filing corpus daily, ensuring no filings are missed due to RSS feed gaps or processing failures.

• Deduplication and normalization — A standardized data pipeline deduplicates filings across both feed sources and normalizes them into the OTCM issuer record format consumed by both Layer 2 and Layer 9.

• Fallback on batch failure — If the daily batch fails, Layer 2 continues with the last confirmed batch data. Layer 9 IDOS scores are flagged as stale but remain operational. A P2 alert escalates to the operations team for manual review.

6.6 Oracle Fault Tolerance and Performance Specifications

6.6.1 Complete Oracle SLA Reference

Oracle	Primary Source	Secondary / Fallback	Fail-Safe Behavior	SLA
Custody Verification	Empire Stock Transfer API (Ed25519 signed, ~400ms)	OTCM internal verification node	REJECT ALL TRANSFERS — hard fail-safe. No fallback trades permitted on custody uncertainty.	< 200ms
OFAC / SDN	U.S. Treasury OFAC API	Cached copy updated hourly	Use last confirmed SDN list if < 24 hours old. Halt if > 48 hours stale.	< 50ms
AML Risk Score	Chainalysis KYT + TRM Labs	Locally cached scores	Use cached score if < 6 hours old. On-demand refresh for first-time wallets.	< 400ms
TWAP / Price	Pyth Network on-chain feed	Last confirmed Pyth price	Use last confirmed price. Circuit breaker deactivated if TWAP unavailable > 5 min.	< 100ms
EDGAR Intelligence	EDGAR RSS + EFTS API	Previous batch results	Continue with last batch data. Layer 9 IDOS flags as stale. P2 alert raised.	< 60s (batch)

Asymmetric Fail-Safe: Custody vs. All Other Oracles

The Custody Verification Oracle is the only oracle with a hard fail-safe (reject all transfers) rather than a cached-data fallback. Every other oracle has a graceful degradation path — trading continues on cached data within defined staleness windows. The custody oracle does not because the consequences are asymmetric: a stale AML score creates manageable risk; a custody discrepancy threatens the foundational 1:1 backing guarantee of every ST22 Digital Securities token on the platform. The permanent lock of the Global Unified CEDEX Liquidity Pool is only meaningful if the tokens it trades have verified real-equity backing at every moment.

6.6.2 Oracle Security Properties

The Oracle Network's security properties are determined by its architecture rather than by trust in any individual provider:

Security Property	Mechanism	Effect
Single-oracle compromise resistance	2-of-3 Byzantine consensus required for every approval decision	Attacker must simultaneously compromise two of three independent sources
Replay attack prevention	Ed25519 signatures include block height and timestamp — stale signatures rejected	Captured oracle responses cannot be replayed in subsequent blocks
Price manipulation resistance	TWAP window + 3σ outlier rejection	Single-block or short-duration manipulation cannot move circuit breaker reference
SDN evasion resistance	3-layer matching: exact address + fuzzy name + 2-hop clustering	Proxy wallet strategies are detected through graph analysis of funding paths
AML score gaming	Dual-provider aggregation (Chainalysis + TRM Labs)	Different ML models and data sources reduce vulnerability to single-provider blind spots
EDGAR data tampering	SEC-sourced data signed and published on-chain	Manipulation would require compromising SEC's own EDGAR system

Groovy Company, Inc. dba OTCM Protocol | CIK: 1499275 | Version 7.0 | March 2026 | Confidential