No one chooses pairs
Pairing is deterministic and on-chain:- Bucket — Your token’s market cap maps to a bucket (e.g. 30 SOL → 800 SOL in steps). Same formula for everyone; no manual buckets.
- Window — Time is split into slots (e.g. slot / window_size). Everyone in the same slot shares the same window.
- Match key —
Blake3(mint || bucket || window) % match_key_space. Two tokens in the same bucket and same window that collide in this key space form a duel.
No one chooses the winner
Resolution is rule-based and checked on-chain:- When a duel is matched, a target market cap is set (e.g. 110% of the bucket’s reference).
- When any buy or sell causes either token’s post-trade market cap ≥ target, the duel can be resolved.
- The program requires:
winner_mcap >= targetorloser_mcap >= target, andwinner_mcap >= loser_mcap. So the “winner” is always the token with the higher market cap at resolution. The relayer only submits the tx; it cannot assign a different winner—the program rejects it.
What you can trust
| Concern | How it’s handled |
|---|---|
| Who gets paired? | Derived from mcap (bucket), slot (window), and Blake3(mint, bucket, window). No off-chain pairing. |
| Who wins? | Program enforces: target reached and winner_mcap ≥ loser_mcap. Relayer can’t flip the outcome. |
| Mercy rate? | On-chain: loser SOL → winner tokens into mercy vault. Your claim = (vault balance × your loser token balance) / total loser tokens in circulation when the duel resolved. |