Skip to main content
Strike Protocol distributes STRIKE tokens to traders based on their trading activity using an epoch-based emission system. The system rewards larger positions, higher leverage, and longer hold times while maintaining exact distribution fairness.

Overview

Token Supply

1 billion STRIKE tokens distributed over 10 epochs

Distribution Method

Epoch-based with doubling difficulty thresholds

Earning Mechanism

Real-time accumulation while positions are open

Claiming

On-demand claims to user wallets

Token Contract

STRIKE is a standard ERC-20 token deployed on Monad Testnet:
contract StrikeToken is ERC20, Ownable {
    uint256 public constant MAX_SUPPLY = 1_000_000_000 * 1e18; // 1 billion tokens

    constructor(address initialOwner)
        ERC20("Strike Token", "STRIKE")
        Ownable(initialOwner) {
        _mint(initialOwner, MAX_SUPPLY);
    }
}
The entire 1 billion token supply is minted at deployment and held by the protocol controller wallet for distribution.

Epoch System

10 Epochs with Doubling Thresholds

The STRIKE distribution is divided into 10 epochs, each allocating 30 million tokens. Epochs progress based on trading volume with doubling thresholds.
Understanding Base Notional: The base notional threshold represents the position size required to earn the full epoch allocation (30M tokens) when trading at 1000x leverage for 21 days (3 weeks). Lower leverage or shorter hold times earn proportionally less.
EpochTokens AllocatedBase Notional Threshold*Cumulative Tokens
130M$40M30M
230M$80M60M
330M$160M90M
430M$320M120M
530M$640M150M
630M$1.28B180M
730M$2.56B210M
830M$5.12B240M
930M$10.24B270M
1030M$20.48B300M
*At 1000x leverage held for 21 days. Actual earnings scale proportionally with leverage and time.
1

Early Epochs

Epochs 1-3: Easy to complete, bootstrap early adopters with generous rewards
2

Growth Epochs

Epochs 4-7: Moderate difficulty, sustainable distribution as protocol grows
3

Mature Epochs

Epochs 8-10: High thresholds for long-term protocol sustainability

Epoch Progression

An epoch automatically transitions to the next when the total tokens earned across all positions reaches the 30M allocation:
if tokens_earned_this_epoch >= 30_000_000:
    # Mark current epoch as completed
    current_epoch.status = 'completed'
    current_epoch.is_active = False

    # Activate next epoch
    next_epoch.is_active = True
    next_epoch.start_date = now()
Epoch progression is automatic and irreversible. Once an epoch completes, no new tokens can be earned in that epoch.

Token Calculation Formula

The Linear Formula

Tokens are calculated using a linear formula that rewards:
  • Larger positions (higher notional value)
  • Higher leverage (up to 1000x)
  • Longer holding periods (measured in days)
tokens_earned = 30M × (notional / base_notional)
                    × (leverage / 1000)
                    × (days_open / 21)

Formula Components

  • Notional Position
  • Leverage Factor
  • Time Factor
  • Base Notional
Position Size in USD
notional = abs(szi) × current_price
  • szi: Signed size (positive for long, negative for short)
  • Higher notional = more tokens
  • Scales linearly with position size

Calculation Examples

Scenario:
  • Epoch: 1 (base notional = $40M)
  • Position: $10,000 notional
  • Leverage: 1000x
  • Days open: 7 days
Calculation:
tokens = 30M × ($10K / $40M) × (1000 / 1000) × (7 / 21)
       = 30M × 0.00025 × 1.0 × 0.333
       = 2,500 STRIKE tokens
Result: ~2,500 tokens after 1 week
Scenario:
  • Epoch: 5 (base notional = $640M)
  • Position: $50,000 notional
  • Leverage: 100x
  • Days open: 21 days
Calculation:
tokens = 30M × ($50K / $640M) × (100 / 1000) × (21 / 21)
       = 30M × 0.000078125 × 0.1 × 1.0
       = 234.375 STRIKE tokens
Result: ~234 tokens after 3 weeks
Scenario:
  • Epoch: 1 (base notional = $40M)
  • Position: $1,000,000 notional (large trader)
  • Leverage: 1000x (maximum)
  • Days open: 21 days (full period)
Calculation:
tokens = 30M × ($1M / $40M) × (1000 / 1000) × (21 / 21)
       = 30M × 0.025 × 1.0 × 1.0
       = 750,000 STRIKE tokens
Result: 750K tokens (2.5% of epoch allocation)

Real-Time Token Accumulation

Background Calculation Service

Tokens accumulate in real-time while positions are open. A background service runs every 10 seconds to update token balances:
class TokenCalculatorService:
    CALCULATION_INTERVAL = 10  # seconds
    BATCH_SIZE = 100           # positions per cycle

    async def calculate_tokens(position):
        # Calculate time since last update
        days_since_last = (now - position.last_calculated) / 86400

        # Calculate incremental tokens
        new_tokens = calculate_tokens_for_position(
            epoch=current_epoch,
            notional_position=position.notional,
            leverage=position.leverage,
            days_open=days_since_last
        )

        # Update accumulated total
        position.tokens_earned += new_tokens
        position.last_calculated = now
