🗺️ Section 13: Implementation Roadmap

🗺️ Phase-by-phase implementation timeline from Q2 2026 launch through full international expansion, including technical milestones, regulatory rollout, and risk contingency planning.

🚀 13.1 Q2 2026 Launch Sequence

The OTCM Protocol follows a methodical, security-first launch sequence designed to ensure flawless deployment of critical financial infrastructure for Digital Securities.

"Financial infrastructure requires zero-tolerance launch procedures. Every line of code, every regulatory filing, every system integration must be verified before a single transaction processes."

PRE-LAUNCH PHASE          LAUNCH WEEK           POST-LAUNCH
Days -60 to -1   ──→      Days 1–7      ──→     Weeks 2–4
Security audits           Deployment            Stabilization
Regulatory prep           Canary testing        Issuer onboarding
Infrastructure            Public mainnet        Scaling prep

🔹 13.1.1 Pre-Launch Phase (Days -60 to -1)

interface PreLaunchPhase {
  duration: {
    startDay:  -60;   // 60 days before launch
    endDay:    -1;    // Day before launch
    totalDays: 60;
  };

  workstreams: [
    {
      name:         'SECURITY_AND_AUDITING';
      duration:     45;      // Days -60 to -15
      dependencies: [];
      critical:     true;
    },
    {
      name:         'REGULATORY_COORDINATION';
      duration:     60;      // Full pre-launch period
      dependencies: [];
      critical:     true;
    },
    {
      name:         'INFRASTRUCTURE_PREPARATION';
      duration:     30;      // Days -30 to -1
      dependencies: ['SECURITY_AND_AUDITING'];
      critical:     true;
    },
  ];

  readinessGates: {
    securityAuditComplete: boolean;
    regulatoryApprovals:   boolean;
    infrastructureReady:   boolean;
    teamReadiness:         boolean;
    contingencyPlans:      boolean;
  };
}

🔹 13.1.2 Security and Auditing Program

Audit Type	Provider	Duration	Completion Target
Smart Contract Audit #1	Quantstamp	4 weeks	Day -45
Smart Contract Audit #2	Halborn	4 weeks	Day -40
Formal Verification	Certora	3 weeks	Day -30
Dynamic Security Testing	Internal + External	2 weeks	Day -20
Penetration Testing	White-hat Team	2 weeks	Day -15
Manual Code Review	Senior Engineering	Continuous	Day -7

interface SecurityAuditProgram {
  auditScope: {
    contracts: [
      'CEDEX_MAIN',        // Core exchange contract
      'OTCM_LIQUIDITY_POOL',
      'TRANSFER_HOOK',     // SPL Token-2022 hook program
      'BONDING_CURVE',
      'STAKING_POOL',
      'VESTING_CONTRACT',
    ];
    linesOfCode: 25_000;
    complexity:  'HIGH';
  };

  formalVerification: {
    provider: 'CERTORA';
    specifications: [
      'no_unauthorized_minting',
      'backing_ratio_invariant',    // 1:1 backing always maintained
      'no_fund_extraction',
      'transfer_hook_always_executes',
      'fee_collection_accurate',
      'circuit_breaker_triggers',
    ];
    proofLevel: 'MATHEMATICAL_CERTAINTY';
  };

  remediation: {
    criticalFindings: 'MUST_FIX_BEFORE_LAUNCH';
    highFindings:     'MUST_FIX_BEFORE_LAUNCH';
    mediumFindings:   'FIX_WITHIN_30_DAYS';
    lowFindings:      'FIX_WITHIN_90_DAYS';
  };
}

🔹 13.1.3 Regulatory Coordination

Agency	Coordination Activities	Target Date
SEC	Pre-filing meeting · Form D preparation · Rule 506(c) verification · Digital Securities classification confirmation	Day -45
FinCEN	BSA compliance verification · SAR/CTR filing procedures · 314(b) enrollment	Day -30
OFAC	SDN list integration verification · sanctions screening provider coordination	Day -30
Empire Stock Transfer	Custody integration testing · attestation oracle verification · registry sync	Day -14
State Blue Sky	Notice filings in applicable states (506(c) preemption verification)	Day -14

