🐕 Token Safety

🤓 the nerd stuff

How we talk about risk. We only state something as a settled fact when it can be PROVEN — read straight off the deployed bytecode or the live chain state, the same way this whole tool works — or when it is flagged by an external, cited source (an on-chain malicious-contract registry, for example).

No such external source is wired into the Sniffer yet in this first version, so today every single read you get out of it is a findings-based suggestion: here is what the code allows, here is how strong a signal that is, you decide what it means.

That will change the day an external source gets wired in — and this paragraph will say so when it does.

🤓 the nerd stuff

We scan the compiled bytecode for the mint(address,uint256) selector (0x40c10f19). Presence means the function is compiled in and the supply is not fixed by construction — it does not mean the owner will ever call it, and it does not by itself tell you who can reach it; check the Ownership and Roles sections below for that.

This is a red finding: of everything the Sniffer looks for, an unrestricted mint is the one power that can most directly cost a holder value. BLAZE's own token has no mint path at all, on either the owner side or anyone else's — see Tokenomics for the fixed 4.2B supply.

🤓 the nerd stuff

We look for the OpenZeppelin Pausable trio: pause() (0x8456cb59, yellow — the lever itself), unpause() and paused() (both info — the freeze is reversible, and readable).

Their presence means the capability is compiled in; it says nothing about whether it's active right now. Separately, if a live call to paused() comes back true at the moment you run a report, that is reported as its own red finding — a currently-frozen contract is not a "maybe," it's happening.

BLAZE's own game, faucet and casino contracts are all Pausable too — see Trust & Verify for the honest accounting of what that means for BLAZE specifically.

🤓 the nerd stuff

We scan for owner() (0x8da5cb5b), transferOwnership(address) (0xf2fde38b) and renounceOwnership() (0x715018a6) — all info-severity on their own, because presence alone is neutral.

The signal comes from a live read of owner(): if it returns the zero address, ownership really has been given up, and no owner-gated function anywhere in the contract can be reached by anyone through that path. If it returns a real wallet, that wallet holds every owner-only power the rest of this page describes.

We never infer renunciation from a function's existence — only from the live value. This is exactly how BLAZE's own token proves its "renounced, immutable" claim: see Trust & Verify for the live owner readout and address.

🤓 the nerd stuff

This anchor collects owner-gated functions that don't fit a more specific category — right now that's withdraw(uint256) (0x2e1a7d4d, yellow): its presence means the contract holds a balance the owner can move out.

The selector table (Website/honeypot-selectors.js) is extended weekly, and new owner-setter entries land here by default unless they earn their own anchor. As always: a function being reachable is not the same as it being exercised — check whether the contract is renounced (see Ownership) before deciding how much this one matters for a given token.

🤓 the nerd stuff

We look for OpenZeppelin's AccessControl machinery: hasRole(bytes32,address) (0x91d14854, yellow) and DEFAULT_ADMIN_ROLE() (0xa217fddf, info — the top-level role that can grant or revoke every other role).

Their presence tells you the token is role-controlled rather than single-owner-controlled. What it can't tell you — without walking every RoleGranted/RoleRevoked event ever emitted, which the Sniffer does not do — is who currently holds any given role. Role machinery existing is a fact; the roster behind it is not something we can show you here.

🤓 the nerd stuff

We disassemble the bytecode instruction-by-instruction (skipping PUSH-operand data bytes, which is the only correct way to do this — a naive byte scan misreads embedded data as opcodes) and check for SELFDESTRUCT (opcode 0xff).

This is a red finding. The important nuance: post-Cancun, under EIP-6780, SELFDESTRUCT only fully deletes a contract's code and storage when it is called in the SAME transaction that created the contract. Called any time after that, on a chain that has activated Cancun, it now only forwards the contract's native-coin balance to a target address — the code and storage stay put.

We report that the instruction is compiled in, which is a fact readable from bytecode. We do not, and cannot from bytecode alone, claim it can wipe the contract clean today — that depends on execution context we don't have.

Presence ≠ can-wipe-today; it still means the deploying team thought about wiring in a way to destroy the contract, and that's worth knowing regardless.

🤓 the nerd stuff

Two checks feed this anchor. First, a DELEGATECALL opcode (0xf4, info) present in the bytecode means the contract can run code that lives somewhere else, which is the mechanism upgradeable proxies are built on.

Second, and more decisive, we read the EIP-1967 implementation slot — a fixed, standardized storage slot (keccak256("eip1967.proxy.implementation") - 1) that upgradeable proxies store their current implementation address in.

