Skip to main content

Rewards Program

Speculite rewards the behavior that improves market quality: tight liquidity, real execution, and high-quality market creation.

All rewards are funded from taker fees.

Program Tracks​

1) Maker Rewards (Liquidity Rewards)​

Makers earn from a configured share of taker fees when their resting liquidity gets filled.

Primary drivers:

  • fills near midpoint
  • meaningful executed size
  • sustained contribution over payout windows

2) Creator Rewards​

Market creators receive a configured share of taker-fee flow generated by their markets.

This rewards creators who launch markets that attract real trading activity.

Funding Model​

At trade level:

  1. trade executes
  2. taker fee is collected
  3. configured shares are allocated to maker and creator pools
  4. remaining amount stays in protocol treasury

Maker Reward Methodology​

Maker contribution is tracked with a fee-equivalent weighting:

fee_equivalent = size * price * k * (price * (1 - price))^2

Where:

  • size = executed fill size
  • price = executed probability price
  • k = configurable program parameter

Each maker receives a pro-rata share of the maker pool based on total fee-equivalent contribution in the payout period.

Creator Reward Methodology​

Creator rewards are attributed from taker-fee flow generated by markets they created.

Conceptually:

creator_reward = taker_fee_usdc * creator_share

Rewards are aggregated across each creator's markets within the payout period.

Example Calculation (Illustrative)​

Assume:

  • taker fill notional = $2,500
  • taker fee = 0.8%
  • maker reward share = 20% of taker fee
  • creator reward share = 50% of taker fee

Then:

  • taker fee = $2,500 * 0.008 = $20
  • maker pool contribution = $20 * 0.20 = $4
  • creator pool contribution = $20 * 0.50 = $10
  • remaining protocol share = $6

Payout Lifecycle​

  1. collect confirmed trades
  2. aggregate maker + creator reward ledgers
  3. finalize payout period
  4. execute payouts from fee collector
  5. record statuses and failures

Statuses typically progress as:

  • OPEN -> FINALIZED -> PAID

Operational Safeguards​

  • dry-run mode before transfers
  • max payout caps (circuit breaker)
  • dust threshold filtering
  • explicit failure reason tracking
  • retry flows for failed payouts

Common failure codes:

  • INSUFFICIENT_BALANCE
  • BAD_WALLET
  • RPC_ERROR

User Visibility​

Users can track rewards through:

  • in-app rewards surfaces
  • public metadata endpoints (program config, leaderboard, epochs)

Public Program Endpoints​

  • GET /api/rewards/program
  • GET /api/rewards/leaderboard
  • GET /api/rewards/epochs

See Developer Guide for full request/response examples.

Rewards FAQ​

Do all limit orders earn rewards?​

Only filled maker liquidity contributes to payouts under the current model.

Does closer-to-mid liquidity matter?​

Yes. Execution quality near midpoint receives stronger weighting through fee-equivalent contribution.

Are rewards paid in real time?​

No. Rewards are aggregated by payout periods and then finalized and paid.

What happens if a payout fails?​

Failures are recorded with reason codes and can be retried after remediation.

Can reward parameters change?​

Yes. Program parameters are configurable and may evolve as market conditions change.