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 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 Digital Securities 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 Digital Securities compliance 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 · AML: every 6 hours
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:

Primary Feed  ──→  Live API source
Secondary Feed ──→  OTCM internal verification node
Tertiary Feed  ──→  Public audit / on-chain archive

Transfer Hook requires 2-of-3 oracle consensus to APPROVE a transaction.

If consensus cannot be reached:
  └── Affected Transfer Hook defaults to REJECTION
      (conservative fail-safe posture until consensus restored)

If two oracles agree and one is unavailable or returns a discrepant value, the majority consensus governs. This eliminates single-oracle compromise as an attack vector.

---

🏦 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 — the mechanism that makes ST22 tokens Digital Securities rather than unbacked speculation.

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 — the following sequence executes automatically:

Discrepancy Detected (any amount > 0)
         ↓
Hook 1 rejects ALL ST22 transfers — Error 6001
         ↓
Circuit breaker activates automatically
         ↓
OTCM Protocol operations notified simultaneously
Empire Stock Transfer notified simultaneously
         ↓
Trading resumes ONLY after:
  ├── Discrepancy resolved
  └── 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 Digital Securities transfers. Risk scores are computed on a 0–100 scale and mapped to three disposition tiers:

Score	Risk Tier	Disposition
0–30	Low	Automatic approval — transaction proceeds
31–70	Medium	Enhanced review — proceeds but flagged for compliance team audit
71–100	High	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 displayed prices — real-time price quotes for all ST22 trading pairs
• TWAP oracle — the rolling average used by Hook 5's circuit breaker enforcement

---

🔹 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.

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:

• Layer 2 (Transfer Hooks) — provides issuer eligibility data, confirming that a company's SEC registration is current and no regulatory actions have suspended trading
• Layer 9 (Predictive AI Module) — provides real-time filing intelligence driving 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)

⚠️ Fail-Safe Default: The Custody Verification Oracle is the only oracle with a hard fail-safe (reject all transfers) rather than a cached fallback. This reflects the asymmetric risk of a custody discrepancy versus a stale AML score — a custody discrepancy threatens the foundational 1:1 backing guarantee of every ST22 Digital Securities token on the platform.

---

Groovy Company, Inc. dba OTCM Protocol · Wyoming Corporation · invest@otcm.io · otcm.io

---

🔮 The real-time data backbone feeding every Transfer Hook decision — custody verification, sanctions screening, AML scoring, price discovery, and SEC EDGAR intelligence.

---

🏗️ 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 five distinct external data sources. Every ST22 tokenDigital Securities transfer triggers six42 Transfer HooksHook controls — and fivethe most consequential of those sixcontrols requiredepend entirely on live oracle data to render their compliance decisions.decisions:

A

 custody

•       Custody verification hook(Control cannot1) — Cannot function without real-time Empire Stock Transfer balance data.attestation An— OFACthe foundational guarantee of 1:1 backing

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

•       AML hookrisk cannotscoring (Control 11) — Cannot function without live blockchain analytics scores.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 componentcomponent. — itIt is load-bearing infrastructure upon which the entire securityDigital 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

 

TWAP

	Oracle Category		Layer 2 Hook Dependency		Update Frequency	Fail-Safe
Custody Verification	HookControl 1 — 1:1 backing ratio check	Every Solana block (~400ms) + event-triggered	Reject all transfers
Compliance & Sanctions	HookControls 28–10 (OFAC) · Control 11 (AML)	OFAC: hourly · AML: every 6 hours	OFAC: use last list (<24h) · AML: use cached (<6h)
Price Discovery	Control 25 — OFAC / Hook 3 — AML	OFAC: hourly
Price Discovery	Hook 5 —TWAP circuit breaker /	Continuous (Pyth Network)Network sub-second)	Use last confirmed price
SEC EDGAR Intelligence	HookControl 412 — 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.transaction:

 

•       2-of-3 majority consensus governs — If two oracles agree and one is unavailable or returns a discrepant value, the majority consensus governs.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.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 Oracle Architecture and Role

The Custody Verification Oracle provides the real-time backing ratio data that HookControl 1 requires to confirm that circulating ST22 token supply never exceeds custodied Series M share count atheld by Empire Stock Transfer. This oracle is the foundational guarantee of the 1:1 backing model.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 feedattestation 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 — ESTEmpire's private key signs each balance attestationattestation; 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 aany discrepancy between circulating token supply and custodied share count — regardless of cause — Hookthe following automated sequence executes:

 

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

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

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