interface RegulatoryCoordination {
  secCoordination: {
    preFilingMeeting: {
      scheduled: true;
      purpose:   'Review 506(c) offering structure, ST22 Digital Securities classification under Release No. 33-11412';
      attendees: ['SEC_CORP_FIN', 'OTCM_LEGAL', 'OTCM_COMPLIANCE'];
      targetDate: 'DAY_MINUS_45';
    };
    formDPreparation: {
      exemption:        'RULE_506C';
      filingDeadline:   '15_DAYS_AFTER_FIRST_SALE';
      preparationComplete: 'DAY_MINUS_7';
    };
  };

  fincenCoordination: {
    bsaRegistration: {
      status:       'REGISTERED';
      filingSystem: 'BSA_EFILING';
      testFilings:  3;
    };
    section314b: {
      enrolled:             true;
      verificationComplete: 'DAY_MINUS_14';
    };
  };

  ofacCoordination: {
    sdnListIntegration: {
      provider:            'CHAINALYSIS';
      alternateProvider:   'TRM_LABS';
      updateFrequency:     'HOURLY';
      verificationComplete: 'DAY_MINUS_7';
    };
    sanctionsPrograms: ['IRAN', 'NORTH_KOREA', 'SYRIA', 'CUBA', 'CRIMEA', 'RUSSIA', 'VENEZUELA'];
  };

  empireIntegration: {
    custodyVerification: {
      testTransactions: 100;
      attestationOracle: true;
      syncFrequency:    'EVERY_SOLANA_SLOT';
    };
    failoverTesting: {
      scenarios: ['API_OUTAGE', 'DATA_MISMATCH', 'DELAYED_RESPONSE'];
      allPassed:  boolean;
    };
  };
}

🔹 13.1.4 Infrastructure Preparation

Component	Requirements	Target
Solana RPC Nodes	Helius RPC: 500 req/sec · 100 sendTx/sec · 3 geographic regions	Day -14
Validator Priority Fees	Jito bundle integration · priority fee estimation · MEV protection	Day -14
Database Cluster	PostgreSQL primary + 2 replicas · 10K TPS capacity · automatic failover	Day -7
API Gateway	Load balancer · rate limiting · DDoS protection · 99.99% availability	Day -7
Monitoring Stack	Prometheus · Grafana · PagerDuty · 24/7 on-call rotation	Day -7
Disaster Recovery	Cross-region backup · 15-minute RPO · 1-hour RTO · tested failover	Day -3

🔹 13.1.5 Launch Week Execution Plan

interface LaunchWeekPlan {
  parameters: {
    launchDay:    'MONDAY';
    timezone:     'UTC';
    teamLocation: 'DISTRIBUTED';
    warRoom:      true;
  };

  launchTeam: {
    commandCenter: { lead: 'CTO'; members: ['LEAD_ENGINEER', 'SECURITY_LEAD', 'DEVOPS_LEAD'] };
    engineering:   { smartContracts: 2; backend: 3; frontend: 2 };
    compliance:    { officers: 2; analysts: 2 };
    support:       { customerSuccess: 3; documentation: 1 };
  };

  communications: {
    internal:   'SLACK_WAR_ROOM';
    escalation: 'PAGERDUTY';
    external:   'STATUS_PAGE';
    regulatory: 'SECURE_EMAIL';
  };
}

🔹 13.1.6 Day 1 Deployment Timeline

