Skip to main content

🏗️ Section 2: Technical Architecture

🏗️ The complete nine-layer infrastructure stack and how each layer integrates to form a unified, compliance-native trading platform for tokenized securities.

🏗️ SECTION 2: TECHNICAL 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.

Layer

Name

Description

Layer 1

Foundation

Solana blockchain (base layer) providing consensus, finality, and network security at 65,000+ TPS with sub-second settlement finality.

Layer 2

Security Enforcement

SPL Token-2022 Transfer Hook extensions — the Company's most critical innovation. Every ST22 token transfer is intercepted by custom Rust smart contracts that enforce 42 security controls before the transaction completes. See Section 3.

Layer 3

Liquidity Engine

Federated Liquidity Protocol (FLP): sovereign liquidity pools per issuer with optional cross-pool federation routing. Permanently locked liquidity backed 1:1 by Empire Stock Transfer custody. See Section 5.

Layer 4

Custom AMM

OTCM's proprietary Automated Market Maker engine. Major DEXs (Raydium, Orca, Meteora) cannot support Token-2022 Transfer Hooks — they would disable all 42 security controls. OTCM built its own AMM to maintain complete security integrity.

Layer 5

CEDEX

Centralized Exchange with Decentralized settlement — the OTCM trading interface exclusively for ST22 tokens. Combines Web2 user experience with Web3 settlement finality. See Section 4.

Layer 6

Oracle Network

Real-time oracles monitoring SEC EDGAR filings, OTC Markets data, custody verification feeds, and price discovery. Feeds are critical for Transfer Hook decision logic and Predictive AI Module scoring.

Layer 7

DAO Governance

Decentralized Autonomous Organization with multi-tier on-chain voting for protocol upgrades, fee adjustments, and parameter changes. Prevents any single party from unilaterally altering security controls.

Layer 8

Wallet Infrastructure

Native iOS and Android Web3 wallets enabling retail and institutional investors to hold, send, and receive ST22 tokens with full KYC/AML compliance enforced at the wallet level.

Layer 9

Predictive Marketing AI Module

The intelligence layer powering the OTCM commercial engine. A proprietary AI system continuously monitors SEC EDGAR filings (Form D, 10-K/Q NLP, 8-K triggers, DEF 14A proxy data) and OTC Markets Group tier data across approximately 15,000 U.S. OTC companies, building a daily-refreshed Issuer Distress and Opportunity Score. The AI simultaneously operates an investor-side behavioral profiling engine targeting verified accredited wallets on Solana for ST22 launch campaigns. Launch Timing Optimization modeling forecasts optimal bonding curve windows by analyzing competing launch schedules, RPC congestion, sentiment cycles, and historical volume correlation. All AI capabilities are gated behind OTCM Security Token staking tiers and each operation burns tokens permanently — creating deflationary demand driven by platform success. See Section 7 for full specification.

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 tokenized securities — integrating custody verification (Layer 6 Oracle Network), investor eligibility enforcement (Layer 2 Transfer Hooks), and intelligent issuer/investor discovery (Layer 9 Predictive Marketing AI) into a unified stack that functions as a single coherent system rather than a collection of third-party integrations.

🔹 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 design enables independent scaling, testing, and upgrading of individual layers while maintaining system integrity.

Layer

Name

Primary Responsibility

Layer 1

Application Layer

User interfaces, portal access, experience management

Layer 2

Compliance Enforcement

Transfer Hooks, KYC/AML, OFAC, securities law automation

Layer 3

Trading & Liquidity

CEDEX engine, bonding curves, CPMM, liquidity pools

Layer 4

Blockchain Infrastructure

Solana L1, RPC nodes, consensus, finality

Layer 5

External Integration

Custody verification, oracles, SEC EDGAR, analytics

🔹 2.1.3 Architecture Diagram

The following diagram illustrates the nine-layer logical architecture and directional data flows:

// OTCM Protocol — Nine-Layer Architecture
// (Layer 1 = Foundation / Layer 9 = Intelligence)
┌─────────────────────────────────────────────────────────────────────────┐
│  LAYER 9: PREDICTIVE MARKETING AI MODULE                              │
│  EDGAR NLP │ IDOS Scoring │ Investor Targeting │ Launch Timing Optimizer  │
└─────────────────────────────────┬──────────────────────────────────────┘
│ Feeds issuer + investor pipeline
┌─────────────────────────────────┴──────────────────────────────────────┐
│  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: CEDEX (Centralized-Decentralized Exchange)                  │
│  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: 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

