Mechanics documentation

How $TICKET
works.

$TICKET is a Solana meme coin with a fee-funded USDC reward cycle built into the token experience. Buy and hold to qualify. Eligible holders are automatically included in recurring reward events funded by trading activity.

Rewards
USDC
Action
Hold
Entries
Live
Design
Fair

Overview

$TICKET turns token activity into recurring USDC reward events. Instead of inflationary token emissions, the reward pool is designed to be funded from trading-related fees and protocol-controlled routing.

Simple user loop: buy $TICKET, hold enough to qualify, stay eligible for recurring reward events, and if selected in a successful event, USDC is sent automatically.
No claim buttonNo staking pageFee-funded poolDynamic entries

Core principles

No claiming

Eligible rewards are intended to be sent automatically. Users should not need to claim, register, stake, or manually trigger reward collection.

Fee-funded rewards

The USDC reward pool is designed to come from trading-related fees and protocol routing, not from additional $TICKET emissions.

Holders stay in the cycle

The basic action is holding $TICKET. The system is designed to keep holders engaged across recurring reward events rather than forcing constant manual interaction.

Size helps, but does not own the board

Larger holders can receive more reward weight, but the balance curve is designed so oversized wallets face diminishing odds efficiency beyond the target zone.

Reward events

Each reward event checks the current pool, holder state, eligible wallets, and event conditions. An event can pay selected eligible wallets, or it can roll forward so some or all of the pool carries into a future event.

Why rollovers matter: a carried-forward pool can make the next event larger, more visible, and more exciting.

Dynamic entry size

$TICKET does not rely on one permanent fixed entry size. Entry size can update live based on the state of the token economy.

entry_size = adaptive_function(eligible_supply, eligible_holders, burn_state, game_state) updates: live / per reward cycle inputs: holder count · eligible supply · concentration · pool state

The entry engine is designed to respond to eligible holders, eligible supply, burns, and live token conditions. As the holder base grows, the system can make token-entry thresholds more accessible while also making the reward board more competitive.

  • Eligible supply affects how many tokens represent one entry.
  • Eligible holder count affects how crowded the board is.
  • Burn state can reduce the supply base used by the model.
  • Game state can adjust tuning as pools roll, volume changes, and reward events mature.
Public read: entry size is live. Early holders get more time to build position. Later holders may see cheaper token-entry thresholds, but they join a more competitive game.

Early holders vs later holders

Early holders

Early holders may have more time to build entries, holder history, and compounding behavior before the game becomes more crowded. Their main edge is time in the system.

Later holders

Later holders may benefit from a more proven system, more visible reward history, and potentially cheaper token-entry thresholds, but they enter a more competitive board.

The tradeoff: buying early can provide more time to build position. Buying later may offer clearer proof and cheaper entries, but more competition.

Free entry route

$TICKET will include a no-purchase entry route before live rewards begin. The current campaign design is simple: connect a wallet, connect X through a safe OAuth flow, publish the qualifying campaign post, and keep that post live through draw time.

Core rule: free entries must have equivalent odds per entry. They cannot be fake entries, lower-weight entries, or a token gate disguised as openness.

Cadence

Users must be able to participate for free at least once every 12 hours, subject to published limits, abuse checks, and jurisdiction terms.

Entry amount model

The campaign can award a dynamic number of free entries based on disclosed market-activity bands. A practical model is based on 12-hour volume-to-market-cap turnover: lower activity can award more free entries to help distribution and attention; higher activity can award fewer because the system is already active.

example public ladder: 12h turnover ≤ 5% → 5 free entries 12h turnover ≤ 10% → 4 free entries 12h turnover ≤ 25% → 3 free entries 12h turnover ≤ 50% → 2 free entries 12h turnover > 50% → 1 free entry anti-swamp cap: disclosed free-entry pool cap per draw window

If the free-entry pool approaches the disclosed cap, the system should stop issuing new free entries for that period or lower the next period's entries. It should not secretly discount already-issued free entries, because equivalent odds per entry is the point.

X post verification

A qualifying X post must still be published and publicly verifiable at draw time. If a selected free-entry wallet's connected X account deleted the post, made it private, or fails verification, that entry is ineligible and the draw redraws until an eligible participant is selected.

Legal note

This is a product-design summary, not legal advice. Final AMOE/sweepstakes terms, eligibility, jurisdiction restrictions, and disclosures should be reviewed before live rewards.

Balance curve