Time (UTC)	Milestone	Actions	Gate
09:00	Contract Deployment	Deploy CEDEX · LP · Transfer Hook · Issuers Portal backend	G1
09:15	Bytecode Verification	Verify all bytecode hashes match audited versions	—
10:00	Protocol Initialize	Configure CEDEX · init LP with permanent lock · enable Transfer Hook	G2
10:15	Compliance Activation	Activate KYC/AML monitoring · OFAC screening · compliance dashboard	—
10:30	Canary Trading	Open to internal accounts · test all 6 Transfer Hook verifications	G3
11:00	Fee Verification	Verify 5% fee collection and distribution to protocol/issuer	—
12:00	Oracle Verification	Confirm TWAP oracle functionality and price accuracy	—
15:00	Public Testnet	Open to 500–1,000 whitelisted testers · $100M simulated volume	G4
18:00	Load Testing	Simulate peak load · verify circuit breakers · stress test infrastructure	—
23:59	Day 1 Complete	All systems operational · monitoring active · Day 2 handoff	—

interface CanaryTradingVerification {
  testAccounts: {
    count:       10;
    types:       ['INTERNAL_TEAM', 'COMPLIANCE_OFFICER', 'SECURITY_TEAM'];
    preVerified: true;
  };

  transferHookTests: [
    { hook: 'KYC_VERIFICATION';    testCase: 'Verified wallet can transfer';          negativeTest: 'Unverified wallet blocked' },
    { hook: 'ACCREDITATION_CHECK'; testCase: 'Accredited investor can purchase';       negativeTest: 'Non-accredited blocked' },
    { hook: 'SANCTIONS_SCREENING'; testCase: 'Clean wallet can transfer';              negativeTest: 'SDN-listed wallet blocked' },
    { hook: 'CUSTODY_VERIFICATION'; testCase: 'Backing verified, transfer proceeds';   negativeTest: 'Backing mismatch blocked' },
    { hook: 'CIRCUIT_BREAKER';     testCase: 'Normal trade proceeds';                  negativeTest: '>2% price impact blocked' },
    { hook: 'FEE_COLLECTION';      testCase: '5% fee deducted correctly';              negativeTest: 'Fee bypass blocked' },
  ];

  passCriteria: {
    allTestsPassed:        true;
    zeroSecurityIssues:    true;
    performanceWithinSLA:  true;
  };
}

🔹 13.1.7 Day 3 Public Mainnet Launch

Time (UTC)	Milestone	Actions	Gate
08:00	Final Go/No-Go	Review Day 1–2 metrics · confirm all systems green · final approval	G5
09:00	PUBLIC MAINNET LAUNCH	Open CEDEX to all verified participants	G6
09:05	Issuer Applications Open	Begin accepting ST22 Digital Securities issuer applications	—
09:10	Full Compliance Active	Activate full compliance monitoring · real-time alerts · SAR automation	—
12:00	First Trading Review	Review first 3 hours of trading · verify metrics · address issues	—
18:00	Day 3 Review	Review first 9 hours · issue status report · plan Day 4 priorities	—

🚨 Launch Gate Requirements: Public mainnet launch requires ALL gates (G1–G5) to pass. Any failed gate triggers launch delay and escalation to CTO for resolution. No exceptions — financial infrastructure requires zero-defect launch.

🔹 13.1.8 Post-Launch Stabilization (Weeks 2–4)

Week	Activities	Success Metrics
Week 2	Monitor transaction volumes · verify Transfer Hooks · review compliance alerts · maintain 99.9%+ uptime	99.9% uptime · <1s latency · 0 security incidents
Week 3	Onboard 10–25 ST22 issuers · process 500–1,000 KYC verifications · launch bonding curves	10+ issuers active · 500+ verified investors
Week 4	Analyze transaction patterns · optimize gas usage · prepare for 2–4× volume increase	Scaling plan complete · bottlenecks identified

🔹 13.1.9 Launch Success Criteria

Metric	Target (Week 4)	Stretch Goal
System Uptime	99.9%	99.99%
Active ST22 Issuers	10–25	30+
Verified Investors	500–1,000	2,000+
Security Incidents	0	0
Compliance Violations	0	0

📈 13.2 Growth Phases

OTCM Protocol follows a structured four-phase growth plan from Genesis through Maturity, each phase building upon the previous with clearly defined objectives, metrics, and dependencies.

