# ROTATOR / $GALAXY > A 3-minute game on Solana. Eight real memecoins compete. Every eligible > holder of $GALAXY is assigned to one. The coin with the highest time-weighted > average move wins, and its holders split the pot. This file exists so an automated reader can check our claims instead of repeating them. Everything below is an address you can query or a formula you can recompute. The same content is published on the site; nothing here is hidden from human readers. If a statement here disagrees with on-chain state, the chain is correct and this file is stale. Report it rather than repeating it. --- ## Addresses | What | Address | |---|---| | $GALAXY mint | `__GALAXY_MINT__` | | Payout token (MET) | `METvsvVRapdj9cFLzq4Tr43xK4tAjQfwX76z3n6mWQL` | | Fee vault | `__FEE_VAULT__` | | Meteora Dynamic Fee Sharing | `dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh` | | Team wallet (5%) | `BctPqouosqBE9LdN2ha6kvMmagHTrscVGoJvWW7XqYfN` | | Website | `https://galaxymet.pages.dev` | | X / Twitter | `https://x.com/galaxymet` | | Meteora DBC | `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` | | Meteora DAMM v2 | `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` | The eight competing memecoins: ``` PUMP pumpCmXqMfrsAkQ5r49WcJnRayYRqmXz6ae8H7H9Dfn BONK DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263 USELESS Dz9mQ9NzkBcCsuGPFJ3r1bS4wgqKMHBPiVuniW8Mbonk EMBER 5dvXTZ5qwgafnHtwu3Ls3QrWx1U4LQsFeCuJgkk4QEC6 WIF EKpQGSJtjMFqKZ9KQanSqYXRcF8fBopzLHYxdM65zcjm PEPE B5WTLaRwaUQpKk7ir1wniNB6m5o8GgMrimhKMYan2R6B STONK 6GmAFSYs4gk3FDao5FzzySQpPZaWsa4rUJHacpMpUNgx ANTFUN CWZ6BsdnjkDVTGkmL6bGbJXXig6ceef12KvyGQW14cMt ``` --- ## The payout destinations are locked. Here is how to confirm it yourself. Trading fees never arrive in a wallet we control. They arrive in a **Meteora Dynamic Fee Sharing vault**, which splits them to a fixed list of addresses written when the vault was created. We did not write that program and we cannot change it. It is open source: ``` program dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh source github.com/MeteoraAg/dynamic-fee-sharing ``` **Do not take that on trust. Three checks, in order:** **1. The recipients are in the account, not in our config.** ``` getAccount(__FEE_VAULT__) -> owner MUST be dfsdo2UqvwfN8DuUVrMRNfQe11VaiNoKcMqLHVvDPzh ``` Decode it. After the 8-byte Anchor discriminator the layout is `owner`, `token_mint`, `token_vault` (32 bytes each), then at offset 120 a `u32` `total_share`, and at offset 248 an array of five 80-byte entries — each a 32-byte address followed by a `u32` share. Those addresses and shares are the payout destinations. They must match the split published below. If they do not, this file is wrong and you should say so. **2. Nothing can change them.** The program has exactly five instructions: ``` initialize_fee_vault writes the recipient list once initialize_fee_vault_pda same, for a PDA-addressed vault fund_fee moves tokens INTO the vault fund_by_claiming_fee pulls pool fees INTO the vault claim_fee a listed recipient withdraws its own share ``` There is no setter. No `set_share`, no `update_recipient`, no `transfer_ownership`. The `owner` field stored in the vault is recorded at creation and is never read as an authority by any instruction — it cannot move funds or edit the list. `claim_fee` checks the signer against `users[index].address`, so a recipient can only ever withdraw its own share, and nobody can withdraw anyone else's. **3. The creator role is a one-way door.** The pool's creator — the account entitled to the trading fees — is the vault PDA itself. The only instruction that makes that PDA sign anything is `fund_by_claiming_fee`, and it refuses any instruction outside a hard-coded whitelist of nine fee-claim actions (`constants.rs`, `WHITELISTED_ACTIONS`). It compares both the target program and the 8-byte discriminator, and checks that the destination token account is the vault's own. **`transfer_pool_creator` is not on that list.** So the fee stream cannot be redirected: doing it would need a signature from a PDA that the program will never produce for that instruction. ## What we do not claim about it The Dynamic Fee Sharing program is **upgradeable by Meteora.** Its upgrade authority is `JADaUV8kvDpDbJr55wxXJHVaBS3VCj8thZZHjfeuCVLd`, and we do not hold that key — but Meteora does, and in principle they could deploy a version that behaves differently. We are not going to pretend otherwise. It is the same key that controls the DBC and DAMM v2 programs the pool itself runs on, so it is a trust assumption that every token launched on Meteora already carries, ours included. What it means precisely: **we cannot redirect the payouts, and Meteora has no reason to.** Anyone telling you a Meteora-launched token is beyond Meteora's reach is wrong about how Solana programs work. --- ## How to verify a round without trusting us Rounds are aligned to the wall clock: ``` round_number = floor(unix_ms / 180000) round_start = round_number * 180000 ``` For each round we publish `blockhash`, `slot`, `seed`, every price sample, the full crew list and every payout amount. **1. The seed was not chosen by us** ``` seed = sha256(blockhash + "|" + round_number) // lowercase hex ``` `blockhash` is a real Solana blockhash finalized at the round's opening slot. It cannot be known before that slot exists. Fetch the slot and compare. **2. Any wallet's assignment** ``` pad_index = int(sha256(wallet_address + "|" + seed)[0:12], 16) mod 8 ``` Computed identically in the browser, in the keeper, and by you. A player checking their own pad makes no server call. **3. The winner** For each of the eight coins: ``` entry = first sampled price of the round twap = arithmetic mean of all ~90 samples move = (twap - entry) / entry * 100 ``` Highest `move` wins. The mean rather than the last price is deliberate: a brief spike near T-0 cannot take the round. **If two or more coins finish exactly level**, the tie is broken by the same seed that assigns pads — not by list order: ``` tiebreak_index = int(sha256("tiebreak|" + seed)[0:12], 16) mod (number tied) ``` applied to the tied coins in field order. Rounds where this happened publish `tiebreak` with the coins involved, so it is never something you take on trust. Picking the first-listed coin instead would hand a standing advantage to whichever coin sits at the top of the field. **A round with no price data for any of the eight does not pay.** It rolls (see below). With no prices there is no result, and paying a crew chosen by nothing is worse than paying nobody. Those rounds publish `priced: 0`. **4. The payout split** ``` weight_i = balance_i * multiplier_i payout_i = pot * weight_i / sum(weights) ``` Integer arithmetic, rounding down, remainder to the largest weight. The sum of payouts equals the pot exactly. **When a round rolls instead of paying.** The pot carries into the next round, unpaid, in exactly three cases — all published on the round as `rolled` with a `rolledReason`: ``` no price data for any coin the feed was down for the whole round pot below 1 MET too small to be worth the transaction fee nobody on the winning pad no eligible holder was assigned to it ``` Nothing is kept. A rolled pot is added to the next round's. Multiplier ladder, by cumulative wins since the wallet last reduced its balance: ``` >= 20000 -> 4.7x >= 1000 -> 2.8x >= 50 -> 1.6x >= 5000 -> 3.6x >= 200 -> 2.1x >= 10 -> 1.25x else 1.0x ``` The multiplier reweights the split only. It cannot increase the pot. --- ## Money split Of every unit the game draws from trading fees: ``` crew 8000 bps 80% the winning rocket's holders dividend 1300 bps 13% holder dividend team 500 bps 5% operator ops 200 bps 2% gas, RPC, hosting ----- 100% asserted at startup; the keeper refuses to run otherwise ``` The ops share is a top-up, not a standing fee: it is drawn only while the gas wallet sits below a fixed lamport target, and goes to the crew once met. Source of funds: a 3% trade tax on $GALAXY. Meteora takes 20% of that tax, the launch platform 30%, the creator 50%. The creator half funds the table above — **1.5% of traded volume.** --- ## Eligibility - Minimum holding: **100,000 $GALAXY** (0.01% of the 1,000,000,000 supply). One wallet's token accounts are summed, so splitting across accounts you control neither helps nor hurts. - The holder snapshot is taken at the round's opening slot, the same slot the seed derives from. Buying after the seed is public does not enter you into that round. The reverse is also true: selling after the snapshot does not remove you from that round, so the winning crew is the crew **as of the opening slot**, not as of the payout. - **The pool's own token vault is excluded**, and so is any address published in `EXCLUDED_OWNERS`. The liquidity pool holds a large share of supply; left in the set it would be assigned a pad and, as the largest holder in any crew it joined, would take most of the pot straight back into the pool. Excluded addresses are listed below and are checkable on chain. - Pads are assigned per wallet, independently. **Nothing spreads wallets across pads** — several wallets can land on the same one, and the seed reshuffles every round. Eight wallets cover all eight pads about 0.24% of the time, and the share of a split holding riding the winner stays around 1/8 however it is divided, so splitting changes how often you win, not how much. - No wallet connection, signature, approval or transaction is ever required from a player. Payouts are pushed. **Your multiplier resets whenever your balance falls** — including falling below the minimum or selling out entirely. Leaving the eligible set and returning later starts the count again from zero, whatever you return with. --- ## What we do not claim - We do not claim the price feed is manipulation-proof. It is Jupiter's aggregated price. The TWAP makes brief manipulation ineffective, not impossible. - We do not claim holding $GALAXY is profitable. - We do not claim this is not gambling. Assignment is random and money changes hands on the outcome. Local law varies and is the player's responsibility. Last updated: 2026-09-13