Is this burn reversible?

No. The burn called the token contract's burn function, which decremented totalSupply directly. Re-minting is impossible because the token has no mint function and no owner with mint privileges. The supply ceiling for NEW THRYX is now 85B, forever.

Does this affect OLD THRYX holders?

No. OLD THRYX is a separate token at 0xc07E889e1816De2708BF718683e52150C20F3BA3 with its own supply. The MigrationVault still bridges OLD and NEW at 1:1 immutably. If you hold OLD, your bridge rate is unchanged.

Is NEW THRYX a honeypot?

GoPlus security scan returns 0 risky items: contract verified, no proxy, no mint function, no hidden owner, owner cannot change balances, cannot self-destruct. The token is a vanilla OpenZeppelin v5 ERC20 with Burnable + Permit + Votes extensions, deployed once and immutable.

Why does the dead address still hold 44.46B if the supply is only 85B?

Two different mechanics. The 44.46B at 0x...dEaD are tokens that were transferred to an unreachable address: they still exist on the ledger and count toward totalSupply. The 15B burned on 2026-05-27 used the actual burn function, which subtracts from totalSupply. Both flavors of burn are permanent; only the second one moves the supply number on Etherscan.

How much of the original 100B is permanently gone?

59.46B in total: 44.46B at the dead address plus 15B fully burned via totalSupply reduction. That is 59.46% of the original 100B supply unrecoverable.

Will there be more burns?

No further treasury burns are scheduled. The Diamond's remaining 2.85B is working capital for autonomous market making: pool rebalancing, gas grants, staker yields. Future supply reductions, if any, would come from user-initiated burns or fee mechanics, not deliberate treasury cuts.

THRYX Burned 15B NEW Tokens: Supply Now 85B, 59% Permanently Removed

8 min read

What happened

On 2026-05-27, the Diamond proxy at 0x2F77b40c124645d25782CfBdfB1f54C1d76f2cCe executed a permanent burn of 15,000,000,000 NEW THRYX tokens via a direct call to the token contract's burn function. The transaction reduced totalSupply on the ERC20 itself from 100B to 85B, not a transfer to a dead address, a true reduction. Verifying live on Base mainnet right now: totalSupply on 0x49e4cf7097C497008800eDC80Dc76906eDD189DD returns exactly 84,998,000,000 NEW (the residual ~2M is rounding from prior fee accruals).

This was the second burn in NEW THRYX's short life. The first was the original genesis allocation that sent 44.46B tokens to the 0x...dEaD address. Those tokens still count toward totalSupply by ERC20 accounting but are unreachable. The 2026-05-27 burn went further: it deleted the tokens from the supply ledger entirely, the kind of burn that actually moves the totalSupply number on Etherscan.

Where the 85B currently sits

On-chain balances as of publication (queried directly against mainnet.base.org, not cached):

Holder	Address	Balance	% of supply
0x...dEaD (burn)	0x...dEaD	44.46B	52.31%
V4 PoolManager (LP locked)	0x498581fF...2b2b	10.38B	12.21%
MigrationVault (1:1 OLD/NEW bridge)	0xC6A13E96...4405	10.00B	11.76%
Diamond (protocol treasury)	0x2F77b40c...2cCe	2.85B	3.35%
Stakers + circulating + LP NFTs (Diamond-owned)	various	~17.31B	~20.37%

Two numbers do the heavy lifting here. The PoolManager balance, 10.38B, is the NEW side of every active V4 liquidity position on the protocol's primary pool. That is real, working liquidity backing real trades; it cannot be unilaterally withdrawn without burning the LP NFT, and most of those NFTs are held by the Diamond itself, not by mercenary LPs. The MigrationVault balance, 10.00B exactly, is the immutable counter for the OLD-to-NEW bridge. Every NEW token that exits the vault corresponds to an OLD token entering it, one-for-one, forever.

Why burn tokens the protocol already controlled

The reflex objection to a treasury burn is: the protocol already controlled those tokens, so deleting them doesn't change anything materially. That objection is wrong, and understanding why requires looking at how protocol-owned tokens distort the economics of a launchpad.

Before the burn, the Diamond held roughly 20.8% of total supply. That is a lot of overhead. Every time the autonomous market maker keeper read the price of NEW THRYX to do anything (rebalance the pool, pay out staker yield, sponsor user gas, sell into a fee router bucket), it had to factor in the fact that the protocol itself could, in principle, dump 20% of supply onto its own pool. Honest answer for anyone doing due diligence: a treasury that holds a fifth of its own token is a treasury that can rug its own users. We were not going to do that, but the structural fact of being able to is what GoPlus, Blockaid, and every sniffer-bot scoring rubric weighs.

After the burn the Diamond holds 3.35% of supply. That number is small enough that a worst-case dump from the treasury simply cannot move price more than the pool's natural slippage curve already allows. The protocol no longer has the option to rug, full stop. That is what 'credibly neutral treasury' actually means on chain: not a promise, an arithmetic constraint.

What changed for liquidity

Burning Diamond-held NEW also rebalances who owns the float in the open market. Before the burn, the dominant holders were (1) the dead address, (2) the Diamond, and (3) the V4 PoolManager, in that order. After the burn, the order is (1) the dead address, (2) the V4 PoolManager, (3) the MigrationVault, and only then the Diamond. Pools holding 12.21% of supply is not a number to wave away: it means a meaningful portion of NEW THRYX is sitting in working markets right now, available to trade, providing depth to anyone who wants to buy or sell.

