🔐 Section 3: SPL Token-2022 Transfer Hooks — Layer 2

🔐 The security primitive at the heart of OTCM Protocol — 42 mathematically enforced controls that execute atomically on every ST22 Digital Securities transfer via SPL Token-2022 Transfer Hook extensions.

💡 3.1 Architectural Innovation

SPL Token-2022 Transfer Hooks represent a fundamental architectural innovation in blockchain-based securities infrastructure, enabling execution of arbitrary smart contract code during token transfers on the Solana blockchain. This capability transforms compliance from a discretionary administrative function into an immutable, mathematically-enforced property of the token itself.

OTCM Protocol leverages Transfer Hooks to implement federal securities law requirements as non-discretionary smart contract code — creating a paradigm where regulatory compliance is not a matter of corporate policy but of cryptographic certainty. Every ST22 Digital Securities transfer triggers sequential execution of six independent verification hooks, completing comprehensive compliance verification before transaction settlement.

Under the SEC's March 17, 2026 interpretation (Release No. 33-11412), ST22 tokens are formally classified as Digital Securities. The Transfer Hook architecture is precisely the mechanism that makes this classification sustainable — it automates the enforcement obligations that come with that classification at the transfer primitive itself.

🔹 3.1.1 SPL Token-2022 Standard Overview

SPL Token-2022 (Token Extensions Program) is Solana's next-generation token standard, introducing programmable extensions that enable sophisticated token functionality impossible with the original SPL Token Program:

Extension	Capability	OTCM Usage
Transfer Hook	Execute custom logic on every transfer	42 security controls · compliance verification
Permanent Delegate	Irrevocable transfer authority	Protocol-level recovery capability
Confidential Transfers	Zero-knowledge encrypted amounts	Future: Privacy-preserving compliance
Transfer Fee	Protocol-level fee collection	5% fee distribution automation
Metadata Pointer	On-chain token metadata	Security details · issuer info · CUSIP
Non-Transferable	Soulbound token capability	Compliance NFTs · investor credentials

🔹 3.1.2 Transfer Hook Extension Mechanism

The Transfer Hook extension enables token mints to specify a program that must be invoked during every token transfer. This mechanism operates at the Solana runtime level, making it impossible to transfer tokens without executing the hook program:

pub struct TransferHook {
    pub program_id: Pubkey,
    pub authority:  Option<Pubkey>,
}

🔹 3.1.3 Compliance-as-Code Philosophy

OTCM's Transfer Hook implementation embodies the "Compliance-as-Code" philosophy: regulatory requirements are translated into deterministic smart contract logic that executes identically every time, without human discretion, administrative override, or interpretation variability.

"Traditional compliance asks: 'Did you follow the rules?' OTCM's Transfer Hooks ask: 'Can you mathematically prove compliance?' The answer is always verifiable on-chain."

Aspect	Traditional Compliance	Transfer Hook Compliance
Enforcement	Policy-based · discretionary	Code-based · deterministic
Override Capability	Admin can bypass	No bypass possible
Audit Trail	Mutable logs · editable	Immutable blockchain record
Verification	Requires trust in operator	Cryptographically verifiable
Consistency	Varies by analyst / day	100% identical execution
Timing	Post-trade review (T+n)	Pre-trade blocking (T-0)

🔹 3.1.4 Regulatory Advantages

Transfer Hook execution provides regulatory advantages unattainable through traditional compliance procedures:

Immutable Audit Trails — Every compliance check recorded on-chain with cryptographic proof of execution timestamp, inputs, and outcomes
Zero Discretion — Compliance decisions are algorithmic — no analyst judgment, no selective enforcement, no regulatory arbitrage
Real-Time Enforcement — Non-compliant transfers blocked before execution, not flagged for review after the fact
Cryptographic Proof — Regulators can independently verify any historical compliance decision by replaying on-chain data
Continuous Operation — 24/7/365 enforcement with no business hours, holidays, or staffing gaps

💡 SEC Alignment: OTCM's Transfer Hook architecture directly implements the investor protection principles articulated in the SEC's March 17, 2026 interpretation (Release No. 33-11412) and the Crypto Task Force's framework for blockchain-native compliance mechanisms.

🔗 3.2 Transfer Hook Execution Flow

🔹 3.2.1 Hook Invocation Sequence

User Initiates ST22 Transfer
         ↓
Solana Runtime intercepts transfer
         ↓
Hook 1: Custody Verification Oracle     (100–150ms)
         ↓ PASS
Hook 2: OFAC Sanctions Screening        (200–500ms)
         ↓ PASS
Hook 3: Blockchain Analytics / AML      (300–400ms)
         ↓ PASS
Hook 4: Redemption Eligibility          (50–100ms)
         ↓ PASS
Hook 5: Price Impact Circuit Breaker    (50–100ms)
         ↓ PASS
Hook 6: Liquidity Pool Sufficiency      (50–100ms)
         ↓ ALL PASS
Transaction Executes & Settles on Solana
         ↓ ANY FAIL
Entire Transaction Reverts Atomically

🔹 3.2.2 Sequential vs. Parallel Execution

OTCM implements sequential hook execution for critical security reasons:

Mode	Advantage	Trade-off
Sequential (OTCM)	Early exit on failure · deterministic order · simpler debugging	Higher latency (750–1,350ms total)
Parallel	Lower latency (~500ms total)	Non-deterministic · race conditions · wasted compute on early failures