Inter-layer communication follows strict protocols ensuring data integrity and system reliability:

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

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 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 trail written at each layer.

Horizontal Communication: 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 protocol designed for high-throughput, low-latency transaction processing. Unlike modular blockchains (such as Ethereum) 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 securities trading where settlement certainty and deterministic execution are paramount.

🔹 2.2.1 Why Solana: Technical Rationale

The selection of Solana as OTCM's blockchain infrastructure reflects careful analysis of securities trading requirements mapped against available blockchain capabilities:

Requirement

Traditional Alternative

Solana Capability

Transaction Throughput

Ethereum: 15-30 TPS

65,000+ TPS theoretical

Block Time

Ethereum: ~12 seconds

400ms slots

Transaction Cost

Ethereum: $1-$50+

$0.0001 - $0.0025

Finality Time

Ethereum: ~6 minutes

~13 seconds (32 blocks)

Smart Contract Model

Ethereum: 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 exceptional performance through eight core innovations within its base layer. Understanding these innovations is essential for comprehending how OTCM's compliance-intensive operations execute efficiently:

Proof of History (PoH)

Proof of History functions as a "cryptographic clock" that timestamps transactions before they enter consensus. Traditional blockchains require nodes to communicate extensively to agree on transaction ordering and timing. PoH pre-establishes a verifiable sequence of events through a SHA-256 hash chain, where each hash depends on the previous output.

// PoH 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
// Validators can verify order without communication

OTCM Application: Transfer Hook verification benefits from PoH's pre-established ordering. Compliance checks execute in deterministic sequence without consensus delays, enabling the 750-1,250ms total verification time despite six sequential hooks.

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 periods
  • Rollback Cost: Switching votes becomes exponentially more expensive over time
  • Finality: 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<Transaction>) -> ExecutionPlan {
// Group transactions by account access patterns
let read_only: Vec<&Transaction> = filter_read_only(txs);
let write_sets: HashMap<Account, Vec<Transaction>> = 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: Block Propagation Protocol

Turbine addresses the bandwidth bottleneck of block propagation by breaking 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.

Block Propagation Specifications:

  • Packet Size: 64KB shreds (erasure-coded fragments)
  • Fanout Factor: Each node forwards to 200 downstream nodes
  • Reconstruction: 67% of shreds required to reconstruct complete block Gulf Stream: Mempool-less Transaction Forwarding

Gulf Stream eliminates the traditional mempool by forwarding transactions to upcoming leader validators before the current block finalizes. This reduces confirmation latency and memory pressure across the network.

OTCM Application: CEDEX transactions forward immediately to the next leader, reducing the time between user submission and inclusion in a block. This enables the sub-second user experience despite comprehensive compliance verification.

Cloudbreak: Horizontally 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 are specialized nodes responsible for distributed ledger storage, keeping transaction history accessible without overburdening validators. This separation of concerns enables 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). 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 based on stake weight
  • Block Production: The leader validator receives transactions via Gulf Stream and produces blocks with PoH timestamps
  • Block Propagation: Turbine distributes block shreds through the validator network
  • Voting: Validators vote on block validity using Tower BFT with exponential lockout
  • Finality: 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 verification
  • Series M Configuration: Share class creation parameters, conversion ratios, custody arrangements
  • ST22 Token Management: Minting authorization, vesting schedule configuration, treasury management
  • Compliance 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 visualization
  • Order Execution: Market orders, limit orders, swap interface with slippage protection
  • Portfolio Management: Holdings display, transaction history, P&L tracking
  • Compliance 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 nodes
  • Rewards Tracking: APY display (8-60%), reward accrual, claim functionality
  • Epoch Management: 2.6-day epoch visualization, reward distribution timing
  • Governance: 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 requirements
  • Security Control Governance: Multi-tier voting required for any Transfer Hook parameter change
  • Timelock Enforcement: 48-hour execution delay on all passed proposals
  • Treasury Oversight: DAO governance over OTCM Protocol development fund allocation Web3 Wallet Application (Layer 8)

Purpose: Native iOS and Android wallet applications for compliant ST22 token management.

Core Functions:

  • Portfolio Management: Multi-issuer ST22 holdings display, transaction history, P&L tracking
  • Embedded KYC/AML: Inline accreditation verification and compliance status display
  • Token Operations: Send, receive, stake, and redeem ST22 with full Transfer Hook enforcement
  • Institutional Support: Ledger and Trezor hardware wallet integration; multi-sig custody Predictive Marketing AI Dashboard (Layer 9)

