💎 Section 12: Tokenomics & Economic Model

// OTCM Token Parameters (TypeScript)

// Supply parameters

// Token standard

// Authority configuration

// On-chain metadata

// 1:1 Backing Structure Implementation

interface BackingStructure {

/**

• 1:1 backing verification system
• Empire Stock Transfer provides real-time attestations

*/

// Backing parameters

backingAsset: {

type: 'PREFERRED_SERIES_M';

issuer: 'Groovy Company, Inc. dba OTCM Protocol,Protocol'; Inc.';

cusip: string;

parValue: 0.001; // $0.001 per share

};

// Custody verification

custody: {

custodian: 'Empire Stock Transfer';

custodyType: 'QUALIFIED_CUSTODY';

auditFrequency: 'MONTHLY';

attestationFrequency: 'EVERY_SOLANA_SLOT'; // ~400ms

};

// Redemption capability

redemption: {

enabled: true;

minimumRedemption: 1000; // 1,000 OTCM minimum

processingTime: '3_5_BUSINESS_DAYS';

deliveryMethod: ['DRS', 'PHYSICAL_CERTIFICATE'];

};

// Backing verification formula
// backingRatio = custodiedShares / circulatingTokens
// Must equal 1.0000 (100%) at all times

requiredRatio: 1.0000;

toleranceRange: 0.0000; // Zero tolerance

}

🔹 12.1.3 Token Technical Specifications

// OTCM Token Mint Configuration (Rust)
// OTCM Token Mint Configuration

pub struct OTCMTokenConfig {

/// Total supply (fixed at genesis)

pub total_supply: u64, // 1_000_000_000_000_000_000 (with decimals)

/// Decimal precision

pub decimals: u8, // 9

/// Token standard extensions

pub extensions: TokenExtensions {

transfer_hook: TransferHook {

program_id: Pubkey, // Hook program address

extra_accounts: Vec<AccountMeta>,

},

metadata: TokenMetadata {

name: String, // "OTCM Protocol Token"

symbol: String, // "OTCM"

uri: String, // Metadata URI

},

},

/// Authority configuration

pub mint_authority: Option<Pubkey>, // None (disabled)

pub freeze_authority: Option<Pubkey>, // Some(compliance_multisig)

}

impl OTCMTokenConfig {

pub fn is_supply_fixed(&self) -> bool {

self.mint_authority.is_none() // True -— no new tokens can be minted

}

}

🔹 12.1.4 Initial Liquidity Pool Configuration

The OTCM token launches with an initial liquidity pool seeded with protocol capital to ensure immediate trading capability:

🔹 12.1.5 Graduation Mechanism

The OTCM token utilizes a bonding curve structure with a graduation threshold, after which it transitions to DEX trading:

🔹 12.1.6 Post-Graduation Token Economics

Upon reaching the graduation threshold, accumulated bonding curve funds are burned and permanently locked in the CPMM liquidity pool:

// Graduation Mechanism Implementation

interface GraduationMechanism {

/**

• Graduation from bonding curve to CPMM LP

*/

// Graduation trigger

trigger: {

metric: 'MARKET_CAP';

threshold: 250_000; // $250,000 USD

checkFrequency: 'EACH_TRADE';

automaticExecution: true;

};

// Migration process

migration: {

// Step 1: Pause bonding curve trading

pauseBondingCurve: true;

// Step 2: Calculate LP allocation

bondingCurveFunds: number; // Accumulated USDC

remainingTokens: number; // Unsold OTCM from curve

// Step 3: Create CPMM pool

cpmmPool: {

usdcSide: bondingCurveFunds;

otcmSide: remainingTokens;

initialK: bondingCurveFunds * remainingTokens;

};

// Step 4: Lock LP tokens permanently

lpTokens: {

recipient: 'BURN_ADDRESS'; // 0x000...dead

lockDuration: 'PERMANENT';

withdrawable: false;

};

};

// Post-graduation state

postGraduation: {

tradingVenue: 'CEDEX_CPMM';

liquidityLocked: true;

priceDiscovery: 'AMM_DRIVEN';

slippageControl: 'CIRCUIT_BREAKER';

};

}

✓ Permanent Liquidity Lock

Lock:

Post-graduation, LP tokens are sent to athe burn address,address — making liquidity withdrawal mathematically impossible. This creates a "rugpull-proof" structure where underlying liquidity can never be extracted by any party.