Sequential execution ensures that if Hook 1 (Custody Verification) fails, Hooks 2–6 never execute — saving oracle costs and compute resources. Users always know which specific hook rejected their transaction.

🔹 3.2.3 Atomic Transaction Guarantees

Solana's account model provides atomic transaction guarantees: if any hook fails, the entire transaction reverts as if it never occurred. There is no intermediate state where tokens have transferred but compliance verification is incomplete.

🔹 3.2.4 Execution Timing

Hook	Min (ms)	Max (ms)	Avg (ms)	Primary Bottleneck
1. Custody Oracle	100	150	125	Empire API latency
2. OFAC Screening	200	500	350	SDN list size · clustering
3. AML Analytics	300	400	350	ML inference time
4. Redemption Eligibility	50	100	75	KYC database lookup
5. Price Impact	50	100	75	TWAP calculation
6. LP Sufficiency	50	100	75	Pool state read
TOTAL	750	1,350	1,050	Sequential sum

🔗 3.3 Hook 1: Custody Verification Oracle

The Custody Verification Oracle confirms that all circulating ST22 Digital Securities tokens are backed by equivalent equity shares held at Empire Stock Transfer — the SEC-registered transfer agent providing qualified custody services for OTCM Protocol.

🔹 3.3.1 Oracle Architecture

pub struct CustodyOracleData {
    pub issuer_cik:             [u8; 10],
    pub cusip:                  [u8; 9],
    pub share_class:            ShareClass,
    pub custodied_balance:      u64,
    pub circulating_tokens:     u64,
    pub attestation_signature:  [u8; 64],  // Ed25519 — HSM-secured
    pub registry_hash:          [u8; 32],
    pub attestation_timestamp:  i64,
    pub attestation_slot:       u64,
}

🔹 3.3.2 Empire Stock Transfer Integration

Component	Specification
API Endpoint	`https://api.empirestocktransfer.com/v1/custody/verify`
Authentication	API Key + Ed25519 request signing
Response Signing	HSM-secured Ed25519 signature on every attestation
Update Frequency	Every Solana slot (~400ms)
Failover	Multi-region deployment with automatic failover

📋 Proof-of-Reserve — Supply Reconciliation Specification

Version: 6.1 | Applies To: Layer 6 Oracle Network — Hook 1 Custody Verification

The Reconciliation Invariant

At every Solana slot, the following invariant MUST hold for every active ST22 mint:

circulating_supply ≤ custodied_shares

Any condition where on-chain supply exceeds custodied shares is an immediate critical alert (Error 6001 — all transfers halted). The system is designed so that equality (1:1 backing) is the steady state — a custody deficit is impossible under normal operations because shares must be deposited before tokens are minted.

Reconciliation Algorithm — Hook 1 Execution

pub fn verify_custody(
    ctx:             Context<CustodyVerification>,
    transfer_amount: u64,
) -> Result<()> {
    // 1. Verify oracle signature authenticity
    verify_ed25519_signature(
        &oracle_data.attestation_signature,
        &EMPIRE_PUBLIC_KEY,
        &oracle_data.serialize(),
    )?;

    // 2. Reject stale attestations (>10 minutes)
    require!(
        current_time - oracle_data.attestation_timestamp <= 600,
        CustodyError::StaleAttestation  // 6001
    );

    // 3. Check discrepancy within 0.01% tolerance
    require!(
        discrepancy_bps <= MAX_DISCREPANCY_BPS,
        CustodyError::CustodyDiscrepancy  // 6001
    );

    // 4. Confirm sufficient custodied shares for transfer
    require!(
        oracle_data.custodied_balance >= transfer_amount,
        CustodyError::InsufficientCustody  // 6001
    );

    Ok(())
}

pub const MAX_DISCREPANCY_BPS: u64 = 1;  // 0.01% maximum discrepancy

Quarterly Public Proof-of-Reserve Audit

Component	Frequency	Published At	Verifiable By
Empire ledger state hash	Quarterly	otcm.io/proof-of-reserve	Anyone with Empire ledger export
On-chain supply snapshot	Continuous	Solana block explorer	Anyone
Signed custody attestation archive	Quarterly	IPFS + Arweave	Anyone with Empire public key
Third-party attestation (auditor)	Annual	SEC EDGAR (8-K)	Anyone

📋 Regulatory Reference: 17 CFR Section 240.17a-1 et seq. — Transfer Agent Custody Requirements

✗ Error Code 6001: CUSTODY_VERIFICATION_FAILED — Indicates custody verification failure. Possible causes: stale attestation (>10 min), discrepancy >0.01%, insufficient custodied shares, or invalid Empire signature. User should wait for fresh attestation or contact issuer.

🔗 3.4 Hook 2: OFAC Sanctions Screening

The OFAC Sanctions Screening hook prevents transactions to or from wallets associated with the Office of Foreign Assets Control's Specially Designated Nationals (SDN) list, implementing federal sanctions law requirements at the protocol level.

🔹 3.4.1 SDN List Integration

pub struct OfacOracleData {
    pub sdn_merkle_root:       [u8; 32],
    pub sdn_entry_count:       u32,
    pub crypto_sdn_addresses:  Vec<Pubkey>,
    pub last_update:           i64,
    pub publication_id:        [u8; 16],
}

🔹 3.4.2 Address Clustering Analysis