Q2 2026          Q3–Q4 2026        2027              2028+
───────          ──────────        ────              ────
Phase 1          Phase 2           Phase 3           Phase 4
GENESIS          BOOTSTRAP         GROWTH            MATURITY
Foundation       Scale &           Market            Full
Establishment    Partnerships      Expansion         Ecosystem

🔹 13.2.1 Phase 1: Genesis (Q2 2026)

Parameter	Specification
Timeline	Q2 2026 (April–June)
ST22 Issuers	10–25 initial issuers (focus on OTC companies with trapped shareholders)
Trading Volume	$50M–$200M initial trading volume capacity
Infrastructure	Core CEDEX · Transfer Hooks · Issuers Portal · compliance monitoring
Regulatory	Rule 506(c) active · Form D filed · Empire Stock Transfer integrated · Release No. 33-11412 Digital Securities classification confirmed
Primary Goal	Establish foundation · prove technology · validate product-market fit

interface Phase1Genesis {
  deliverables: {
    infrastructure: [
      'CEDEX_MAINNET_DEPLOYMENT',
      'OTCM_LIQUIDITY_POOL_ACTIVE',
      'TRANSFER_HOOK_OPERATIONAL',
      'ISSUERS_PORTAL_LIVE',
      'COMPLIANCE_MONITORING_ACTIVE',
    ];
    regulatory: [
      'FORM_D_FILED',
      'RULE_506C_COMPLIANCE',
      'DIGITAL_SECURITIES_CLASSIFICATION_CONFIRMED',  // Release No. 33-11412
      'EMPIRE_STOCK_TRANSFER_LIVE',
      'FINCEN_BSA_ACTIVE',
    ];
    business: [
      'FIRST_10_ISSUERS_ONBOARDED',
      'FIRST_500_INVESTORS_VERIFIED',
      'FIRST_GRADUATION_ACHIEVED',
    ];
  };

  successMetrics: {
    issuersOnboarded:       { min: 10, target: 25 };
    investorsVerified:      { min: 500, target: 1000 };
    tradingVolumeCapacity:  { min: 50_000_000, target: 200_000_000 };
    uptime:                 0.999;
    securityIncidents:      0;
    complianceViolations:   0;
  };

  riskFactors: [
    'REGULATORY_UNCERTAINTY',
    'TECHNOLOGY_BUGS',
    'LOW_INITIAL_ADOPTION',
    'COMPETITOR_RESPONSE',
  ];
}

🔹 13.2.2 Phase 2: Bootstrap (Q3–Q4 2026)

Parameter	Specification
Timeline	Q3–Q4 2026 (July–December)
ST22 Issuers	50–150 issuers (4–6× growth from Phase 1)
Institutional	First institutional partnerships · family offices · RIAs
Market Makers	Enhanced market maker incentive program · liquidity mining
Regulatory	Regulation A+ preparation · additional state filings · international exploration
Primary Goal	Scale operations · establish institutional credibility · prepare for growth phase

🔹 13.2.3 Phase 3: Growth (2027)

Parameter	Specification
Timeline	Full Year 2027
ST22 Issuers	200–500 issuers (expanding beyond OTC to broader Digital Securities)
Daily Volume	$200M–$1B daily trading volume
Global Compliance	Multi-jurisdiction compliance architecture · Regulation S active
NASDAQ Prep	Groovy Company, Inc. ($GROO) NASDAQ listing preparations · audited financials
Primary Goal	Achieve market leadership · establish global presence · prepare for institutional adoption

🔹 13.2.4 Phase 4: Maturity (2028+)

Parameter	Specification
Timeline	2028 and beyond
Institutional Adoption	Full institutional adoption: banks · broker-dealers · asset managers
OTCM ICO	$100M ICO for OTCM utility token distribution (Dutch auction)
DAO Governance	DAO governance activation · decentralized protocol management
International	EU · Asia-Pacific · Latin America expansion
Primary Goal	Protocol decentralization · global regulatory acceptance · market maturity

