Token disclosure
What can be minted, how fast, and who can change the limits. It starts with the worst case for anyone holding WYRD.
Devnet beta: the SOL here is test SOL, and tokens and creatures have no value.
What can be minted, how fast, and who can change the limits. It starts with the worst case for anyone holding WYRD.
Without a program upgrade, at most 199,999,990 WYRDLIVE more can ever be minted, and at most 4,000,000 WYRDBY DESIGN in any 24 hours.
With an upgrade, after 48 hLIVE of public notice through the Squads multisig Dd41…y5zhLIVE, there is no limit.
Nobody changes anything: today's active limits.
600,000 WYRDLIVE
ADMIN restores the active limits to the approved ones, which takes effect at once.
800,000 WYRDLIVE
ADMIN raises the approved limits to the compiled maximum. The change waits out the in-program timelock of 1 minLIVE and is listed under Pending changes first.
at most 4,000,000 WYRDBY DESIGN
The UPGRADE multisig upgrades the program, after its own time lock.
No limit
Apart from the launch transaction, which mints the launch curve's supply once, only the claim instruction mints, only into the claiming player's own account, and only under the limits on this page. There is no team, treasury, airdrop or admin mint. The figures above also respect the compiled schedule and the lifetime cap. A full breaker plus one day of refill is why any 24 hours can reach twice the daily cap.
Check this address before you buy or receive the token.
DL4PUcLvwM8qggWPpbPgAvjSp5Xq6tzpcDuWsuoBqS2zBY DESIGN
Created by the launch transaction. Supply now 8,000,090.021614 WYRDLIVE.
WYRD_MINT. The program mints no other token and only into the claiming player's own account for it.verify_launch, which emits a LaunchVerified event in that transaction's program logs and records the time in the game settings. Verified on chain at 2026-10-22 11:21:01 UTCLIVE.Anyone can make a token with the same name, ticker and picture. Compare the whole address, every character, not only the first and last few. Copy it from this page; do not trust an address from a reply, a direct message, an advert or a search result.
Every program and program address the token depends on.
| Name | Address BY DESIGN | What it is | On devnet now LIVE |
|---|---|---|---|
wyrd_game | AHKC…rrK8 | The game program. Its claim instruction is the only way new tokens are minted. | Deployed; upgradeable by 6Pps…jCRT |
wyrd_hook | 59t8…JBxQ | The transfer hook. Accepts this token only; this build has no launch window, so it limits no buyer and no transfer. Made immutable right before the launch. | Deployed; immutable (no upgrade authority) |
| Game settings | 7D3u…hskj | The program's settings and counters (GameConfig). | Exists |
| Mint authority | 8BPo…fZZP | The token's mint authority. A program address with no private key: only the game program can sign for it. It mints only in claim; it also signs finalize_metadata, which removes the metadata authorities, and finish_wind_down, which removes the mint authority itself. Both only take powers away. | No account by design |
| Treasury authority | AsK2…WV4T | Becomes the curve's creator and holds the permanently locked pool position; fees it collects go only to the operations wallet. | No account by design |
| Launch curve config | Bw67…G7q5 | Meteora Dynamic Bonding Curve config, created by the game program. | Exists |
| Launch curve pool | GPFz…UQEg | The curve the token launches on. | Exists |
| Pool after graduation | HNG8…rpyt | Meteora DAMM v2 pool the curve migrates to; its liquidity is locked for good. | Exists |
| Hook account list | BHHx…cTDL | The transfer hook's (empty) list of extra accounts. | Exists |
This build has no launch window: from the launch on, anyone can buy from the curve and every transfer passes.
Trading fees, as the launch recorded them: on the launch curve 10%LIVE when trading opens, falling evenly to 1%LIVE over the first 1 hLIVE, then 1%LIVE of each trade; on the graduated pool 1%LIVE of each trade. Most of each fee goes to the operations wallet through the treasury authority above; Meteora keeps a share.
Addresses are derived from the program ids compiled into this build. Each links to the Solana Explorer, where the account and its history can be checked independently of this site.
What has been minted, how much room is left, and every limit with who can change it.
| Limit | Active LIVE | Approved LIVE | Compiled bound BY DESIGN | Who can change it |
|---|---|---|---|---|
| Lifetime cap | 200,000,000 WYRD | does not apply | at most 200,000,000 WYRD | Only ADMIN, only lower, at once. Never below what is minted plus the daily cap left after the same change, so ADMIN can end emission at once and for good by lowering the daily cap to zero and this cap to what is minted. |
| Daily cap (breaker capacity) | 300,000 WYRD | 500,000 WYRD | at most 2,000,000 WYRD | GUARDIAN or ADMIN lower it at once; ADMIN restores it up to approved; approved rises only through the timelock. |
| Per-claim cap | 100,000 WYRD | 100,000 WYRD | at most 200,000 WYRD | As for the daily cap. |
| Cooldown between claims | 1 min | 1 min | at least 1 min | GUARDIAN or ADMIN lengthen it at once; ADMIN shortens it back to the approved value at once; a shorter approved value waits for the timelock. |
| Minimum account age | 1 min | 1 min | at least 1 min | As for the cooldown. |
| Timelock on changes | 1 min | does not apply | at least 1 min | Only through the timelock itself. |
| Claim voucher lifetime | does not apply | does not apply | at most 15 min | Only a program upgrade. |
Claims can never bring the total minted above 11/10BY DESIGN of the planned amounts summed from the day the token goes Live, and never above the lifetime cap. The plan below is compiled into the program; only an upgrade changes it.
| Days after the token goes Live | Planned per day |
|---|---|
| 1 to 90 | 250,000 WYRD |
| 91 to 365 | 200,000 WYRD |
| 366 to 730 | 150,000 WYRD |
| 731 and later | 100,000 WYRD |
BY DESIGN values are compiled into the build this page reads. Before the mainnet deploy they are still draft values and can change; after it, only a program upgrade can change them. A claim that the breaker or the schedule cannot cover is refused, not cut short, so the player keeps their cooldown and can try again later.
Six kinds of change wait in the program's timelock, in public, before they apply: raising the approved limits, a new standby signer, a new operations wallet, a new activation fee, a new timelock and a new admin.
No change is waiting
Two multisigs hold the powers on mainnet: one can upgrade the program, one runs the game.
Can replace the game program, and so change any rule on this page. Its time lock delays every upgrade, so an upgrade is public before it runs.
Runs the game. At once, it can pause and unpause, lower limits or restore the active limits up to the approved ones, end emission for good (lower the daily cap to zero and the lifetime cap to what is minted), replace the guardian, promote the standby signer approved in advance, cancel a pending change, create the launch curve's config, finalize the metadata and begin the wind-down. Only raising the approved limits, a new standby signer, a new operations wallet, a new activation fee, a new timelock and a new admin wait out the program's timelock.
Both multisigs pass the check the program runs before the launch and again when it settles.LIVE
3CB1…DaA1LIVE is a hot key for emergencies: it can pause, revoke the voucher signer, lower the daily and per-claim caps, lengthen the cooldown and the account age, and cancel a pending change. It can never touch the lifetime cap or unpause.DraftA draft from the design notes for the owner to edit. Until the owner signs it, it is not the owner's statement.
Each of the two multisigs has three member keys and needs two approvals for any change.
[Owner: keep the one of the next two paragraphs that is true and delete the other]
In each multisig, one member key belongs to the owner and one to [name], who does not work for the owner and votes on their own. The third key is the owner's backup and cannot vote.
All member keys belong to the owner. Two signatures protect against a stolen key, not against the owner.
The member keys are kept [Owner: where and how, for example on separate hardware wallets].
The guardian, the keeper, the voucher signer, the game signer, the data signer and the freeze key are online keys on the game's servers, which the owner runs. The guardian can pause the game and tighten limits, never loosen them. The operations wallet, the collection's root key and the standby signer are kept offline, and the freeze key has an offline backup.
The upgrade multisig waits 48 hoursBY DESIGN before any upgrade runs. After Season 1, the owner raises that wait to [Owner: the new time lock, between one and two weeks] by [Owner: the date], and sets the upgrade authority to none when [Owner: the condition].
Token scanners flag some parts of this design. Each flag, why it is there, and what to check.
| What a scanner shows | Why | On devnet now LIVE |
|---|---|---|
| Mintable | The game mints rewards when players claim them, so the mint authority stays with the game program's mint authority address. It mints only in the claim instruction, under the limits above; its only other signatures remove powers (the metadata authorities when the metadata is finalized, the mint authority at the end of the wind-down). | Mint authority 8BPo…fZZPLIVE |
| Transfer hook can be changed | While the launch curve runs, the hook's authority is FhVo…HLuM, an address of Meteora's curve program that only that program can use; it removes the hook on the trade that completes the curve. The hook program itself is immutable from the launch on. | Hook authority none (removed)LIVEHook program none (removed)LIVE |
| Mutable metadata | Until the admin runs finalize_metadata after the token is Live, the metadata's update authority is the game program's mint authority address. No instruction can edit the metadata; finalizing removes the authority for good. The owner sets its date; this table shows whether it has run. | Not finalized yetLIVEUpdate authority 8BPo…fZZPLIVE |
| Not sellable, or no route | While the curve runs, Jupiter's main router does not trade tokens with a transfer hook, and Jupiter's Shield marked such tokens as not sellable: 36 of 40 hook tokens sampledSNAPSHOT2026-10-15. During the curve, trade on this site's swap page or on Meteora; the pool can also be followed on DexScreener. Selling into the curve works. | The curve has graduated to the pool; the hook is removedLIVE |
| The pool programs can be upgraded | Meteora can upgrade its curve program (DBC) and its pool program (DAMM v2). This project cannot change that. | DBC upgrade authority DHLX…6ViXLIVEDAMM v2 upgrade authority DHLX…6ViXLIVE |
The freeze authority must be none: the launch is refused otherwise, and nothing can set one later.BY DESIGN Freeze authority now: noneLIVE. A scanner's score is its own; this table only explains where each flag comes from.
DraftA draft from the design notes for the owner to edit. Until the owner signs it, it is not the owner's statement.
Before this game, the owner launched two tokens on Solana that use a transfer hook: ohm and everest. Much of this token's code is adapted from theirs, so anyone comparing the programs will see the same patterns.
Their accounts on mainnet show that both were most likely wound down within hours of launch. [Owner: confirm, with the dates]
[Owner: why each one was wound down, what holders could still do afterwards, and what this game does differently]
Creatures are Metaplex Core assets in one collection. Three online keys of the game server (the game signer, the data signer and the freeze key) and one cold key of the owner hold powers over it. This section says what each can do, so a leak or a mistake has a known worst case. The powers below were tested on the deployed Metaplex Core program. BY DESIGN
The game's keeper is an automated job that sends a few transactions on its own. It uses two hot keys that hold little SOL. Neither is the admin, the voucher signer or an upgrade authority: the keeper refuses to start if one of them is. BY DESIGN
5xyN…hCQg BY DESIGNG5mV…NMX4 BY DESIGNIt signs every new creature and every hatch, so it is on the game server whenever genesis, hatching or breeding is open. Whoever holds it can:
A leak of this key cannot be undone for the collection: replacing the key in time limits the damage, but once it has taken the collection over, the owner's cold key cannot take it back.
The owner decided to harden this collection once its name, image and metadata are final, and before genesis opens. Until then the standard design above applies, with every power listed. Hardening means:
After hardening, whoever holds the game signer can only:
The cost: the collection's update authority, its name and its metadata address can never change again.
Every bred egg is frozen when it is created, under this key, and only this key can release it. It has no other power over the collection. The key is fixed per egg: a later key cannot release the eggs an earlier one froze. The freeze key is an online key on the game server: it signs and pays each release when an egg's time is up.
The game server holds the secret behind the hourly seeds of the genes hash chain. Whoever holds it can work out the genes of a genesis egg shortly after it is bought, once the block its genes come from exists, until that hour's seed is published a few minutes after the hour ends, while the eggs can already be traded. After that, anyone can check them. It cannot choose them: every seed was fixed by the head of the chain published before the sale, and the block comes after the purchase.
deployments/devnet.json): a site that changed its ledger could also change what it shows here. A ledger Memo signed by any other key does not count.