⏳ 12.2 Token Vesting Schedule

🔹 12.2.1 Vesting Philosophy

OTCM Protocol implements a structured vesting schedule designed to align issuer incentives with long-term token success, prevent market manipulation through sudden large sells, and create predictable supply dynamics that enable informed investment decisions.

"Vesting ensures that token issuers maintain skin-in-the-game throughout the protocol's growth phase. Immediate large-scale selling is structurally impossible, protecting all participants from dump scenarios."

🔹 12.2.2 ST22 Issuer Token Allocation

When issuers mint ST22 tokens (ST22 Security Token 2022s), they receive a fixed allocation subject to the vesting schedule:

🔹 12.2.3 Vesting Timeline

The 60% issuer allocation follows a structured release schedule over 30 months:months:

Total Vestingvesting Period:period: 30 months (time from minting to final release, assuming immediate graduation)

🔹 12.2.4 Vesting Smart Contract Implementation

Version: 6.01 | Implementation: Rust/Anchor on-chain enforcement — Transfer Hook integrated

Vesting is enforced at the Transfer Hook layer (Control 24) — locked tokens cannot be transferred regardless of wallet owner action. There is no administrative override and no grace period. The vesting schedule below is enforced by on-chain state, not policy.

/// On-chain vesting account — one per ST22 issuer allocation
#[account]
pub struct VestingAccount {
    pub version: u8,
    /// The wallet that receives tokens as they unlock
    pub beneficiary:          Pubkey,
    /// The ST22 mint this vesting schedule applies to
    pub mint: Pubkey,
    /// Total tokens allocated to this vesting schedule
    pub total_allocation:     u64,
    /// Tokens claimed so far
    pub total_claimed:        u64,
    /pub claimed_phases:       u8,      // Unix timestamp of graduation eventBitmask — set1 bybit BondingCurveper program on graduation
    /// Zero until graduation occursphase
    pub graduation_timestamp: i64,     /// BitmaskSet ofby whichBondingCurve phaseson have been claimed (bit 0 = phase 1, etc.)graduation
    pub claimed_phases:creation_timestamp:   u8,
    /// Bump seed for PDA derivation
    pub bump: u8,i64,
}

/// Five vesting phases — enforced by Transfer Hook Control 24

#[derive(BorshSerialize, BorshDeserialize, Clone, Copy, PartialEq)]
pub enum VestingPhase {
    Phase1MintCompletion  = 0,  // 20% — immediate at mint
    Phase2Graduation      = 1,  // 20% — at $250K market cap
    Phase3SixMonths       = 2,  // 20% — 6 months post-graduation
    Phase4TwelveMonths    = 3,  // 20% — 12 months post-graduation
    Phase5EighteenMonths  = 4,  // 20% — 18 months post-graduation
}
impl VestingAccount {
    pub const PHASE_ALLOCATION_BPS: u64 = 2000; // 20% per phase (basis points)
    pub const MONTHS_6_SECONDS:  i64 = 15_778_800; // 6 months in seconds
    pub const MONTHS_12_SECONDS: i64 = 31_557_600; // 12 months in seconds
    pub const MONTHS_18_SECONDS: i64 = 47_336_400; // 18 months in seconds

    /// Returns the unlockable amount for a given phase at the current time
    pub fn unlockable_for_phase(
        &self,
        phase: VestingPhase,
        current_timestamp: i64,
    ) -> Result {
        // Already claimed — return zero
        let phase_bit = 1u8 << (phase as u8);
        if self.claimed_phases & phase_bit != 0 {
            return Ok(0);
        }

        let phase_allocation = self.total_allocation
            .checked_mul(Self::PHASE_ALLOCATION_BPS)
            .ok_or(VestingError::Overflow)?
            .checked_div(10_000)
            .ok_or(VestingError::Overflow)?;

        let is_unlocked = match phase {
            VestingPhase::Phase1MintCompletion => true, // Immediate
            VestingPhase::Phase2Graduation => {
                self.graduation_timestamp > 0 // Graduation has occurred
            }
            VestingPhase::Phase3SixMonths => {
                self.graduation_timestamp > 0
                    && current_timestamp >= self.graduation_timestamp
                        .checked_add(Self::MONTHS_6_SECONDS)
                        .ok_or(VestingError::Overflow)?
            }
            VestingPhase::Phase4TwelveMonths => {
                self.graduation_timestamp > 0
                    && current_timestamp >= self.graduation_timestamp
                        .checked_add(Self::MONTHS_12_SECONDS)
                        .ok_or(VestingError::Overflow)?
            }
            VestingPhase::Phase5EighteenMonths => {
                self.graduation_timestamp > 0
                    && current_timestamp >= self.graduation_timestamp
                        .checked_add(Self::MONTHS_18_SECONDS)
                        .ok_or(VestingError::Overflow)?
            }
        };

        if is_unlocked { Ok(phase_allocation) } else { Ok(0) }
    }