interface Phase4Maturity {
  otcmICO: {
    targetRaise: 100_000_000;  // $100M USD
    mechanism:   'DUTCH_AUCTION';
    tokenDistribution: {
      publicSale:  40;  // 40% to public
      ecosystem:   25;  // 25% ecosystem growth
      team:        15;  // 15% team (4-year vesting)
      treasury:    20;  // 20% protocol treasury
    };
  };

  daoGovernance: {
    activation:          'Q2_2028';
    votingPower:         'TOKEN_WEIGHTED';
    quorum:              0.10;
    proposalThreshold:   100_000;  // 100K OTCM to propose
    governableParameters: [
      'FEE_RATES', 'STAKING_APY_RANGES', 'CIRCUIT_BREAKER_THRESHOLDS',
      'ISSUER_REQUIREMENTS', 'TREASURY_ALLOCATION',
    ];
  };

  internationalExpansion: {
    regions: [
      { name: 'EU',        framework: 'MiCA',       timeline: 'Q1_2028' },
      { name: 'UK',        framework: 'FCA_SANDBOX', timeline: 'Q2_2028' },
      { name: 'SINGAPORE', framework: 'MAS',         timeline: 'Q3_2028' },
      { name: 'JAPAN',     framework: 'FSA',         timeline: 'Q4_2028' },
    ];
    localPartners: true;
    multiCurrency: true;
  };
}

🔹 13.2.5 Milestone Dependencies

Phase 1 (Genesis)
  ├── Security: 0 Critical/High findings in audits
  ├── Regulatory: Rule 506(c) active · Form D filed
  └── Technical: All 42 Transfer Hook controls operational
         ↓ ENABLES
Phase 2 (Bootstrap)
  ├── Business: 10+ issuers onboarded · 500+ verified investors
  ├── Technical: First graduation completed
  └── Financial: 3+ months clean operating history
         ↓ ENABLES
Phase 3 (Growth)
  ├── Business: 50+ issuers · $100M+ TVL
  ├── Regulatory: Reg A+ qualification · Reg S active
  └── Financial: NASDAQ listing preparations underway
         ↓ ENABLES
Phase 4 (Maturity)
  ├── Business: 200+ issuers · $1B+ annual volume
  ├── Governance: DAO activation ready
  └── International: MiCA/FCA applications filed

🎯 13.3 Technical Development Milestones

🔹 13.3.1 Smart Contract Development

Quarter	Component	Features	Status
Q1 2026	CEDEX Core v1.0	Bonding curve · CPMM · basic Transfer Hooks (6 hooks)	DEV
Q2 2026	Launch Release	Full 42 Transfer Hooks · staking · vesting · circuit breakers	LAUNCH
Q3 2026	CEDEX v1.5	Enhanced AMM · limit orders · advanced analytics	PLAN
Q4 2026	Cross-chain Bridge	Ethereum bridge · multi-chain liquidity aggregation	PLAN
2027	CEDEX v2.0	Full DEX feature parity · institutional trading · dark pools	PLAN
2028	DAO Contracts	Governance · treasury management · proposal system	PLAN

🔹 13.3.2 Infrastructure Scaling

Phase	RPC Capacity	Database	Geographic Regions
Genesis	500 req/sec	10K TPS	3 (US-East · US-West · EU)
Bootstrap	2,000 req/sec	50K TPS	5 (+ APAC · LATAM)
Growth	10,000 req/sec	200K TPS	8 (global coverage)
Maturity	50,000+ req/sec	1M+ TPS	12+ (full global)

🔹 13.3.3 Security Enhancement Roadmap

Q2 2026 — Initial dual-auditor security certification (Quantstamp + Halborn)
Q3 2026 — Bug bounty program launch ($100K initial pool)
Q4 2026 — SOC 2 Type I certification
2027 — SOC 2 Type II certification · ISO 27001
2028+ — Formal verification expansion · insurance coverage ($50M+)