Token calculations are deterministic and verifiable. The same inputs always produce the same output, ensuring fair distribution.

Position Lifecycle

1

Position Opened

  • Token reward record created in database
  • Initial tokens_earned = 0
  • opened_at timestamp recorded
  • Position added to calculation queue
2

Position Active

  • Background service calculates tokens every 10 seconds
  • Tokens accumulate based on formula
  • UI shows real-time balance updates
  • No gas costs for accumulation
3

Position Closed

  • Final token calculation performed
  • tokens_earned becomes final total
  • Tokens move to tokens_settled (claimable)
  • Position removed from active queue
4

Tokens Claimed

  • User initiates claim transaction
  • Atomic database update + blockchain transfer
  • Tokens sent to user’s wallet
  • tokens_claimed recorded permanently

Token Claiming

Claiming Mechanism

Users can claim their settled tokens (from closed positions) at any time:
async def claim_tokens(wallet_address: str):
    # Use atomic stored procedure for race-condition safety
    result = await execute_db_query(
        supabase.rpc('claim_tokens_atomic', {
            'wallet_addr': wallet_address
        })
    )

    claimable_amount = result.data[0]['claimable_amount']

    if claimable_amount > 0:
        # Transfer tokens from controller to user
        tx_result = await transfer_strike_tokens(
            recipient=wallet_address,
            amount=claimable_amount
        )

        return {
            'success': True,
            'tokens_claimed': claimable_amount,
            'tx_hash': tx_result['tx_hash']
        }

Claiming Safety Features

Atomic Claims

Database procedure ensures no double-claiming even under race conditions

Settled Only

Only closed position tokens can be claimed, preventing premature claims

On-Chain Verification

Every claim includes blockchain transaction proving token transfer

Audit Trail

Full claim history recorded with timestamps and transaction hashes

Claim States

StateDescriptionCan Claim?
EarningPosition is open, tokens accumulating❌ No
SettledPosition closed, tokens finalized✅ Yes
ClaimedTokens transferred to wallet✅ Already claimed

Database Schema

Token Rewards Table

CREATE TABLE token_rewards (
    id BIGSERIAL PRIMARY KEY,
    position_id BIGINT UNIQUE NOT NULL,
    wallet_address TEXT NOT NULL,
    symbol TEXT NOT NULL,
    notional_position NUMERIC NOT NULL,
    leverage INTEGER NOT NULL,

    -- Timestamps
    opened_at TIMESTAMPTZ NOT NULL,
    last_calculated_at TIMESTAMPTZ,
    settled_at TIMESTAMPTZ,

    -- Token amounts
    tokens_earned NUMERIC DEFAULT 0,      -- Accumulated while open
    tokens_settled NUMERIC DEFAULT 0,     -- Final amount after close
    tokens_claimed NUMERIC DEFAULT 0,     -- Amount claimed to wallet

    -- Claiming metadata
    claim_tx_hash TEXT,
    claimed_at TIMESTAMPTZ,

    -- Epoch tracking
    epoch_number INTEGER NOT NULL,

    CONSTRAINT fk_position FOREIGN KEY (position_id)
        REFERENCES positions(id) ON DELETE CASCADE
);

Atomic Claim Procedure

CREATE OR REPLACE FUNCTION claim_tokens_atomic(wallet_addr TEXT)
RETURNS TABLE(claimable_amount NUMERIC) AS $$
DECLARE
    total_claimable NUMERIC;
BEGIN
    -- Calculate claimable amount (settled but not claimed)
    SELECT COALESCE(SUM(tokens_settled - tokens_claimed), 0)
    INTO total_claimable
    FROM token_rewards
    WHERE wallet_address = wallet_addr
      AND tokens_settled > tokens_claimed
    FOR UPDATE;  -- Lock rows to prevent race conditions

    -- Mark tokens as claimed
    UPDATE token_rewards
    SET tokens_claimed = tokens_settled,
        claimed_at = NOW()
    WHERE wallet_address = wallet_addr
      AND tokens_settled > tokens_claimed;

    RETURN QUERY SELECT total_claimable;
END;
$$ LANGUAGE plpgsql;

Security & Fairness

Fair Distribution Guarantees

1

Deterministic Formula

Same inputs always produce same outputs - no randomness or favoritism
2

Time-Based Accumulation

Longer holds earn proportionally more - rewards commitment
3

Leverage Weighting

Higher risk (leverage) earns more - fair risk/reward ratio
4

Epoch Boundaries

Clear thresholds prevent manipulation of distribution timing

Anti-Abuse Measures

No Double Claiming

Atomic database procedure prevents claiming the same tokens twice

Settled-Only Claims

Open positions cannot be claimed, preventing premature withdrawals

On-Chain Verification

All transfers verified on blockchain, creating immutable audit trail

Position Validation

Only real trading positions earn tokens, not fake records

Precision & Rounding

All token calculations use Decimal arithmetic with ROUND_DOWN to prevent over-allocation:
from decimal import Decimal, ROUND_DOWN