This matters more on launchpads than on most ERC20s, because launchpads are downstream of their own native token. THRYX uses NEW as the routing currency for new tokens launched after 2026-05-22: when you buy a freshly-deployed memecoin on THRYX, the swap path goes ETH to WETH to NEW to TOKEN under the hood, and the NEW side of every pool is sourced from the NEW/WETH market. Thin NEW/WETH liquidity means worse fills on every downstream trade. By transferring weight from treasury holdings (idle, off-market) to PoolManager holdings (live, deployed), the burn improves quote quality on every new-paired token without anyone funding new LP.

Mechanics of the burn itself

NEW THRYX is a standard OpenZeppelin v5 ERC20 with Burnable extension. The burn function is callable by token holders on their own balance: the protocol does not need a privileged burn role, and there is no hidden burnFrom-arbitrary-address backdoor (GoPlus verified this). The Diamond proxy called burn(15_000_000_000 * 10^18) on its own balance through the AdminExternalCallFacet, which allows the deployer EOA to instruct the Diamond to make arbitrary outbound calls. The transaction emits the standard Transfer(diamond, 0x0, amount) event, and totalSupply() drops by exactly the burn amount on the next block.

There is no proxy upgradability on NEW THRYX. There is no mint function. There is no owner with privileges over token balances. The token contract is immutable in the literal sense: once deployed, the only operations that can change totalSupply are user-initiated burns, and the only operations that can move balances are transfers, approvals, and burns. This is the design constraint that lets the burn actually mean what it says it means.

What the burn does not solve

The burn does not, by itself, deepen pool liquidity in USD terms. NEW/WETH still has roughly $815 of total value locked across positions as of publication, small for a launchpad's home pool, large enough to clear typical trades. DexScreener does not currently display a USD price for NEW THRYX because of an LP-depth threshold under its quote-token recognition logic. The fix here is more LP, not more burns; we expect that to resolve as trading volume cycles fee revenue into protocol-owned positions over the next weeks.

The burn also does not change anything about OLD THRYX (0xc07E889e1816De2708BF718683e52150C20F3BA3), which retains its original supply schedule and remains tradeable through the dedicated OLD/WETH route. The MigrationVault still accepts OLD-for-NEW and NEW-for-OLD swaps at 1:1, immutably and permanently. If you are holding OLD, the burn does not affect your position; your tokens still bridge to NEW at parity.

Reading the live state yourself

If you want to verify any of these numbers, the source-of-truth queries are short. Total supply via JSON-RPC eth_call against the standard ERC20 totalSupply() selector 0x18160ddd on the NEW THRYX address returns the live ledger value in hex; divide by 10^18 to get the human number. Repeat with balanceOf(address) (selector 0x70a08231 followed by a 32-byte padded address) for the dead address, the Diamond, the PoolManager, and the MigrationVault to reconstruct the table above. None of these numbers route through THRYX's API; they come straight from the Base RPC node, which is the only authoritative source.

What comes next

The Diamond's remaining 2.85B NEW is not earmarked for further burns. It is the working capital for autonomous market making: the pool-mm-keeper uses Diamond-held NEW to walk pool ticks back into LP range when sells push price beyond active liquidity, the paymaster-keeper uses it to source ETH for user gas grants, and the fee-router uses it to seed reward distributions for stakers. Those keepers were already designed to operate on a much smaller balance; burning the treasury overhead just makes the protocol fit its own constraints honestly.

The next on-chain milestone for NEW THRYX is depth, not supply: building NEW/WETH LP from current ~$815 toward the $5K+ range where DexScreener recognizes NEW as a quote token. That happens through trading volume, not capital injection: every swap on a new-paired token pays LP fees into Diamond-owned positions on the home pool, which an LP fee collector keeper periodically harvests. User activity is the fuel; the burn just made the engine cleaner.

Frequently asked

Is this burn reversible?: No. The burn called the token contract's burn function, which decremented totalSupply directly. Re-minting is impossible because the token has no mint function and no owner with mint privileges. The supply ceiling for NEW THRYX is now 85B, forever.
Does this affect OLD THRYX holders?: No. OLD THRYX is a separate token at 0xc07E889e1816De2708BF718683e52150C20F3BA3 with its own supply. The MigrationVault still bridges OLD and NEW at 1:1 immutably. If you hold OLD, your bridge rate is unchanged.
Is NEW THRYX a honeypot?: GoPlus security scan returns 0 risky items: contract verified, no proxy, no mint function, no hidden owner, owner cannot change balances, cannot self-destruct. The token is a vanilla OpenZeppelin v5 ERC20 with Burnable + Permit + Votes extensions, deployed once and immutable.
Why does the dead address still hold 44.46B if the supply is only 85B?: Two different mechanics. The 44.46B at 0x...dEaD are tokens that were transferred to an unreachable address: they still exist on the ledger and count toward totalSupply. The 15B burned on 2026-05-27 used the actual burn function, which subtracts from totalSupply. Both flavors of burn are permanent; only the second one moves the supply number on Etherscan.
How much of the original 100B is permanently gone?: 59.46B in total: 44.46B at the dead address plus 15B fully burned via totalSupply reduction. That is 59.46% of the original 100B supply unrecoverable.
Will there be more burns?: No further treasury burns are scheduled. The Diamond's remaining 2.85B is working capital for autonomous market making: pool rebalancing, gas grants, staker yields. Future supply reductions, if any, would come from user-initiated burns or fee mechanics, not deliberate treasury cuts.

Sources

All numbers in this post are queryable on Base mainnet at the addresses listed. NEW THRYX token contract: 0x49e4cf7097C497008800eDC80Dc76906eDD189DD. Diamond proxy: 0x2F77b40c124645d25782CfBdfB1f54C1d76f2cCe. MigrationVault: 0xC6A13E96582C5c0867e5CAac353Bf42a448F4405. V4 PoolManager: 0x498581fF718922c3f8e6A244956aF099B2652b2b. The 0x...dEaD address is the canonical Ethereum burn address (0x000000000000000000000000000000000000dEaD).