$TICKET should reward meaningful holders without letting a single oversized wallet dominate the reward cycle.

The design uses a target balance zone. Up to the target zone, balance can count strongly. After that zone, additional $TICKET can still improve positioning, but with diminishing odds efficiency. The goal is not to punish large holders. The goal is to keep the board attractive for strong holders without letting one oversized position make the game feel pointless for everyone else.

balance_score = curve(wallet_share, eligible_supply) strong zone: up to the target concentration band diminishing zone: oversized balances still count, but less efficiently
  • Small and mid-sized holders remain meaningfully competitive.
  • Strong holders can still improve their position with size.
  • Oversized holders face diminishing odds efficiency instead of unlimited dominance.
  • The curve can be tuned over time to reduce farming and keep the board healthy.
Result: larger holders still matter. They just do not get infinite proportional dominance from holding too much supply in one wallet.

Holder score

Entries are the simple public layer. Holder score is the deeper quality layer. A wallet’s reward weight can consider balance, current entries, holding duration, compounding behavior, wallet behavior quality, and exclusion rules.

holder_score inputs: - balance strength - entry count - time held - compounding behavior - wallet quality checks - protocol exclusions

The exact weighting does not need to expose every constant, but the system should still be auditable. Public users will be able to see visible score components, understand what improves eligibility, and verify after each event that wallets were scored consistently against the published rules.

Design goal: reward real holders, make behavior matter, and keep the system harder to game without asking users to trust a black box.

Burns, rollovers, and supply

Burns or protocol-controlled supply reduction can support the system by reducing eligible supply and changing entry dynamics. Rollovers can carry reward pools forward, making future events larger and more visible.

Supply can shrinkEntries can updatePools can rollNext event can grow

Tokenomics and fee routing

$TICKET is designed around a simple economic loop: token activity funds the reward game, the reward game creates anticipation, and anticipation gives holders a reason to stay active instead of treating the token like a one-and-done chart trade.

The launch configuration will route trading-related fees into public buckets before live rewards begin:

  • USDC reward pool: funds recurring reward events for eligible holders.
  • Burn / supply reduction: can reduce eligible supply and support the entry model.
  • Liquidity and market health: supports the token’s ability to trade cleanly as attention moves in waves.
  • Operations and infrastructure: pays for indexers, automation, distribution, monitoring, proof dashboards, and maintenance.
  • Growth / treasury: supports marketing, ecosystem distribution, and future protocol development.
Commitment: before live rewards begin, the launch configuration should publish the active fee routing, reward-pool address, reserve routing, exclusion policy, contract address, and proof dashboard. The public docs explain the mechanism; the live config proves the current numbers.

Distribution reserve

Reward pages will separate gross pool, net payout, and reserve retained before live rewards begin. The headline number should not pretend every USDC in the pool is being paid in the current event if part of it is reserved for future cycles.

This reserve is intentional. A reward system that pays out 100% of every pool with no reserve can become fragile during quiet periods. A distribution reserve gives the game more ways to stay alive between attention spikes.

Reserve proceeds can be routed toward:

  • future reward pools or rollover support;
  • burns or supply-control actions;
  • automation and distributor costs;
  • proof, monitoring, and security infrastructure;
  • treasury or growth programs if publicly configured.
gross_pool → distribution_event → net_rewards + protocol_reserve reserve use: future pools · burns · infrastructure · growth · market health

Users should care about all three numbers: the visible pool creates anticipation, the net distribution shows what was actually paid, and the retained reserve shows what stays in the system.

Transparency and verification

$TICKET will not ask holders to accept unverifiable discretion once live rewards begin. The system can keep anti-farming constants private while still publishing enough proof for users to check whether events were run correctly.

Before live rewards

  • Contract address: published once the live token is deployed.
  • Reward-pool address: published so users can verify USDC inflows and outflows.
  • Fee routing: current live percentages published in the launch configuration before rewards begin.
  • Eligibility rules: minimum requirements, exclusion categories, and score components shown in plain English.
  • Randomness method: the draw source and event process documented before payouts begin.
  • Proof dashboard: each event will show snapshot hash, eligible-wallet count, gross pool, net payout, reserve retained, selected wallets, payout transactions, and excluded wallets with reasons.

What can stay private

Exact score weights, anti-farming thresholds, and tuning constants can remain unpublished if revealing them would make farming easier. That does not mean outcomes should be arbitrary. The commitment is: public rules, public event records, public payout transactions, and enough post-event evidence to detect manipulation.

