> ## Documentation Index
> Fetch the complete documentation index at: https://docs.strike.markets/llms.txt
> Use this file to discover all available pages before exploring further.

# $STK Distribution

> Epoch-based token distribution system that rewards trading activity with STRIKE tokens

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

<CardGroup cols={2}>
  <Card title="Token Supply" icon="layer-group">
    **1 billion STRIKE tokens** distributed over 10 epochs
  </Card>

  <Card title="Distribution Method" icon="calendar">
    **Epoch-based** with doubling difficulty thresholds
  </Card>

  <Card title="Earning Mechanism" icon="chart-line">
    **Real-time accumulation** while positions are open
  </Card>

  <Card title="Claiming" icon="hand-holding-dollar">
    **On-demand claims** to user wallets
  </Card>
</CardGroup>

## Token Contract

STRIKE is a standard **ERC-20 token** deployed on Monad Testnet:

```solidity theme={null}
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);
    }
}
```

<Info>
  The entire 1 billion token supply is minted at deployment and held by the protocol controller wallet for distribution.
</Info>

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

<Info>
  **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.
</Info>

| Epoch  | Tokens Allocated | Base Notional Threshold\* | Cumulative Tokens |
| ------ | ---------------- | ------------------------- | ----------------- |
| **1**  | 30M              | \$40M                     | 30M               |
| **2**  | 30M              | \$80M                     | 60M               |
| **3**  | 30M              | \$160M                    | 90M               |
| **4**  | 30M              | \$320M                    | 120M              |
| **5**  | 30M              | \$640M                    | 150M              |
| **6**  | 30M              | \$1.28B                   | 180M              |
| **7**  | 30M              | \$2.56B                   | 210M              |
| **8**  | 30M              | \$5.12B                   | 240M              |
| **9**  | 30M              | \$10.24B                  | 270M              |
| **10** | 30M              | \$20.48B                  | 300M              |

<sub>\*At 1000x leverage held for 21 days. Actual earnings scale proportionally with leverage and time.</sub>

<Steps>
  <Step title="Early Epochs">
    **Epochs 1-3**: Easy to complete, bootstrap early adopters with generous rewards
  </Step>

  <Step title="Growth Epochs">
    **Epochs 4-7**: Moderate difficulty, sustainable distribution as protocol grows
  </Step>

  <Step title="Mature Epochs">
    **Epochs 8-10**: High thresholds for long-term protocol sustainability
  </Step>
</Steps>

### Epoch Progression

An epoch automatically transitions to the next when the total tokens earned across all positions reaches the 30M allocation:

```python theme={null}
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()
```

<Warning>
  Epoch progression is **automatic** and **irreversible**. Once an epoch completes, no new tokens can be earned in that epoch.
</Warning>

## 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)

```python theme={null}
tokens_earned = 30M × (notional / base_notional)
                    × (leverage / 1000)
                    × (days_open / 21)
```

### Formula Components

<Tabs>
  <Tab title="Notional Position">
    **Position Size in USD**

    ```python theme={null}
    notional = abs(szi) × current_price
    ```

    * `szi`: Signed size (positive for long, negative for short)
    * Higher notional = more tokens
    * Scales linearly with position size
  </Tab>

  <Tab title="Leverage Factor">
    **Position Leverage (1-1000)**

    ```python theme={null}
    leverage_multiplier = leverage / 1000
    ```

    * Base leverage: 1000x (100% of allocation)
    * 500x leverage = 50% of potential tokens
    * 100x leverage = 10% of potential tokens
    * Lower leverage = slower accumulation
  </Tab>

  <Tab title="Time Factor">
    **Days Position is Open**

    ```python theme={null}
    time_multiplier = days_open / 21
    ```

    * Base duration: 21 days (3 weeks)
    * 21 days open = 100% time allocation
    * 7 days open = 33.3% time allocation
    * Accumulates continuously (fractional days)
  </Tab>

  <Tab title="Base Notional">
    **Epoch Difficulty**

    ```python theme={null}
    base_notional = $40M × 2^(epoch - 1)
    ```

    * Doubles each epoch
    * Epoch 1: \$40M
    * Epoch 2: \$80M
    * Epoch 3: \$160M
    * Higher epochs = harder to earn
  </Tab>
</Tabs>

### Calculation Examples

<AccordionGroup>
  <Accordion title="Example 1: Early Epoch, High Leverage">
    **Scenario:**

    * Epoch: 1 (base notional = \$40M)
    * Position: \$10,000 notional
    * Leverage: 1000x
    * Days open: 7 days

    **Calculation:**

    ```python theme={null}
    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
  </Accordion>

  <Accordion title="Example 2: Later Epoch, Lower Leverage">
    **Scenario:**

    * Epoch: 5 (base notional = \$640M)
    * Position: \$50,000 notional
    * Leverage: 100x
    * Days open: 21 days

    **Calculation:**

    ```python theme={null}
    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
  </Accordion>

  <Accordion title="Example 3: Maximum Efficiency">
    **Scenario:**

    * Epoch: 1 (base notional = \$40M)
    * Position: \$1,000,000 notional (large trader)
    * Leverage: 1000x (maximum)
    * Days open: 21 days (full period)

    **Calculation:**

    ```python theme={null}
    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)
  </Accordion>
</AccordionGroup>

## 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:

```python theme={null}
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
```

<Info>
  Token calculations are **deterministic** and **verifiable**. The same inputs always produce the same output, ensuring fair distribution.
</Info>

### Position Lifecycle

<Steps>
  <Step title="Position Opened">
    * Token reward record created in database
    * Initial `tokens_earned = 0`
    * `opened_at` timestamp recorded
    * Position added to calculation queue
  </Step>

  <Step title="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
  </Step>

  <Step title="Position Closed">
    * Final token calculation performed
    * `tokens_earned` becomes final total
    * Tokens move to `tokens_settled` (claimable)
    * Position removed from active queue
  </Step>

  <Step title="Tokens Claimed">
    * User initiates claim transaction
    * Atomic database update + blockchain transfer
    * Tokens sent to user's wallet
    * `tokens_claimed` recorded permanently
  </Step>
</Steps>

## Token Claiming

### Claiming Mechanism

Users can claim their **settled tokens** (from closed positions) at any time:

```python theme={null}
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