    /// Total currently claimable across all phases
    pub fn total_claimable(&self, current_timestamp: i64) -> Result {
        let phases = [
            VestingPhase::Phase1MintCompletion,
            VestingPhase::Phase2Graduation,
            VestingPhase::Phase3SixMonths,
            VestingPhase::Phase4TwelveMonths,
            VestingPhase::Phase5EighteenMonths,
        ];
        phases.iter().try_fold(0u64, |acc, &phase| {
            let unlockable = self.unlockable_for_phase(phase, current_timestamp)?;
            acc.checked_add(unlockable).ok_or(error!(VestingError::Overflow))
        })
    }
}

/// Transfer Hook Control 24 — enforces vesting locks
/// Called by Hook layer before every ST22 transfer
pub fn check_vesting_lock(
    vesting_account: &VestingAccount,
    transfer_amount: u64,
    sender_wallet: &Pubkey,
    current_timestamp: i64,
) -> Result<()> {
    // Only applies to the beneficiary wallet
    if &vesting_account.beneficiary != sender_wallet {
        return Ok(());
    }

    // Calculate how many tokens are currently locked
    let total_unlocked = vesting_account
        .total_claimable(current_timestamp)?
        .checked_add(vesting_account.total_claimed)
        .ok_or(VestingError::Overflow)?;
    let locked_amount = vesting_account.total_allocation
        .saturating_sub(total_unlocked);

    // Reject if transfer would require locked tokens
    // (sender must hold sufficient unlocked balance)
    require!(
        transfer_amount <= vesting_account.total_allocation
            .saturating_sub(locked_amount),
        TransferHookError::TokensLocked  // Error 6024
    );

    Ok(())
}

#[error_code]
pub enum VestingError {
    #[msg("Arithmetic overflow in vesting calculation")]
    Overflow,
    #[msg("Graduation timestamp not yet set — graduation has not occurred")]
    GraduationNotOccurred,
    #[msg("Phase already claimed")]
    AlreadyClaimed,
}

Vesting Schedule Summary

24-Hour Cooldown: Control 23 (velocity limit) enforces a minimum 24-hour gap between vesting claims for the same wallet — preventing rapid sequential claim-and-sell patterns.

🔹 12.2.5 Anti-Dump Mechanisms

Beyond vesting, additional anti-dump mechanisms protect token holders:

• Daily Sell Limit:Limit — Maximum 1% of daily volume can be sold by any single wallet
• Price Impact Circuit Breaker:Breaker — Transactions exceeding 2% price impact are rejected
• Velocity Detection:Detection — Rapid sequential sells from related wallets trigger freeze
• Cool-Down Period:Period — 24-hour minimum between vesting claims

🔹 12.2.6 Vesting Visualization

// Vesting Timeline Visualization
// Visual representation of vesting schedule

Month 0 (Mint) ████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 20%

Month 0+ (Grad) ████████████████████████████████████████░░░░░░░░░░ 40%

Month 6 ████████████████████████████████████████████████░░ 60%

Month 12 ████████████████████████████████████████████████░░ 80%

Month 18 ██████████████████████████████████████████████████ 100%

█ = Unlocked tokens ░ = Locked tokens

Key Events:

├---── Day 0:       Token minting → 20% immediately available
  ├---── Graduation:  $250K MC reached → Additional 20% unlocked
  ├---── +6 months:  Time-based release → Additional 20% unlocked
  ├---── +12 months: Time-based release → Additional 20% unlocked
  └---── +18 months: Final release → All tokens fully vested

// Fee Distribution Mechanism

// Fee calculation

// Distribution split

// Fee collection

Annual Protocol Revenue scales= linearlyDaily withVolume trading× volume.4% The× following365
table illustrates revenue at various volume levels: