Skip to main content

🎯 Section 1: Executive Summary

🎯 A high-level overview of OTCM Protocol — the problem we solve, the technology we built, and the market opportunity we address.

🎯 SECTION 1: EXECUTIVE SUMMARY

🌟 1.1 Protocol Vision and Mission

OTCM Protocol represents a transformative institutional-grade market infrastructure platform engineered to address one of American finance's most pressing yet systematically overlooked problems: the structural abandonment of over 11,000 companies trading on over-the-counter markets, trapping an estimated $50+ billion in shareholder value within securities that have become effectively untradeable. Through innovative blockchain technology combined with rigorous SEC compliance, OTCM demonstrates how cryptographic innovation can revitalize failing traditional financial infrastructure while enhancing—rather than circumventing—investor protections.

🔹 1.1.1 The Fundamental Problem

The United States securities markets operate on a tiered structure where companies unable to meet the listing requirements of major exchanges (NYSE, NASDAQ) trade on over-the-counter (OTC) markets. While this system theoretically provides capital access for smaller companies, a critical design flaw has emerged: when companies lose regulatory eligibility or market maker support, their shareholders become trapped in positions they cannot exit. Unlike listed securities with continuous trading, OTC securities can become completely illiquid overnight, transforming shareholders from investors into unwilling hostages of their own holdings.

This problem is not theoretical—it represents real financial harm to millions of American investors who purchased securities in good faith only to discover they cannot sell them at any price. The trapped shareholder exists in regulatory limbo: they own a legitimate security, filed properly with the SEC, yet have no mechanism to exit their position regardless of personal circumstances, financial need, or investment strategy changes.

🔹 1.1.2 The OTCM Solution

OTCM Protocol addresses this market failure through a novel combination of blockchain technology and traditional securities infrastructure. Rather than attempting to create an alternative to existing regulatory frameworks—an approach that has led to extensive regulatory enforcement actions against other crypto projects—OTCM integrates with and enhances the existing securities law structure.

The protocol creates Security Tokens (ST22) that tokenize securities with 1:1 backing by Series M preferred shares held at Empire Stock Transfer, a SEC-registered transfer agent. This architecture enables:

  • 24/7/365 Global Trading: Continuous market access unrestricted by traditional market hours or geographic limitations
  • Permanent Liquidity: Mathematically guaranteed trading capability through permanently locked liquidity pools
  • Regulatory Compliance: Full integration with SEC reporting requirements, KYC/AML procedures, and transfer agent oversight
  • Verifiable Asset Backing: Real-time oracle confirmation that every token is backed 1:1 by custodied securities
  • Fraud Prevention: Smart contract enforcement of 42 security controls making "rugpulls mathematically impossible"

🔹 1.1.3 Mission Statement

"We're not disrupting functioning markets. We're creating permanent markets where none exist. We're not circumventing securities law. We're automating its enforcement with mathematical precision.”

This mission was born from direct experience. OTCM Protocol emerged from Groovy Company, Inc.'s own loss of 15c2-11 eligibility, which trapped 18,000+ shareholders in illiquid positions. This "we've been there" narrative drives every architectural decision, ensuring the protocol addresses real problems faced by real companies and their shareholders.

⚠️ 1.2 Market Problem Scale

Understanding the magnitude of the trapped shareholder problem requires examination of both quantitative data and the systemic forces creating this market failure. The problem is not merely large—it is growing, as regulatory compliance costs continue rising while traditional market infrastructure provides no viable alternatives for smaller public companies.

🔹 1.2.1 Quantifying the Crisis

Market Metric

Current Status

Total OTC Companies with Impaired Liquidity

11,000+

Estimated Trapped Shareholder Value

$50+ Billion

Affected Shareholders (Estimated)

5+ Million

OTC Companies Without Market Maker Support

~90%

Companies Losing 15c2-11 Eligibility Annually

500-1,000+

Annual Compliance Costs (Forcing Abandonment)

$25,000 - $75,000+

Expert Market Securities (Cannot Be Quoted)

3,500+

Grey Market Securities (No Published Quotes)

5,000+

These statistics represent conservative estimates. The actual scope of trapped shareholder value likely exceeds these figures, as many affected companies have ceased all public disclosure, making precise measurement impossible. The problem compounds annually as more companies fall below regulatory thresholds while existing trapped shareholders remain unable to exit.

🔹 1.2.2 The Vicious Cycle of Abandonment