Beyond direct SDN address matching, OTCM implements sophisticated address clustering analysis to detect wallets associated with sanctioned entities:

Funding Source Analysis — Traces wallet funding sources to identify indirect SDN connections
Common Ownership Detection — Identifies wallets controlled by the same entity through transaction pattern analysis
Mixer/Tumbler Detection — Flags wallets with significant exposure to known mixing services
High-Risk Jurisdiction Exposure — Elevated scrutiny for wallets with connections to OFAC-sanctioned jurisdictions

🔹 3.4.3 Screening Implementation

pub fn check_ofac_compliance(
    sender:    &Pubkey,
    recipient: &Pubkey,
    oracle:    &OfacOracleData,
) -> Result<()> {
    // Direct SDN address match
    if sender_blocked || recipient_blocked {
        return Err(OfacError::SanctionedAddress.into());  // 6002
    }

    // Cluster association scoring (threshold: 70)
    if sender_cluster.sdn_association_score > 70 {
        return Err(OfacError::ClusterAssociation {
            address: *sender,
            score:   sender_cluster.sdn_association_score,
            reason:  "High SDN cluster association".to_string(),
        }.into());
    }
    if recipient_cluster.sdn_association_score > 70 {
        return Err(OfacError::ClusterAssociation {
            address: *recipient,
            score:   recipient_cluster.sdn_association_score,
            reason:  "High SDN cluster association".to_string(),
        }.into());
    }

    Ok(())
}

📋 Regulatory Reference: 31 CFR § 500–598 — OFAC Sanctions Administration Regulations

✗ Error Code 6002: OFAC_SANCTIONS_MATCH — Wallet blocked due to OFAC sanctions. This is a PERMANENT block — the wallet cannot transact ST22 tokens. There is no appeal process through OTCM; affected parties must resolve sanctions status with OFAC directly.

🔗 3.5 Hook 3: Blockchain Analytics / AML Screening

The Blockchain Analytics Screening hook implements Bank Secrecy Act AML requirements through machine learning-based risk assessment, analyzing 200+ transaction features to identify money laundering patterns, sanctions evasion, theft proceeds, and coordinated suspicious activity.

🔹 3.5.1 ML Risk Assessment Data Model

pub struct AmlRiskAssessment {
    pub risk_score:      u8,
    pub categories:      AmlRiskCategories,
    pub triggered_flags: Vec<AmlFlag>,
    pub confidence:      u8,
    pub model_version:   [u8; 8],
}

pub struct AmlRiskCategories {
    pub sanctions_evasion:     u8,  // 0–100
    pub money_laundering:      u8,  // 0–100
    pub theft_proceeds:        u8,  // 0–100
    pub darknet_exposure:      u8,  // 0–100
    pub mixer_exposure:        u8,  // 0–100
    pub gambling_exposure:     u8,  // 0–100
    pub coordinated_activity:  u8,  // 0–100
}

🔹 3.5.2 Risk Scoring Tiers

Score	Risk Level	Automated Action	Follow-up
0–30	Low	Auto-approve	None required
31–70	Medium	Enhanced review queue	Manual analyst review within 24h
71–100	High	Auto-reject (Error 6003)	SAR filing evaluation

🔹 3.5.3 Analytics Provider Integration

Chainalysis KYT (Know Your Transaction) — Real-time transaction screening with 15-second SLA
TRM Labs Forensics — Deep historical analysis and entity resolution
Elliptic Navigator — Cross-chain exposure analysis for multi-chain actors

🔹 3.5.4 Implementation

pub const LOW_RISK_THRESHOLD:  u8 = 30;
pub const HIGH_RISK_THRESHOLD: u8 = 71;

pub fn screen_aml(
    sender:    &Pubkey,
    recipient: &Pubkey,
    amount:    u64,
) -> Result<AmlScreeningResult> {
    match max_risk {
        0..=30  => Ok(AmlScreeningResult::AutoApprove),
        31..=70 => {
            queue_enhanced_review(sender, recipient, amount);
            Ok(AmlScreeningResult::ProceedWithFlag)
        },
        71..=100 => Err(AmlError::RiskThresholdExceeded {
            score:     max_risk,
            threshold: HIGH_RISK_THRESHOLD,
        }.into()),  // 6003
        _ => unreachable!(),
    }
}

📋 Regulatory Reference: 31 CFR § 1010 — Bank Secrecy Act AML Requirements

✗ Error Code 6003: AML_RISK_EXCEEDED — Transaction rejected due to high AML risk score (71–100). Wallet may have exposure to money laundering, sanctions evasion, theft proceeds, darknet markets, or coordinated suspicious activity. Appeal requires compliance review.

🔗 3.6 Hook 4: Redemption Eligibility Verification

The Redemption Eligibility hook implements a critical distinction in OTCM's compliance architecture: while permissionless trading allows any verified wallet to purchase and transfer ST22 tokens, redemption (conversion to underlying equity shares) requires full investor verification in accordance with federal securities law.

🔹 3.6.1 KYC/AML Requirements for Redemption

Requirement	Verification Method
Identity Verification	Government-issued photo ID + liveness check via Jumio/Onfido
Address Verification	Utility bill or bank statement within 90 days
SSN/TIN Verification	IRS W-9 form with SSN/TIN matching
Sanctions Screening	72-hour waiting period after initial OFAC/SDN clear
PEP Screening	Politically Exposed Person database check

🔹 3.6.2 Accredited Investor Verification

