ParityParity

How Parity works

A complete description of the launch flow, where the fees come from, how the keeper sizes and executes its buys, and what it will not do.

01

Overview

Parity launches one coin on two chains at once: a pump.fun coin on Solana and a Flap tax token on BNB Chain. Both have a fixed supply of one billion, so if their prices match, their market caps match. Parity's job is to keep them matched.

It does that with the fees the coin already generates. pump.fun pays a creator fee on every curve trade, and Flap tax tokens take a configurable tax on every buy and sell. Both flow to wallets Parity controls. A keeper process watches the two market caps and, whenever one falls outside a band around the other, spends that chain's accrued fees buying the cheaper side back up.

The keeper only ever buys, and burns what it buys. It never sells either side, so it can never push a price down or dump on holders, and every rebalance shrinks supply.
02

Launching a pair

You need one wallet: a Solana wallet such as Phantom. The BNB side is created by Parity's own wallet. The flow from the Launch page:

  1. 1
    Fill in the token
    Name, ticker, description, image and optional links. The same metadata is used on both chains.
  2. 2
    Choose a dev buy
    An optional SOL amount you pay from your own wallet. There is no BNB dev buy: the Parity wallet only ever pays the BNB creation gas, never a position.
  3. 3
    Set the band
    How far apart the two market caps may drift before the keeper steps in (default ±3%). Fees are fixed: 1% on both chains.
  4. 4
    Sign once
    The server builds a pump.fun create_v2 transaction, pre-signed by the new mint, and your wallet signs it as payer. The server broadcasts it.
  5. 5
    BNB follows automatically
    Once Solana confirms, the server calls Flap's Portal.newTokenV6 from the Parity wallet, creating the tax token at a vanity address ending in 7777.

If the BNB step fails after Solana succeeded, the row shows as partial and the BNB side can be retried from the server without touching Solana again.

03

Metadata and images

Each chain has its own expectations for metadata, so the image is pinned twice.

ChainWhere it goesWhy
SolanaPinata, public ipfs.io links in the on-chain URIpump.fun, explorers and aggregators load the URI forever; the public gateway keeps that traffic free.
BNBFlap's upload API (funcs.flap.sh)Flap's indexer only reads files pinned on its own gateway. The returned CID is passed as the token's meta.

Images are capped at 5 MB and must be PNG, JPEG, WebP or GIF. Square images around 512px render best across both ecosystems.

04

Where the fees come from

Solana: pump.fun creator fees

Every pump.fun coin has a creator key fixed at mint time. Parity sets a 1% creator fee on every coin (pump.fun allows up to 3%), which accrues to a vault derived from that key, one vault for every coin the key created. Parity sets the creator to its Solana keeper wallet, so fees from every launch land in one vault. Only the keeper can sweep it, and it does so before each buy when the vault holds more than PARITY_MIN_SWEEP_SOL.

BNB: Flap tax

Flap tax tokens charge buyTaxRate and sellTaxRate in basis points; Parity sets both to 1%. It also sets mktBps to 10,000, so after Flap's protocol cut the whole tax goes to the beneficiary, which is the Parity BNB wallet. On the bonding curve the tax is collected in BNB and forwarded immediately. After graduation it is collected in the token itself, liquidated by Flap's tax processor once a threshold is reached, and paid out in BNB. Flap's trigger bot calls dispatch(), so nothing on Parity's side needs to claim anything.

Fees are pooled per chain across all launches. A busy pair subsidises a quiet one. Per-pair attribution is on the roadmap.
05

The keeper loop

pnpm parity runs a loop that walks every live pair every PARITY_INTERVAL_MS (30 seconds by default). One tick does this for each pair:

  1. 1
    Read both sides
    On the curve, price comes straight from the on-chain curve state. After graduation it comes from Birdeye. SOL and BNB in USD come from Birdeye as well.
  2. 2
    Compute the gap
    gap = (higher − lower) / higher, in basis points. A snapshot is written for the charts.
  3. 3
    Decide
    If the gap is inside the pair's band, do nothing. Otherwise the lower side is the lagging side.
  4. 4
    Fund
    On Solana, sweep the creator vault if it is worth a transaction. On BNB the fees are already in the wallet.
  5. 5
    Size
    Work out exactly how much native token lifts the lagging price to the other side's price (next section). Cap it by what is spendable above the gas reserve and by the per-tick maximum.
  6. 6
    Buy
    Execute on the bonding curve, or on Jupiter and PancakeSwap after graduation. Log the action with the transaction hash.
  7. 7
    Burn
    Burn the tokens just bought: on Solana from the Token-2022 account, on BNB by sending them to the dead address. Flap tokens can't be moved for an hour after a buy, so anything still held is retried every tick. Logged as its own action.
06

Sizing the buy

Both bonding curves have closed forms, so the keeper can compute the exact spend rather than nudging and re-checking.

pump.fun

The curve is constant product on virtual reserves. With virtual SOL reserve v and virtual token reserve t, price is v / t and k = v · t is constant. To reach target price p*:

Δv = √(p* · k) − v

The spend is Δv grossed up by about 1.5% for protocol and creator fees.

Flap

Flap's curve is (x + h)(y + r) = K, which gives price = (r + reserve)² / k. To reach p*:

Δreserve = √(p* · k) − r − reserve

The spend is Δreserve grossed up by the 1% curve fee plus the token's buy tax, because on the curve the tax is taken from the input.

After graduation

On a DEX the pool depth is read from Birdeye liquidity. Treating the pool as constant product with quote-side depth L / 2, the quote needed to move price from p to p* is approximately:

Δquote ≈ (√(p* / p) − 1) · L / 2

The keeper then buys through Jupiter on Solana and the PancakeSwap V2 router on BNB, using the fee-on-transfer swap so the tax does not revert the trade.

07

Curve to DEX

Both tokens start on a bonding curve and graduate to a DEX pool once enough supply is sold. Parity handles both phases and the transition.

pump.funFlap
Opening market cap≈ 28 SOL≈ 5.5 BNB
Graduationcurve fills (≈ 793M sold), migrates to pump AMM800M circulating (80%), migrates to PancakeSwap V2
Detectbonding curve account reports completePortal.getTokenV8 status = DEX
Buy venue afterJupiterPancakeSwap V2 router
Price source afterBirdeye (solana)Birdeye (bsc)

The two sides do not graduate at the same moment. Between the first and second graduation the keeper keeps working; the only thing that changes is which venue and price source it uses on each side.

08

Keeper wallets and funding

Parity holds two wallets. Their addresses are shown on the Launch page and printed when the keeper starts.

WalletRoleNeeds
Solana keeperpump.fun creator on every launch. Sweeps the creator vault and buys on Solana.A little SOL for transaction fees. Keeps PARITY_RESERVE_SOL untouched.
BNB keeperFlap beneficiary on every launch. Creates every BNB token (gas only) and buys on BNB with accrued tax.A little BNB for creation gas. Keeps PARITY_RESERVE_BNB untouched.

Neither wallet needs to be pre-funded with trading budget. The budget is the fees. If a side lags and the matching wallet has nothing to spend, the keeper logs a skip and tries again next tick.

09

Configuration

Everything is set in the environment. Band is per pair and chosen at launch; the rest applies to the keeper globally.

VariableDefaultMeaning
PARITY_BAND_BPS300Default band offered on the Launch page.
PARITY_INTERVAL_MS30000Seconds between keeper passes, in ms.
PARITY_MAX_SPEND_SOL0.5Most SOL spent on one pair in one tick.
PARITY_MAX_SPEND_BNB0.2Most BNB spent on one pair in one tick.
PARITY_RESERVE_SOL0.02SOL the keeper never spends (gas).
PARITY_RESERVE_BNB0.005BNB the keeper never spends (gas).
PARITY_MIN_SWEEP_SOL0.01Sweep the creator vault only above this.
PARITY_MIN_TRADE_SOL0.005Skip buys smaller than this.
PARITY_MIN_TRADE_BNB0.002Skip buys smaller than this.
10

Limits and risks

  • One direction only. The keeper lifts the lower side and burns what it buys. It cannot pull the higher side down, so a sharp pump on one chain is matched only as fast as fees allow.
  • Fees are the ceiling. A pair with little volume earns little, and the keeper can only spend what has been earned on that chain.
  • Pooled per chain. Fees from all pairs on a chain sit in one wallet and are spent on whichever pair lags most. Attribution per pair is not enforced yet.
  • Oracles. Native prices and post-graduation token prices come from Birdeye. A stale or missing quote makes the keeper skip that tick rather than guess.
  • Slippage. Curve buys use the contract quote minus 3%. DEX buys use the router quote minus 3% minus tax. A revert is logged as an error, not retried in the same tick.
  • Keys on a server. Both keeper wallets are hot wallets. Keep only what the loop needs in them.
11

Contracts and programs

NameAddress
Flap Portal (BSC)0xe2cE6ab80874Fa9Fa2aAE65D277Dd6B8e65C9De0
Flap Tax Token V3 implementation0x024f18294970B5c76c0691b87f138A0317156422
PancakeSwap V2 router0x10ED43C718714eb63d5aA57B78B54704E256024E
pump.fun program6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P
pump AMM programpAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA
pump.fun fee programpfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ

Flap launches use newTokenV6 with TOKEN_TAXED_V3, an 80% DEX threshold and the V2 migrator. The older V2 tax token is disabled on Flap mainnet. pump.fun launches use create_v2 (Token-2022) via @pump-fun/pump-sdk.

12

FAQ

Do I need BNB to launch?
No. The BNB token is created by the Parity wallet, which pays only the creation gas. Launchers cannot spend it on a dev buy.
Who owns the tokens the keeper buys?
Nobody. They are burned right after the buy, so each rebalance permanently reduces supply. If a burn is not possible yet (transfers locked on a curve) the tokens are held and burned later, never sold.
What if the two sides graduate at different times?
Nothing special. The keeper switches venue and price source per side independently and keeps rebalancing.
Can I change the band later?
It is stored per launch and can be edited in the database today; a UI for it is planned.
What does 'in band' mean on the table?
The gap between the two market caps is at or below the pair's band, so the keeper is idle for that pair.