Skip to main content

🗺️ 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.infrastructure Thisfor sectionDigital details the comprehensive pre-launch preparation, launch week execution plan, and post-launch stabilization procedures.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."

// Launch Sequence Overview
// OTCM Protocol Launch Timeline Overview
┌---┐
│                    Q2 2026 LAUNCH SEQUENCE TIMELINE                         │
└---┘

PRE-LAUNCH PHASE LAUNCH WEEK POST-LAUNCH

Days -60 to -1 ──→ Days 1-1–7 ──→ Weeks 2-2–4

│Security │audits           │Deployment            ▼Stabilization
▼Regulatory ▼
┌---┐  ┌---┐  ┌---┐
│ SECURITY & AUDIT    │  │ DAY 1: DEPLOYMENT   │  │ WEEK 2: MONITOR     │
│ • Quantstamp audit  │  │ • 09:00 Contracts   │  │ • Performance       │
│ • Halborn audit     │  │ • 10:00 Initialize  │  │ • Compliance        │
│ • Certora verify    │  │ • 10:30prep           Canary │testing        │Issuer •onboarding
99.9% SLA         │
│ • Penetration test  │  │ • 15:00 Testnet     │  │                     │
├---┤  ├---┤  ├---┤
│ REGULATORY COORD    │  │ DAY 3: MAINNET      │  │ WEEK 3: ONBOARD     │
│ • SEC pre-filing    │  │ • 09:00Infrastructure            Public │mainnet        │ • 10-25 issuers     │
│ • FinCEN coord      │  │ • Full compliance   │  │ • 500-1K KYC        │
│ • OFAC integration  │  │ • Issuer apps open  │  │ • Bonding curves    │
├---┤  ├---┤  ├---┤
│ INFRASTRUCTURE      │  │ DAYS 4-7: STABILIZE │  │ WEEK 4: OPTIMIZE    │
│ • RPC deployment    │  │ • Monitor metrics   │  │ • Gas optimization  │
│ • Validator config  │  │ • Bug fixes         │  │ • Scale planning    │
│ • Disaster recovery │  │ • Load testing      │  │ • 2-4xScaling prep         │
└---┘  └---┘  └---┘

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

The pre-launch phase encompasses all preparation activities required before mainnet deployment. This 60-day period ensures comprehensive security validation, regulatory coordination, and infrastructure readiness.

// Pre-Launch Phase Configuration

interface PreLaunchPhase {

/**

  • 60-day pre-launch preparation framework

*/

// Phase parameters

duration: {

startDay: -60; // 60 days before launch

endDay: -1; // Day before launch

totalDays: 60;

};

// Major workstreams

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: Launch{
    readinesssecurityAuditComplete: gatesboolean;
    regulatoryApprovals:   boolean;
    infrastructureReady:   boolean;
    teamReadiness:         boolean;
    contingencyPlans:      boolean;
  };
}

readinessGates: {

securityAuditComplete: boolean;

regulatoryApprovals: boolean;

infrastructureReady: boolean;

teamReadiness: boolean;

contingencyPlans: boolean;

};

}

🔹 13.1.2 Security and Auditing Program

Smart contract security represents the foundation of OTCM Protocol's integrity. The security program employs multiple independent audit firms, formal verification, and continuous testing:

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

// Security Audit Program Configuration

interface SecurityAuditProgram {

/**

  • Comprehensive security audit framework

*/

// Audit scope

auditScope: {

contracts: [

'CEDEX_MAIN', // Core exchange contract

'OTCM_LIQUIDITY_POOL', // Liquidity pool management

'TRANSFER_HOOK', // SPL Token-2022 hook program

'BONDING_CURVE', // Sigmoid bonding curve

'STAKING_POOL', // Staking rewards distribution

'VESTING_CONTRACT', // Issuer token vesting

];

linesOfCode: 25_000; // Estimated LOC

complexity: 'HIGH'; // Financial infrastructure

};

// Formal verification specifications

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';

};

// Penetration testing scope

penetrationTesting: {

areas: [

'RPC_ENDPOINT_SECURITY',

'API_AUTHENTICATION',

'WALLET_INTEGRATION',

'ORACLE_MANIPULATION',

'MEV_ATTACK_VECTORS',

'DDOS_RESILIENCE',

];

methodology: 'OWASP_TOP_10 + BLOCKCHAIN_SPECIFIC';

};

// Remediation requirements

remediation: {

criticalFindings: 'MUST_FIX_BEFORE_LAUNCH';

highFindings: 'MUST_FIX_BEFORE_LAUNCH';

mediumFindings: 'FIX_WITHIN_30_DAYS';

lowFindings: 'FIX_WITHIN_90_DAYS';

informationalFindings: 'TRACKED';

};

}

🔹 13.1.3 Regulatory Coordination

Pre-launch regulatory coordination ensures compliance with SEC, FinCEN, and OFAC requirements before processing any transactions:

Agency

Coordination Activities

Target Date

SEC

Pre-filing meeting,meeting · Form D preparation,preparation · Rule 506(c) verification · Digital Securities classification confirmation

Day -45

FinCEN

BSA compliance verification,verification · SAR/CTR filing procedures,procedures · 314(b) enrollment

Day -30

OFAC

SDN list integration verification,verification · sanctions screening provider coordination

Day -30

Empire Stock Transfer

Custody integration testing,testing · attestation oracle verification,verification · registry sync

Day -14

State Blue Sky

Notice filings in applicable states (506(c) preemption verification)

Day -14

// Regulatory Coordination Framework

interface RegulatoryCoordination {

/**

  • Pre-launch regulatory preparation

*/

// SEC coordination

secCoordination: {

preFilingMeeting: {

scheduled: true;

purpose: 'Review 506(c) offering structure, ST22 tokenDigital classification'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';

};

};

// FinCEN coordination

fincenCoordination: {

bsaRegistration: {

status: 'REGISTERED';

filingSystem: 'BSA_EFILING';

testFilings: 3; // Test SAR/CTR submissions

};

section314b: {

enrolled: true; // Information sharing

verificationComplete: 'DAY_MINUS_14';

};

};

// OFAC coordination

ofacCoordination: {

sdnListIntegration: {

provider: 'CHAINALYSIS';

alternateProvider: 'TRM_LABS';

updateFrequency: 'HOURLY';

verificationComplete: 'DAY_MINUS_7';

};

sanctionsPrograms: [

'IRAN', 'NORTH_KOREA', 'SYRIA', 'CUBA',

'CRIMEA', 'RUSSIA', 'VENEZUELA'

];

};

// Empire Stock Transfer integration

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

Infrastructure preparation ensures all systems are production-ready with appropriate redundancy, performance capacity, and disaster recovery capabilities:

Component

Requirements

Target

Solana RPC Nodes

Helius RPC: 500 req/sec,sec · 100 sendTx/sec,sec · 3 geographic regions

Day -14

Validator Priority Fees

Jito bundle integration,integration · priority fee estimation,estimation · MEV protection

Day -14

Database Cluster

PostgreSQL primary + 2 replicas,replicas · 10K TPS capacity,capacity · automatic failover

Day -7

API Gateway

Load balancer,balancer · rate limiting,limiting · DDoS protection,protection · 99.99% availability

Day -7

Monitoring Stack

Prometheus,Prometheus Grafana,· PagerDuty,Grafana · PagerDuty · 24/7 on-call rotation

Day -7

Disaster Recovery

Cross-region backup,backup · 15-minute RPO,RPO · 1-hour RTO,RTO · tested failover

Day -3

🔹 13.1.5 Launch Week Execution Plan

Launch week follows a precise execution plan with hourly milestones, verification checkpoints, and escalation procedures:

// Launch Week Configuration

interface LaunchWeekPlan {

/**

  • Detailed launch week execution framework

*/

// Launch parameters

parameters: {

launchDay: 'MONDAY'; // Start of week for maximum coverage

timezone: 'UTC'; // Global standard

teamLocation: 'DISTRIBUTED'; // 24/7 coverage

warRoom: true; // Dedicated command center

};

// Team structure

launchTeam: {

commandCenter: {

lead: 'CTO';

members: ['LEAD_ENGINEER', 'SECURITY_LEAD', 'DEVOPS_LEAD'];

};

engineering: {

smartContracts: 2;

backend: 3;

frontend: 2;

2

};

compliance: {

officers: 2;

analysts: 2;

2

};

support: {

customerSuccess: 3;

documentation: 1;

1

};

};

// Communication channels

communications: {

internal: 'SLACK_WAR_ROOM';

escalation: 'PAGERDUTY';

external: 'STATUS_PAGE';

regulatory: 'SECURE_EMAIL';

};

}

🔹 13.1.6 Day 1 Deployment Timeline

Day 1 (Monday) follows a minute-by-minute deployment schedule:

Time (UTC)

Milestone

Actions

Gate

09:00

Contract Deployment

Deploy CEDEX,CEDEX LP,· LP · Transfer Hook,Hook · Issuers Portal backend

G1

09:15

Bytecode Verification

Verify all bytecode hashes match audited versions

—

10:00

Protocol Initialize

Configure CEDEX,CEDEX · init LP with permanent lock,lock · enable Transfer Hook

G2

10:15

Compliance Activation

Activate KYC/AML monitoring,monitoring · OFAC screening,screening · compliance dashboard

—

10:30

Canary Trading

Open to internal accounts,accounts · test all 6 Transfer Hook verifications

G3

11:00

Fee Verification

Verify 5% fee collection,collection and distribution to protocol/issuer

—

12:00

Oracle Verification

Confirm TWAP oracle functionality,functionality and price accuracy

—

15:00

Public Testnet

Open to 500-500–1,000 whitelisted testers,testers · $100M simulated volume

G4

18:00

Load Testing

Simulate peak load,load · verify circuit breakers,breakers · stress test infrastructure

—

23:59

Day 1 Complete

All systems operational,operational · monitoring active,active · Day 2 handoff

—

// Canary Trading Verification

interface CanaryTradingVerification {

/**

  • Internal testing before public access

*/

// Test accounts

testAccounts: {

count: 10;

types: ['INTERNAL_TEAM', 'COMPLIANCE_OFFICER', 'SECURITY_TEAM'];

preVerified: true; // KYC complete

};

// Transfer Hook verification checklist

transferHookTests: [

{

hook: 'KYC_VERIFICATION';

testCase: 'Verified wallet can transfer';

negativeTest: 'Unverified wallet blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

{

hook: 'ACCREDITATION_CHECK';

testCase: 'Accredited investor can purchase';

negativeTest: 'Non-accredited blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

{

hook: 'SANCTIONS_SCREENING';

testCase: 'Clean wallet can transfer';

negativeTest: 'SDN-listed wallet blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

{

hook: 'CUSTODY_VERIFICATION';

testCase: 'Backing verified, transfer proceeds';

negativeTest: 'Backing mismatch blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

{

hook: 'CIRCUIT_BREAKER';

testCase: 'Normal trade proceeds';

negativeTest: '>2% price impact blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

{

hook: 'FEE_COLLECTION';

testCase: '5% fee deducted correctly';

negativeTest: 'Fee bypass blocked';

status: 'PENDING' | 'PASSED' | 'FAILED';

},

];

//passCriteria: Pass{
    criteriaallTestsPassed:        true;
    zeroSecurityIssues:    true;
    performanceWithinSLA:  true;
  };
}

passCriteria: {

allTestsPassed: true;

zeroSecurityIssues: true;

performanceWithinSLA: true;

};

}

🔹 13.1.7 Day 3 Public Mainnet Launch

Day 3 (Wednesday) marks the public mainnet launch, opening CEDEX to all verified participants:

Time (UTC)

Milestone

Actions

Gate

08:00

Final Go/No-Go

Review Day 1-1–2 metrics,metrics · confirm all systems green,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 via Issuers Portal

—

09:10

Full Compliance Active

Activate full compliance monitoring,monitoring · real-time alerts,alerts · SAR automation

—

12:00

First Trading Review

Review first 3 hours of trading,trading · verify metrics,metrics · address issues

—

18:00

Day 3 Review

Review first 9 hours,hours · issue status report,report · plan Day 4 priorities

—

🚨 Launch Gate Requirements

Requirements:

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

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

Post-launch stabilization ensures the protocol operates reliably while scaling to initial capacity:

Week

Activities

Success Metrics

Week 2

Monitor transaction volumes,volumes · verify Transfer Hooks,Hooks · review compliance alerts,alerts · maintain 99.9%+ uptime SLA

99.9% uptime,uptime · <1s latency,latency · 0 security incidents

Week 3

Onboard 10-10–25 ST22 issuers,issuers · process 500-500–1,000 KYC verifications,verifications · launch bonding curves, begin capital accumulationcurves

10+ issuers active,active · 500+ verified investors

Week 4

Analyze transaction patterns,patterns · optimize gas usage,usage · prepare for 2-4x2–4× volume increase, plan infrastructure scalingincrease

Scaling plan complete,complete · bottlenecks identified

// Post-Launch Stabilization Framework

interface PostLaunchStabilization {

/**

  • Weeks 2-4 stabilization framework

*/

// Week 2: Monitor & Verify

week2: {

monitoring: {

transactionVolume: true;

systemPerformance: true;

transferHookExecution: true;

complianceAlerts: true;

};

uptimeSLA: 0.999; // 99.9% minimum

maxLatency: 1000; // 1 second max

incidentResponseTime: 15; // 15 minutes

};

// Week 3: Onboarding Ramp

week3: {

issuerOnboarding: {

target: { min: 10, max: 25 };

processTime: '48_HOURS';

approvalRate: 0.80; // 80% expected approval

};

investorKYC: {

target: { min: 500, max: 1000 };

verificationTime: '24_HOURS';

approvalRate: 0.85; // 85% expected approval

};

bondingCurves: {

launchTarget: 10; // 10 SMT bonding curves

monitoringLevel: 'INTENSIVE';

};

};

// Week 4: Optimization & Scaling

week4: {

patternAnalysis: {

transactionPatterns: true;

peakUsageTimes: true;

botDetection: true;

};

optimization: {

gasUsage: true; // Reduce transaction costs

computeUnits: true; // Optimize CU consumption

rpcEfficiency: true; // Reduce unnecessary calls

};

scalingPreparation: {

targetMultiplier: 4; // Prepare for 4x current load

infrastructureUpdates: true;

capacityPlanning: true;

};

};

}

🔹 13.1.9 Launch Success Criteria

Metric

Target (Week 4)

Stretch Goal

System Uptime

99.9%

99.99%

Active ST22 Issuers

10-10–25

30+

Verified Investors

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

// Growth Phase Trajectory
// OTCM Protocol Growth Phase Overview
┌---┐
│                        OTCM GROWTH TRAJECTORY                           │
└---┘

PHASE 4

MATURITY

2028+

┌---┐
│ 2,000+  │
PHASE 3        │ Issuers │
GROWTH         │ $1B+    │
2027           │ Daily   │
┌---┐    │ Volume  │
│ 200-500 │    │ ICO     │
│ Issuers │    │ DAO     │
PHASE 2                │ $200M+  │    └---┘
BOOTSTRAP              │ Daily   │
Q3-Q4 2026             │ Volume  │
┌---┐            │ NASDAQ  │
PHASE 1        │ 50-150  │            └---┘
GENESIS        │ Issuers │
Q2 2026          │ Inst    │
┌---┐    │ Partner │
│ 10-25   │    └---┘
│ Issuers │
│ $50-200M│
└---┘

═══════════════════════════════════════════════════════════════════════════

Q2 2026 Q3-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)

PHASE 1 | Genesis — Foundation Establishment

Parameter

Specification

Timeline

Q2 2026 (April - April–June)

ST22 Issuers

10-10–25 initial issuers (focus on OTC companies with trapped shareholders)

Trading Volume

$50M-50M–$200M initial trading volume capacity

Infrastructure

Core CEDEX,CEDEX · Transfer Hooks,Hooks · Issuers Portal,Portal · compliance monitoring

Regulatory

Rule 506(c) active,active · Form D filed,filed · Empire Stock Transfer integrated · Release No. 33-11412 Digital Securities classification confirmed

Primary Goal

Establish foundation,foundation · prove technology,technology · validate product-market fit

// Phase 1: Genesis Configuration

interface Phase1Genesis {

/**

deliverables:
  • Phase{ 1:infrastructure: Genesis[ -'CEDEX_MAINNET_DEPLOYMENT', Foundation'OTCM_LIQUIDITY_POOL_ACTIVE', Establishment
  • Q2'TRANSFER_HOOK_OPERATIONAL', 2026'ISSUERS_PORTAL_LIVE', (April'COMPLIANCE_MONITORING_ACTIVE', -]; June)
regulatory:

*/

[ 

'FORM_D_FILED',
      'RULE_506C_COMPLIANCE',
      'DIGITAL_SECURITIES_CLASSIFICATION_CONFIRMED',  // CoreRelease deliverables
No.

deliverables:33-11412 {

infrastructure: [

'CEDEX_MAINNET_DEPLOYMENT',

'OTCM_LIQUIDITY_POOL_ACTIVE',

'TRANSFER_HOOK_OPERATIONAL',

'ISSUERS_PORTAL_LIVE',

'COMPLIANCE_MONITORING_ACTIVE',

];

regulatory: [

'FORM_D_FILED',

'RULE_506C_COMPLIANCE',

'EMPIRE_STOCK_TRANSFER_LIVE',

'FINCEN_BSA_ACTIVE',

];

business: [

'FIRST_10_ISSUERS_ONBOARDED',

'FIRST_500_INVESTORS_VERIFIED',

'FIRST_GRADUATION_ACHIEVED',

];

};

// Success metrics

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: Risk[
    factors'REGULATORY_UNCERTAINTY',
    'TECHNOLOGY_BUGS',
    'LOW_INITIAL_ADOPTION',
    'COMPETITOR_RESPONSE',
  ];
}

riskFactors: [

'REGULATORY_UNCERTAINTY',

'TECHNOLOGY_BUGS',

'LOW_INITIAL_ADOPTION',

'COMPETITOR_RESPONSE',

];

}

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

PHASE 2 | Bootstrap — Scale & Partnerships

Parameter

Specification

Timeline

Q3-Q3–Q4 2026 (July - July–December)

ST22 Issuers

50-50–150 issuers (4-6x4–6× growth from Phase 1)

Institutional

First institutional partnerships,partnerships · family offices,offices · RIAs

Market Makers

Enhanced market maker incentive program,program · liquidity mining

Regulatory

Regulation A+ preparation,preparation · additional state filings,filings · international exploration

Primary Goal

Scale operations,operations · establish institutional credibility,credibility · prepare for growth phase

🔹 13.2.3 Phase 3: Growth (2027)

PHASE 3 | Growth — Market Expansion

Parameter

Specification

Timeline

Full Year 2027

ST22 Issuers

200-200–500 issuers (expanding beyond OTC to broader securities)Digital Securities)

Daily Volume

$200M-200M–$1B daily trading volume

Global Compliance

Multi-jurisdiction compliance architecture,architecture · Regulation S active

NASDAQ Prep

Groovy CompanyCompany, Inc. ($GROO) NASDAQ listing preparations,preparations · audited financials

Primary Goal

Achieve market leadership,leadership · establish global presence,presence · prepare for institutional adoption

🔹 13.2.4 Phase 4: Maturity (2028+)

PHASE 4 | Maturity — Full Ecosystem

Parameter

Specification

Timeline

2028 and beyond

Institutional Adoption

Full institutional adoption: banks,banks · broker-dealers,dealers · asset managers

OTCM ICO

$100M ICO for OTCM utility token distribution (Dutch auction)

DAO Governance

DAO governance activation,activation · decentralized protocol management

International

InternationalEU market expansion: EU,· Asia-Pacific,Pacific · Latin America expansion

Primary Goal

AchieveProtocol protocoldecentralization decentralization,· global regulatory acceptance,acceptance · market maturity

// Phase 4: Maturity Configuration

interface Phase4Maturity {

/**

  • Phase 4: Maturity - Full Ecosystem
  • 2028+

*/

// ICO parameters

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

};

vestingSchedules: {

publicSale: 'IMMEDIATE';

ecosystem: '3_YEAR_LINEAR';

team: '4_YEAR_1_YEAR_CLIFF';

treasury: 'DAO_CONTROLLED';

};

};

// DAO governance

daoGovernance: {

activation: 'Q2_2028';

votingPower: 'TOKEN_WEIGHTED';

quorum: 0.10; // 10% of tokens

proposalThreshold: 100_000; // 100K OTCM to propose

governableParameters: [

'FEE_RATES',

'STAKING_APY_RANGES',

'CIRCUIT_BREAKER_THRESHOLDS',

'ISSUER_REQUIREMENTS',

'TREASURY_ALLOCATION',

];

};

// International expansion

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

Each phase builds upon the previous with critical dependencies that must be satisfied before progression:

// Milestone Dependency Graph
// Milestone Dependency Graph

PHASEPhase 1 (Genesis) PHASE├── 2Security: (Bootstrap)

0 

├---Critical/High Corefindings Infrastructurein ---► Scaling Infrastructure
│   └--- CEDEX Mainnet                 └--- Multi-region deployment
│   └--- Transfer Hooks                └--- Enhanced monitoring
│   └--- Issuers Portal                └--- API v2 release
│audits
  ├---── 10-25 Issuers ---► 50-150 Issuers
│   └--- Manual onboarding             └--- Automated OTOS
│   └--- Custom support                └--- Self-service portal
│
├---Regulatory: Rule 506(c) Activeactive ---►· RegForm A+D Preparation
│filed
  └---── AccreditedTechnical: onlyAll └---42 Non-accreditedTransfer planningHook │controls └---operational
         US↓ onlyENABLES
└--- International exploration

PHASEPhase 2 (Bootstrap) PHASE├── 3Business: (Growth)

10+ 

issuers onboarded · 500+ verified investors
  ├---── InstitutionalTechnical: PartnersFirst ---►graduation Full Institutional Adoption
│completed
  └---── FamilyFinancial: offices3+ └---months Banks,clean broker-dealersoperating │history
         └---↓ RIAsENABLES
└--- Asset managers
│
├--- Market Maker Program ---► Deep Liquidity
│   └--- Incentive structure           └--- Competitive spreads
│   └--- Initial participants          └--- Major market makers
│
├--- Reg A+ Preparation ---► Global Compliance
│   └--- SEC engagement                └--- Multi-jurisdiction
│   └--- Audited financials            └--- Regulation S active

PHASEPhase 3 (Growth) PHASE├── Business: 50+ issuers · $100M+ TVL ├── Regulatory: Reg A+ qualification · Reg S active └── Financial: NASDAQ listing preparations underway ↓ ENABLES Phase 4 (Maturity)

├---── $200M-1BBusiness: Daily200+ Volumeissuers ---►· $1B+ Dailyannual Volume
│   └--- Proven scalability            └--- Market leadership
│volume
  ├---── NASDAQ Preparation ---► Groovy Company Listed
│   └--- $GROO audited                 └--- Public company status
│
├--- Protocol Proven ---► $100M ICO +Governance: DAO │activation ready
  └---── TrackInternational: recordMiCA/FCA └---applications Community governance
│   └--- Regulatory acceptance         └--- Decentralized controlfiled

🎯 13.3 Technical Development Milestones

🔹 13.3.1 Smart Contract Development

Quarter

Component

Features

Status

Q1 2026

CEDEX Core v1.0

Bonding curve,curve CPMM,· CPMM · basic Transfer Hooks (6 hooks)

DEV

Q2 2026

Launch Release

Full 36+42 Transfer Hooks,Hooks staking,· vesting,staking · vesting · circuit breakers

LAUNCH

Q3 2026

CEDEX v1.5

Enhanced AMM,AMM · limit orders,orders · advanced analytics

PLAN

Q4 2026

Cross-chain Bridge

Ethereum bridge,bridge · multi-chain liquidity aggregation

PLAN

2027

CEDEX v2.0

Full DEX feature parity,parity · institutional trading,trading · dark pools

PLAN

2028

DAO Contracts

Governance,Governance · treasury management,management · proposal system

PLAN

🔹 13.3.2 Infrastructure Scaling

Phase

RPC Capacity

Database

Geographic Regions

Genesis

500 req/sec

10K TPS

3 (US-E,East · US-W,West · EU)

Bootstrap

2,000 req/sec

50K TPS

5 (+ APAC,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:2026 — Initial dual-auditor security certification (Quantstamp + Halborn)
  • Q3 2026:2026 — Bug bounty program launch ($100K initial pool)
  • Q4 2026:2026 — SOC 2 Type I certification
  • 2027:2027 — SOC 2 Type II certification,certification · ISO 27001
  • 2028+: — Formal verification expansion,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,only · unlimited raise,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,received · retail investors can participate

Q4 2027

NASDAQ Listing ($GROO)

Groovy CompanyCompany, Inc. listed on NASDAQ,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,registration · local legal entity

United Kingdom

Q2 2028

FCA

Sandbox participation,participation · full authorization

Singapore

Q3 2028

MAS

Capital Markets Services license

Japan

Q4 2028

FSA/JFSA

Local partnership,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,audits · formal verification,verification · bug bounty

Regulatory Action

LOW

HIGH

Pre-filing SEC meetings,meetings · Digital Securities compliance-first design

Infrastructure Failure

LOW

MEDIUM

Multi-region redundancy,redundancy · automatic failover

Low Initial Adoption

MEDIUM

MEDIUM

Groovy CompanyCompany, Inc. as flagship issuer,issuer · targeted outreach

Market Manipulation

MEDIUM

MEDIUM

Circuit breakers,breakers 36+· 42 Transfer Hooks,Hooks · real-time monitoring

🔹 13.5.2 Rollback Procedures

// Rollback Procedures

interface RollbackProcedures {

/**

  • Emergency rollback framework

*/

// Trigger conditions

triggerConditions: [

'CRITICAL_SECURITY_VULNERABILITY',

'REGULATORY_STOP_ORDER',

'CATASTROPHIC_DATA_CORRUPTION',

'PROLONGED_INFRASTRUCTURE_FAILURE',

];

// Rollback levels

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 protocol

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:Commander — CTO (primary) or CEO (secondary) has full authority during crisis
  • War Room Activation:Activation — Immediate team assembly within 15 minutes of incident detection
  • Communication Cadence:Cadence — Hourly status updates internally,internally · 4-hour updates externally
  • Regulatory Notification:Notification — SEC/FinCEN notification within 24 hours of material incident
  • Post-Incident Review:Review — Mandatory root cause analysis within 72 hours of resolution ✓ Implementation Readiness

✓ 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

Four properties of Solana made it the only viable foundation for OTCM's compliance architecture at launch:

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. It makes compliance enforcement structurally impossible to bypass — not policy-based, not application-layer, but enforced at the token transfer primitive itself. 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

Despite Solana's technical advantages, remaining Solana-only creates real institutional friction:

  • Institutional custody infrastructure (Fireblocks,Fireblocks BitGo,· BitGo · Anchorage) has deeper Ethereum integration than Solana integration
  • 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

The cross-chain roadmap resolves this tension by expanding OTCM's reach to where institutional capital already sits, while maintaining the Solana native architecture as the authoritative compliance and settlement layer.

🔸 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,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 governing all phases: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

Wormhole is the primary interoperability protocol under evaluation for Phase 1. It is Solana-native, battle-tested with $35B+ in cross-chain volume, and is the only major bridge with a formally verified guardian network.

PHASE 1 ARCHITECTURE — WORMHOLE READ BRIDGE:

SOLANA (authoritative layer)
  │
  │  Empire custody oracle publishes signed attestation on Solana
  │  every slot (~400ms)
  │
  ▼
WORMHOLE GUARDIAN NETWORK (19 independent validators)
  │
  │  Guardians observe and sign the custody attestation message
  │  Signed VAA (Verified Action Approval) published to target chain
  │
  ▼
ETHEREUM / BASE / ARBITRUM (read-only consumer)
  │
  │  EVM contract reads signed custody attestation via Wormhole
  │  Can verify: total supply, custodied shares, last update slot
  │  CANNOT execute trades — read-only data relay
  │
  ▼
USE CASE: Institutional investors on EVM chains can verify
1:1 backing WITHOUT bridging assets or moving capital to Solana.
This addresses institutional custody preference without changing
the Solana compliance 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. This is the mechanism under evaluation for Phase 2 wrapped ST22 tokens on EVM chains.

rust

// NTT Architecture — Supply Invariant Maintained Across Chains
//
// Total global supply = Solana supply + SUM(all EVM wrapped supplies)
// Invariant: global_supply <= empire_custodied_shares (always)
//
// When tokens bridge Solana → Ethereum:
//   1. Solana tokens are LOCKED in NTT manager contract (not burned)
//   2. Equivalent wrapped tokens MINTED on Ethereum
//   3. Solana circulating supply DECREASES by bridged amount
//   4. Total global supply unchanged
//
// When tokens bridge Ethereum → Solana:
//   1. Ethereum wrapped tokens BURNED
//   2. Solana tokens UNLOCKED from NTT manager
//   3. Transfer Hook executes on unlock — all 42 controls apply
//
// CRITICAL: Transfer Hooks execute on the Solana unlock transaction.
// This means compliance is enforced on EVERY return from EVM to Solana,
// ensuring no sanctioned or non-KYC wallet can repatriate tokens.

pub struct NttManagerConfig {
    /// Maximum tokens that can exist on any single EVM chain at one time
    pub per_chain_cap: u64,              // Default: 10% of circulating supply
    /// Minimum lock period before bridging back to Solana
    pub bridge_lock_period_slots: u64,   // 25,920 slots = 3 hours minimum
    /// Whether Transfer Hook runs on bridge-out (Solana → EVM)
    pub hook_on_bridge_out: bool,        // true — Hook 1-4 run before lock
    /// Whether Transfer Hook runs on bridge-in (EVM → Solana)
    pub hook_on_bridge_in: bool,         // true — all 42 controls run on unlock
}

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

Phase 3 evaluates whether OTCM's compliance model can be ported to EVM chains without requiring the Wormhole bridge for each transaction. Two approaches are under evaluation:

Option A — ERC-1363 Transfer-and-Call

ERC-1363 extends ERC-20 with a transferAndCall mechanism that invokes a receiver contract on every transfer — the closest EVM analog to SPL Transfer Hooks. Key limitations vs. Transfer Hooks:

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 ERC-1363 compatible

Option B — ERC-3643 Compatibility Layer

ERC-3643 (T-REX) is the leading Ethereum security token standard with $32B+ in deployed assets and completed security audits. Rather than building a custom EVM compliance layer,assets. OTCM is evaluating whether a compatibility wrapper could allow ST22 Digital Securities tokens to be represented as ERC-3643 tokens on Ethereum — inheriting the T-REX compliance infrastructure and institutional distribution network.Ethereum.

Consideration

Assessment

Institutional familiarity

High

— $32B deployed,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 at that time,costs, institutional demand for EVM-native compliance enforcement,demand, and the state of Ethereum's own 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)

Yes✅ — everyEvery transfer

Via Wormhole read relay

Yes — via oracle

OFAC sanctions (Hook 2)

Yes✅ — everyEvery transfer

Application layer only

Partial — gas constrained

AML risk scoring (Hook 3)

Yes✅ — everyEvery transfer

Application layer only

Partial — gas constrained

KYC/accreditation (Hook 4)

Yes✅ — everyEvery transfer

Application layer only

Via ONCHAINID (if ERC-3643)

Circuit breaker (Hook 5)

Yes✅ — everyEvery transfer

Not enforced

Evaluating

LP sufficiency (Hook 6)

Yes✅ — everyEvery transfer

Not applicable

Not applicable

Controls 7–42

Yes✅ — everyEvery 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 RequirementRequirements

Any cross-chain expansion beyond Phase 1 (read-only) requires a DAO governance vote with the following thresholds: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,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

Back to top