Section 2: Technical Architecture

OTCM PROTOCOL

Comprehensive 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 technology stack that powers the OTCM Protocol ST22 Digital 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

OTCM Protocol is not a single application — it is a comprehensive nine-layer infrastructure stack, each layer serving a distinct and irreplaceable function. The architecture is designed so that securities compliance enforcement occurs at Layer 2, the lowest programmable layer, ensuring that no higher-layer component can bypass, override, or selectively apply the 42 Transfer Hook security controls. This eliminates the attack surface present in platforms where compliance is implemented at the application layer, where it can be circumvented by trading venues, third-party wallets, or alternative front-ends that do not share the issuer's compliance obligations.

The nine-layer design reflects lessons from both traditional securities infrastructure — where compliance exists at the institutional level but can be routed around by unregulated venues — and DeFi infrastructure, which was designed for permissionless token movement rather than securities regulation. Each layer was purpose-built for tokenized securities. No layer is repurposed from general DeFi infrastructure.

Layer 9	Predictive AI Module	Layer 9 Predictive Marketing AI Module: EDGAR NLP pipeline, Issuer Distress and Opportunity Score (IDOS) generation, investor targeting engine, Launch Timing Optimization Engine (LTOE). Feeds qualified issuer and investor candidates into the platform pipeline. See Section 10.
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 maintains all 42 Transfer Hook controls post-trade. See Section 6.
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 History (PoH) + Tower BFT consensus. The 400ms block time matches Empire Stock Transfer's custody oracle refresh interval — ensuring real-time 1:1 verification on every block.

2.1.2 Protocol Layer Design Philosophy

The nine-layer architecture enforces strict separation of concerns — each layer handles a distinct responsibility and communicates with adjacent layers through well-defined interfaces. This design enables independent scaling, testing, and upgrading of individual layers without compromising 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.

Principle	Implementation	Security Consequence
Compliance at lowest layer	Layer 2 Transfer Hooks intercept every transfer before settlement	Cannot be bypassed by any higher-layer component including OTCM itself
Single-venue enforcement	CEDEX is the only exchange that preserves all 42 Transfer Hook controls	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 for others
Empire as custody authority	Empire Stock Transfer holds Series M shares and owns investor onboarding	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, immutable compliance history for every transaction

2.1.3 Architecture Diagram — Data Flow

The following describes directional data flow across the nine layers during a standard ST22 token transfer on CEDEX:

Flow Direction	Path	Description
Downward (request)	Layer 9/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 → Layer 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 the issuer acquisition pipeline and feed into CEDEX launch mechanics

Critical Architecture Principle

Layer 6 (Oracle Network) feeds Layer 2 (Security Enforcement) directly — not through Layer 5 (CEDEX) or any application layer. This means compliance decisions are based on authoritative real-time data from Empire Stock Transfer, OFAC, and AML providers — not on data that has passed through OTCM's own application stack. Any attempt to manipulate oracle inputs would have to compromise Empire Stock Transfer's custody system directly, not OTCM's software.

2.1.4 Cross-Layer Communication

Inter-layer communication follows strict protocols ensuring data integrity and separation 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). No higher-layer action reaches Layer 1 without passing through Layer 2 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. A full on-chain audit trail is written at each layer transition.

• Oracle Feeds (Layer 6 → Layer 2) — Empire Stock Transfer 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 proposals write directly to parameter configurations in Layer 2, Layer 3, and Layer 4 via the 48-hour timelock mechanism. 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 high-throughput Layer 1 blockchain designed for low-latency, high-volume transaction processing. Unlike modular blockchains that offload scaling to separate Layer 2 solutions, Solana handles all transaction processing, state management, and consensus on its base layer — a critical property for securities trading where settlement certainty and deterministic execution are paramount.

2.2.1 Why Solana: Technical Rationale

The selection of Solana as OTCM Protocol's blockchain infrastructure reflects a single 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 Solana reinforce this selection but are secondary to the compliance architecture capability.