The OTC market abandonment problem operates as a self-reinforcing cycle that, once initiated, becomes nearly impossible to escape:

  • Revenue Decline or Business Challenges: Company experiences operational difficulties, reducing available capital for non-essential expenses
  • Compliance Cost Pressure: Annual costs of $25,000-$75,000+ for audits, legal counsel, transfer agent fees, and regulatory filings become unsustainable
  • Market Maker Withdrawal: Market makers, seeing declining volume and increasing risk, withdraw quotation support
  • 15c2-11 Eligibility Loss: Without current information or market maker support, company loses ability to have shares publicly quoted
  • Shareholder Trap Activation: Existing shareholders discover they cannot sell their positions at any price through normal channels
  • Recovery Impossibility: Without trading revenue or capital access, company lacks resources to restore compliance, creating permanent trap
  • Secondary Harms: Trapped shareholders face cascading consequences—inability to rebalance portfolios, estate planning complications, tax basis issues, and psychological stress of owning unsellable assets

🔹 1.2.3 Regulatory Barriers

The regulatory framework, while designed to protect investors, creates unintended consequences that trap shareholders in abandoned securities:

SEC Rule 15c2-11: Requires broker-dealers to obtain and review specified information about an issuer and its security before publishing quotations. When companies fail to maintain current public information, quotations become prohibited, eliminating trading ability regardless of shareholder desire to transact.

Expert Market Designation: Securities failing 15c2-11 requirements are relegated to the "Expert Market," where only sophisticated institutional investors can trade. Retail shareholders—often the majority of owners—lose all trading access while still owning the security.

Transfer Agent Costs: Basic transfer agent services cost $3,000-$10,000+ annually, with per-transaction fees adding additional burden. Companies abandoning the public markets often also abandon transfer agent relationships, leaving shareholders unable to even transfer shares to willing buyers in private transactions.

Audit Requirements: PCAOB-registered audit firms charge $15,000-$50,000+ annually for microcap company audits. These costs, essential for maintaining current information status, often exceed the operational capacity of struggling companies.

🔹 1.2.4 Market Segmentation Analysis

The trapped shareholder problem affects distinct market segments requiring tailored solutions:

OTC Tier

Companies

Liquidity

OTCM Target

Est. Value

OTCQX

~500

Moderate

Secondary

$5B

OTCQB

~1,000

Limited

Secondary

$8B

Pink Current

~3,500

Poor

Primary

$12B

Pink Limited

~1,500

Minimal

Primary

$5B

Expert Market

~3,500

None (Retail)

Critical

$10B

Grey Market

~5,000+

None

Critical

$10B+

TOTAL

15,000+

—

—

$50B+

📍 1.3 The Origin Story: From Crisis to Innovation

OTCM Protocol's architecture reflects lessons learned from direct experience with the trapped shareholder problem. Understanding this origin story provides essential context for the protocol's design decisions and operational priorities.

🔹 1.3.1 The Groovy Company Experience

Groovy Company, Inc. (OTCUS: GROO) operated as a publicly traded company with 18,000+ shareholders when it encountered the vicious cycle described above. Despite having shareholders who wanted to trade and a company willing to facilitate transactions, the loss of 15c2-11 eligibility created an insurmountable barrier between willing buyers and willing sellers.

The experience revealed several critical insights:

  • Shareholder Frustration: Investors expressed genuine distress at being unable to exit positions, particularly those facing personal financial circumstances requiring liquidity
  • System Failure Recognition: The problem was not company-specific but systemic—thousands of companies and millions of shareholders faced identical circumstances
  • Solution Absence: No existing platform, service, or mechanism provided viable solutions for trapped shareholders in abandoned securities
  • Regulatory Compatibility Requirement: Any solution must work within—not against—existing securities law frameworks to achieve legitimacy and longevity

🔹 1.3.2 Understanding the Trapped Shareholder

The trapped shareholder represents a specific failure mode in securities markets where ownership rights become severed from economic rights. These shareholders possess legally valid ownership of securities—confirmed by transfer agent records, reflected on company capitalization tables, and documented in SEC filings—yet cannot exercise the fundamental economic right of disposition.

Common trapped shareholder scenarios include:

Estate Administration: Heirs inherit positions in illiquid securities they cannot distribute, sell, or value for estate tax purposes, creating administrative paralysis.

Portfolio Rebalancing: Investors holding diversified portfolios discover they cannot sell abandoning positions to deploy capital elsewhere, distorting intended allocations.

Financial Emergencies: Shareholders facing medical expenses, job loss, or other financial needs cannot access capital theoretically represented by their holdings.