<CardGroup cols={2}>
  <Card title="Atomic Claims" icon="shield-check">
    Database procedure ensures **no double-claiming** even under race conditions
  </Card>

  <Card title="Settled Only" icon="lock">
    Only **closed position tokens** can be claimed, preventing premature claims
  </Card>

  <Card title="On-Chain Verification" icon="link">
    Every claim includes **blockchain transaction** proving token transfer
  </Card>

  <Card title="Audit Trail" icon="clipboard-list">
    Full **claim history** recorded with timestamps and transaction hashes
  </Card>
</CardGroup>

### Claim States

| State       | Description                           | Can Claim?        |
| ----------- | ------------------------------------- | ----------------- |
| **Earning** | Position is open, tokens accumulating | ❌ No              |
| **Settled** | Position closed, tokens finalized     | ✅ Yes             |
| **Claimed** | Tokens transferred to wallet          | ✅ Already claimed |

## Database Schema

### Token Rewards Table

```sql theme={null}
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

```sql theme={null}
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

<Steps>
  <Step title="Deterministic Formula">
    Same inputs always produce same outputs - no randomness or favoritism
  </Step>

  <Step title="Time-Based Accumulation">
    Longer holds earn proportionally more - rewards commitment
  </Step>

  <Step title="Leverage Weighting">
    Higher risk (leverage) earns more - fair risk/reward ratio
  </Step>

  <Step title="Epoch Boundaries">
    Clear thresholds prevent manipulation of distribution timing
  </Step>
</Steps>

### Anti-Abuse Measures

<CardGroup cols={2}>
  <Card title="No Double Claiming" icon="ban">
    Atomic database procedure prevents claiming the same tokens twice
  </Card>

  <Card title="Settled-Only Claims" icon="hourglass">
    Open positions cannot be claimed, preventing premature withdrawals
  </Card>

  <Card title="On-Chain Verification" icon="search">
    All transfers verified on blockchain, creating immutable audit trail
  </Card>

  <Card title="Position Validation" icon="badge-check">
    Only real trading positions earn tokens, not fake records
  </Card>
</CardGroup>

### Precision & Rounding

All token calculations use **Decimal arithmetic** with **ROUND\_DOWN** to prevent over-allocation:

```python theme={null}
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

```python theme={null}
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

```python theme={null}
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

```http theme={null}
GET /tokens/{wallet_address}
```

**Response:**

```json theme={null}
{
  "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

```http theme={null}
POST /tokens/claim
Authorization: Bearer <wallet_signature>
```

**Request:**

```json theme={null}
{
  "wallet_address": "0x123..."
}
```

**Response:**

```json theme={null}
{
  "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:

| Epoch | Threshold      | Est. Completion | Cumulative Distribution |
| ----- | -------------- | --------------- | ----------------------- |
| 1     | \$40M          | 1-2 months      | 3%                      |
| 2     | \$80M          | 3-4 months      | 6%                      |
| 3     | \$160M         | 6-8 months      | 9%                      |
| 4-6   | $320M-$1.28B   | 1-2 years       | 18%                     |
| 7-10  | $2.56B-$20.48B | 3-5 years       | 30%                     |

<Info>
  **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
</Info>

### 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

<Card title="Coming Soon" icon="shield-heart">
  **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.
</Card>

### Treasury-Based Bonus Emissions

<Card title="Under Consideration" icon="vault">
  **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.
</Card>

<Warning>
  **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.
</Warning>

## Best Practices for Traders

### Maximizing Token Earnings

<CardGroup cols={2}>
  <Card title="Hold Longer" icon="clock">
    Tokens accumulate over time - longer holds earn more
  </Card>

  <Card title="Use Leverage" icon="arrow-trend-up">
    Higher leverage positions earn tokens faster (up to 1000x)
  </Card>

  <Card title="Size Matters" icon="chart-column">
    Larger positions earn proportionally more tokens
  </Card>

  <Card title="Early Epochs" icon="bolt">
    Earlier epochs have lower thresholds, easier to earn
  </Card>
</CardGroup>

### Strategic Timing

<Tabs>
  <Tab title="Early Epochs (1-3)">
    * **Easiest to earn** with low base notional
    * Best time for **smaller traders** to accumulate
    * Higher percentage of epoch allocation per position
  </Tab>

  <Tab title="Mid Epochs (4-7)">
    * **Balanced difficulty** for growing protocol
    * Good for **medium-sized positions**
    * Sustainable long-term earning rate
  </Tab>

  <Tab title="Late Epochs (8-10)">
    * **Highest thresholds** require significant volume
    * Best for **institutional traders**
    * Long-term protocol maturity phase
  </Tab>
</Tabs>

***

<Info>
  **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.
</Info>