Requirement	Ethereum (alternative)	Solana (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 throughput	15–30 TPS practical	65,000+ TPS theoretical · 400–600 TPS for compliance-verified ST22 trades
Block time	~12 seconds	~400ms — matches Empire custody oracle refresh interval
Transaction cost	$1–$50+ per transaction	$0.0001–$0.0025 per transaction
Smart contract execution	Sequential EVM — limits parallel compliance checking	Sealevel parallel execution — enables concurrent Transfer Hook verification
Settlement finality	~6 minutes (32 block confirmations)	~13 seconds (32 block confirmations)

2.2.2 Core Protocol Innovations

Solana achieves its performance characteristics through eight core innovations. Understanding these is essential context for how OTCM Protocol's compliance-intensive Transfer Hook architecture executes efficiently at scale:

• Proof of History (PoH) — A SHA-256 hash chain that timestamps transactions before they enter consensus, eliminating the need for network-wide communication to agree on transaction ordering. This 'cryptographic clock' is the primary source of Solana's throughput advantage and the mechanism that enables deterministic 400ms block times.

• Tower BFT Consensus — A PoH-optimized Byzantine Fault Tolerant consensus algorithm that leverages the historical record to reduce message complexity. Validators can agree on block validity faster because PoH provides a shared, verifiable time reference.

• Turbine Block Propagation — A block propagation protocol that breaks data into small packets and propagates them across the network in a structured tree pattern — similar to BitTorrent. Reduces bandwidth requirements and enables fast propagation even as block size grows.

• Gulf Stream Mempool-less Transaction Forwarding — Transactions are forwarded directly to the expected leader validator before the current block finalizes, eliminating the mempool bottleneck. This enables higher throughput and faster confirmation with 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 commits transactions 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 multiple SSDs. This enables the high-throughput state management required for OTCM's Transfer Hook oracle reads on every transaction.

• Archivers — Distributed Ledger Storage — Ledger data is distributed to network nodes called Archivers for long-term storage, offloading the burden from validators. Ensures the immutable on-chain compliance audit trail OTCM Protocol writes on every Transfer Hook decision is permanently accessible.

2.2.3 SPL Token-2022: The Compliance-Critical Standard

SPL Token-2022 is Solana's next-generation token program. Its Transfer Hook extension is the foundational capability that makes the OTCM Protocol compliance architecture possible. Without Transfer Hook 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 (Third-Party Sponsored) risk exposure.

SPL Token-2022 Feature	OTCM Protocol Usage
Transfer Hooks	42 security controls invoked atomically on every ST22 transfer — the core compliance enforcement mechanism
Metadata Extension	Token metadata stored on-chain: issuer identity, CUSIP, Series M authorization details, regulatory classification
Permanent Delegate	Empire Stock Transfer designated as permanent delegate authority — enables custody oracle verification and emergency freeze capability
Confidential Transfers	Available for future institutional privacy requirements — not currently activated in production
Transfer Fee Extension	5% protocol transaction fee configured at the token program level — cannot be bypassed by trading venues

2.3 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 (~400ms). Controls 36–42 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 execution 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 — external 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 trading venue.	Section 6
Layer 6	Oracle Network	Layer 6 feeds Layer 2 directly — empire custody oracle (~400ms), OFAC/SDN hourly, AML real-time, EDGAR daily. Not routed through application layer.	Section 7
Layer 7	DAO Governance	On-chain governance with 48-hour timelock. 42 Transfer Hook controls are immutable — DAO cannot weaken investor protections. Activation: 2028.	Section 8
Layer 8	Wallet Infrastructure	KYC/AML enforced at wallet activation — compliance is ambient, not optional. Routes all operations through Layer 2 Transfer Hook enforcement.	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 architecture itself, not from policy, trust relationships, or operator behavior. These properties hold regardless of whether OTCM Protocol acts in good faith, because the architecture does not depend on OTCM Protocol's good faith to function:

Security Property	Mechanism	Cannot Be Defeated By
Compliance unbypassable	42 Transfer Hook controls enforce 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 Control 1 verifies 1:1 backing on every transfer	OTCM Protocol, Empire Stock Transfer, or any issuer
OFAC/SDN screening continuous	Control 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 investor themselves
Oracle manipulation resistant	Layer 6 feeds Layer 2 directly · Primary + secondary + tertiary oracle architecture · Discrepancy triggers circuit breaker	Compromise of any single oracle feed
Governance cannot weaken controls	42 Transfer Hook controls in immutable on-chain program · Outside DAO governance scope	Any governance 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

The Alesia Doctrine

The architecture's security properties are named the Alesia Doctrine after the military principle of encirclement — 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