Tax Basis Issues: Without trading, shareholders cannot realize losses for tax purposes despite holding securities with effectively zero economic value.

Psychological Burden: The inability to exit creates ongoing stress, as shareholders watch holdings they cannot sell while feeling powerless to act.

🔹 1.3.3 The Genesis of OTCM Protocol

Recognizing that blockchain technology could provide the missing infrastructure for trapped shareholder liquidity, OTCM Protocol was conceived as a comprehensive solution addressing every aspect of the problem:

  • Permanent Liquidity: Unlike temporary solutions dependent on market maker willingness, blockchain-based liquidity pools provide guaranteed, permanent trading capability through smart contract enforcement
  • Regulatory Integration: Rather than creating parallel systems requiring new regulatory frameworks, OTCM integrates with existing SEC-registered transfer agents and established securities law
  • Asset Backing Transparency: Real-time oracle verification of 1:1 backing eliminates concerns about token/asset disconnection that have plagued other tokenization efforts
  • Fraud Prevention: Smart contract enforcement of security controls addresses manipulation risks that have undermined confidence in crypto markets
  • Scalable Infrastructure: Purpose-built Layer 2 architecture enables serving thousands of issuers through standardized "cookie-cutter" processes rather than bespoke implementations

💡 1.4 Core Innovation: The Perpetual Preferred Share Model

OTCM Protocol's fundamental innovation—the perpetual preferred share model—creates an entirely new category of crypto asset that bridges traditional securities infrastructure with blockchain efficiency. This architecture distinguishes OTCM from both traditional securities (lacking blockchain trading capability) and typical crypto tokens (lacking real asset backing).

🔹 1.4.1 Architectural Foundation

The perpetual preferred share model operates on a simple but powerful principle: create permanent, irrevocable separation between tokens and underlying securities while maintaining verifiable 1:1 asset backing. This is achieved through three interlocking mechanisms:

  • Special Share Class Creation: Companies issue Preferred Series "M" shares specifically designed for tokenization—non-voting, non-dividend securities that exist solely to back tokens
  • Permanent Custodial Deposit: Series M shares are permanently deposited with Empire Stock Transfer under irrevocable custody arrangements that prohibit withdrawal by any party
  • 1:1 Token Minting: For each deposited share, exactly one blockchain token is minted—no more, no fewer—with oracle verification ensuring this ratio remains permanent

🔹 1.4.2 The Series M Share Structure

Preferred Series "M" shares are purpose-built instruments designed specifically for the tokenization process with carefully considered characteristics:

Attribute

Specification

Share Class

Preferred Series "M" ("Meme") Shares

Voting Rights

None — tokenization does not affect corporate governance

Dividend Rights

None — economic participation through token appreciation only

Conversion Rights

Optional 1:1 to common stock (requires KYC redemption)

Authorized Quantity

1,000,000,000 (1 billion) per issuer — fixed, non-dilutable

Deposit Status

Permanent — cannot be withdrawn, redeemed, or transferred

Custodian

Empire Stock Transfer (SEC-registered transfer agent)

Token Backing Ratio

Exactly 1:1 — oracle-verified, immutable

🔹 1.4.3 Permanent Deposit Mechanism

The permanent deposit mechanism distinguishes OTCM from other tokenization approaches where backing assets can be withdrawn, creating rug-pull or de-pegging risks. Under the OTCM model:

  • Irrevocable Transfer: Once Series M shares are deposited with Empire Stock Transfer, no party—including the issuing company, OTCM Protocol, or Empire Stock Transfer itself—can withdraw them
  • Legal Enforcement: The deposit arrangement is governed by binding legal agreements that prohibit any mechanism for share recovery
  • Smart Contract Verification: Before every token transfer, Transfer Hook verification confirms backing shares remain in custody
  • Mathematical Guarantee: The combination of legal permanence and smart contract verification creates mathematical certainty that tokens will always be fully backed—"rugpulls become mathematically impossible"

🔹 1.4.4 1:1 Backing Verification

The oracle verification system continuously confirms 1:1 backing through multiple independent channels:

Primary Oracle (Empire Stock Transfer API): Real-time feed of custody balances with cryptographic signatures confirming authenticity. Updated every block (~400ms).

Secondary Oracle (OTCM Verification Node): Independent verification node cross-referencing Empire Stock Transfer data with blockchain token supply. Any discrepancy triggers immediate circuit breaker.

Tertiary Oracle (Public Audit): Quarterly third-party audit of custody holdings published on-chain for public verification.

This multi-oracle architecture provides Byzantine fault tolerance—the system continues operating correctly even if one oracle provides incorrect data, as consensus among multiple oracles is required for verification.

🏗️ 1.5 Technical Architecture: The Nine-Layer Stack

OTCM Protocol comprises four integrated infrastructure components working in concert to deliver permanent, compliant, secure trading for tokenized securities. Each component addresses specific market infrastructure requirements while integrating with other components through well-defined interfaces.

🔹 1.5.1 CEDEX — Layer 5 (See Section 5)

CEDEX represents purpose-built trading infrastructure achieving simultaneous satisfaction of three historically contradictory objectives:

  • Permissionless Trading: Blockchain-based accessibility allowing anyone with compliant credentials to trade without intermediary approval
  • Integrated Compliance: Federal securities law requirements (KYC/AML, accreditation, OFAC) enforced at the protocol level through Transfer Hooks
  • Custodial Risk Elimination: Non-custodial trading where users maintain control of assets throughout the transaction process The CEDEX architecture addresses a fundamental problem: existing DEXs (Raydium, Orca, Meteora) cannot support OTCM's compliance requirements because their codebases were built before SPL Token-2022 with Transfer Hooks existed. Rather than compromise on compliance, OTCM built custom trading infrastructure with native Token-2022 support.

Metric

CEDEX Performance

Traditional DEX

Throughput (TPS)

400-600

~2,000

Compliance Verification

Native (Every TX)

None

Token-2022 Support

Full (Transfer Hooks)

Partial/None

Asset Backing Verification

Oracle (Real-time)

None

Securities Law Integration

Comprehensive

None

🔹 1.5.2 Federated Liquidity Protocol — Layer 3 (See Section 4)

The OTCM Liquidity Pool (OTCM LP) serves as unified institutional-grade market infrastructure providing permanent liquidity for all ST22 tokens. Unlike traditional liquidity pools managed by market makers who can withdraw at any time, OTCM LP operates under permanent lock mechanisms enforced by smart contracts.

Capital Accumulation Mechanisms (Four Sources):

  • Bonding Curve Graduations: When ST22 tokens graduate from bonding curve to CPMM trading, accumulated capital ($1-5M per issuer) permanently transfers to OTCM LP
  • Trading Fee Allocation: 44 basis points (0.44%) of the 5% transaction fee automatically routes to OTCM LP for depth enhancement
  • Staking Reward Reinvestment: 2% of staking rewards mandatorily reinvest into OTCM LP, creating compounding growth
  • Permanent Lock Enforcement: Capital entering OTCM LP cannot be withdrawn—override requires 2/3 DAO supermajority vote plus 48-hour timelock Projected Growth: $2M initial → $12.5M Year 1 → $64.3M Year 5 through accumulated trading fees, graduations, and reinvestment.

🔹 1.5.3 SPL Token-2022 Transfer Hook Enforcement — Layer 2 (See Section 3)

SPL Token-2022 Transfer Hooks provide OTCM's core compliance enforcement mechanism. Every ST22 token transfer triggers six sequential verification hooks that must complete successfully before the transaction executes. Any hook failure causes atomic transaction reversion with specific error codes enabling rapid diagnosis.

The Six Transfer Hooks:

  • Hook 1 — Custody Verification (100-150ms): Confirms circulating token supply ≤ custodied share count. Error 6001 if backing insufficient.
  • Hook 2 — OFAC Screening (200-500ms): Checks both parties against SDN list updated hourly. Error 6002 if sanctioned address detected.
  • Hook 3 — AML Verification (300-400ms): Machine learning risk scoring (0-30 approve, 71-100 reject, 31-70 enhanced review). Error 6003 if threshold exceeded.
  • Hook 4 — Redemption Eligibility (50-100ms): For redemption transactions, verifies KYC completion and accreditation status. Error 6004 if ineligible.
  • Hook 5 — Price Impact Limit (50-100ms): Enforces 2% maximum price movement versus TWAP. Error 6006 if circuit breaker triggers.
  • Hook 6 — Liquidity Ratio (50-100ms): Maintains 150% minimum liquidity ratio. Error 6007 if ratio violated. Total verification time: 750-1,350ms per transaction, with parallel execution reducing typical latency to under 1 second.

🔹 1.5.4 Issuers Portal Compliance Gateway — Application Layer

The Issuers Portal provides standardized compliance gateway consolidating KYC/AML verification, accreditation certification, OFAC screening, and regulatory reporting into a single institutional-grade interface. This eliminates the requirement for individual issuers to independently navigate complex securities law infrastructure.

Key Functions:

  • Issuer Onboarding: Guided workflow from application to Series M share deposit to ST22 token launch (3-4 weeks typical)
  • Investor Verification: Centralized KYC/AML/accreditation for all platform participants
  • Regulatory Reporting: Automated Form D filings, TA-1 compliance, suspicious activity reporting
  • Global Investor Access: Regulation S for non-US investors, Regulation A+ Tier 2 pathway for unaccredited US investors (up to $75M annually)


📋 ACCOUNT SCHEMA VERSIONING POLICY

Version: 6.0 | Applies To: All on-chain account types in OTCM Protocol programs

Problem Statement

Solana accounts have fixed sizes at allocation. Adding fields to an existing on-chain account requires explicit reallocation via AccountInfo::realloc() and a funded payer. Without a versioning strategy, protocol upgrades that modify account schemas will either corrupt existing accounts or require a full account migration, creating a trading halt risk.

Versioning Strategy

All OTCM on-chain accounts include a mandatory version: u8 field as the first field after the Anchor discriminator. This enables forward-compatible schema evolution.

rust

/// Base trait implemented by all versioned OTCM accounts
pub trait VersionedAccount {
    fn version(&self) -> u8;
    fn current_version() -> u8;
    fn migrate(&mut self) -> Result<()>;
}

/// Example: InvestorRecord versioning
#[account]
pub struct InvestorRecord {
    pub version: u8,              // MUST be field index 0
    pub wallet: Pubkey,
    pub kyc_status: KycStatus,
    pub accreditation_expiry: i64,
    pub risk_score: u8,
    // v2 fields (added in protocol v2 — zero-initialized on migration)
    pub jurisdiction: [u8; 2],    // ISO 3166-1 alpha-2 country code
    pub enhanced_dd_flag: bool,   // Enhanced due diligence required
    // v3 fields (reserved for future use — always zero until v3 upgrade)
    pub _reserved: [u8; 32],
}

impl VersionedAccount for InvestorRecord {
    fn version(&self) -> u8 { self.version }
    fn current_version() -> u8 { 2 }

    fn migrate(&mut self) -> Result<()> {
        match self.version {
            1 => {
                // v1 → v2: initialize new fields to safe defaults
                self.jurisdiction = [0u8; 2];   // Unknown jurisdiction
                self.enhanced_dd_flag = false;
                self.version = 2;
                Ok(())
            }
            2 => Ok(()), // Already current
            _ => Err(error!(SchemaError::UnknownVersion)),
        }
    }
}

Migration Execution Model

Account migrations are lazy — triggered on the first interaction with an account after a protocol upgrade, not via a batch migration transaction. This eliminates migration-related trading halts.

Protocol Upgrade Deployed (new program version)
              │
              ▼
User submits transfer involving InvestorRecord account
              │
              ▼
Transfer Hook reads account → checks account.version < current_version()
              │
       ┌---┴---┐
   Up-to-date    Needs migration
       │               │
       ▼               ▼
  Continue         Call account.migrate()
  validation       Realloc if size increased
                   Write migrated data
                   Continue validation

Schema Change Governance Requirements

Change Type

Governance Required

Migration Strategy

Trading Impact

Add optional field (with

_reserved

 space)

DAO notification only

Lazy migration — no halt

None

Add required field (no reserved space)

DAO vote — 48h timelock

Lazy migration + realloc

None

Rename field (same type, same offset)

DAO vote — 48h timelock

IDL update only

None

Remove field

DAO vote — 7-day timelock

Mark deprecated — keep in struct

None

Change field type

DAO vote — 7-day timelock

Full account migration required

Possible brief halt

Change account size beyond reserved space

DAO vote — 7-day timelock

Realloc all affected accounts

Planned maintenance window

DAO Upgrade + Account Compatibility Requirement

No DAO-approved program upgrade may activate on mainnet until: (1) the new program version handles all existing account schema versions via migrate(), and (2) the upgrade proposal includes a schema compatibility attestation signed by the auditing firm. This requirement is enforced at the governance layer — proposals without a compatibility attestation are automatically rejected by the DAO contract.

🚨 INCIDENT RESPONSE & DISASTER RECOVERY SPECIFICATION

Version: 6.0 | Owner: OTCM Protocol Engineering + Compliance

Severity Classification

Severity

Definition

Examples

Response SLA

P0 — Critical

Active exploit or total service loss

Transfer Hook bypass, LP fund drain, oracle compromise

15 minutes to triage, 1 hour to mitigation

P1 — High

Significant degradation or security concern

Oracle consensus failure, CEDEX order matching halt, RPC failover triggered

30 minutes to triage, 4 hours to resolution

P2 — Medium

Partial service degradation

Single oracle feed unavailable, elevated latency, circuit breaker activation

2 hours to triage, 24 hours to resolution

P3 — Low

Minor issues or monitoring alerts

Performance degradation, non-critical bug reports

Next business day

P0 Critical Response Runbook

STEP 1 — DETECT (automated, <60 seconds)
  Monitoring system detects anomaly → PagerDuty alert fires
  Alert routes to: On-call engineer + CTO + Security Lead simultaneously
  Auto-actions: Screenshot oracle state, capture on-chain event logs

STEP 2 — ASSESS (0–15 minutes)
  On-call engineer reviews:
    - Transfer Hook error codes (last 100 transactions)
    - Oracle consensus state
    - LP pool balances vs. expected
    - CEDEX order book state
  Decision: Activate Global Circuit Breaker (Control 36)?

STEP 3 — CONTAIN (15–60 minutes)
  If LP drain or Hook bypass confirmed:
    → Activate Control 36 (Global Circuit Breaker) — 3-of-4 multisig
    → Notify Empire Stock Transfer to suspend custody API
    → Post status update at status.otcm.io
    → Preserve all logs — do not modify chain state
  If oracle failure only:
    → Oracle consensus failure activates Control 40 automatically
    → Engage backup oracle operators
    → No circuit breaker needed unless Hook failures result

STEP 4 — COMMUNICATE (within 1 hour of detection)
  Internal: Notify all keyholders, legal counsel, compliance officer
  External (if material): Post incident notice on status.otcm.io
  Regulatory (if securities-related): Notify Empire Stock Transfer,
    consult legal counsel re: SEC disclosure obligations

STEP 5 — RECOVER
  Root cause analysis completed
  Fix developed and tested on devnet
  Independent security review of fix (Halborn or Quantstamp on-call)
  If program upgrade required: DAO vote + 48h timelock
  Trading resumes only after: fix deployed + monitoring confirms normal state

STEP 6 — POST-MORTEM (within 7 days)
  Written post-mortem published at otcm.io/security
  Root cause, timeline, impact, fix, and prevention measures documented
  Post-mortem shared with audit firms

Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)

Component

RTO (max downtime)

RPO (max data loss)

Recovery Method

Transfer Hook enforcement

Tied to Solana network

Zero — blockchain is source of truth

Solana consensus recovery

CEDEX order matching (off-chain)

4 hours

0 seconds — all orders replayed from on-chain events

K8s pod restart + state replay

Oracle network

30 minutes

Zero — oracle data re-fetched from source

Failover to secondary/tertiary feeds

Investor portal

2 hours

24 hours — daily DB snapshots

RDS snapshot restore

AI module (Layer 9)

24 hours

72 hours — IDOS scores recalculated from raw data

Full EDGAR re-ingestion

LP pool capital

Zero — permanent lock

Zero — on-chain permanent

N/A — capital cannot be lost

Infrastructure Redundancy Architecture

PRIMARY REGION (us-east-1 — AWS)
  ├--- CEDEX order matching — 3x EC2 instances (auto-scaling group)
  ├--- Helius RPC primary — 500 req/sec dedicated tier
  ├--- Oracle primary feeds — AWS CloudHSM partition
  ├--- Investor portal — ECS Fargate + RDS Multi-AZ
  └--- AI module inference — SageMaker endpoint

FAILOVER REGION (us-west-2 — AWS) — warm standby
  ├--- CEDEX order matching — 1x EC2 instance (scales on failover)
  ├--- Triton/QuickNode RPC — backup cluster
  ├--- Oracle secondary feeds — GCP CloudHSM (different provider)
  └--- Portal DB replica — RDS read replica (promoted on failover)

FAILOVER TRIGGER:
  Automatic: Health check fails 3 consecutive times (90-second detection)
  Manual: On-call engineer via runbook
  DNS failover: Route 53 health checks — 60-second TTL

GDPR vs. Immutable Blockchain — Technical Resolution

A critical compliance tension exists between GDPR Article 17 (Right to Erasure) and Solana's immutable ledger. OTCM Protocol resolves this through data architecture separation:

ON-CHAIN (immutable — never contains PII):
  ✓ Wallet public keys (pseudonymous — not directly PII under GDPR)
  ✓ Token transfer amounts and timestamps
  ✓ Compliance status flags (VERIFIED / FROZEN — no identity data)
  ✓ Audit log hashes (SHA-256 of full audit record — not reversible)

OFF-CHAIN (mutable — subject to GDPR erasure):
  ✓ Full name, email, address, date of birth
  ✓ KYC document images (passport, utility bills)
  ✓ Accreditation verification records
  ✓ AML screening results and risk scores
  ✓ All PII collected during investor onboarding

ERASURE PROCEDURE (GDPR Article 17 request):
  Step 1: Verify identity of requesting data subject
  Step 2: Delete all off-chain PII from investor portal DB
  Step 3: Set on-chain InvestorRecord.kyc_status = ERASED
  Step 4: Wallet retains token balance — ownership is not PII
  Step 5: Future transfers rejected (ERASED status = Hook 4 rejection)
  Step 6: Confirm erasure in writing within 30 days (GDPR requirement)

NOTE: On-chain transaction history (amounts, timestamps, wallet addresses)
cannot be erased — this is disclosed to all investors at onboarding.
Wallet addresses are pseudonymous identifiers, not directly PII, consistent
with EDPB guidance on blockchain and GDPR (Opinion 05/2019).

Cyber Insurance Coverage

OTCM Protocol maintains the following insurance coverage as a condition of institutional operations:

Coverage Type

Minimum Coverage

Insurer Category

Renewal

Cyber Liability (1st party)

$5,000,000

A-rated carrier

Annual

Technology Errors & Omissions

$5,000,000

A-rated carrier

Annual

Crime / Social Engineering

$2,000,000

A-rated carrier

Annual

Directors & Officers

$3,000,000

A-rated carrier

Annual

Specific carrier names disclosed to institutional investors under NDA upon request.

🏛️ DAO GOVERNANCE SECURITY SPECIFICATION

Version: 6.0 | Applies To: Layer 7 — DAO Governance (activation target: 2028)

Governance Attack Vector Mitigations

The DAO governance system must resist several well-documented attack vectors. Each is addressed below with the specific technical mitigation.

Attack Vector

Description

OTCM Mitigation

Governance takeover (51% attack)

Attacker acquires >50% of voting power

66.67% supermajority required — attacker needs 2/3 of staked tokens

Flash loan governance attack

Borrow tokens, vote, repay — all in one transaction

Voting power snapshot taken at block N-100 — flash loans cannot acquire historical stake

Low quorum capture

Vote passes with minimal participation

30% minimum quorum — proposal fails if <30% of staked tokens vote

Proposal spam

Flood governance with proposals to cause confusion

100,000 OTCM staked required to submit proposal — economic cost deters spam

Timelock bypass

Attempt to execute before timelock expires

Smart contract enforces 48-hour timelock — no administrative override

Parameter creep

Gradually adjust parameters to dangerous levels

Rate limits: max 10% change to any fee parameter per proposal

Security control weakening

Propose to reduce the 42 security controls

Security controls in immutable contract — DAO cannot modify them

Governance Scope Boundaries (Immutable vs. Governable)

IMMUTABLE (cannot be changed by DAO or any party):
  ✗ The 42 Transfer Hook security controls
  ✗ The 1:1 token-to-share backing ratio
  ✗ LP token permanent lock mechanism
  ✗ Mint authority (disabled — no new tokens can ever be minted)
  ✗ OFAC/sanctions screening requirement

GOVERNABLE (requires DAO supermajority vote + 48h timelock):
  ✓ Protocol fee rate (bounded: 1% min, 10% max)
  ✓ Issuer fee rate (bounded: 0% min, 5% max)
  ✓ Graduation threshold (bounded: $100K min, $1M max)
  ✓ Staking APY parameters (bounded by mathematical constraints)
  ✓ Oracle staleness thresholds (bounded: 1 slot min, 1000 slots max)
  ✓ Bug bounty reward levels
  ✓ Program upgrades (security fixes only — with audit requirement)

OPERATOR CONTROLLED (OTCM Protocol, Inc. — no DAO vote required):
  ✓ Marketing and partnership decisions
  ✓ API endpoint additions (non-breaking)
  ✓ Layer 9 AI model retraining
  ✓ Infrastructure scaling (RPC nodes, K8s)

Voting Power Snapshot Implementation

rust