def _decimal_to_token_units(amount: Decimal, decimals: int) -> int:
    """Convert Decimal to token units (18 decimals for STRIKE)."""
    scaling_factor = Decimal(10) ** decimals
    return int((amount * scaling_factor).to_integral_value(rounding=ROUND_DOWN))
This ensures the protocol never distributes more tokens than allocated for each epoch.

Integration with Trading

Position Creation

When a trader opens a position, the token reward system automatically:
  1. Creates token reward record with initial state
  2. Records epoch number, notional, leverage
  3. Sets opened_at timestamp for time tracking
  4. Adds position to calculation queue
await create_token_reward_record(
    position_id=position_id,
    wallet_address=wallet_address,
    symbol=symbol,
    notional_position=notional,
    leverage=leverage,
    opened_at=datetime.utcnow()
)

Position Closure

When a position closes, the system:
  1. Performs final token calculation
  2. Moves tokens from tokens_earned to tokens_settled
  3. Records settled_at timestamp
  4. Removes from active calculation queue
await finalize_token_rewards_for_position(
    position_id=position_id,
    close_time=datetime.utcnow()
)

UI Display

The frontend shows real-time token balances:
  • Active Positions: Shows accumulating tokens_earned (updates every 10s)
  • Closed Positions: Shows final tokens_settled amount
  • Claim Button: Enabled when tokens_settled > tokens_claimed

API Endpoints

Get Token Balance

GET /tokens/{wallet_address}
Response:
{
  "wallet_address": "0x123...",
  "total_earned": "125000.50",
  "total_settled": "100000.00",
  "total_claimed": "50000.00",
  "claimable": "50000.00",
  "earning": "25000.50",
  "positions": [
    {
      "position_id": 42,
      "symbol": "BTC-PERP",
      "tokens_earned": "25000.50",
      "status": "open"
    }
  ]
}

Claim Tokens

POST /tokens/claim
Authorization: Bearer <wallet_signature>
Request:
{
  "wallet_address": "0x123..."
}
Response:
{
  "success": true,
  "tokens_claimed": "50000.00",
  "tx_hash": "0xabc...",
  "gas_used": 65000
}

Token Economics

Distribution Timeline

Based on current testnet activity, estimated epoch completion times:
EpochThresholdEst. CompletionCumulative Distribution
1$40M1-2 months3%
2$80M3-4 months6%
3$160M6-8 months9%
4-6320M320M-1.28B1-2 years18%
7-102.56B2.56B-20.48B3-5 years30%
Note: Only 300 million tokens (30% of total supply) are distributed through the epoch system. The remaining 700 million tokens are reserved for:
  • Team allocation
  • Treasury reserves
  • Future incentive programs
  • Strategic partnerships

Value Accrual

STRIKE token value accrues through:
  1. Governance Rights: Future DAO governance over protocol parameters
  2. Fee Discounts: Reduced trading fees for STRIKE holders
  3. Staking Rewards: Stake tokens to earn protocol revenue share
  4. Scarcity: Fixed 1B supply with decreasing emission rate

Future Enhancements

The STRIKE token rewards system is designed to evolve with the protocol. Planned enhancements include:

Loss Cashback Mechanism

Coming Soon

Additional token bonuses for losing trades to improve trader retention and reduce churn during difficult market conditions.STRIKE tokens may offer bonus distributions to traders who experience losses, ensuring even unsuccessful traders receive protocol value and incentivizing continued participation. For example, traders could receive bonus tokens proportional to their realized losses (e.g., 0.5 tokens per dollar lost).This creates a more sustainable ecosystem where traders are rewarded for activity regardless of P&L outcomes.

Treasury-Based Bonus Emissions

Under Consideration

Increased token emissions during low-liquidity periods when treasury reserves are constrained and payout reliability is uncertain.During periods when the protocol treasury is below optimal levels or when payout processing faces uncertainty, bonus STRIKE token emissions could compensate traders for elevated risk. This mechanism would:
  • Automatically adjust based on treasury health metrics
  • Provide additional compensation when system risk is higher
  • Maintain trader confidence during protocol growth phases
  • Create natural economic incentives to participate during bootstrapping periods
This ensures the token distribution adapts dynamically to protocol conditions, rewarding early supporters who trade during less certain times.
Note: These features are in planning stages and not yet implemented. Token economics and distribution formulas are subject to change based on protocol governance and community feedback.

Best Practices for Traders

Maximizing Token Earnings

Hold Longer

Tokens accumulate over time - longer holds earn more

Use Leverage

Higher leverage positions earn tokens faster (up to 1000x)

Size Matters

Larger positions earn proportionally more tokens

Early Epochs

Earlier epochs have lower thresholds, easier to earn

Strategic Timing

  • Early Epochs (1-3)
  • Mid Epochs (4-7)
  • Late Epochs (8-10)
  • Easiest to earn with low base notional
  • Best time for smaller traders to accumulate
  • Higher percentage of epoch allocation per position

Summary: The STRIKE token system rewards active traders with a fair, deterministic, and secure distribution mechanism. Tokens accumulate in real-time based on position size, leverage, and hold time, with automatic epoch progression ensuring sustainable long-term distribution.