PAIR

How PAIR works

$PAIR launched on Pons V2 with a 2.5% creator tax. That tax funds a rolling 30m 0s auction-free distribution: the protocol buys one token and hands it to $PAIR holders, and holders decide which token that is by burning.

The loop
  1. 01
    Trading pays the creator tax

    Every $PAIR trade on Pons pays a base protocol fee to Pons and a 2.5% creator tax. The creator tax accrues in the Pons fee escrow, credited to the distributor wallet.

  2. 02
    The distributor claims and budgets

    At the end of each epoch the worker claims accrued fees, holds back a small gas reserve and treats the rest as the epoch budget.

  3. 03
    It reads the selected reward token

    The reward for an epoch was decided by the burn vote held during the previous epoch. It must still be in the approved registry, and still have liquidity, or the epoch is skipped rather than executed badly.

  4. 04
    It buys, having simulated first

    The purchase is simulated from the distributor address at the current block. The simulated output sets the minimum-out guard, so a bad fill reverts instead of executing.

  5. 05
    It snapshots holders at the purchase block

    Balances are read from chain at the exact block the purchase landed in, checked against the indexer, and frozen. The block number is published on every epoch page.

  6. 06
    It distributes proportionally

    Each eligible holder receives floor(bought × balance ÷ eligible supply) in integer base units. The sub-unit remainder is carried into the next epoch rather than handed to anyone.

  7. 07
    The next epoch opens

    Burns cast during the epoch that just ended are tallied, the winner becomes the next reward, and voting resets.

Burning is permanent

Burning $PAIR is not staking, locking, or depositing. The PairBurnVote contract moves your tokens to 0x…dEaD in the same transaction that records your vote. The contract has no withdrawal function and holds no balance — there is no mechanism, for you or for anyone else, to get burned tokens back.

In exchange, the burn is a permanent, public vote: the event carries the burner, the amount, the candidate and the epoch it applies to, so the entire competition can be rebuilt from logs without trusting this website.

Candidates come from an approved registry mirrored into the contract’s allowlist. An arbitrary contract address cannot be voted for, whether through this site or by crafting a transaction by hand.

Eligibility
Rewards go to every address holding $PAIR at the snapshot block, except:
  • burn sinks (0x0 and 0x…dEaD)
  • the distributor wallet
  • the Pons bonding curve and liquidity pools
  • treasury and protocol contracts
  • any address an operator has explicitly excluded

The eligibility formula is a swappable module, and the module used is recorded on every epoch — so past epochs stay reproducible if the formula ever changes.

Verify it yourself
  • The distributor wallet — live balance, pending fees, and confirmation that Pons really names it as the creator fee recipient.
  • Every epoch page publishes its snapshot block, eligible supply, purchase transaction, distribution transactions and a downloadable recipient CSV.
  • Burns are indexed from contract events, each linked to its transaction.
  • Fee rates on this site are read from the Pons V2 contracts at request time, not hard-coded — the factory is verified before any of them are shown.
Risks
  • Burned $PAIR is destroyed. There is no refund path.
  • Reward tokens are bought at market. Their value can fall to zero after they are distributed.
  • Distribution volume depends entirely on trading volume. Low volume means small or skipped epochs — an epoch with nothing to distribute is recorded as skipped, not dressed up as a distribution of zero.
  • This is experimental software interacting with third-party contracts. Nothing here is financial advice.