/// Governance token snapshot — prevents flash loan attacks
#[account]
pub struct VotingPowerSnapshot {
    pub voter: Pubkey,
    /// Slot at which snapshot was taken (must be >= proposal_creation_slot - 100)
    pub snapshot_slot: u64,
    /// Staked OTCM balance at snapshot_slot — immutable after creation
    pub staked_balance: u64,
    /// Derived from staked_balance — cannot be inflated after snapshot
    pub voting_power: u64,
}

pub fn calculate_voting_power(staked_balance: u64) -> u64 {
    // 1:1 voting power per staked OTCM (no quadratic voting in v1)
    staked_balance
}

pub fn validate_snapshot_eligibility(
    snapshot_slot: u64,
    proposal_creation_slot: u64,
) -> Result<()> {
    // Snapshot must predate proposal by at least 100 slots
    // This window (40 seconds) makes flash loan attacks impractical
    require!(
        snapshot_slot <= proposal_creation_slot.saturating_sub(100),
        GovernanceError::SnapshotTooRecent
    );
    Ok(())
}

🔹 1.5.5 DAO Governance — Layer 7

Layer 7 provides decentralized protocol stewardship through on-chain voting with a 48-hour proposal timelock. Gold-tier OTCM Security Token stakers vote on protocol upgrades, fee adjustments, FLP configuration, and Transfer Hook parameter changes. No single party — including OTCM Protocol, Inc. — can unilaterally alter the 42 Transfer Hook security controls that protect investor assets.

🔹 1.5.6 Web3 Wallet Infrastructure — Layer 8

Native iOS and Android wallets provide fully compliant ST22 token management. KYC/AML verification is enforced at the wallet layer, making compliance ambient — users cannot interact with ST22 tokens without meeting eligibility requirements. Hardware wallet support (Ledger, Trezor) serves institutional custody needs. All on-chain operations route through Layer 2 Transfer Hook enforcement regardless of wallet type or entry point.

🔹 1.5.7 Predictive Marketing AI Module — Layer 9 (See Section 10)

Layer 9 is the commercial intelligence engine converting OTCM's technical infrastructure into an active issuer pipeline. A proprietary AI continuously monitors SEC EDGAR filings and OTC Markets Group data across ~15,000 U.S. OTC companies, generating a daily-refreshed Issuer Distress and Opportunity Score (IDOS). An investor-side behavioral profiling engine targets verified accredited wallets on Solana for ST22 launch campaigns, and the Launch Timing Optimization Engine (LTOE) forecasts optimal bonding curve windows. All AI operations are gated behind OTCM Security Token staking tiers and permanently burn tokens on execution. See Section 10 for the complete specification.

🏆 1.6 Key Differentiators

OTCM Protocol distinguishes itself from both traditional securities infrastructure and existing crypto projects through fundamental architectural decisions:

Differentiator

OTCM Approach

Industry Standard

Asset Backing

1:1 permanent, oracle-verified

Trust-based or algorithmic

Liquidity Model

Permanently locked pools

Withdrawable at any time

Compliance

Protocol-enforced (Transfer Hooks)

Policy-based or none

Rug Pull Protection

Mathematically impossible

Trust in developers

Regulatory Approach

Integration and automation

Avoidance or ambiguity

Target Market

Abandoned/illiquid securities

New token creation

📋 1.7 Value Proposition Summary

OTCM Protocol delivers distinct value propositions to each stakeholder category:

🔹 For Trapped Shareholders

  • Exit Capability: Finally ability to sell positions held for years or decades without liquidity
  • Price Discovery: Transparent market pricing replacing subjective valuations
  • 24/7 Access: Global trading capability not restricted by market hours or geography

🔹 For Issuing Companies

  • Shareholder Value Restoration: Enable liquidity for shareholders previously unable to trade
  • Compliance Cost Elimination: No market maker fees ($5,000-$20,000+/month), minimal listing costs ($5,000 one-time)
  • Community Building: MemeCommunity token cultureengagement drives organic communityecosystem engagementgrowth
  • Treasury Asset: 60% token allocation provides treasury assets for company operations

🔹 For Investors

  • Access to Previously Unavailable Markets: Trade in securities with no prior trading venue
  • Verified Asset Backing: Oracle confirmation eliminates concerns about token/asset disconnection
  • Fraud Protection: 42 security controls and permanent liquidity locks eliminate common attack vectors
  • Staking Rewards: 8-60% APY through staking participation with 2.6-day epochs ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━---
Back to top