Purpose: Intelligence interface exposing AI module capabilities for issuers and operators.

Core Functions:

  • IDOS Dashboard: Real-time Issuer Distress and Opportunity Score rankings across 15,000+ OTC companies
  • Investor Pool Analytics: Qualified accredited wallet targeting for ST22 launch campaigns
  • Launch Timing: Launch Readiness Score monitoring and optimal window recommendations
  • Burn 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 (Security Enforcement) implements OTCM's 42-control security architecture through SPL Token-2022 Transfer Hooks, intercepting every ST22 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. See Section 3 for the full specification:

Transfer Hook Architecture

SPL Token-2022's Transfer Hook extension enables custom program execution during every token transfer. OTCM leverages this capability to implement six sequential compliance verification hooks:

Hook

Function

Data Source

Latency

Error

Hook 1

Custody Verification

Empire Stock API

100-150ms

6001

Hook 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 returns an error, the entire transaction reverts atomically. This ensures that non-compliant transfers can never execute, even partially. Solana's account model and Sealevel's transaction isolation guarantee 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 delay
  • Risk Score 31-70: Enhanced review — transaction proceeds but flagged for compliance team review
  • Risk 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 form the integrated 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
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 cluster
  • Geographic Distribution: US-East, US-West, EU-West, APAC nodes
  • MEV 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 leader
  • Processing: Leader includes transaction in block, Sealevel executes Transfer Hooks in parallel with non-conflicting transactions
  • Propagation: Turbine distributes block shreds across validator network
  • Voting: Validators vote on block validity using 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 (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.

🔄 2.4 Data Flow Specification

This section provides detailed specifications for transaction data flow through OTCM Protocol's nine-layer architecture. Understanding 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:

// Transaction Lifecycle Diagram
┌──────────────────────────────────────────────────────────────────────────┐
│                     ST22 TRANSACTION LIFECYCLE                           │
└──────────────────────────────────────────────────────────────────────────┘

User Action Phase 1: INITIATION (0-50ms)

│                 • Parameter validation
│                 • Wallet signature
▼                 • RPC submission
┌────────┐
│ Submit │──────────► Gulf Stream forwards to leader validator
└────────┘
│
▼              Phase 2: VERIFICATION (750-1,350ms)
┌────────────────────────────────────────────────────────────┐
│  TRANSFER HOOKS EXECUTION (Sequential)                     │
│  Hook 1: Custody ──► Hook 2: OFAC ──► Hook 3: AML          │
│  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           • Token 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 source
  • Performs verification logic against compliance rules
  • Records verification result in compliance log
  • Returns 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<Swap>, 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 activity
  • Flagging queue: Transactions meeting review thresholds enter compliance team queue
  • SAR evaluation: Suspicious Activity Report filing determination for flagged transactions
  • Regulatory 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.1 Empire Stock Transfer Integration

The Empire Stock Transfer integration provides the custody verification foundation for all ST22 token operations:

// Empire Stock Transfer API
// Custody Oracle API Specification

interface CustodyOracleResponse {

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

}

// API Endpoint

GET https://api.empirestocktransfer.com/v1/custody/{issuer_cik}

Authorization: Bearer {api_key}

X-Oracle-Signature: {signature}

🔹 2.5.2 Compliance Oracle Network

OFAC Screening API:

// OFAC Screening API
// OFAC Screening Request

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": "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 Key + Signature

1,000/min

Chainalysis

REST/JSON

OAuth 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: Compliance oracle results cached for 1 block (~400ms) to reduce redundant queries
  • Batch Processing: Off-chain systems aggregate compliance data for efficient on-chain verification
  • Geographic 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 compromise of any single security control does not result in system-wide vulnerability.

🔹 2.7.1 Defense-in-Depth Model

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 hashing
  • Encryption: AES-256-GCM for data at rest, TLS 1.3 for data in transit
  • Oracle Signatures: Ed25519 signatures on all oracle attestations for non-repudiation

🔹 2.7.3 Attack Surface Analysis

The following attack vectors have been analyzed and mitigated:

MEV/Frontrunning: Jito bundle integration routes transactions through validator bundles that resist frontrunning. Circuit breakers (2% TWAP deviation) limit profitability of sandwich attacks.

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

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Back to top