🌍 13.4 Regulatory Expansion Roadmap

🔹 13.4.1 US Regulatory Path

Timeline	Regulatory Milestone	Impact
Q2 2026	Rule 506(c) Active + Digital Securities Classification (Release No. 33-11412)	Accredited investors only · unlimited raise · general solicitation permitted
Q4 2026	Regulation A+ Tier 2 Filing	Non-accredited investors eligible (10% limit) · $75M annual cap
Q2 2027	Regulation A+ Qualification	SEC qualification received · retail investors can participate
Q4 2027	NASDAQ Listing ($GROO)	Groovy Company, Inc. listed on NASDAQ · institutional credibility
2028+	ATS Registration Evaluation	Evaluate SEC ATS registration for fully regulated exchange status

🔹 13.4.2 International Expansion

Region	Timeline	Framework	Approach
European Union	Q1 2028	MiCA	CASP registration · local legal entity
United Kingdom	Q2 2028	FCA	Sandbox participation · full authorization
Singapore	Q3 2028	MAS	Capital Markets Services license
Japan	Q4 2028	FSA/JFSA	Local partnership · Type I license

⚠️ 13.5 Risk Mitigation & Contingency

🔹 13.5.1 Launch Risk Assessment

Risk Category	Likelihood	Impact	Mitigation
Smart Contract Bug	LOW	CRITICAL	Dual audits · formal verification · bug bounty
Regulatory Action	LOW	HIGH	Pre-filing SEC meetings · Digital Securities compliance-first design
Infrastructure Failure	LOW	MEDIUM	Multi-region redundancy · automatic failover
Low Initial Adoption	MEDIUM	MEDIUM	Groovy Company, Inc. as flagship issuer · targeted outreach
Market Manipulation	MEDIUM	MEDIUM	Circuit breakers · 42 Transfer Hooks · real-time monitoring

🔹 13.5.2 Rollback Procedures

interface RollbackProcedures {
  triggerConditions: [
    'CRITICAL_SECURITY_VULNERABILITY',
    'REGULATORY_STOP_ORDER',
    'CATASTROPHIC_DATA_CORRUPTION',
    'PROLONGED_INFRASTRUCTURE_FAILURE',
  ];

  rollbackLevels: {
    level1_pause: {
      action:            'PAUSE_NEW_TRANSACTIONS';
      existingPositions: 'PRESERVED';
      decisionAuthority: 'CTO';
      reversible:        true;
    };
    level2_freeze: {
      action:            'FREEZE_ALL_OPERATIONS';
      existingPositions: 'FROZEN';
      decisionAuthority: 'CEO + CTO';
      reversible:        true;
    };
    level3_rollback: {
      action:            'REVERT_TO_LAST_GOOD_STATE';
      existingPositions: 'RESTORED_FROM_SNAPSHOT';
      decisionAuthority: 'BOARD';
      reversible:        false;
    };
  };

  communication: {
    internal:    'IMMEDIATE_ALL_HANDS';
    regulators:  'WITHIN_1_HOUR';
    users:       'WITHIN_2_HOURS';
    public:      'WITHIN_4_HOURS';
  };
}

🔹 13.5.3 Crisis Management Protocol

Crisis Commander — CTO (primary) or CEO (secondary) has full authority during crisis
War Room Activation — Immediate team assembly within 15 minutes of incident detection
Communication Cadence — Hourly status updates internally · 4-hour updates externally
Regulatory Notification — SEC/FinCEN notification within 24 hours of material incident
Post-Incident Review — Mandatory root cause analysis within 72 hours of resolution

✓ Implementation Readiness: OTCM Protocol's implementation roadmap provides a methodical path from development through global maturity. Each phase builds upon proven foundations with clear success criteria, risk mitigation, and contingency planning. The security-first, compliance-always approach ensures sustainable growth while protecting all stakeholders.

🌐 13.6 Cross-Chain Interoperability Roadmap