pub enum AccreditationStatus {
    NotVerified,
    Accredited {
        method:            AccreditationMethod,
        verification_date: i64,
        expiration_date:   i64,   // Typically 90 days
        verifier:          String, // e.g., "VerifyInvestor.com"
    },
    NonAccreditedPermitted {
        regulation:       OfferingRegulation,
        investment_limit: u64,
    },
}

pub enum AccreditationMethod {
    Income,        // $200K / $300K annual income
    NetWorth,      // $1M+ net worth excluding primary residence
    Professional,  // Series 7, 65, or 82 license
    Entity,        // Qualified entity (bank, trust, etc.)
    KnowledgeTest, // SEC proposed "accreditation exam"
}

🔹 3.6.3 Implementation

pub fn verify_redemption_eligibility(
    wallet:     &Pubkey,
    token_mint: &Pubkey,
    amount:     u64,
) -> Result<()> {
    // KYC must be verified
    require!(
        investor.kyc_status == KycStatus::Verified,
        RedemptionError::KycIncomplete  // 6004
    );

    // 72-hour sanctions cooling period
    require!(
        current_time - investor.sanctions_clear_timestamp >= cooling_period,
        RedemptionError::SanctionsCoolingPeriod  // 6004
    );

    // Reg D 506(c): accreditation required
    if offering.regulation == Regulation::RegD506c {
        match &investor.accreditation {
            AccreditationStatus::Accredited { expiration_date, .. } => {
                require!(
                    current_time < *expiration_date,
                    RedemptionError::AccreditationExpired  // 6004
                );
            },
            _ => return Err(RedemptionError::AccreditationRequired.into()),
        }
    }

    Ok(())
}

📋 Regulatory Reference: 17 CFR 230.506(c) — Regulation D Accredited Investor Requirements

✗ Error Code 6004: REDEMPTION_ELIGIBILITY_FAILED — Wallet not eligible for redemption. Possible causes: KYC incomplete, sanctions cooling period active (<72h), accreditation expired or missing for Reg D offerings. Note: Regular ST22 trading remains permitted — only redemption to underlying shares is blocked.

🔗 3.7 Hook 5: Price Impact Circuit Breaker

The Price Impact Circuit Breaker prevents single transactions from causing excessive market movement, implementing regulatory objectives prohibiting manipulative trading devices. Any transaction causing greater than 2% price movement against the Time-Weighted Average Price (TWAP) oracle is automatically rejected.

🔹 3.7.1 TWAP Oracle Integration

pub struct TwapOracle {
    pub token_mint:        Pubkey,
    pub twap_1h:           u64,
    pub twap_24h:          u64,
    pub observation_count: u32,
    pub min_observations:  u32,
    pub last_update_slot:  u64,
}

🔹 3.7.2 2% Threshold Enforcement

pub const MAX_PRICE_IMPACT_BPS: u64 = 200;  // 2.00%

pub fn check_price_impact(
    pool:            &LiquidityPool,
    trade_amount:    u64,
    trade_direction: TradeDirection,
) -> Result<()> {
    let (post_sol_reserve, post_token_reserve) = match trade_direction {
        TradeDirection::Buy  => (
            pool.sol_reserve + trade_amount,
            pool.token_reserve - calculate_output(trade_amount, pool)?,
        ),
        TradeDirection::Sell => (
            pool.sol_reserve - calculate_output(trade_amount, pool)?,
            pool.token_reserve + trade_amount,
        ),
    };

    let post_trade_price = post_sol_reserve * 1_000_000 / post_token_reserve;
    let deviation = if post_trade_price > twap {
        (post_trade_price - twap) * 10000 / twap
    } else {
        (twap - post_trade_price) * 10000 / twap
    };

    require!(
        deviation <= MAX_PRICE_IMPACT_BPS,
        CircuitBreakerError::PriceImpactExceeded {
            expected_impact_bps: deviation,
            max_allowed_bps:     MAX_PRICE_IMPACT_BPS,
        }  // 6006
    );

    Ok(())
}

📋 Regulatory Reference: 17 CFR 240.10b-5(b) — Prohibition on Manipulative Trading Devices

✗ Error Code 6006: PRICE_IMPACT_EXCEEDED — Transaction would cause >2% price movement from TWAP. User should reduce trade size or split into multiple smaller transactions. This protects all market participants from sudden price manipulation.

🔗 3.8 Hook 6: Liquidity Pool Sufficiency

The Liquidity Pool Sufficiency hook ensures the OTCM Liquidity Pool maintains adequate reserves to support all outstanding ST22 Digital Securities tokens. The hook confirms a minimum 150% ratio of locked capital to circulating ST22 value before allowing redemption transactions.

🔹 3.8.1 150% Ratio Requirement

Component	Calculation
Locked Capital	Total SOL in unified LP (permanently locked)
Circulating Value	Sum of (ST22 supply × current price) for all tokens
Sufficiency Ratio	Locked Capital ÷ Circulating Value × 100%
Minimum Required	≥ 150% — redemptions pause if below

🔹 3.8.2 Implementation

pub const MIN_SUFFICIENCY_RATIO_BPS: u64 = 15000;  // 150.00%

pub fn check_liquidity_sufficiency(
    pool:             &UnifiedLiquidityPool,
    redemption_amount: u64,
) -> Result<()> {
    require!(
        post_redemption_ratio >= MIN_SUFFICIENCY_RATIO_BPS,
        LiquidityError::InsufficientLiquidity {
            current_ratio:  post_redemption_ratio,
            required_ratio: MIN_SUFFICIENCY_RATIO_BPS,
        }  // 6007
    );

    Ok(())
}

📋 Regulatory Reference: Securities Exchange Act Rule 15c2-11 — Capital Adequacy Requirements

✗ Error Code 6007: LIQUIDITY_INSUFFICIENT — Pool ratio below 150% threshold. Redemptions temporarily paused until trading volume rebuilds reserves. Regular ST22 trading (non-redemption) remains permitted.

🛡️ 3.9 Thirty-Six Supplementary Security Controls

Beyond the six primary Transfer Hooks, OTCM implements thirty-six supplementary security controls integrated into the transfer hook logic — creating a comprehensive 42-point security framework.

🔹 3.9.1 Smart Contract Controls (1–6)

#	Control	Description
1	Formal Verification	Certora Prover mathematical proof of contract correctness
2	Multi-Audit Requirement	Independent audits by Quantstamp, Halborn, and OtterSec
3	Immutable Bytecode	No proxy pattern — code cannot be changed post-deployment
4	Bug Bounty Program	Up to $500K rewards for critical vulnerabilities
5	Reentrancy Guards	Checks-Effects-Interactions pattern enforcement
6	Integer Overflow Protection	Rust's checked arithmetic prevents overflow attacks

🔹 3.9.2 Access Control Framework (7–12)

#	Control	Description
7	Multi-Sig Administration	4-of-7 threshold for administrative actions
8	Timelock Delays	48-hour delay on all parameter changes
9	Role-Based Access	Granular permission system (operator · compliance · admin)
10	Emergency Pause	2-of-7 emergency pause with 24hr auto-unpause
11	DAO Override	2/3 supermajority required for lock override
12	Key Rotation	Quarterly key rotation with HSM backing

🔹 3.9.3 Transaction Integrity Controls (13–18)

Atomic Execution — All-or-nothing transaction commitment
Orphan Prevention — No partial execution states possible
Replay Protection — Unique transaction signatures prevent replay
Deadline Enforcement — Transactions expire after specified block height
Slippage Protection — User-configurable maximum price deviation

🔹 3.9.4 Oracle & Data Controls (19–24)

Multi-Oracle Consensus — Cross-reference multiple data sources
Staleness Detection — Reject data older than threshold (10 min)
Signature Verification — Ed25519 verification of all oracle data
Rate Limiting — Maximum oracle queries per block per mint
Fallback Oracles — Automatic failover to backup data sources
Data Freshness Proofs — On-chain attestation of data recency

🔹 3.9.5 Monitoring & Alerting (25–30)

Real-Time Monitoring — 24/7 transaction pattern analysis
Anomaly Detection — ML-based unusual activity identification
SEC Notification — Automatic reporting of compliance failures
Compliance Dashboard — Real-time visibility for regulators
Audit Log Export — On-demand historical data retrieval
Alert Escalation — Tiered notification for severity levels

🔹 3.9.6 Governance & Recovery (31–36)

Proposal System — On-chain governance for parameter changes
Voting Mechanism — Token-weighted voting with delegation
Quorum Requirements — Minimum participation thresholds
Veto Power — Compliance officer veto on security-relevant proposals
Migration Capability — Controlled upgrade path for critical fixes
Disaster Recovery — Documented procedures for catastrophic scenarios

❌ 3.10 Error Handling and Recovery

Code	Hook	Condition	User Action
6001	Custody	Discrepancy >0.01%	Wait · retry · contact issuer
6002	OFAC	Sanctioned address	PERMANENT — contact OFAC
6003	AML	Risk score 71–100	Request compliance review
6004	Redemption	KYC / accreditation issue	Complete verification
6006	Price Impact	>2% TWAP deviation	Reduce size · split trade
6007	Liquidity	<150% pool ratio	Wait for ratio recovery

⚡ 3.11 Performance Specifications

Metric	Value	Notes
Total Hook Latency	750–1,350ms	Sequential execution
Compute Units	~800,000 CU	Per complete transfer
Effective TPS	400–600	Compliance overhead
Oracle Cost/Transfer	$2–$5	Chainalysis · Empire APIs

🔒 Cross-Program Invocation (CPI) Security Specification

CPI Boundary Map

Calling Program	Target Program	CPI Type	Accounts Passed	Privilege Check
TransferHook	TokenProgram (SPL Token-2022)	`invoke_signed`	mint · source · dest · authority	PDA authority verified — no signer escalation
TransferHook	OracleRegistry	`invoke`	oracle_account · sequence_registry	Read-only — no write authority passed
TransferHook	AuditLog	`invoke_signed`	audit_pda · system_program	PDA bump verified — canonical bump enforced
CEDEX AMM	TransferHook	`invoke`	extra_account_metas	Hook invoked by token program — not directly by AMM
IssuersPortal	TokenProgram	`invoke_signed`	mint_authority_pda	Mint authority is PDA — program cannot overmint

Privilege Escalation Prevention: All OTCM programs use invoke_signed only when the signing PDA is owned by the calling program. No OTCM instruction passes a user-provided signer to a CPI target. Client-supplied accounts not in the ExtraAccountMetaList PDA registry cause immediate instruction failure.

Account Discriminator Registry

Account Type	Discriminator (hex)	Program	Mutable
ComplianceState	`a1 f3 07 2c 88 4e b1 d0`	TransferHook	Yes
InvestorRecord	`3b 9a c2 11 55 fe 07 44`	TransferHook	Yes
OracleAttestation	`c4 12 7a 38 f0 9d 22 b5`	OracleRegistry	No
OracleSequenceRegistry	`77 e8 01 4f 2d 6a b3 90`	OracleRegistry	Yes
LpPoolState	`58 3d aa 17 0c 84 f2 61`	LiquidityPool	Yes
BondingCurveState	`e9 04 b6 7c 13 2f 55 a8`	BondingCurve	Yes
AuditLogEntry	`2a 7f 03 c1 99 b4 8e d6`	AuditLog	No
IssuanceRecord	`6c 18 d5 40 aa 7b 33 f9`	IssuersPortal	Yes

⚠️ Discriminators above are specification targets. Actual deployed values are generated by Anchor at compile time from sha256("account:")[..8] and must be verified against deployed program IDL before audit sign-off.

🛡️ Supplementary Security Controls — Complete Technical Specification

Controls 7–42 enforced at the Transfer Hook layer

Control Classification

Class	Controls	Description
Account Integrity	7–13	Validate account ownership, sizes, and relationships
Transaction Integrity	14–20	Enforce transaction-level constraints
Market Integrity	21–27	Prevent manipulation and abnormal trading patterns
Operational Security	28–35	Logging, rate limiting, and operational controls
Emergency Controls	36–42	Circuit breakers and emergency response mechanisms

Controls 7–13: Account Integrity

#	Control	Trigger Condition	Enforcement	Error Code
7	Signer Verification	Transfer authority ≠ token account owner or valid delegate	Reject — invalid signer	6007
8	Account Owner Check	Any passed account not owned by expected program	Reject — wrong owner	6008
9	Mint Consistency	Source/dest token accounts reference different mints	Reject — mint mismatch	6009
10	Account Size Validation	Any account data length < minimum expected struct size	Reject — corrupt account	6010
11	Discriminator Validation	Account discriminator ≠ expected 8-byte prefix	Reject — type confusion	6011
12	Token Account State	Source or dest account in Frozen state	Reject — account frozen	6012
13	Delegate Scope Check	Delegated transfer amount > approved delegation amount	Reject — delegation exceeded	6013

Controls 14–20: Transaction Integrity

#	Control	Trigger Condition	Enforcement	Error Code
14	Zero-Amount Guard	Transfer amount = 0	Reject — zero transfer	6014
15	Self-Transfer Guard	Source wallet = destination wallet	Reject — self transfer	6015
16	Overflow Guard	Amount arithmetic produces u64 overflow	Reject — arithmetic overflow	6016
17	Atomic Execution	Any hook CPI fails mid-sequence	Full transaction revert	6017
18	Sequence Integrity	Hook execution order violated (must run 1→6)	Reject — hook order violation	6018
19	Timestamp Validity	Block timestamp > attestation expiry	Reject — stale attestation	6019
20	Duplicate Transaction	Same (source · dest · amount · slot) within 10 slots	Reject — probable duplicate	6020

Controls 21–27: Market Integrity

#	Control	Trigger Condition	Enforcement	Error Code
21	Wash Trade Detection	Source and destination wallets share verified KYC identity	Reject — wash trade	6021
22	Wallet Concentration Limit	Post-transfer balance > 5% of circulating supply	Reject — concentration limit	6022
23	Velocity Limit	Wallet transfers > 10 transactions within 100 slots	Reject — velocity exceeded	6023
24	Graduated Token Lock	Transfer of pre-graduation tokens before vesting cliff	Reject — locked tokens	6024
25	LP Drain Protection	Single transaction would reduce LP depth > 20%	Reject — LP drain attack	6025
26	Price Oracle Deviation	Submitted price deviates > 5% from TWAP oracle	Reject — price manipulation	6026
27	Coordinated Transfer Detection	>3 wallets with correlated transfer patterns in same slot	Flag + manual review	6027

Controls 28–35: Operational Security

#	Control	Trigger Condition	Enforcement	Error Code
28	Immutable Audit Log	Every successful/failed transfer	Write audit PDA entry — always	None (non-rejecting)
29	Rate Limit per Wallet	>50 transfer attempts per wallet per epoch (2.6 days)	Reject after threshold	6029
30	Rate Limit per Mint	>10,000 transfers per ST22 mint per slot	Reject until next slot	6030
31	Oracle Query Rate Limit	>22 oracle lookups per single transaction	Reject — oracle abuse	6031
32	Compute Budget Enforcement	Remaining CU < 50,000 before Hook 6	Reject — insufficient CU	6032
33	Account Rent Validation	Any account below rent-exempt minimum	Reject — rent depleted	6033
34	Program Version Check	Caller program version < minimum compatible version	Reject — version mismatch	6034
35	Key Rotation Compliance	Oracle signer key not in current oracle registry	Reject — unrecognized signer	6035

Controls 36–42: Emergency Controls

#	Control	Trigger Condition	Enforcement	Error Code
36	Global Circuit Breaker	Protocol-wide pause activated by 3-of-4 multisig	Reject all transfers	6036
37	Per-Mint Circuit Breaker	>30% price movement in single slot for specific ST22	Halt mint-specific transfers for 1 hour	6037
38	Custody Discrepancy Halt	Token supply > custodied shares (oracle verified)	Halt all transfers for affected mint	6038
39	OFAC Emergency Block	New OFAC SDN list entry matching active wallet	Immediate freeze — no grace period	6039
40	Oracle Consensus Failure	<2 of 3 oracle feeds available for >5 minutes	Halt affected hook category	6040
41	Controlled Migration	Emergency contract migration — 4-of-7 multisig + 48h timelock	Allow migration to new program	6041
42	Regulatory Compliance Override	Law enforcement or regulatory freeze order received	Comply per legal process	6042

🚨 Incident Response and Operational Monitoring

Monitoring Stack

Layer	Tool	Metrics Collected	Alert Threshold
Solana RPC	Helius Webhooks + custom indexer	Transaction success rate · block lag · RPC latency	Success rate <99% for 60s
Transfer Hook	On-chain event indexer (Geyser plugin)	Hook rejections by error code · CU consumption · execution time	>5% rejection rate per code per minute
Oracle Network	Custom oracle monitor	Attestation age · sequence gaps · consensus failures	Any oracle > staleness threshold
CEDEX AMM	Order flow metrics	Fill rate · slippage · LP depth · circuit breaker fires	LP depth drops >30% in 1 hour
API / Portal	Datadog APM	p95 latency · error rate · concurrent sessions	p95 >500ms or error rate >1%
Smart Contracts	Solana program log indexer	Error code frequency · account state anomalies	Any Error 6001 (custody) or 6036 (global halt)

Incident Severity Classification

Severity	Definition	Response Time	Escalation
P0 — Critical	Trading halted · custody discrepancy · global circuit breaker · active exploit	15 minutes	Immediate — all hands
P1 — High	Oracle consensus failure · >10% hook rejection rate · CEDEX degraded	30 minutes	On-call engineer + CTO
P2 — Medium	Single oracle feed down · elevated latency · single hook degraded	2 hours	On-call engineer
P3 — Low	Non-critical monitoring alert · performance degradation	Next business day	Ticket

RTO / RPO Targets

Component	RTO	RPO	Degraded Mode
Transfer Hook enforcement	Tied to Solana network	N/A — on-chain, always consistent	No degraded mode — transfers halt
CEDEX order matching	30 minutes	Zero — orders queued, not lost	Read-only order book visible
Oracle network (primary)	5 minutes	Last confirmed attestation	Secondary oracle takes over
Investor portal	1 hour	5 minutes (session state)	Read-only mode
API (external)	2 hours	15 minutes	Cached responses

🔑 Key Custodianship Register

Classification: Institutional Security Documentation | Review Cadence: Quarterly or upon any keyholder change

Privileged Key Inventory

Key	Holder	Custody Type	Rotation Schedule
Freeze Authority	Compliance Multisig (3-of-5)	AWS CloudHSM — dedicated partition	Annual + upon regulatory event
Mint Authority	DISABLED — burned post-mint	N/A	Cannot be re-enabled
Program Upgrade Authority	Admin Multisig (4-of-7)	Ledger hardware — geographically distributed	Semi-annual
Oracle Signing Keys	Per-oracle HSM partitions	AWS CloudHSM (primary) · GCP CloudHSM (secondary)	Quarterly
Treasury SOL Multisig	Treasury Multisig (3-of-5)	Ledger hardware — 5 keyholders	Annual
LP Emergency Override	Emergency Multisig (4-of-7)	Ledger hardware — air-gapped signing	Used only in emergency

Freeze Authority Specification

Holder: Compliance Multisig — 3-of-5 threshold

Permitted Use Cases:

OFAC SDN list match — mandatory freeze, no discretion
Active law enforcement hold order — mandatory freeze
Court-ordered asset freeze — mandatory freeze
SAR-trigger investigation hold — discretionary, compliance officer approval required

Prohibited Use Cases:

Competitive, commercial, or operational reasons
Retaliation or dispute resolution
Any use not related to regulatory compliance

Audit Requirement: Every freeze action generates an immutable on-chain audit record (Control 28) and a concurrent off-chain report to Empire Stock Transfer within 24 hours.

4-of-7 Admin Multisig Composition Requirements

Requirement	Specification
Geographic distribution	Minimum 4 distinct countries
Cloud provider distribution	No more than 2 keyholders on same cloud provider
Organizational distribution	Minimum 3 keyholders external to Groovy Company, Inc. dba OTCM Protocol
Hardware wallet requirement	All keyholders must use Ledger or equivalent FIPS 140-2 certified device
Key ceremony requirement	Initial keyholder setup must occur via documented key ceremony with legal witness
Replacement procedure	Lost keyholder: remaining 4-of-6 must authorize replacement via on-chain governance vote

🧪 Smart Contract Test Coverage Specification

Version: 6.1 | Status: Pre-Mainnet Requirements — Must Be Met Before Launch Certification

Coverage Requirements

Program	Unit Test Coverage	Integration Test Coverage	Fuzz Corpus Size	Status
TransferHook	≥ 95% line coverage	All 42 controls tested	≥ 10,000 inputs	Required pre-launch
CEDEX AMM	≥ 92% line coverage	All order types + edge cases	≥ 50,000 inputs	Required pre-launch
LiquidityPool (FLP)	≥ 90% line coverage	Graduation + lock mechanics	≥ 20,000 inputs	Required pre-launch
BondingCurve	≥ 90% line coverage	Price invariant tests	≥ 30,000 inputs	Required pre-launch
OracleRegistry	≥ 95% line coverage	Consensus + replay tests	≥ 5,000 inputs	Required pre-launch
IssuersPortal	≥ 88% line coverage	KYC + accreditation flows	≥ 5,000 inputs	Required pre-launch

🔗 Transfer Hook Inter-Hook State Model

Version: 6.1 | Critical: Defines shared account access between hooks

Hook Isolation Guarantee

Each of the six Transfer Hooks is stateless with respect to the others during a single transaction execution. Hooks do NOT write shared mutable state that subsequent hooks read. This eliminates TOCTOU (time-of-check-time-of-use) vulnerabilities between hooks.

HOOK EXECUTION MODEL:

  Transaction Input Accounts (immutable snapshot for all hooks)
         │
         ├──► Hook 1  reads: oracle_cache_pda (readonly)
         │           writes: audit_log_pda (append-only)
         │
         ├──► Hook 2  reads: ofac_oracle_pda (readonly) · investor_record (readonly)
         │           writes: audit_log_pda (append-only)
         │
         ├──► Hook 3  reads: aml_oracle_pda (readonly) · investor_record (readonly)
         │           writes: audit_log_pda (append-only)
         │
         ├──► Hook 4  reads: investor_record (readonly) · compliance_state (readonly)
         │           writes: audit_log_pda (append-only)
         │
         ├──► Hook 5  reads: price_oracle_pda (readonly) · lp_pool_state (readonly)
         │           writes: audit_log_pda (append-only)
         │
         └──► Hook 6  reads: lp_pool_state (readonly)
                     writes: audit_log_pda (append-only)

KEY PROPERTY: All cross-hook reads are from (readonly) accounts.
              No hook reads data that a prior hook has written.
              audit_log_pda is append-only — no hook reads what another hook wrote.

Account Mutability Map Per Hook

Account	Hook 1	Hook 2	Hook 3	Hook 4	Hook 5	Hook 6
oracle_cache_pda (custody)	R	—	—	—	—	—
ofac_oracle_pda	—	R	—	—	—	—
aml_oracle_pda	—	—	R	—	—	—
price_oracle_pda	—	—	—	—	R	—
investor_record_pda	—	R	R	R	—	—
compliance_state_pda	R	—	—	R	—	—
lp_pool_state_pda	—	—	—	—	R	R
audit_log_pda	W	W	W	W	W	W
sequence_registry_pda	W	—	—	—	—	—

R = Read-only · W = Write · — = Not accessed

⚙️ Compute Unit Budget Specification

Version: 6.1 | Pre-Mainnet Benchmarks Required Before Launch

Component	Operation	Measured CU (avg)	Worst-Case CU
Hook 1	Custody oracle balance read	~18,000	28,000
Hook 2	OFAC fuzzy name match	~95,000	140,000
Hook 3	AML risk score lookup	~22,000	35,000
Hook 4	KYC / accreditation PDA check	~14,000	20,000
Hook 5	TWAP + 2% impact calculation	~45,000	68,000
Hook 6	LP reserve sufficiency check	~12,000	18,000
Base AMM	CPMM swap logic	~180,000	220,000
Account validation	Discriminator + owner checks	~15,000	22,000
Audit logging	On-chain event emission	~8,000	12,000
TOTAL		~409,000	~563,000 (40% of cap)

Priority Fee Strategy: Dynamic fee computed as base_fee × clamp(recent_fee_p75 / base_fee, 1.0, 10.0). Transactions resubmitted with escalating fees at 5-second intervals, up to 3 retries before returning TRANSACTION_TIMEOUT.

⚠️ Pre-Launch Requirement: All six Transfer Hook programs must complete CU profiling under worst-case conditions (500-entry OFAC list, minimum LP depth) before mainnet certification.

🛡️ 3.12 Security Audit Status

Audit Program — Pre-Mainnet Certification Gates

All four audit engagements below are hard launch gates. Mainnet deployment is prohibited until every gate is cleared with zero open Critical or High severity findings.

Firm	Scope	Status	Gate Requirement
Quantstamp	TransferHook programs (all 42 controls) · CEDEX AMM · LiquidityPool	Engagement initiated Q1 2026	Final report — 0 Critical/High open
Halborn	Oracle network · key management · infrastructure penetration test	Engagement in progress	Final report — 0 Critical/High open
OtterSec	BondingCurve · IssuersPortal · staking contracts	Preliminary review complete — full audit Q2 2026	Final report — 0 Critical/High open
Certora	Formal verification of CPMM invariant (x×y=k) · Transfer Hook atomicity · LP lock permanence	Specification complete — proof development Q1 2026	All specified invariants proved — no counterexamples

Bug Bounty Program

Active bug bounty required minimum 30 days before mainnet launch.

Severity	Reward	Example Vulnerability
Critical	Up to $100,000	Transfer Hook bypass · LP fund extraction · mint authority exploit
High	Up to $25,000	Oracle replay attack · CPI privilege escalation · freeze authority bypass
Medium	Up to $5,000	Circuit breaker bypass · rate limit evasion · account spoofing
Low	Up to $500	Gas optimization issues · non-critical logic errors

Submissions: security@otcm.io — PGP key published at otcm.io/security.txt Scope: All on-chain programs · oracle infrastructure · CEDEX order matching engine Out of scope: Frontend UI · third-party dependencies · known issues in public tracker

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