A non-zero value there means the contract IS an upgradeable proxy, and we report it unconditionally — even if we can't read the implementation's bytecode behind it, because "we don't know what's behind the curtain" is itself the finding, not a reason to stay silent.

When we can read the implementation, we re-scan its bytecode through the same table and fold those findings into the same report.

The upgradeable disclosure is the loudest asterisk this tool can put on a report: if a token is behind an EIP-1967 proxy, treat every single other finding here as provisional — mint, pause, roles, all of it — the logic examined today is not guaranteed to be the logic running tomorrow.

What we don't catch: proxy detection here is EIP-1967 only. EIP-1167 minimal-proxy clones and beacon proxies are NOT detected — a contract built on either pattern will read as a plain, ordinary, non-upgradeable contract in this tool. Absence of a proxy finding is not proof a token can't be swapped out; it's proof the one specific standard we check for isn't in use.

• No buy/sell simulation — we never trade the token, so a transfer that only reverts on the DEX path (not a plain wallet-to-wallet transfer) won't show up here.
• Unverified source means every name you see is inferred from selectors, not read from a label — a match is a strong hint, not a citation.
• Dead code can trip a false positive: a selector can be compiled in and unreachable, so a power we report may never actually be callable.
• Nonstandard function names are a false negative risk — a rename defeats a selector match even when the underlying power is very much still there.
• We only look for AccessControl machinery (roles exist) — we do not, and cannot without a log scan, list who actually holds those roles.
• Proxy detection is EIP-1967 only, as covered above — EIP-1167 clones and beacon proxies read as ordinary, non-upgradeable contracts here.
• We flag POWERS, not intent. We never render a verdict on any token. The sniffer does carry a small curated list of well-known Sonic projects (USDC, wS, SHADOW, BEETS and friends) — those get a green identity card saying whose published contract the address is, verified against the chain before it shipped. That card is recognition, never a verdict: the full scan still runs and still barks at the real owner powers those tokens keep by design (see "How we talk about risk," above).

🤓 the nerd stuff

What CAN happen now:

• The price moves, both ways, cheaply. Anyone can buy or sell. On the combined depth of both pools, doubling the price costs on the order of 4,140 wS and taking it 10× costs about 21,623 wS — a few hundred dollars, not a fortune. Anyone with that budget can print a chart that looks like a moonshot. (Those two figures move with the reserves; 📈 The Price recomputes them live rather than trusting this paragraph.)
• We could sell into it. The treasury still holds about 1.053B BLAZE — 25.2% of supply — unlocked, and the seven game floats hold ~575M more. Selling the treasury would take the price down roughly 50%; the game floats roughly 34%. Nothing prevents either. We publish both numbers live on 📈 The Price instead of leaving them to be found.
• A quoted price can be stale or venue-specific. Two pools can disagree for a while until an arbitrage bot closes the gap, and a third-party price site reads whichever it read last.

What CANNOT happen:

• The liquidity cannot be pulled before the cliff. 10% of each pool's LP was burned to 0x…dEaD forever; the rest sits in a timelock — BlazeLpLock, verified at 0x2c7cc1E993eeffb168BB2A6901247432004EF85A — with no early-release function, no pause and no rescue. It opens 1 March 2028. Before then a release pays out zero, to us as much as to anyone; after it, the release call is permissionless and can only ever pay the beneficiary. The treasury holds zero LP on both pools.
• The token cannot be changed. Everything else on this page still holds for BLAZE: ownership is renounced, so there is no mint, no pause, no blacklist, no tax change and no proxy. A pool does not hand anybody a power the token never had.

The lock's small print, since this is the page that exists to read small print. The guarantee is about when, not about who. BlazeLpLock's entire owner-power list is transferOwnership: the owner cannot move the LP early, shorten the cliff, pause it or point a release at a stranger — but the owner can hand the lock to a different address, which changes which address collects the LP in March 2028. Anyone telling you the lock has "no owner power" has read it wrong, including if that someone is us on some other page. It is also audited by AI agents, not by a paid security firm: it wraps OpenZeppelin 5.1.0's VestingWallet, and OpenZeppelin's library is audited, but the ~30 custom lines around it are not. They were reviewed three times before deploy, which is a real thing and still not a firm's audit. 🔒

The nose still applies — to us and to everyone else. A tradeable pair is exactly the situation the Sniffer was written for: it is what makes owner powers worth money. Paste BLAZE, or any other Sonic token, into 🐕 The Rug Sniffer and read the powers for yourself. Remember its two standing limits, both listed above: it does not simulate a buy or a sell, so it cannot tell you a pool is tradeable — and it never renders a verdict, on our token least of all.