Trust model: if v1 uses an off-chain indexer or distributor, that will be stated clearly. The proof dashboard exists so users can verify what happened instead of trusting a marketing paragraph.

Hit chance and burn rate

Reward events do not need to behave like a flat lottery. Hit chance can respond to live game conditions.

A practical public model:

  • More burn pressure can improve the system’s willingness to release value because supply is being reduced.
  • More rollovers can increase anticipation and make a future hit more meaningful.
  • More pool growth can create a stronger reason for holders to stay engaged.
  • Lower activity periods can preserve pool value instead of forcing weak payouts that nobody notices.
  • Transparent event records can show whether payouts, reserves, and rollovers matched the public configuration.
hit_chance = adaptive_function(pool_state, burn_state, rollover_count, volume_state) public principle: burns and healthy activity can make hits more attractive; rollovers can make the next event louder.

The exact tuning does not need to expose every parameter, but every completed event should be reviewable. The important idea is that the system can link supply reduction, pool growth, and payout timing into one game loop while publishing enough evidence for holders to verify the result.

Why the game can work in lower volume

Most meme coins get weaker when volume slows because there is nothing left to watch except the chart. $TICKET is designed to keep a visible game state even when volume is not at peak levels.

Lower-volume periods can still matter because:

  • pools can carry forward instead of being wasted on forgettable payouts;
  • entry size can keep updating as holders and supply change;
  • burns can change future entry dynamics;
  • larger carried-forward pools can create more attention-worthy reward moments for eligible holders;
  • visible pool growth can bring attention back when the next event becomes attractive.
The reflexive loop: quiet period → pool/rollover builds → event becomes more interesting → holders and buyers return → volume improves → pool gets funded again.

This is what makes $TICKET more thought-out than a simple attention token. The game is designed to create reasons for attention to come back.

Plain-language summary

$TICKET is a Solana meme coin with a fee-funded USDC reward game built around holding. Trading-related fees can fund recurring reward events for eligible wallets. Holders do not need to claim, stake, or manually enter. If a wallet is eligible and selected in a successful event, USDC rewards are intended to be sent automatically.

The design includes dynamic entry sizing, holder-score components, rollover pools, fee-funded rewards, reserve routing, burn-linked game state, and balance-concentration controls for oversized holders. Some anti-farming constants may remain private, but live events will publish proof: pool balances, snapshots, eligibility counts, selected wallets, reserves, exclusions, and payout transactions.

$TICKET is still experimental, market-dependent, and execution-dependent. It can be more structured than a typical attention-only meme coin without removing crypto risk, reward variability, or regulatory uncertainty.

This is not financial advice and does not guarantee profit.

Risk notes

$TICKET involves crypto-market risk and experimental token mechanics. Important risks include token volatility, low-volume periods, reward pool variability, smart-contract or infrastructure risk, off-chain indexer or distributor risk if used, regulatory uncertainty around chance-based reward systems, possible farming or Sybil behavior, and execution risk during launch.

If contract addresses, fee routing, randomness method, audits, team information, or proof dashboards are not yet published, users should treat the system as pre-launch documentation rather than verified live infrastructure.

Users should only participate with risk they understand.

FAQ

Do I need to claim rewards?

No. The goal is automatic redistribution to eligible wallets when rewards are paid.

Do I need to stake?

No. The core design is based on holding $TICKET, not staking into a separate contract.

Can I enter without buying $TICKET?

Yes. Before live rewards begin, $TICKET will publish a no-purchase free-entry route. The current design uses X sharing with safe account connection, a 12-hour participation cadence, equivalent odds per entry, and draw-time post verification.

Where do rewards come from?

Rewards are designed to come from trading-related fees and protocol-controlled routing into a USDC reward pool.

Does buying more $TICKET help?

Yes, larger holders can have stronger positioning. However, the system can use a diminishing odds curve after the target zone so oversized wallets do not dominate the board unfairly.

Is there a fixed entry size?

Entry size can be dynamic. It can update based on eligible supply, holder count, and live game state.

Is earlier better?

Earlier holders may have more time to build entries, holder history, and compounding behavior before the game becomes more crowded. Later users may still benefit from cheaper token-entry thresholds and more visible proof of the system.

Is profit guaranteed?

No. $TICKET is experimental and rewards depend on volume, eligibility, event outcomes, protocol execution, and market behavior.