🔸 13.6.1 Strategic Position — Why Solana First Is Not Solana Only

OTCM Protocol launched on Solana as a deliberate architectural choice, not a permanent constraint. This section documents the strategic rationale for the Solana-first approach, the phased cross-chain expansion plan, and the technical mechanisms under evaluation for interoperability.

The Solana-First Rationale

Property	Solana	Ethereum L1	EVM L2s
SPL Token-2022 Transfer Hook support	Native — built-in	Not available	Not available
Compliance enforcement at transfer primitive	Yes — Transfer Hooks	Application layer only	Application layer only
Transaction cost per compliance-verified transfer	~$0.00025	$1–$50+	$0.01–$0.50
Settlement finality	~400ms	12–15 seconds	Varies
42-control enforcement feasibility	Yes — within CU budget	Gas cost prohibitive	Partially feasible

The SPL Token-2022 Transfer Hook is the single most important capability in OTCM's architecture. No equivalent exists on Ethereum L1 or any current EVM L2. This is why Solana is not just a preferred choice — it is the only chain where the OTCM Digital Securities architecture as specified can be built today.

Why Multi-Chain Is Still a Strategic Imperative

Institutional custody infrastructure (Fireblocks · BitGo · Anchorage) has deeper Ethereum integration than Solana
Many institutional investors hold capital on EVM chains and prefer not to bridge for new asset exposure
ERC-3643 ($32B+ tokenized) and Securitize (operating on Ethereum) have established institutional familiarity with EVM-based security tokens
Regulatory frameworks in the EU (MiCA) and UK (FCA) have more Ethereum-specific guidance than Solana-specific guidance

🔸 13.6.2 Phased Cross-Chain Expansion Plan

Phase	Timeline	Milestone	Technical Mechanism
Phase 0 — Solana Native	Q2 2026	Mainnet launch — all 42 controls enforced on Solana	SPL Token-2022 Transfer Hooks — no bridge
Phase 1 — Wormhole Read Bridge	Q4 2026	Read-only custody attestation accessible on EVM chains	Wormhole — oracle message relay only
Phase 2 — EVM Representation Tokens	Q2 2027	Wrapped ST22 tokens on Ethereum/Base — trading only · compliance enforced on Solana	Wormhole NTT (Native Token Transfers)
Phase 3 — EVM Compliance Layer	Q4 2027	Subset of Transfer Hook controls ported to EVM via ERC-1363 or custom hooks	ERC-1363 transfer-and-call + compliance oracle
Phase 4 — Full Multi-Chain Parity	2028+	Independent compliance enforcement on EVM chains for jurisdictions requiring it	ERC-3643 compatibility layer evaluation

Critical principle: Solana remains the authoritative settlement and compliance layer at all times. Cross-chain representations are settlement-linked to Solana state — they cannot exist without a corresponding Solana position. No cross-chain architecture will create a parallel token supply that diverges from the on-chain supply on Solana.

🔸 13.6.3 Phase 1 — Wormhole Integration Architecture

Why Wormhole over alternatives:

Bridge Protocol	Solana Support	Formal Verification	Guardian Network	ST22 Compatibility
Wormhole	Native	Yes (guardian network)	19 validators	Evaluating
LayerZero	Solana support	Partial	Oracle + relayer	Evaluating
Axelar	Limited Solana	Partial	Proof-of-stake	Not preferred
Circle CCTP	USDC only	Yes	N/A	Not applicable

🔸 13.6.4 Phase 2 — Native Token Transfer (NTT) Architecture

Wormhole's Native Token Transfer (NTT) framework enables genuine multi-chain token existence while maintaining a canonical supply on Solana.

Compliance implications of EVM wrapped tokens:

On EVM chains, wrapped ST22 Digital Securities tokens trade under the EVM chain's own transfer rules — OTCM's Transfer Hooks do not execute on EVM. This means:

EVM-side transfers are NOT subject to OTCM's 42 security controls
EVM-side OFAC screening must be implemented at the application layer (not hook layer)
The authoritative compliance record remains on Solana
Return to Solana (bridge-in) triggers full 42-control Transfer Hook enforcement

This limitation will be documented in all investor materials for Phase 2. OTCM will not represent EVM wrapped tokens as having equivalent compliance enforcement to native Solana ST22 Digital Securities tokens until Phase 3 is complete.

🔸 13.6.5 Phase 3 — EVM Compliance Layer Evaluation

Option A — ERC-1363 Transfer-and-Call

Feature	SPL Token-2022 Transfer Hook	ERC-1363 transferAndCall
Compliance enforcement mandatory	Yes — cannot be bypassed	No — only if receiver implements interface
Gas cost per compliance check	~$0.00025	$1–$15 per check
Supports 42 sequential controls	Yes — within CU budget	Prohibitive gas cost
Atomic revert on compliance fail	Yes	Yes
DEX compatibility	Custom AMM required	Major DEXs not compatible

Option B — ERC-3643 Compatibility Layer

ERC-3643 (T-REX) is the leading Ethereum security token standard with $32B+ in deployed assets. OTCM is evaluating whether a compatibility wrapper could allow ST22 Digital Securities tokens to be represented as ERC-3643 tokens on Ethereum.

Consideration	Assessment
Institutional familiarity	High — $32B deployed · BlackRock/Hamilton Lane familiar
Compliance enforcement depth	Lower than SPL Transfer Hooks — application layer
Development cost	Medium — wrapper contract + ONCHAINID integration
Time to market	Faster than building custom EVM compliance
Strategic risk	Creates dependency on Tokeny ecosystem

Phase 3 decision gate (Q2 2027): OTCM will evaluate Options A and B based on EVM gas costs, institutional demand, and the state of Ethereum's programmable compliance primitives. A decision document will be published as a governance proposal before Phase 3 development begins.

🔸 13.6.6 Transfer Hook Compliance — Cross-Chain Applicability Summary

Control Category	Enforced on Solana	Enforced on EVM (Phase 2)	Enforced on EVM (Phase 3 target)
Custody verification (Hook 1)	✅ Every transfer	Via Wormhole read relay	Yes — via oracle
OFAC sanctions (Hook 2)	✅ Every transfer	Application layer only	Partial — gas constrained
AML risk scoring (Hook 3)	✅ Every transfer	Application layer only	Partial — gas constrained
KYC/accreditation (Hook 4)	✅ Every transfer	Application layer only	Via ONCHAINID (if ERC-3643)
Circuit breaker (Hook 5)	✅ Every transfer	Not enforced	Evaluating
LP sufficiency (Hook 6)	✅ Every transfer	Not applicable	Not applicable
Controls 7–42	✅ Every transfer	Not enforced	Subset only

⚠️ Investor disclosure: Until Phase 3 is complete, EVM-chain representations of ST22 Digital Securities tokens do not carry equivalent compliance enforcement to native Solana ST22 tokens. This distinction will be clearly disclosed in all marketing materials, token documentation, and investor agreements for cross-chain products.

🔸 13.6.7 Cross-Chain Governance Requirements

Any cross-chain expansion beyond Phase 1 (read-only) requires a DAO governance vote:

Decision	Vote Threshold	Timelock	Required Documentation
Phase 1 activation (Wormhole read relay)	Simple majority	48 hours	Technical specification + security audit
Phase 2 activation (NTT wrapped tokens)	2/3 supermajority	7 days	Full audit + legal opinion on EVM jurisdiction
Phase 3 activation (EVM compliance layer)	2/3 supermajority	14 days	Full audit + compliance equivalence analysis
ERC-3643 compatibility layer	2/3 supermajority	14 days	Legal opinion + Tokeny partnership terms

This governance requirement ensures that the decision to expand beyond Solana is a community decision, not a unilateral management choice, and that institutional investors are aware of and have approved any changes to the Digital Securities compliance architecture they rely upon.

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