Section 2: Technical Architecture
🏗️OTCMThePROTOCOLcompleteComprehensive Technical Whitepaper — Version 7.0
ST22 Digital Securities Platform | March 2026 | Groovy Company, Inc. dba OTCM Protocol
Section 2: Technical Architecture
A comprehensive description of the nine-layer
infrastructuretechnology stackandthathowpowerseachthelayerOTCMintegratesProtocolto form a unified, compliance-native trading platform forST22 DigitalSecurities.Securities Platform, the Solana blockchain foundation, and the cross-layer communication architecture.
🏗️ 2.1 Layered Architecture Overview
🔹 2.1.1 The Nine-Layer Technology Stack
The OTCM Protocol L2 is not a single application but a comprehensive nine-layer infrastructure stack, each layer serving a distinct and irreplaceable function. The stack is designed so that security enforcement occurs at the lowest possible layer (Layer 2), ensuring that no higher-layer component can bypass, override, or selectively apply the 42 Transfer Hook security controls.
This architecture eliminates the attack surface that exists in platforms where compliance is implemented at the application layer rather than the token transfer primitive. Under the SEC's March 17, 2026 interpretation (Release No. 33-11412), ST22 Security Tokens are formally classified as Digital Securities — and this nine-layer architecture is purpose-built to enforce every obligation that classification entails.
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The nine-layer architecture represents a deliberate departure from existing DeFi infrastructure, which was designed for permissionless token movement rather than securities compliance. Each layer was purpose-built for Digital Securities — integrating custody verification (Layer 6), investor eligibility enforcement (Layer 2), and intelligent issuer/investor discovery (Layer 9) into a unified stack that functions as a single coherent system.
🔹 2.1.2 Protocol Layer Design Philosophy
The nine-layer architecture enforces strict separation of concerns, where each layer handles a distinct responsibility with well-defined interfaces to adjacent layers. This enables independent scaling, testing, and upgrading of individual layers while maintaining system integrity.
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🔹 2.1.3 Architecture Diagram
┌─────────────────────────────────────────────────────────────────┐
│ LAYER 9 — Predictive Marketing AI │
│ EDGAR NLP · IDOS Scoring · Launch Timing · Investor Targeting │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 8 — Wallet Infrastructure │
│ iOS · Android · Ledger/Trezor · KYC/AML Enforcement │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 7 — DAO Governance │
│ On-chain Voting · 48-hour Timelock · Supermajority Controls │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 6 — Oracle Network ←──── External Data Sources │
│ EST Custody · OFAC/SDN · AML · EDGAR · Price Feeds │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 5 — CEDEX Exchange │
│ Order Matching · Bonding Curve · CPMM · Settlement │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 4 — Custom AMM Engine │
│ Token-2022 Native · Circuit Breakers · TWAP │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 3 — Federated Liquidity Protocol │
│ Sovereign Per-Issuer LP · Permanent Locks · Capital Routes │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 2 — SPL Token-2022 Transfer Hooks ◄── LAYER 6 FEEDS │
│ 42 Controls · OFAC · AML · KYC · Custody · Circuit Breaker │
├─────────────────────────────────────────────────────────────────┤
│ LAYER 1 — Solana Foundation │
│ 65,000+ TPS · 400ms Slots · Tower BFT · PoH · Sealevel │
└─────────────────────────────────────────────────────────────────┘
Note:Layer 6 (Oracle Network) feeds Layer 2 (Security Enforcement) directly with real-time custody, sanctions, and AML data. Layer 9 (AI Module) operates as an intelligence overlay — consuming Layer 6 oracle feeds and populating the issuer pipeline that feeds qualified candidates into the Issuers Portal and Layer 5 CEDEX launch mechanism.
🔹 2.1.4 Cross-Layer Communication
Downward Communication (Request Flow) Actions at Layer 9 (AI), Layer 8 (Wallet), or Layer 5 (CEDEX) flow downward through Layer 2 (Security Enforcement) for Transfer Hook verification, drawing oracle data from Layer 6, before settling on Layer 1 (Solana).
Upward Communication (Response Flow) Settlement confirmations propagate upward from Layer 1 through Layer 2 compliance acknowledgement, Layer 6 oracle confirmation, and into user-facing interfaces at Layer 5 / Layer 8 — with a full on-chain audit trail written at each layer.
Horizontal Communication Components within each layer communicate via defined internal APIs. Layer 7 (DAO Governance) has a unique horizontal relationship: passed governance proposals write directly to parameter configurations in Layer 2, Layer 3, and Layer 4 via a 48-hour timelock mechanism — the only cross-layer write path not triggered by a token transfer event.
⚡ 2.2 Layer 1: Solana Blockchain Foundation
OTCM Protocol's technical foundation rests on Solana — a monolithic Layer 1 blockchain designed for high-throughput, low-latency transaction processing. Unlike modular blockchains that offload scaling to Layer 2 solutions, Solana handles all transaction processing, state management, and consensus directly on its base layer — a critical characteristic for Digital Securities trading where settlement certainty and deterministic execution are paramount.
🔹 2.2.1 Why Solana: Technical Rationale
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
💡Critical Design Decision:SPL Token-2022's Transfer Hook extension enables OTCM to execute compliance verification during every token transfer at the protocol level — a capability not available on Ethereum or most other blockchains without complex, gas-intensive proxy patterns.
🔹 2.2.2 Core Protocol Innovations
Solana achieves its exceptional performance through eight core innovations. Understanding these is essential for comprehending how OTCM's compliance-intensive operations execute efficiently.
Proof of History (PoH) Functions as a "cryptographic clock" that timestamps transactions before they enter consensus. PoH pre-establishes a verifiable sequence of events through a SHA-256 hash chain, where each hash depends on the previous output.
hash_n = SHA256(hash_n-1)
hash_n+1 = SHA256(hash_n)OTCM Application: Transfer Hook verification benefits from PoH's pre-established ordering. Compliance checks execute in deterministic sequence without consensus delays, enabling 750–1,250ms total verification time despite six sequential hooks.
Tower BFT Solana's custom PBFT implementation optimized to leverage PoH as its clock source. Traditional PBFT requires O(n²) message complexity; Tower BFT reduces this through PoH-synchronized voting.
Vote Lockout— Validators commit with exponentially increasing lockout periodsRollback Cost— Switching votes becomes exponentially more expensive over timeFinality— 32-block confirmation provides practical finality (~13 seconds)
Sealevel: Parallel Smart Contract Execution Processes thousands of smart contracts simultaneously by identifying non-overlapping transactions and executing them in parallel across available CPU cores.
OTCM Application: CEDEX trading transactions touching different ST22 token pairs execute in parallel. Transactions involving the same token pair serialize automatically, ensuring atomic state updates.
Turbine: Block Propagation Protocol Breaks blocks into smaller packets distributed through a tree structure. Each validator receives partial data and forwards it to downstream validators — achieving O(log n) propagation complexity.
Packet Size:64KB shreds (erasure-coded fragments)Fanout Factor:Each node forwards to 200 downstream nodesReconstruction:67% of shreds required to reconstruct a complete block
Gulf Stream: Mempool-less Transaction Forwarding Eliminates the traditional mempool by forwarding transactions to upcoming leader validators before the current block finalizes, reducing confirmation latency and memory pressure.
OTCM Application: CEDEX transactions forward immediately to the next leader, reducing the time between user submission and block inclusion — enabling sub-second UX despite comprehensive compliance verification.
Cloudbreak: Horizontally Scaled Account Database Implements Solana's account database using memory-mapped files optimized for concurrent reads and writes, supporting the parallel access patterns essential for high-throughput trading.
Pipelining: Transaction Processing Unit Operates similarly to CPU instruction pipelining with distinct stages for data fetching, signature verification, banking (state changes), and recording.
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
Archivers: Distributed Ledger Storage Specialized nodes responsible for distributed ledger storage, enabling validators to maintain high performance while ensuring complete historical data availability for compliance and audit purposes.
🔹 2.2.3 Consensus Mechanism Deep Dive
Solana employs a hybrid consensus mechanism combining Proof of History (PoH) with Delegated Proof of Stake (dPoS), achieving Byzantine Fault Tolerance while maintaining securities-grade throughput.
Leader Selection → Deterministic rotation among validators by stake weight
Block Production → Leader receives transactions via Gulf Stream · adds PoH timestamps
Block Propagation → Turbine distributes block shreds through validator network
Voting → Validators vote via Tower BFT with exponential lockout
Finality → 32 confirmations (~13 seconds) = practical finality🔹 2.2.4 Network Performance Specifications
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
📐 2.3 Layer-by-Layer Technical Specifications
🔹 2.3.1 Layers 1, 8 & 9: Application, Wallet & AI Module
Issuers Portal
Purpose: Comprehensive onboarding and management interface for companies tokenizing securities as Digital Securities through OTCM Protocol.
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
Core Functions:
Company Registration— SEC CIK validation, corporate document upload, authorized signatory verificationSeries M Configuration— Share class creation parameters, conversion ratios, custody arrangementsST22 Token Management— Minting authorization, vesting schedule configuration, treasury managementCompliance Dashboard— Real-time trading analytics, regulatory reporting, investor cap table
CEDEX Trading Interface
Purpose: Real-time trading interface for ST22 Digital Securities transactions with integrated compliance verification.
Core Functions:
Market Discovery— Token listing, price charts, volume analytics, market depth visualizationOrder Execution— Market orders, limit orders, swap interface with slippage protectionPortfolio Management— Holdings display, transaction history, P&L trackingCompliance Status— Real-time KYC status, verification requirements, restriction alerts
Staking Interface
Core Functions:
Stake Management— Deposit/withdraw OTCM tokens, delegation to validator nodesRewards Tracking— APY display (8–60%), reward accrual, claim functionalityEpoch Management— 2.6-day epoch visualization, reward distribution timingGovernance— Voting on protocol proposals, delegation to representatives
DAO Governance Interface (Layer 7)
Core Functions:
Proposal Management— Submit, review, and vote on protocol governance proposals with quorum requirementsSecurity Control Governance— Multi-tier voting required for any Transfer Hook parameter changeTimelock Enforcement— 48-hour execution delay on all passed proposalsTreasury Oversight— DAO governance over OTCM Protocol development fund allocation
Web3 Wallet Application (Layer 8)
Core Functions:
Portfolio Management— Multi-issuer ST22 holdings display, transaction history, P&L trackingEmbedded KYC/AML— Inline accreditation verification and compliance status displayToken Operations— Send, receive, stake, and redeem ST22 with full Transfer Hook enforcementInstitutional Support— Ledger and Trezor hardware wallet integration · multi-sig custody
Predictive Marketing AI Dashboard (Layer 9)
Core Functions:
IDOS Dashboard— Real-time Issuer Distress and Opportunity Score rankings across 15,000+ OTC companiesInvestor Pool Analytics— Qualified accredited wallet targeting for ST22 launch campaignsLaunch Timing— Launch Readiness Score monitoring and optimal window recommendationsBurn Analytics— Real-time on-chain tracking of OTCM token burns from AI module operations
🔹 2.3.2 Layer 2: Security Enforcement — SPL Token-2022 Transfer Hooks
Layer 2 implements OTCM's 42-control security architecture through SPL Token-2022 Transfer Hooks, intercepting every ST22 Digital Securities transfer before it completes. Oracle data from Layer 6 feeds real-time custody balances, sanctions lists, and AML scores into each hook's decision logic.
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
💡Atomic Execution Guarantee:If any Transfer Hook returns an error, the entire transaction reverts atomically. Non-compliant transfers can never execute, even partially. Solana's account model and Sealevel's transaction isolation guarantee this atomicity.
Hook 3 — AML Risk Scoring Tiers:
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
🔹 2.3.3 Layers 3, 4 & 5: Federated Liquidity, Custom AMM & CEDEX
Layers 3, 4, and 5 form the integrated trading and liquidity stack. Layer 3 manages sovereign per-issuer liquidity pools. Layer 4 is OTCM's proprietary AMM, purpose-built for Token-2022 compliance. Layer 5 (CEDEX) combines centralized order matching with decentralized settlement.
CEDEX Engine
Bonding Curve Trading (Pre-Graduation): New ST22 tokens begin trading on linear bonding curves:
P(n) = P0 + (g × n)
P0 = 0.000001 SOL · g = 0.0000000079 SOL/tokenCPMM Trading (Post-Graduation): Upon graduation (market cap ≥ $250,000), tokens transition to Constant Product Market Maker mechanics:
output = (input_amount × output_reserve) / (input_reserve + input_amount)OTCM Liquidity Pool — Four Capital Accumulation Mechanisms:
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Projected LP Growth:
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
🔹 2.3.4 Layer 1: Solana Blockchain Foundation
RPC Node Architecture:
Primary RPC— Helius dedicated nodes (500 req/sec · 100 sendTx/sec tier)Failover RPC— Triton/QuickNode backup clusterGeographic Distribution— US-East · US-West · EU-West · APAC nodesMEV Protection— Jito bundle integration for frontrunning protection
Transaction Lifecycle on Solana:
Submission → Transaction submitted to RPC node · forwarded via Gulf Stream to leader
Processing → Leader includes tx in block · Sealevel executes Transfer Hooks in parallel
Propagation → Turbine distributes block shreds across validator network
Voting → Validators vote on block validity via Tower BFT
Confirmation → Transaction confirmed after 1 block (~400ms)
Finality → Practical finality achieved after 32 blocks (~13 seconds)🔹 2.3.5 Layer 6: Oracle Network & External Data Integration
Layer 6 provides the real-time data bridge between on-chain Transfer Hook enforcement and the off-chain data sources required for Digital Securities compliance — custody verification, sanctions screening, AML scoring, and SEC EDGAR intelligence.
Empire Stock Transfer Integration:
|
|
|---|---|
|
|
|
|
|
|
|
|
Compliance Oracle Network:
OFAC/SDN Oracle— Updates hourly from Treasury Department SDN list. Implements fuzzy matching algorithms for name variations and aliasesBlockchain Analytics Oracle— Integrates Chainalysis KYT and TRM Labs. Provides wallet risk scoring based on transaction history, counterparty analysis, and pattern detectionSEC EDGAR Integration— Pulls company financial data, filing status, and corporate action information for issuer onboarding verification and ongoing compliance monitoring
📋 RPC Infrastructure Redundancy Specification
Version: 6.1 | Extends: RPC Node Architecture
Health Check and Alerting:
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🔗 Transaction Durability Specification
Version: 6.1 | Applies To: All CEDEX transaction submissions
Blockhash Lifecycle Management Solana transactions are valid only while their recent_blockhash is within the last ~150 blocks (~60 seconds). CEDEX manages blockhash freshness proactively.
Durable Nonce Accounts — Institutional Orders For large institutional orders requiring extended signing windows (e.g., multi-sig approval workflows >60 seconds), CEDEX supports durable nonce account-based transactions — bypassing the blockhash expiry constraint.
🔄 2.4 Data Flow Specification
🔹 2.4.1 Transaction Lifecycle
Every ST22 Digital Securities transaction follows a deterministic lifecycle from user initiation through settlement and post-transaction monitoring.
🔹 2.4.2 Nine-Layer Transaction Processing Model
Phase 1: Initiation (0–50ms) Transaction initiation begins when a user submits an ST22 transfer through CEDEX:
interface TransactionParams {
tokenMint: PublicKey; // ST22 Digital Securities token address
amount: u64; // Transfer amount in base units
maxPrice: u64; // Slippage protection (0 = market)
recipientWallet: PublicKey; // Destination wallet
deadline: i64; // Unix timestamp expiry
}Phase 2: Verification (750–1,350ms) All six Transfer Hooks execute sequentially. Each hook:
Queries its designated oracle or data sourcePerforms verification logic against compliance rulesRecords verification result in the compliance logReturns PASS to continue or ERROR to revert
Phase 3: Execution (400–600ms) Upon successful verification, transaction execution proceeds atomically:
Swap output calculated via CPMM formulaPool reserves updated (Effects before Interactions — CEI pattern)Tokens transferred to recipientFees distributed to protocol and issuer
Phase 4: Settlement (~13 seconds) Settlement occurs through Solana's Tower BFT consensus. After 32 block confirmations, the transaction achieves practical finality with cryptographic guarantees against reversal.
Phase 5: Post-Transaction Monitoring (Ongoing)
Real-time pattern analysis— ML models analyze transaction patterns for suspicious activityFlagging queue— Transactions meeting review thresholds enter compliance team queueSAR evaluation— Suspicious Activity Report filing determination for flagged transactionsRegulatory reporting— Automated generation of required regulatory filings
🔹 2.4.3 Error Handling & Recovery
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🔌 2.5 External System Integration
🔹 2.5.1 Empire Stock Transfer Integration
GET https://api.empirestocktransfer.com/v1/custody/{issuer_cik}
Authorization: Bearer {api_key}
X-Oracle-Signature: {signature}
Response:
{
"issuer_cik": "string", // SEC CIK number
"cusip": "string", // CUSIP identifier
"share_class": "SERIES_M", // Always Series M
"custodied_balance": u64, // Verified share count
"last_verification": i64, // Unix timestamp
"attestation_signature": "string", // Ed25519 signature
"audit_hash": "string" // SHA-256 of audit data
}🔹 2.5.2 Compliance Oracle Network
OFAC Screening API:
POST https://oracle.otcm.io/v1/ofac/screen
{
"wallet_address": "7xKXt...",
"transaction_type": "transfer",
"counterparty": "9yMPs..."
}
Response:
{
"status": "CLEAR" | "MATCH" | "PARTIAL_MATCH",
"sdn_match_confidence": 0.0–1.0,
"last_list_update": "2026-03-17T00:00:00Z",
"verification_id": "uuid"
}🔹 2.5.3 External API Specifications
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
⚡ 2.6 Performance Engineering
🔹 2.6.1 Throughput Analysis
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
🔹 2.6.2 End-to-End Latency
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
🔹 2.6.3 Scalability Architecture
Token Pair Isolation— Trades in different ST22 tokens execute in parallel (no account overlap)Oracle Caching— Compliance oracle results cached for 1 block (~400ms) to reduce redundant queriesBatch Processing— Off-chain systems aggregate compliance data for efficient on-chain verificationGeographic Distribution— Multi-region RPC deployment minimizes network latency globally
🏗️ 2.7 Security Architecture
🔹 2.7.1 Defense-in-Depth Model
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🔹 2.7.2 Cryptographic Standards
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
🔹 2.7.3 Attack Surface Analysis
|
|
|---|---|
|
|
|
|
|
|
|
|
🚀 2.8 Deployment Topology
┌─────────────────────────────────────────────────────┐
│ OTCM PROTOCOL DEPLOYMENT │
│ │
│ Infrastructure: Kubernetes (K8s) │
│ CDN: Cloudflare │
│ Primary RPC: Helius │
│ Failover RPC: Triton │
│ │
│ Regions: US-East · US-West · EU-West · APAC │
└─────────────────────────────────────────────────────┘Groovy Company, Inc. dba OTCM Protocol · Wyoming Corporation · invest@otcm.io · otcm.io
🏗️ The complete nine-layer infrastructure stack and how each layer integrates to form a unified, compliance-native trading platform for tokenized securities.
🏗️ 2.1 Layered Architecture Overview
🔹 2.1.1 The Nine-Layer Technology Stack
The OTCM Protocol L2 is not a single application but a comprehensive nine-layer infrastructure stack, each layer serving a distinct and irreplaceable function. The stackarchitecture is designed so that securitysecurities compliance enforcement occurs at Layer 2, the lowest possibleprogrammable layer (Layer 2),layer, ensuring that no higher-layer component can bypass, override, or selectively apply the 42 Transfer Hook security controls. This architecture eliminates the attack surface that existspresent in platforms where compliance is implemented at the application layerlayer, ratherwhere thanit can be circumvented by trading venues, third-party wallets, or alternative front-ends that do not share the tokenissuer's transfercompliance primitive.obligations.
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The nine-layer architecture represents a deliberate departure from existingand DeFi infrastructure, which was designed for permissionless token movement rather than securities compliance.regulation. Each layer was purpose-built for tokenized securitiessecurities. —No integratinglayer custodyis verificationrepurposed (from general DeFi infrastructure.
|
Layer 9 |
Predictive |
Layer 9 Predictive Marketing |
|
Layer 8 |
Wallet Infrastructure |
Native iOS and Android wallets with KYC/AML enforcement at wallet activation. Hardware wallet support (Ledger, Trezor) for institutional custody. All wallet operations route through Layer 2 Transfer Hook enforcement regardless of entry point. See Section 9. |
|
Layer 7 |
DAO Governance |
On-chain proposal and voting system with mandatory 48-hour timelock. Governs fee parameters, AMM configuration, and liquidity pool settings. The 42 Transfer Hook security controls are immutable — DAO governance cannot weaken investor protections. Activation target: 2028. See Section 8. |
|
Layer 6 |
Oracle Network |
Real-time data feeds: Empire Stock Transfer custody verification (~400ms), OFAC/SDN hourly refresh, Chainalysis/TRM Labs AML risk scoring, SEC EDGAR issuer data, TWAP price feeds. Layer 6 feeds Layer 2 directly — oracle data drives Transfer Hook decisions on every transaction. See Section 7. |
|
Layer 5 |
CEDEX |
Compliant Exchange for Digital Securities: centralized order matching with decentralized Solana settlement. Exclusive trading venue for all ST22 tokens. Dual-layer execution model — compliance verification layer + trading execution layer. Only exchange that |
|
Layer 4 |
Custom AMM Engine |
Proprietary Automated Market Maker operating against the Global Unified CEDEX Liquidity Pool. CPMM formula (x × y = k) with u128 overflow-safe arithmetic. Purpose-built because all major external DEXs (Raydium, Orca, Jupiter, Meteora) disable SPL Token-2022 Transfer Hooks at trade execution. See Section 5. |
|
Layer 3 |
Global Unified CEDEX Liquidity Pool |
Single protocol-owned liquidity pool shared by all ST22 issuers simultaneously. Seeded once by OTCM Protocol treasury. Deepened continuously by 5% transaction fees across all issuers and by investor secondary sale proceeds. LP tokens burned at initialization — withdrawal mathematically impossible. Replaces per-issuer FLP model. See Section 4. |
|
Layer 2 |
Security Enforcement |
SPL Token-2022 Transfer Hook extensions — 42 sequential security controls enforced on every ST22 token transfer. Controls cover custody verification, OFAC/SDN screening, AML risk scoring, accreditation check, holding period enforcement (Control 24), price impact limits, volume halts, wallet concentration limits, and 33 additional investor protections. Any control failure causes atomic transaction reversion. See Section 3. |
|
Layer 1 |
Solana Foundation |
Solana blockchain base layer providing consensus, finality, and network security. 65,000+ TPS theoretical throughput. ~400ms block confirmation time. ~$0.00025 average transaction cost. Proof of |
🔹 2.1.2 Protocol Layer Design Philosophy
The nine-layer architecture enforces strict separation of concerns,concerns where— each layer handles a distinct responsibility and communicates with adjacent layers through well-defined interfaces to adjacent layers.interfaces. This design enables independent scaling, testing, and upgrading of individual layers whilewithout maintainingcompromising system integrity. A change to Layer 4 (Custom AMM Engine) cannot affect Layer 2 (Security Enforcement) — the compliance controls are structurally isolated from the trading mechanics above them.
|
|
|
|
|||
|
|
|
| |||
Layer 2 |
| Transfer |
Cannot be bypassed by any higher-layer component including OTCM itself |
||
|
|
| CEDEX |
Eliminating multi-venue fragmentation eliminates compliance gaps |
||
|
Protocol-owned liquidity |
Global pool funded by OTCM treasury — not per-issuer or market-maker |
No single issuer failure can drain pool or eliminate liquidity |
|||
|
|
|
Regulated custodian — not OTCM — controls the financial relationship |
|||
|
Immutable security controls |
42 Transfer Hook controls in immutable on-chain program |
DAO governance cannot weaken investor protections |
|||
|
On-chain audit trail |
Every Transfer Hook decision permanently recorded on Solana |
Complete, |
|||
|
|
|
🔹 2.1.3 Architecture Diagram — Data Flow
The following diagram illustrates the nine-layer logical architecture anddescribes directional data flows:flow across the nine layers during a standard ST22 token transfer on CEDEX:
//
OTCM
Protocol
—
Nine-Flow Direction
Path
Description
Downward (request)
Layer Architecture9/8/5 //→ Layer 2 → Layer 1
User or AI action flows down through Transfer Hook verification (Layer 2), drawing oracle data from Layer 6, before settling on Solana (Layer 1)
Oracle feed
Layer 6 → Layer 2
Empire custody data, OFAC/SDN list, AML scores, and TWAP prices feed Layer 2 Transfer Hook decision logic directly — not through higher layers
Upward (confirmation)
Layer 1 =→ FoundationLayer 2 → Layer 5/8
Settlement confirmation propagates upward from Solana through compliance acknowledgement at Layer 2, into CEDEX order book update at Layer 5 / wallet balance update at Layer 8
Governance
Layer 7 → Layer 2/3/4
DAO-approved parameter changes write to Layer 2, Layer 3, and Layer 4 configuration via 48-hour timelock — the only cross-layer write path not triggered by a token transfer
AI pipeline
Layer 9 → Layer 5
IDOS scores and investor targeting data from Layer 9 =populate Intelligence)
┌---┐
│ LAYER 9: PREDICTIVE MARKETING AI MODULE │
│ EDGAR NLP │ IDOS Scoring │ Investor Targeting │ Launch Timing Optimizer │
└---┬---┘
│ Feedsthe issuer + investoracquisition pipeline ┌---┴---┐and │feed LAYER 8: WALLET INFRASTRUCTURE │
│ iOS Wallet │ Android Wallet │ KYC/AML at wallet │ HW Vault support │
└---┬---┘
│ Governance
┌---┴---┐
│ LAYER 7: DAO GOVERNANCE │
│ On-chain proposals │ 48hr timelock │ Security param governance │
└---┬---┘
│ Trade routing + settlement
┌---┴---┐
│ LAYER 5:into CEDEX (Centralized-Decentralizedlaunch Exchange)mechanics
│
│
Bonding
Curve │ CPMM post-grad │ Order matching │ Compliance UI │
└---┬---┘
│ AMM execution
┌---┴---┐
│ LAYER 4: CUSTOM AMM ENGINE │
│ Token-2022 native │ Price discovery │ Fee routing (5% protocol) │
└---┬---┘
│ Liquidity depth
┌---┴---┐
│ LAYER 3: FEDERATED LIQUIDITY PROTOCOL (FLP) │
│ Per-issuer sovereign pools │ Cross-pool federation │ Permanent locks │
└---┬---┘
│ Oracle feeds for hook logic
┌---┴---┐
│ LAYER 6: ORACLE NETWORK │
│ EST Custody │ OFAC/SDN │ Chainalysis/TRM │ SEC EDGAR │ Price Feeds │
└---┬---┘
│ Enforces 42 controls on every transfer
┌---┴---┐
│ LAYER 2: SECURITY ENFORCEMENT — SPL TOKEN-2022 TRANSFER HOOKS │
│ Hook 1: Custody │ Hook 2: OFAC │ Hook 3: AML │ Hooks 4-6 + 36 Supp. │
└---┬---┘
│ Consensus + settlement finality
┌---┴---┐
│ LAYER 1: SOLANA FOUNDATION │
│ 65,000+ TPS │ 400ms blocks │ PoH + Tower BFT │ Gulf Stream │
└---┘
Note:
Critical Architecture Principle
Layer 6 (Oracle Network) feeds Layer 2 (Security Enforcement) directly with— not through Layer 5 (CEDEX) or any application layer. This means compliance decisions are based on authoritative real-time custody,data sanctions,from Empire Stock Transfer, OFAC, and AML data. Layer 9 (AI Module) operates as an intelligence overlayproviders — consumingnot Layeron 6data that has passed through OTCM's own application stack. Any attempt to manipulate oracle feedsinputs andwould populatinghave theto issuercompromise pipelineEmpire thatStock feedsTransfer's qualifiedcustody candidatessystem intodirectly, thenot IssuersOTCM's Portalsoftware.
and
Layer
5
CEDEX
launch mechanism.
🔹 2.1.4 Cross-Layer Communication
Inter-layer communication follows strict protocols ensuring data integrity and systemseparation reliability:of responsibilities:
• Downward Communication (Request Flow): — Actions at Layer 9 (AI Module), Layer 8 (Wallet), or Layer 5 (CEDEX) flow downward through Layer 2 (Security Enforcement) for Transfer Hook verification, drawing oracle data from Layer 6, before settling on Layer 1 (Solana).Downward CommunicationNo (Requesthigher-layer Flow):action Actions atreaches Layer 91 (AIwithout Module), Layer 8 (Wallet), or Layer 5 (CEDEX) flow downwardpassing through Layer 2 (Security Enforcement) for Transfer Hook verification, drawing oracle data from Layer 6, before settling on Layer 1 (Solana).compliance.
• Upward Communication (Response Flow): — Settlement confirmations propagate upward from Layer 1 through Layer 2 compliance acknowledgement, Layer 6 oracle confirmation, and into the user-facing interfaces at Layer 5 /and Layer 8,8. withA full on-chain audit trail written at each layer.Upward Communication (Response Flow): Settlement confirmations propagate upward from Layer 1 through Layer 2 compliance acknowledgement, Layer 6 oracle confirmation, and into the user-facing interfaces at Layer 5 / Layer 8, with full on-chain audit trailis written at each layer.layer transition.
Horizontal• Communication:Oracle HorizontalFeeds Communication:(Layer Components6 within→ eachLayer layer2) communicate— viaEmpire definedStock internalTransfer APIs.custody data, OFAC/SDN list updates, AML risk scores, and price oracle feeds flow directly from Layer 6 to Layer 2. This is the only external data channel that influences compliance decisions — it does not pass through OTCM's application layer.
• Governance Writes (Layer 7 (→ Layers 2/3/4) — Passed DAO Governance) has a unique horizontal relationship: passed governance proposals write directly to parameter configurations in Layer 2, Layer 3, and Layer 4 via athe 48-hour timelock mechanismmechanism. —This is the only cross-layer write path not triggered by a token transfer event. Governance cannot write to the immutable Transfer Hook security control logic — only to adjustable parameters within defined governance bounds.
• Horizontal Communication — Components within each layer communicate via defined internal APIs. No horizontal communication crosses layer boundaries — all cross-layer interaction follows the directional protocols above.
⚡ 2.2 Layer 1: Solana Blockchain Foundation
OTCM Protocol's technical foundation rests on Solana, a monolithichigh-throughput Layer 1 blockchain protocol designed for low-latency, high-throughput, low-latencyvolume transaction processing. Unlike modular blockchains (such as Ethereum) that offload scaling to separate Layer 2 solutions, Solana handles all transaction processing, state management, and consensus directly on its base layer—layer — a critical characteristicproperty for securities trading where settlement certainty and deterministic execution are paramount.
🔹 2.2.1 Why Solana: Technical Rationale
The selection of Solana as OTCM'OTCM Protocol's blockchain infrastructure reflects carefula analysissingle decisive criterion: SPL Token-2022 Transfer Hook support. No other production blockchain provides native, atomic compliance enforcement at the token transfer primitive. The performance and cost advantages of securitiesSolana tradingreinforce requirementsthis mappedselection againstbut availableare blockchainsecondary capabilities:to the compliance architecture capability.
Requirement
TraditionalEthereum Alternative(alternative)
Solana Capability(selected)
Transfer Hook enforcement
Not natively supported — requires proxy patterns at significant gas cost
Native SPL Token-2022 standard — atomic, low-cost, no proxy needed
Transaction Throughputthroughput
Ethereum: 15-15–30 TPS practical
65,000+ TPS theoretical · 400–600 TPS for compliance-verified ST22 trades
Block Timetime
Ethereum: ~12 seconds
~400ms slots— matches Empire custody oracle refresh interval
Transaction Costcost
Ethereum: $1-1–$50+ per transaction
$0.0001 - 0001–$0.0025 per transaction
FinalitySmart Timecontract execution
Ethereum:Sequential EVM — limits parallel compliance checking
Sealevel parallel execution — enables concurrent Transfer Hook verification
Settlement finality
~6 minutes (32 block confirmations)
~13 seconds (32 blocks)block confirmations)
Smart
Contract
ModelEthereum: Sequential EVM
Parallel Sealevel execution
Token Standard
ERC-20/ERC-1400
SPL Token-2022 + Transfer Hooks
💡 Critical Design Decision
SPL Token-2022's Transfer Hook extension enables OTCM to execute compliance verification during every token transfer at the protocol level—a capability not available on Ethereum or most other blockchains without complex, gas-intensive proxy patterns.
🔹 2.2.2 Core Protocol Innovations
Solana achieves its exceptionalperformance performancecharacteristics through eight core innovations within its base layer.innovations. Understanding these innovations is essential context for comprehending how OTCM'OTCM Protocol's compliance-intensive operationsTransfer executeHook efficiently:architecture executes efficiently at scale:
• Proof of History (PoH)
Proof— ofA HistorySHA-256 functionshash as a "cryptographic clock"chain that timestamps transactions before they enter consensus.consensus, Traditionaleliminating blockchainsthe requireneed nodesfor tonetwork-wide communicate extensivelycommunication to agree on transaction orderingordering. This 'cryptographic clock' is the primary source of Solana's throughput advantage and timing.the PoHmechanism pre-establishesthat aenables verifiabledeterministic sequence400ms ofblock eventstimes.
through• aTower SHA-256BFT hashConsensus chain,— whereA eachPoH-optimized hashByzantine dependsFault onTolerant consensus algorithm that leverages the previoushistorical output.
record
to //reduce PoHmessage Sequence Generation
// Proof of History Hash Chain
hash_n = SHA256(hash_n-1)
hash_n+1 = SHA256(hash_n)
// Each hash proves a specific amount of time has passed
//complexity. Validators can verifyagree orderon withoutblock communication
validity OTCMfaster Application:because TransferPoH Hookprovides verificationa benefitsshared, from PoH's pre-established ordering. Compliance checks execute in deterministic sequence without consensus delays, enabling the 750-1,250ms total verificationverifiable time despite six sequential hooks.reference.
Tower• BFT
Tower BFT represents Solana's custom implementation of Practical Byzantine Fault Tolerance (PBFT) consensus, optimized to leverage PoH as its clock source. Traditional PBFT requires O(n²) message complexity for n validators; Tower BFT reduces this through PoH-synchronized voting.
Consensus Parameters:
Vote Lockout: Validators commit to votes with exponentially increasing lockout periodsRollback Cost: Switching votes becomes exponentially more expensive over timeFinality: 32-block confirmation provides practical finality (~13 seconds) Sealevel: Parallel Smart Contract Execution
Sealevel is Solana's parallel execution engine that processes thousands of smart contracts simultaneously. Unlike Ethereum's sequential EVM, Sealevel identifies non-overlapping transactions and executes them in parallel across available CPU cores.
// Sealevel Parallel Scheduling
// Transaction Parallelization Logic
fn schedule_transactions(txs: Vec) -> ExecutionPlan {
// Group transactions by account access patterns
let read_only: Vec<&Transaction> = filter_read_only(txs);
let write_sets: HashMap> = group_by_writes(txs);
// Transactions touching different accounts execute in parallel
// Transactions touching same account execute sequentially
ExecutionPlan::optimize(read_only, write_sets)
}
OTCM Application: CEDEX trading transactions touching different ST22 token pairs execute in parallel, enabling the platform to handle hundreds of concurrent trades. Transactions involving the same token pair serialize automatically, ensuring atomic state updates.
Turbine:Turbine Block Propagation Protocol
— Turbine addresses the bandwidth bottleneck ofA block propagation byprotocol breakingthat blocksbreaks data into smallersmall packets distributedand throughpropagates them across the network in a structured tree structure.pattern Each— validatorsimilar receivesto partialBitTorrent. dataReduces bandwidth requirements and forwardsenables it to downstream validators, achieving O(log n)fast propagation complexity.even as block size grows.
• Block Propagation Specifications:
Packet Size: 64KB shreds (erasure-coded fragments)Fanout Factor: Each node forwards to 200 downstream nodesReconstruction: 67% of shreds required to reconstruct complete block Gulf Stream:Stream Mempool-less Transaction Forwarding
Gulf— StreamTransactions eliminatesare forwarded directly to the traditional mempool by forwarding transactions to upcomingexpected leader validatorsvalidator before the current block finalizes.finalizes, eliminating the mempool bottleneck. This reducesenables higher throughput and faster confirmation latencywith lower memory requirements.
• Sealevel Parallel Smart Contract Execution — OTCM Protocol's most important Solana-specific capability: Sealevel enables parallel execution of non-overlapping transactions. Multiple ST22 Transfer Hook verifications can execute simultaneously on different accounts — a critical performance property for a platform processing thousands of concurrent trades.
• Pipelining Transaction Processing — A Transaction Processing Unit (TPU) that validates, processes, and memorycommits pressuretransactions through parallel hardware stages, similar to a CPU pipeline. Eliminates sequential bottlenecks in transaction processing.
• Cloudbreak Horizontally Scaled State — Solana's accounts database is designed for simultaneous read/write access across themultiple network.
OTCM Application: CEDEX transactions forward immediately to the next leader, reducing the time between user submission and inclusion in a block.SSDs. This enables the sub-secondhigh-throughput userstate experiencemanagement despiterequired comprehensivefor complianceOTCM's verification.Transfer Hook oracle reads on every transaction.
Cloudbreak:• HorizontallyArchivers Scaled Account Database
Cloudbreak implements Solana's account database using memory-mapped files optimized for concurrent reads and writes. The system supports parallel access patterns essential for high-throughput trading operations.
Pipelining: Transaction Processing Unit
Solana's transaction processing pipeline operates similarly to CPU instruction pipelining, with distinct stages for data fetching, signature verification, banking (state changes), and recording. Different transactions occupy different pipeline stages simultaneously.
Stage 1
Stage 2
Stage 3
Stage 4
Data Fetch
Signature Verify
Banking
Recording
GPU
GPU
CPU
Kernel
Archivers:— Distributed Ledger Storage
Archivers— areLedger specializeddata is distributed to network nodes responsiblecalled Archivers for distributed ledgerlong-term storage, keepingoffloading transactionthe historyburden accessible without overburdeningfrom validators. ThisEnsures separationthe ofimmutable concerns enables validators to maintain high performance while ensuring complete historical data availability foron-chain compliance and audit purposes.
trail 🔹OTCM 2.2.3Protocol Consensus Mechanism Deep Dive
Solana employs a hybrid consensus mechanism combining Proof of History (PoH) with Delegated Proof of Stake (dPoS). This hybrid approach achieves Byzantine Fault Tolerance while maintaining the throughput necessary for securities trading applications.
Consensus Flow:
Leader Selection: A deterministic schedule rotates leader responsibility among validators basedwrites on stake weightBlock Production: The leader validator receives transactions via Gulf Stream and produces blocks with PoH timestampsBlock Propagation: Turbine distributes block shreds through the validator networkVoting: Validators vote on block validity using Tower BFT with exponential lockoutFinality: After 32 confirmations (~13 seconds), transactions achieve practical finality
🔹 2.2.4 Network Performance Specifications
Metric
Specification
OTCM Utilization
Theoretical TPS
65,000+
400-600 TPS (compliance overhead)
Block Time (Slot)
400ms
Used for PoH synchronization
Finality Time
~13 seconds (32 blocks)
Settlement certainty for trades
Transaction Cost
$0.0001 - $0.0025
~5,000 lamports base fee
Architecture Type
Monolithic L1
No L2 dependency for settlement
Consensus
PoH + dPoS (Tower BFT)
Deterministic ordering
📐 2.3 Layer-by-Layer Technical Specifications
This section provides detailed technical specifications for each layer of the nine-layer architecture, including interface definitions, performance requirements, and integration protocols. Layers are grouped by functional relationship where appropriate.
🔹 2.3.1 Layers 1, 8 & 9: Application, Wallet & AI Module
The Application Layer provides user-facing interfaces enabling interaction with OTCM Protocol. All interfaces share common authentication, state management, and API connectivity patterns while presenting specialized functionality for different user types.
Issuers Portal
Purpose: Comprehensive onboarding and management interface for companies tokenizing securities through OTCM Protocol.
Core Functions:
Company Registration: SEC CIK validation, corporate document upload, authorized signatory verificationSeries M Configuration: Share class creation parameters, conversion ratios, custody arrangementsST22 Token Management: Minting authorization, vesting schedule configuration, treasury managementCompliance Dashboard: Real-time trading analytics, regulatory reporting, investor cap table
Component
Technology Stack
Frontend Framework
React 18+ with TypeScript, TailwindCSS
State Management
Redux Toolkit with RTK Query for API caching
Wallet Integration
Solana Wallet Adapter (Phantom, Solflare, Ledger)
Authentication
SIWS (Sign-In With Solana) + JWT sessions
Document Processing
DocuSign API for legal signatures, S3 for storage
CEDEX Trading Interface
Purpose: Real-time trading interface enabling ST22 token transactions with integrated compliance verification.
Core Functions:
Market Discovery: Token listing, price charts, volume analytics, market depth visualizationOrder Execution: Market orders, limit orders, swap interface with slippage protectionPortfolio Management: Holdings display, transaction history, P&L trackingCompliance Status: Real-time KYC status, verification requirements, restriction alerts Staking Interface
Purpose: Staking management dashboard for OTCM token holders participating in protocol governance and rewards.
Core Functions:
Stake Management: Deposit/withdraw OTCM tokens, delegation to validator nodesRewards Tracking: APY display (8-60%), reward accrual, claim functionalityEpoch Management: 2.6-day epoch visualization, reward distribution timingGovernance: Voting on protocol proposals, delegation to representatives DAO Governance Interface (Layer 7)
Purpose: On-chain governance portal for OTCM Security Token holders to propose and vote on protocol parameter changes, security control updates, and treasury decisions.
Core Functions:
Proposal Management: Submit, review, and vote on protocol governance proposals with quorum requirementsSecurity Control Governance: Multi-tier voting required for anyevery Transfer Hook parameterdecision changeTimelockis Enforcement:permanently 48-houraccessible.
execution delay
on2.2.3 all passedSPL proposals
TreasuryToken-2022: Oversight:The DAOCompliance-Critical governanceStandard
overSPL Token-2022 is Solana's next-generation token program. Its Transfer Hook extension is the foundational capability that makes the OTCM Protocol developmentcompliance fundarchitecture allocationpossible. Web3Without WalletTransfer ApplicationHook support, OTCM would be forced to implement compliance at the application layer — exactly the architecture the January 28, 2026 Joint Staff Statement identifies as creating Category 2 (LayerThird-Party 8)
Sponsored) risk exposure.
Purpose: Native
iOS
and
Android
wallet
applicationsSPL forToken-2022 compliantFeature
OTCM Protocol Usage
Transfer Hooks
42 security controls invoked atomically on every ST22 tokentransfer management.— the core compliance enforcement mechanism
CoreMetadata Functions:Extension
Portfolio
Management:
Multi-Token metadata stored on-chain: issuer ST22identity, holdingsCUSIP, display,Series transactionM history,authorization P&Ldetails, trackingEmbeddedregulatory KYC/AML:classification
Inline
accreditation
Permanent Delegate
Empire Stock Transfer designated as permanent delegate authority — enables custody oracle verification and complianceemergency statusfreeze displayTokencapability
Operations:
Send,
receive,
stake, and redeem ST22 with full Transfer Hook enforcementInstitutional Support: Ledger and Trezor hardware wallet integration; multi-sig custody Predictive Marketing AI Dashboard (Layer 9)
Purpose:Confidential IntelligenceTransfers
interface
exposing
AI module capabilitiesAvailable for issuersfuture andinstitutional operators.privacy requirements — not currently activated in production
CoreTransfer Functions:Fee Extension
IDOS
Dashboard:
Real-time5% Issuerprotocol Distresstransaction andfee Opportunityconfigured Scoreat rankings across 15,000+ OTC companiesInvestor Pool Analytics: Qualified accredited wallet targeting for ST22 launch campaignsLaunch Timing: Launch Readiness Score monitoring and optimal window recommendationsBurn Analytics: Real-time on-chain tracking of OTCMthe token burnsprogram fromlevel AI— modulecannot operations🔹bypassed by trading venues
2.3.23 Layer 2: Security Enforcement — SPL Token-2022 Transfer Hooks
Layer 2 is OTCM Protocol's most critical innovation. It is the only layer in the nine-layer stack that cannot be disabled, upgraded, or worked around by any participant — including OTCM Protocol itself. The 42 security controls implemented in Layer 2 are the technical expression of the Alesia Doctrine: compliance by encirclement, not by trust.
Every ST22 token transfer — whether initiated through CEDEX, a hardware wallet, a third-party interface, or any other entry point — must pass through all 42 Transfer Hook controls before the transaction completes on-chain. There is no administrative override. There is no whitelist for trusted parties. The controls execute identically for every participant on every transfer.
2.3.1 The 42 Controls — Six Categories
Category
Controls
Description
Custody & Asset Backing
Controls 1, 36–42
Verify circulating token supply never exceeds Empire-custodied Series M share count. Control 1 is the primary custody oracle check (Security~400ms). Enforcement)Controls implements36–42 OTCM'provide redundant custody verification channels.
Sanctions & AML
Controls 2, 3
Control 2: OFAC/SDN real-time screening of both sender and recipient (updated hourly). Control 3: ML-based AML risk scoring (0–30 approve / 31–70 enhanced review / 71–100 reject). Error codes 6002/6003.
Investor Eligibility
Controls 4, 24, 25–30
Control 4: Accreditation verification — buyer must be a verified accredited investor in Empire's system. Control 24: Holding period enforcement — Rule 144 (6 months US) / Reg S (12 months non-US), Error 6024. Controls 25–30: KYB/entity verification for institutional investors.
Market Integrity
Controls 5, 16, 17, 18
Control 5: Wallet concentration limit — no single wallet may exceed 4.99% of circulating supply. Control 16: Price impact limit — rejects transactions exceeding 2% TWAP deviation. Control 17: TWAP oracle integrity check. Control 18: Volume halt — 24-hour suspension if any wallet sells >30% of circulating supply.
CEI & Reentrancy
Controls 6–15
Checks-Effects-Interactions pattern enforcement on all Cross-Program Invocations (CPI). Prevents reentrancy attacks across the 42-control securityexecution chain.
Governance & Audit
Controls 19–23, 31–35
Governance parameter validation — ensures runtime values are within DAO-approved bounds. Immutable audit log writes — every Transfer Hook decision permanently recorded on-chain with full context.
2.3.2 Control 24: Holding Period Enforcement
Control 24 is the specific Transfer Hook control that enforces the mandatory holding periods required by Regulation D Rule 506(c) and Regulation S. It is the on-chain mechanism that makes OTCM Protocol's issuance model legally compliant at the transfer primitive rather than relying on investor self-compliance.
• Purchase timestamp recording — When Empire Stock Transfer delivers ST22 tokens to a verified investor wallet, the timestamp is recorded on-chain in the investor's VestingAccount state. This record is immutable.
• Jurisdiction flag — Each investor wallet is flagged as U.S. (Reg D) or non-U.S. (Reg S) based on Empire's KYC/KYB determination. The flag determines which holding period applies.
• Transfer attempt check — On every transfer attempt, Control 24 computes: current_timestamp − purchase_timestamp and compares it to the applicable threshold (15,778,800 seconds / 6 months for U.S.; 31,536,000 seconds / 12 months for non-U.S.).
• Rejection before expiry — If the holding period has not elapsed, the transaction reverts with Error 6024 (TokensLocked). No partial compliance, no grace period, no administrative override.
• Automatic clearance — Once the holding period elapses, Control 24 clears automatically on the next transfer attempt. No action required from the investor, Empire, or OTCM Protocol.
2.3.3 Execution Architecture
The 42 Transfer Hook controls execute through an optimized parallel architecture designed to achieve sub-1,000ms total verification time while maintaining atomic transaction guarantees:
Execution Phase
Controls
Method
Target Latency
Critical path — sequential
Controls 1, 2, 3, 4, 24
Sequential — each must pass before next executes
400–600ms
Market integrity — parallel
Controls 5, 16, 17, 18
Parallel execution alongside critical path
50–100ms
CEI enforcement — parallel
Controls 6–15
Parallel CPI validation
20–50ms
Governance validation — parallel
Controls 19–23
Parallel parameter boundary check
10–30ms
Audit log write
Controls 31–35
Asynchronous after approval decision
Non-blocking
Extended custody verification
Controls 36–42
Parallel redundant oracle cross-check
100–200ms
Total (parallel)
All 42
Parallel execution reduces total to critical path time
< 1,000ms
2.4 Layer 3: Global Unified CEDEX Liquidity Pool
Layer 3 is the liquidity infrastructure that makes secondary trading economically viable for all ST22 issuers simultaneously. In the V7 architecture, Layer 3 is a single, protocol-owned global pool rather than the per-issuer sovereign pool model used in earlier versions. This change resolves the fundamental bootstrapping problem that has caused every prior microcap liquidity solution to fail.
2.4.1 The Bootstrapping Problem — Why Per-Issuer Pools Fail
Every prior attempt to create secondary market liquidity for microcap OTC securities has failed for the same reason: each issuer or each token requires its own liquidity — and the cost of creating adequate per-token liquidity exceeds the economic capacity of the issuers and investors involved.
Traditional market makers face the same problem. A market maker committing $50,000 in capital to support a single illiquid OTC security earns perhaps $200 in daily spread revenue. The economics do not work. Each token launched on a bonding curve or seeded with per-issuer liquidity starts from zero depth and must independently reach the critical mass required for meaningful price discovery. Most never do.
2.4.2 The Global Pool Architecture
The OTCM Global Unified CEDEX Liquidity Pool solves the bootstrapping problem by inverting the economics. Rather than each issuer creating its own pool from zero, all ST22 issuers trade against a single protocol-owned pool that accumulates depth from the first day of operation and deepens with every new issuer that onboards:
• One-time treasury seed — OTCM Protocol seeds the pool once from its treasury at platform launch. This is the only capital deployment required from OTCM — no per-issuer contribution is needed.
• 5% transaction fee accumulation — Every trade on CEDEX across every ST22 issuer generates a 5% fee. A defined allocation of this fee routes directly to the Global Pool. As trading volume grows with each new issuer, pool depth grows proportionally.
• Investor secondary sale routing — When accredited investors sell ST22 tokens after the holding period expires, proceeds route into the Global Pool — providing ongoing buy-side depth and creating a direct link between investor liquidity and pool deepening.
• Permanent lock — LP tokens are burned at pool initialization. There is no withdrawal mechanism — not for OTCM Protocol, not for any investor, not for any DAO vote. Once capital enters the Global Pool, it is permanently committed to providing liquidity for all ST22 issuers.
2.4.3 Network Effect Economics
The Global Pool creates a compounding network effect that makes the platform more valuable with every issuer:
Pool State
Depth Effect
For New Issuers
For Existing Issuers
1 issuer
Thin — minimum viable trading
Pool provides basic buy-side
—
10 issuers
Moderate depth from accumulated fees
Significantly better price discovery
Deeper pool reduces price impact
50 issuers
Strong depth — institutional-grade price discovery
Day-one liquidity comparable to established markets
Low slippage on large trades
100+ issuers
Self-sustaining — fees alone maintain and grow pool
Access to deep pre-existing market
Network effect fully operational
"The Global Unified CEDEX Liquidity Pool is the first market infrastructure for OTC microcap securities where the n+1 issuer benefits from the work done by issuers 1 through n. Every issuer that onboards makes the platform better for all existing issuers — and for all future issuers. This compounding dynamic does not exist in any prior microcap liquidity solution."
2.5 Layers 4–9: Overview
The remaining five layers are described in dedicated sections. The following provides a reference summary of each layer's function, key architectural decision, and cross-reference to its full specification:
Layer
Name
Key Architectural Decision
Section
Layer 4
Custom AMM Engine
Purpose-built CPMM specifically to support SPL Token-2022 Transfer Hooks,Hooks intercepting— everyexternal DEXs disable Transfer Hook functionality
Section 5
Layer 5
CEDEX
Dual-layer execution: centralized OMS for order matching + decentralized Solana settlement for Transfer Hook enforcement. Exclusive ST22 transfertrading beforevenue.
it
completes.
Section 6
Layer 6
Oracle dataNetwork
from
Layer 6 feeds real-timeLayer 2 directly — empire custody balances,oracle sanctions(~400ms), lists,OFAC/SDN andhourly, AML scoresreal-time, intoEDGAR eachdaily. hook'sNot decisionrouted logic.through Seeapplication layer.
Section 3 for the full specification:7
TransferLayer Hook Architecture7
SPLDAO Token-2022'sGovernance
On-chain governance with 48-hour timelock. 42 Transfer Hook extensioncontrols enablesare customimmutable program— executionDAO duringcannot everyweaken tokeninvestor transfer.protections. OTCMActivation: leverages2028.
this
capability
toSection implement8
six
sequential
Layer 8
Wallet Infrastructure
KYC/AML enforced at wallet activation — compliance verificationis hooks:
ambient, Hook
Function
Datanot Source
Latency
Error
Hookoptional. 1
CustodyRoutes Verification
Empireall Stockoperations API
100-150ms
6001
Hookthrough Layer 2
OFAC Screening
SDN List Oracle
200-500ms
6002
Hook 3
AML Analytics
Chainalysis/TRM
300-400ms
6003
Hook 4
Redemption Eligibility
KYC Registry
50-100ms
6004
Hook 5
Price Impact Limit
TWAP Oracle
50-100ms
6006
Hook 6
Liquidity Ratio
Pool State
50-100ms
6007
TOTAL
Complete Verification Pipeline
—
750-1,350ms
—
💡 Atomic Execution Guarantee
If any Transfer Hook returnsenforcement.
an
error,
Section 9
Layer 9
Predictive AI Module
EDGAR NLP + IDOS scoring across ~15,000 OTC companies. Generates daily-refreshed tokenization readiness scores. Powers issuer acquisition pipeline.
Section 10
2.6 Architecture Security Properties
The nine-layer architecture produces a set of security properties that are structural — they arise from the entirearchitecture transactionitself, revertsnot atomically.from Thispolicy, ensurestrust thatrelationships, non-compliantor transfersoperator canbehavior. neverThese execute,properties evenhold partially.regardless Solana'sof accountwhether modelOTCM andProtocol Sealevel'sacts transactionin isolationgood guaranteefaith, this atomicity.
Hook Implementation Details
Hook 1 — Custody Verification Oracle:
// Hook 1: Custody Verification (Rust/Anchor)
pub fn verify_custody(
ctx: Context<CustodyVerification>,
transfer_amount: u64,
) -> Result<()> {
let oracle_data = ctx.accounts.custody_oracle.load()?;
let total_circulating = ctx.accounts.mint.supply;
let custodied_shares = oracle_data.verified_balance;
// Ensure tokens never exceed custodied backing
require!(
total_circulating + transfer_amount <= custodied_shares,
OtcmError::InsufficientCustody // Error 6001
);
emit!(CustodyVerified { timestamp: Clock::get()?.unix_timestamp });
Ok(())
}
Hook 3 — AML Risk Scoring:
The AML verification hook implements a three-tier risk scoring system:
Risk Score 0-30: Automatic approval — transaction proceeds without delayRisk Score 31-70: Enhanced review — transaction proceeds but flagged for compliance team reviewRisk Score 71-100: Automatic rejection — transaction reverts with error 6003
🔹 2.3.3 Layers 3, 4 & 5: Federated Liquidity, Custom AMM & CEDEX
Layers 3, 4, and 5 formbecause the integratedarchitecture trading and liquidity stack. Layer 3 (Federated Liquidity Protocol) manages sovereign per-issuer liquidity pools. Layer 4 (Custom AMM) is OTCM's proprietary AMM, purpose-built for Token-2022 compliance. Layer 5 (CEDEX) is the trading interface combining centralized order matching with decentralized settlement:Sealevel parallel execution to process multiple trades concurrently while maintaining atomic state updates.
CEDEX Engine
CEDEX operates as a purpose-built trading infrastructure combining centralized order matching efficiency with decentralized settlement guarantees:
Bonding Curve Trading (Pre-Graduation):
New ST22 tokens begin trading on bonding curves using a modified constant product formula:
// CEDEX Bonding Curve Formula
// Bonding Curve Price Formula
price = (SOL_reserve + delta_SOL) / (token_supply - delta_tokens)
// With 5% protocol fee:
effective_price = price * 1.05
// Graduation triggers when market_cap >= $250,000 USD
// CANONICAL DEFINITION: market_cap = P(n_current) x circulating_supply
// P(n_current) = bonding curve price at current tokens issued (no oracle needed)
// Evaluation occurs on every buy/sell. No circular dependency.
CPMM Trading (Post-Graduation):
Upon graduation (market cap ≥ $250,000), tokens transition to Constant Product Market Maker (CPMM) mechanics with deeper liquidity:
// CPMM Swap Calculation
// CPMM Invariant: k = x * y (constant product)
// Where x = SOL reserves, y = token reserves
fn calculate_output(
input_amount: u64,
input_reserve: u64,
output_reserve: u64,
) -> u64 {
let input_with_fee = input_amount * 9955; // 0.45% fee
let numerator = input_with_fee * output_reserve;
let denominator = (input_reserve * 10000) + input_with_fee;
numerator / denominator
}
OTCM Liquidity Pool
The OTCM Liquidity Pool aggregates capital from four sources, creating unified market depth across all ST22 tokens:
Capital Source
Contribution Rate
Lock Status
Bonding Curve Graduations
$1M-$5M per issuer
Permanent
Trading Fee Allocation
0.44% of volume
Permanent
Staking Reward Reinvestment
2% of rewards
Permanent
Initial Protocol Deposit
$2M at launch
Permanent
Projected LP Growth:
Year 1
Year 2
Year 3
Year 4
Year 5
$12.5M
$27.3M
$41.8M
$53.2M
$64.3M
🔹 2.3.4 Layer 1: Solana Blockchain Foundation
Layer 1 (Solana Foundation) provides the base consensus, settlement finality, and network security upon which all eight higher layers depend. This layer integrates the eight core Solana innovations (detailed in Section 2.2.2) into a cohesive infrastructure supporting securities trading requirements.
RPC Node Architecture
OTCM operates dedicated RPC infrastructure with the following specifications:
Primary RPC: Helius dedicated nodes (500 req/sec, 100 sendTx/sec tier)Failover RPC: Triton/QuickNode backup clusterGeographic Distribution: US-East, US-West, EU-West, APAC nodesMEV Protection: Jito bundle integration for frontrunning protection Transaction Lifecycle on Solana
Understanding Solana's transaction lifecycle is essential for comprehending OTCM's settlement guarantees:
Submission: Transaction submitted to RPC node, forwarded via Gulf Stream to upcoming leaderProcessing: Leader includes transaction in block, Sealevel executes Transfer Hooks in parallel with non-conflicting transactionsPropagation: Turbine distributes block shreds across validator networkVoting: Validators vote on block validity using Tower BFTConfirmation: Transaction confirmed after 1 block (~400ms)Finality: Practical finality achieved after 32 blocks (~13 seconds)
🔹 2.3.5 Layer 6: Oracle Network & External Data Integration
Layer 6 (Oracle Network) provides the real-time data bridge between on-chain Transfer Hook enforcement and the off-chain data sources required for securities compliance — custody verification, sanctions screening, AML scoring, and SEC EDGAR intelligence. This layer implements oracle patterns ensuring data integrity while maintaining the performance requirements of blockchain-based trading.
Empire Stock Transfer Integration
Empire Stock Transfer serves as OTCM's qualified custodian, providing SEC-registered transfer agent services for Series M share custody:
Integration Point
Function
Custody Oracle API
Real-time balance verification, cryptographically signed attestations, updated every block (~400ms)
Share Registration
Series M share issuance recording, beneficial ownership tracking, corporate action processing
Redemption Processing
KYC-verified token-to-share conversions, DRS registration, certificate issuance
Audit Reporting
Quarterly custody attestations, regulatory examination support, transaction audit trails
Compliance Oracle Network
OTCM's compliance verification relies on a network of specialized oracles:
OFAC/SDN Oracle: Updates hourly from Treasury Department Specially Designated Nationals list. Implements fuzzy matching algorithms for name variations and aliases.
Blockchain Analytics Oracle: Integrates Chainalysis KYT (Know Your Transaction) and TRM Labs data. Provides wallet risk scoring based on transaction history, counterparty analysis, and pattern detection.
SEC EDGAR Integration: Pulls company financial data, filing status, and corporate action information. Used for issuer onboarding verification and ongoing compliance monitoring.
🌐 RPC INFRASTRUCTURE REDUNDANCY SPECIFICATION
Version: 6.0 | Extends: Existing RPC Node Architecture
Multi-Provider RPC Architecture
TRAFFIC ROUTING (weighted round-robin with health checks):
CEDEX Trade Submissions (sendTransaction):
Primary: Helius dedicated RPC — 100 sendTx/sec (us-east-1)
Secondary: Triton RPC cluster — 50 sendTx/sec (us-west-2)
Tertiary: QuickNode RPC — 25 sendTx/sec (eu-west-1)
Failover trigger: Primary unavailable for >5 seconds
Chain State Reads (getAccountInfo, getBalance):
Primary: Helius — 500 req/sec
Fallback: Public Solana RPC (rate limited — emergency only)
Cache TTL: 400ms (1 block) for account state, 100ms for slot
WebSocket Subscriptions (accountSubscribe for real-time updates):
Primary: Helius WebSocket endpoint
Fallback: Triton WebSocket endpoint
Reconnect: Exponential backoff — 1s, 2s, 4s, 8s, max 30s
Transaction Submission Reliability
typescript
async function submitWithFallback(
transaction: VersionedTransaction,
config: SubmitConfig
): Promise {
const providers = [heliusRpc, tritonRpc, quicknodeRpc];
for (let attempt = 0; attempt < config.maxAttempts; attempt++) {
const provider = providers[attempt % providers.length];
try {
const sig = await provider.sendRawTransaction(
transaction.serialize(),
{ skipPreflight: false, maxRetries: 0 }
);
// Confirm on any provider (signatures are global)
await confirmWithTimeout(sig, config.commitmentLevel, 30_000);
return sig;
} catch (err) {
if (isHookRejection(err)) {
// Transfer Hook rejection — dodoes not retry, return error to user
throw new HookRejectionError(err);
}
// Network error — try next provider after delay
await sleep(config.retryDelayMs * (attempt + 1));
}
}
throw new MaxRetriesExceededError();
}
Health Check and Alerting
Health Check
Frequency
Alert Threshold
Action
Helius RPC latency
Every 30 seconds
p95 > 500ms for 2 minutes
Shift traffic to Triton
sendTransaction success rate
Per minute
<95% success rate
Alert P2 + increase tip
Oracle feed freshness
Every block
Any feed stale beyond threshold
Hook failsafe activates
CEDEX order matching lag
Continuous
>2 block lag between chain and OMS
Alert P1
WebSocket disconnect rate
Per hour
>5 disconnects/hour
Alert P2
🔗 TRANSACTION DURABILITY SPECIFICATION
Version: 6.0 | Applies To: All CEDEX transaction submissions
Blockhash Lifecycle Management
Solana transactions are valid only while their recent_blockhash is within the last ~150 blocks (~60 seconds). CEDEX manages blockhash freshness as follows:
typescript
class BlockhashManager {
private cachedBlockhash: { hash: string; validUntilSlot: number } | null = null;
private readonly REFRESH_SLOTS_BEFORE_EXPIRY = 20; // Refresh 8 seconds before expiry
async getFreshBlockhash(): Promise {
const currentSlot = await connection.getSlot();
if (
!this.cachedBlockhash ||
currentSlot >= this.cachedBlockhash.validUntilSlot - this.REFRESH_SLOTS_BEFORE_EXPIRY
) {
const { blockhash, lastValidBlockHeight } =
await connection.getLatestBlockhash('confirmed');
this.cachedBlockhash = {
hash: blockhash,
validUntilSlot: lastValidBlockHeight,
};
}
return this.cachedBlockhash.hash;
}
}
Durable Nonce Accounts — Institutional Orders
For large institutional orders that require extended signing windows (e.g., multi-sig approval workflows requiring >60 seconds), CEDEX supports durable nonce account-based transactions. These bypass the blockhash expiry constraint.
Standard Transaction (retail):
blockhash expires ~60 seconds after fetch
Suitable for: single-signer retail trades
Durable Nonce Transaction (institutional):
nonce account used instead of blockhash
Transaction valid until nonce is advanced
Suitable for: 4-of-7 multisig treasury trades, large block orders
CEDEX automatically selects transaction type based on:
- Wallet type (hardware multisig → durable nonce)
- Order size (> $500,000 → offer durable nonce option)
- User preference setting in institutional portal
Transaction Confirmation Strategy
typescript
const CONFIRMATION_CONFIG = {
commitment: 'confirmed', // 2/3 supermajority — sufficient for trading
preflightCommitment: 'processed', // Faster preflight check
// Confirmation polling
maxRetries: 0, // Manual retry management
skipPreflight: false, // Always run preflight — catches Hook failures
// Timeout per attempt
confirmationTimeoutMs: 30_000, // 30 seconds per attempt
// Resubmission
maxResubmissions: 3,
resubmissionIntervalMs: 5_000, // 5 seconds between attempts
// On confirmed: update order book, emit WebSocket event to UI
onConfirmed: (signature: string) => updateOrderBook(signature),
// On timeout: escalate to P2 incident if >3 consecutive timeoutsdepend on same route
onTimeout: (signature: string) => escalateIfPatternDetected(signature),
};
🔄 2.4 Data Flow Specification
This section provides detailed specifications for transaction data flow through OTCM Protocol's nine-layergood architecture.faith Understandingto this flow is essential for developers integrating with the protocol and auditors verifying compliance implementation.
🔹 2.4.1 Transaction Lifecycle
Every ST22 token transaction follows a deterministic lifecycle from user initiation through settlement and post-transaction monitoring:function:
//
Transaction
Lifecycle
Diagram
┌---┐
│ ST22 TRANSACTION LIFECYCLE │
└---┘
UserSecurity Action Phase 1: INITIATION (0-50ms)Property
Mechanism
│
•
ParameterCannot validationBe │Defeated •By
Wallet
signature
▼
•
RPCCompliance submissionunbypassable
┌---┐
│
Submit42 │---► Gulf Stream forwards to leader validator
└---┘
│
▼ Phase 2: VERIFICATION (750-1,350ms)
┌---┐
│ TRANSFER HOOKS EXECUTION (Sequential) │
│Transfer Hook 1:controls Custodyenforce ---►at Layer 2 — below all application layers
Any front-end, wallet, or trading venue — including CEDEX itself
Rugpull impossible
LP tokens burned at initialization · Series M shares under irrevocable Empire custody · Transfer Hook 2:Control OFAC1 ---►verifies Hook1:1 3:backing AMLon │
│ Hook 4: KYC ---► Hook 5: Circuit Breaker ---► Hook 6: LP │
└---┘
│
├--- FAIL ---► Atomic Revert + Error Code
│
▼ PASS Phase 3: EXECUTION (400-600ms)
┌---┐
│ • CPMM calculation • Fee deduction (5%) │
│ • Reserve update • Tokenevery transfer
│
│ • Event emission • State commitment │
└---┘
│
▼ Phase 4: SETTLEMENT (~13 seconds)
┌---┐
│ • Block confirmation • Tower BFT voting │
│ • 32-block finality • Compliance recording │
│ • Fee distribution • Audit trail creation │
└---┘
│
▼ Phase 5: MONITORING (Ongoing)
┌---┐
│ • Pattern analysis • SAR evaluation │
│ • Regulatory reporting • Anomaly detection │
└---┘
🔹 2.4.2 Nine-Layer Transaction Processing Model
Phase 1: Initiation (0-50ms)
Transaction initiation begins when a user submits an ST22 transfer through the CEDEX interface:
// Transaction Parameters (TypeScript)
interface TransactionParams {
tokenMint: PublicKey; // ST22 token address
amount: u64; // Transfer amount in base units
maxPrice: u64; // Slippage protection (0 = market)
recipientWallet: PublicKey; // Destination wallet
deadline: i64; // Unix timestamp expiry
}
Phase 2: Verification (750-1,350ms)
The verification phase executes all six Transfer Hooks sequentially. Each hook:
Queries its designated oracle or data sourcePerforms verification logic against compliance rulesRecords verification result in compliance logReturns PASS to continue or ERROR to revert Phase 3: Execution (400-600ms)
Upon successful verification, transaction execution proceeds atomically:
// Swap Execution (Rust/Anchor)
fn execute_swap(ctx: Context, params: SwapParams) -> Result<()> {
// Calculate output using CPMM formula
let output = calculate_cpmm_output(
params.input_amount,
ctx.accounts.pool.sol_reserve,
ctx.accounts.pool.token_reserve,
)?;
// Apply 5% protocol fee
let fee = output * 500 / 10000; // 5% = 500 basis points
let net_output = output - fee;
// Atomic state updates
ctx.accounts.pool.sol_reserve += params.input_amount;
ctx.accounts.pool.token_reserve -= output;
// Transfer tokens to recipient
transfer_tokens(ctx.accounts.recipient, net_output)?;
// Distribute fees
distribute_fees(fee, &ctx.accounts.fee_recipients)?;
emit!(SwapExecuted { ... });
Ok(())
}
Phase 4: Settlement (~13 seconds)
Settlement occurs through Solana's Tower BFT consensus mechanism. After 32 block confirmations, the transaction achieves practical finality with cryptographic guarantees against reversal.
Phase 5: Post-Transaction Monitoring (Ongoing)
Post-transaction monitoring implements continuous compliance oversight:
Real-time pattern analysis: Machine learning models analyze transaction patterns for suspicious activityFlagging queue: Transactions meeting review thresholds enter compliance team queueSAR evaluation: Suspicious Activity Report filing determination for flagged transactionsRegulatory reporting: Automated generation of required regulatory filings
🔹 2.4.3 Error Handling & Recovery
OTCM implements comprehensive error handling with specific error codes enabling rapid diagnosis:
Code
Error Type
Recovery Action
6001
Insufficient Custody Backing
Wait for oracle update or reduce amount
6002
OFAC Sanctioned Address
Transaction permanently blocked
6003
AML Risk Threshold Exceeded
Contact compliance for review
6004
KYC/Accreditation Invalid
Complete verification via portal
6006
Circuit Breaker Triggered
Reduce order size or wait for TWAP reset
6007
Liquidity Ratio Violation
Reduce order size below pool limits
2.5 System Integration Architecture
OTCM Protocol integrates with multiple external systems to deliver comprehensive securities trading functionality. This section documents API specifications, authentication protocols, and data exchange formats.
🔌 2.5 External System Integration
🔹 2.5.1Protocol, Empire Stock TransferTransfer, Integration
or any issuer
TheOFAC/SDN Empirescreening Stockcontinuous
Transfer
integration
providesControl 2 screens both parties on every transfer against SDN list updated hourly
A single onboarding check — rescreening happens on every trade
Holding period unwaivable
Control 24 enforces Rule 144/Reg S timestamps on every transfer attempt · No administrative override exists
OTCM Protocol, Empire, or the custodyinvestor verification foundation for all ST22 token operations:themselves
//
Empire
Stock Transfer API
// Custody Oracle API Specification
interface CustodyOracleResponse {
issuer_cik: string; // SEC CIK number
cusip: string; // CUSIP identifier
custodied_balance: u64; // Verified share count
last_verification: i64; // Unix timestamp
attestation_signature: string; // Ed25519 signature
audit_hash: string; // SHA-256 of audit data
}
// API Endpoint
GETOracle manipulation resistanthttps://api.empirestocktransfer.com/v1/custody/{issuer_cik}
Bearer {api_key}
X-Oracle-Signature: {signature}
🔹 2.5.2 Compliance Oracle Network
OFAC Screening API:
// OFAC Screening API
// OFAC Screening Request
POSTLayer https://oracle.otcm.io/v1/ofac/screen
6 {
feeds "wallet_address":Layer "7xKXt...",
2 "transaction_type":directly "transfer",
· "counterparty": "9yMPs..."
}
// Response
{
"status": "CLEAR" | "MATCH" | "PARTIAL_MATCH",
"sdn_match_confidence": 0.0 - 1.0,
"last_list_update": "2025-12-22T00:00:00Z",
"verification_id": "uuid"
}
🔹 2.5.3 External API Specifications
System
Protocol
Auth Method
Rate Limit
Empire Stock
REST/JSON
API KeyPrimary + Signature
1,000/min
Chainalysis
REST/JSON
OAuthsecondary 2.0
10,000/hour
SEC+ EDGAR
REST/XML
User-Agent ID
10/sec
Helius RPC
JSON-RPC 2.0
API Key
500/sec
⚡ 2.6 Performance Engineering
OTCM Protocol's performance engineering balances compliance verification requirements with user experience expectations. This section documents throughput optimization strategies, latency management approaches, and scalability architecture.
🔹 2.6.1 Throughput Optimization
While Solana theoretically supports 65,000+ TPS, OTCM's compliance verification overhead reduces effective throughput to 400-600 TPS. This remains substantially higher than required for securities trading while ensuring every transaction passes compliance checks.
Throughput Analysis:
Metric
Solana Theoretical
OTCM Effective
Peak TPS
65,000+
400-600
Daily Capacity
5.6B transactions
~50M transactions
Compliance Overhead
N/A
750-1,350ms/tx
🔹 2.6.2 Latency Management
End-to-end latency for a typical CEDEX trade:
Phase
Latency
User submission to RPC
50-100ms
Transfer Hook verification
750-1,350ms
Swap execution
400-600ms
Block confirmation (first)
~400ms
TOTAL (to confirmation)
1.6-2.5 seconds
Full finality (32 blocks)
~13 seconds
🔹 2.6.3 Scalability Architecture
OTCM's scalability strategy leverages Solana's Sealevel parallel execution for horizontal scaling of non-conflicting transactions:
Token Pair Isolation: Trades in different ST22 tokens execute in parallel (no account overlap)Oracle Caching: Compliancetertiary oracle resultsarchitecture cached· forDiscrepancy 1triggers blockcircuit (~400ms)breaker
to
reduce redundant queriesBatch Processing: Off-chain systems aggregate compliance data for efficient on-chain verificationGeographic Distribution: Multi-region RPC deployment minimizes network latency globally
🏗️ 2.7 Security Architecture
OTCM implements a defense-in-depth security model with multiple overlapping protection layers. This approach ensures that compromiseCompromise of any single securityoracle controlfeed
does
not
result
Governance cannot weaken controls
42 Transfer Hook controls in system-wideimmutable vulnerability.on-chain program · Outside DAO governance scope
🔹
2.7.1
Defense-in-DepthAny Modelgovernance proposal regardless of vote margin
Pool permanence enforced
LP tokens sent to burn address on initialization · Smart contract has no withdrawal function
Any party including DAO supermajority
Layer
Protection
Mechanism
Threat Mitigated
Network
WAF, DDoS protection, rate limiting
Network-level attacks, flooding
Application
Input validation, CSRF protection, CSP
Injection, XSS, session hijacking
Smart Contract
Formal verification, audit, bug bounty
Logic bugs, reentrancy, overflow
Compliance
Transfer Hooks, 42-point security
Unauthorized trading, sanctions evasion
Custody
Multi-sig, HSM, custody verification
Asset misappropriation, insider threat
🔹 2.7.2 Cryptographic Standards
OTCM employs industry-standard cryptographic primitives:
Key Derivation: Ed25519 for Solana wallet signatures (128-bit security equivalent)Hashing: SHA-256 for transaction verification, Blake3 for high-performance hashingEncryption: AES-256-GCM for data at rest, TLS 1.3 for data in transitOracle Signatures: Ed25519 signatures on all oracle attestations for non-repudiation
🔹 2.7.3 Attack Surface Analysis
The followingAlesia attack vectors have been analyzed and mitigated:Doctrine
MEV/Frontrunning:The Jitoarchitecture's bundlesecurity integrationproperties routesare transactionsnamed throughthe validatorAlesia bundlesDoctrine thatafter resistthe frontrunning.military Circuit breakers (2% TWAP deviation) limit profitabilityprinciple of sandwichencirclement attacks.— OTCM Protocol's compliance controls surround every transaction from multiple independent layers, making successful circumvention structurally impossible rather than merely difficult. The doctrine holds: any attempt to bypass compliance at one layer encounters compliance enforcement at the layers below it. There is no gap.
Groovy Company, Inc. dba OTCM Protocol | CIK: 1499275 | Version 7.0 | March 2026 | Confidential
Oracle Manipulation: Multi-oracle architecture requires consensus across Empire Stock Transfer, OFAC, and blockchain analytics sources. Single oracle compromise cannot affect transaction verification.
Rug Pull Attempts: Permanent liquidity locks enforced by smart contract make liquidity withdrawal mathematically impossible. Override requires 2/3 DAO supermajority plus 48-hour timelock.
Smart Contract Exploits: Formal verification using Certora, security audits by Quantstamp and Halborn, active bug bounty program with up to $100K rewards.
🚀 2.8 Deployment Topology
OTCM Protocol deploys across multiple regions with redundant infrastructure ensuring high availability:
// Global Deployment Architecture
┌---┐
│ OTCM DEPLOYMENT TOPOLOGY │
└---┘
┌---┐ ┌---┐
│ US-EAST │ │ US-WEST │
│ (Primary) │◄---►│ (Secondary) │
└---┬---┘ └---┬---┘
│ │
└---┬---┘
│
┌---┴---┐
│ GLOBAL LOAD BALANCER │
└---┬---┘
│
┌---┼---┐
│ │ │
┌---┴---┐ ┌---┴---┐ ┌---┴---┐
│ EU-WEST │ │ APAC │ │ LATAM │
│ (DR Site) │ │ (Edge) │ │ (Edge) │
└---┘ └---┘ └---┘
Infrastructure: Kubernetes (K8s) | CDN: Cloudflare | RPC: Helius + Triton