QuaiAxe (QAXE)

QuaiAxe turns Quai mining rewards into a token burn. A miner points their payout at a predicted address that has no code deployed to it. Anyone can later "collect" that address's balance into a shared vault, which splits it between a burn (the miner's chosen share, bought from the QAXE market and burned on the spot) and, optionally, a payout back to the miner — plus a small protocol fee.

#The mental model

1. A miner picks a burn share, 10% to 100%, and — below 100% — a payout wallet for the rest.
2. The site derives a mining address for that exact combination. The address is a CREATE2 prediction: nothing is deployed there. It is just a normal-looking Cyprus-1 address that the miner's rig can be pointed at like any other wallet.
3. The miner mines to it. A Quai mining reward is a coinbase credit, not a function call — it lands on the address's balance whether or not anything is deployed there, and whether or not the address will ever have code. So does a plain transfer from a pool that pays from its own wallet.
4. Anyone collects the deposit. Collecting deploys a tiny forwarder contract at the predicted address; its constructor immediately selfdestructs the balance into the shared vault, in the same transaction, and the address is code-free again — reusable for the next reward.
5. The vault splits the deposit: a 0.5% protocol fee to the treasury, the miner's chosen burn share reserved to buy and burn QAXE, and the rest (if any) pushed to the miner's payout wallet.
6. Anyone sweeps. Sweeping buys QAXE from the live market with a bounded slice of everything reserved for burning, and burns every QAXE the vault holds. The caller who triggers a collect or a sweep gets a small, capped gas refund funded out of that action's own principal — it is never worth more than the real cost, but it is enough that running the keeper is close to free.

Nothing in the system has an owner-controlled pause, upgrade, or withdrawal of burn principal. See security for the full threat model.

#Why a no-code deposit address ("Model A")

The alternative would be pointing a miner's payout directly at a smart contract. That does not work reliably on Quai: RedeemLockedQuai() (the function that finally pays out a locked mining reward) does an unconditional balance credit with no code check and no EVM call — so a contract-adjacent address technically can receive it, but a plain pool payout, sent with a fixed 21,000 gas limit, cannot reach an address that has a receive() or fallback() to run, because 21,000 gas is exactly what a value transfer to an empty account costs and nothing is left over to execute code.

QuaiAxe avoids the whole problem: a deposit address has genuinely no code at the time a reward or transfer lands on it. Coinbase credits and plain transfers both work exactly like they would to any ordinary wallet, because as far as the chain is concerned, that is what it is. The address only briefly gets code — a forwarder that self-destructs in the same transaction — when someone chooses to collect it, and it is code-free again immediately after.

#Components

#Splitting the deposit — the exact formula

For a gross deposit g and a chosen burn share burnBps (1000–10000, i.e. 10%–100%):

fee      = g * 50 / 10000                    // 0.5%, always to the treasury
rest     = g - fee
burnLeg  = rest * burnBps / 10000            // reserved principal, eventually bought and burned
minerLeg = rest - burnLeg                    // pushed to the payout wallet (0 at burnBps = 10000)

Integer division truncates every intermediate term; the remainder always lands in minerLeg because it is computed by subtraction, never its own product, so fee + burnLeg + minerLeg is exactly g to the wei. See burn-vault for the full accounting model.

#The 14-day reward lock

This is a Quai network rule, not a QuaiAxe rule: every mining reward is locked for a minimum of lock=0 — about 241,920 blocks, roughly 14 days — before it is credited to the miner's address at all. Locking longer (lock=1/2/3, roughly 3/6/12 months) earns a network reward boost that decays over the first year. A QuaiAxe deposit address does not exist as far as the chain's balance is concerned until that lock clears; there is nothing to collect before then. See integrate for the exact stratum strings, including the password field that carries the lock byte.

#Status (soft launch, 2026-09-23)

V2 was deployed to mainnet and its readback (curve, token, treasury, factory, every constant, INIT_CODE_HASH) verified to match the source on 2026-09-23. Independently, at deploy time:

• QaxeBurnVault.sweeps() == 0, totalTokensBurned() == 0, totalQuaiSpent() == 0 — no sweep has happened yet.
• The V1 probe vault (see v1-probe) also shows sweeps() == 0 and a zero balance — no reward has reached it yet either.

Both are expected: nothing mines to a QuaiAxe address until a miner is actually pointed at one, and a fresh reward sits in Quai's mandatory lock for ~14 days before it is even credited. No mining reward has been observed landing on a QuaiAxe deposit address, and V2 has never swept or burned. This page states that plainly rather than implying otherwise.

#Live addresses (Cyprus-1, chain 9)

Verified by reading each contract's code and constructor-bound state directly from https://rpc.quai.network/cyprus1 on 2026-09-23.

The treasury address is not printed here; read it live with vault.treasury() (see burn-vault) if you need it.

#Where to go next

• Integrating a miner or a site: integrate
• Full vault accounting reference: burn-vault
• Deriving deposit addresses and batching collections: deposit-factory
• Running a keeper: keeper
• Trading QAXE: pool
• Threat model: security