•       Resolution required before resumption — Trading resumes only after the discrepancy is resolved and dual2-of-3 oracle confirmationconsensus received.confirms Thisthe 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 HookControls 28–10 with a continuously updated, indexed copy of the U.S. Treasury Department's Specially Designated Nationals (SDN) list. The oracle implements fuzzy namemultiple matching and address clustering analysislayers to catch wallets attempting to transact through proxies of sanctioned entities.entities — not just direct address matches:

 

	Parameter		Specification
SourcePrimary 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 fuzzyknown sanctioned addresses
Matching method 2	Fuzzy entity name match +for addressentity investors — catches slight variations in registered entity names
Matching method 3	Address clustering
Reject behavior	Hookanalysis — identifies wallets receiving funds from or sending funds to sanctioned addresses within 2 returnshops
Rejection behavior	Controls 8–10 return Error 6002;6003 (SenderSanctioned) or 6004 (ReceiverSanctioned); transaction reverts atomically
False positive protocol	Manual review pathway; OTCM compliance team notified within 5 minutesminutes; 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:30	Low	Automatic approval — transaction proceeds Score without additional review	✓ Allowed
  31–70:70	Medium	Enhanced review — transaction proceeds but flagged for compliance team audit Score within 24 hours	⚠️ Flagged
  71–100:100	High	Automatic rejection — Hook 3 returns Error 6003;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.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)firms — who publish price attestations directly on-chain,chain. providingThis architecture provides manipulation-resistant price feeds with sub-second update cadence.cadence, Thissourced from entities with direct market access rather than derived from other on-chain markets.

Pyth price data feedsserves CEDEX'stwo displayedconsumers priceswithin the OTCM Protocol stack: real-time price display in the CEDEX trading interface, and the TWAP oracle usedthat byControl Hook25's 5.price impact circuit breaker enforces on every transfer.

 

🔹 6.4.2 Time-Weighted Average Price (TWAP)TWAP Calculation and Circuit Breaker Parameters

HookControl 5 (Price Impact Circuit Breaker)25 enforces a maximum 2% price movement per transaction against a rolling TWAP.Time-Weighted Average Price. The TWAP is calculated usingacross 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.activations Theor, TWAPconversely, windowallow issustained amanipulation DAO-governableto parameter.move the reference price.

 

from

	TWAP Parameter		Default Value		Governance	Rationale
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
OracleBalances manipulation guardresistance against responsiveness to genuine market movements
OutlierMinimum rejectionobservations (>3σ	median) 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 servesis unique in serving two distinct consumers inwithin the OTCM Protocol nine-layer stack. ForA single data pipeline serves both, eliminating redundant API calls and ensuring consistent data across compliance and intelligence functions:

 

•       Layer 2 (Transfer Hooks), it— providesProvides issuer eligibility data —through Control 12, confirming that aan company'issuer's SEC registration is current andcurrent, no regulatory actions have suspended trading.trading, Forand 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), it— providesProvides 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 outreachtokenization prioritization.readiness Aassessment.

single

 EDGAR data pipeline serves both consumers, eliminating redundant API calls.

🔹 6.5.2  EDGAR Data Pipeline — Filing-Level Detail

 

	Filing Type		TransferControl Hook12 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 (Hook— 4)non-compliant issuers halted at Control 12	Tier degradation scoring input— 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	Reject all transfers (Ed25519 signed, ~400ms)	OTCM internal verification node	REJECT ALL TRANSFERS — hard fail-safe)safe. No fallback trades permitted on custody uncertainty.	< 200ms
OFAC/OFAC / SDN	U.S. Treasury OFAC API	Cached copy updated hourly	Use last confirmed SDN list (if < 24h24 old)hours old. Halt if > 48 hours stale.	< 50ms
AML Risk Score	Chainalysis KYT + TRM Labs	Locally cached scores	Use cached score (if < 6h6 old)hours old. On-demand refresh for first-time wallets.	< 400ms
TWAP / Price	Pyth Network on-chain feed	Last confirmed Pyth price	Use last confirmed priceprice. 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