π The Blaze Papers / Reading Receipts
π§Ύ Reading Receipts
Every Sonic transaction leaves behind a receipt, whether it succeeds or not β this page is what π§Ύ The Receipt is reading when it turns that receipt into plain English. Gas, transfers, approvals, two-phase bets, and how to check any of it yourself.
π§Ύ What is a transaction, really?
π₯± degen tl;dr
A transaction is a receipt the chain keeps forever. The moment it's included in a block, it's permanent, public, and unchangeable β not "hard to change," not "change costs money." Nobody can edit it, delete it, or quietly slip in a different amount after the fact. Not us, not you, not the network itself. π
π€ the nerd stuff
A transaction is a signed message β from one address, to one address (or to nothing, for a contract deployment), carrying an amount of native S, and optionally a payload of contract data. Sonic groups transactions into blocks, and each block links to the one before it by including that block's hash β that link is what makes rewriting history mean rewriting every block after it, across every node holding a copy.
Every transaction gets its own unique identifier, the transaction hash, and that hash is what you paste into The Receipt or sonicscan.org to pull it back up.
β½ Gas β you pay even when it fails
π₯± degen tl;dr
Every transaction costs a little S in gas β the fee for the network's computers to actually run it. That's true even if the transaction fails. The computer still did the work up to the point it gave up, and that work isn't free just because the outcome wasn't what you wanted. A failed transaction still shows up on the chain, and it still cost you gas. β½
π€ the nerd stuff
Gas meters computation and storage β every opcode a transaction executes consumes a small amount, up to the gas limit the sender set, at the gas price the sender agreed to pay. If execution reverts partway through, the gas already spent up to that point is still owed β only the state changes get rolled back, not the fee. See Reverts below for exactly what "rolled back" does and doesn't undo.
πΈ Transfers β just log entries, plus BLAZE's own tax
π₯± degen tl;dr
A token transfer isn't the token "moving" the way a coin moves between pockets β it's a line written into that token contract's own bookkeeping, and the network records that a Transfer happened. On BLAZE specifically, a small slice of every transfer burns on the way through: send 100,000 BLAZE and 99,958 arrive β the other 42 is gone forever, permanently removed from supply.
That's the 0.042% auto-burn tax, and it shows up as its own line in the receipt, not hidden inside the transfer amount. π₯
π€ the nerd stuff
Every ERC-20 transfer emits a Transfer(from, to, amount) event β
that's the log entry a decoder reads to know a transfer happened at all; the raw
transaction data alone doesn't say "100 tokens moved," the log does.
BLAZE's own contract additionally burns
0.042% (burnPercentage = 42, divided by
100,000) off the top of every transfer β but only while total supply is
above 3.18 billion (Fantom's old max supply, hardcoded as the floor).
Today's supply sits above that floor, so the tax is active: send 100,000 BLAZE and the receiving wallet's balance goes up by 99,958, while 42 gets burned to the zero address in the same transaction β two separate log lines, one transaction. Below 3.18B the tax simply stops applying, and a transfer moves the full amount with no burn line at all β don't assume the tax is on just because BLAZE is the token in question.
βοΈ Approvals β what you're actually signing away
π₯± degen tl;dr
An approval isn't a transfer β nothing moves the moment you sign one. It's a standing permission slip: "this contract may move up to THIS much of my tokens, whenever it wants, until I say otherwise." Sign an unlimited approval and that "up to" number is effectively your entire bag, forever, not just what you meant to spend today.
Games and dapps ask for approvals for a reason β but the receipt of an approval transaction shows you exactly what was signed away, which is why it's worth actually reading. Check what you've handed out and take it back at π§Ή The Great Revoker, and check the contract itself for owner powers at π The Rug Sniffer. βοΈ
π€ the nerd stuff
An ERC-20 approve(spender, amount) call writes a number into the
token's allowance[owner][spender] storage slot β it does not move
any tokens itself, and it has no expiry field in the standard, so the number sits
there exactly as written until a later call overwrites it.
A receipt for an
approval transaction decodes as an Approval event, not a
Transfer β same shape of log, different meaning, and mixing the two
up is the single most common misread of a wallet-history entry.
BLAZE's own casino
pages deliberately never approve MaxUint256: Roll the Dice approves
the exact bet, the coin flip approves a flat per-session cap (maxBet,
420 BLAZE), and Blaze Drop and Spin the Wheel each approve a page-picked
session credits β a handful of bets' worth. Every one of these is
bounded, never unlimited, and it lands back at or near zero as it
gets spent, never open-ended.
See The Great Revoker for the full mechanics of finding and clearing standing approvals you no longer want out there.
π² Two-phase bets β commit now, reveal later
π₯± degen tl;dr
The dice, plinko, wheel and crash games are each two transactions, not one: the first escrows your bet and locks in a commitment, and the second β a few blocks later β reveals the actual outcome. If you only ever look at the first receipt, it will never show you whether you won, because it doesn't know yet.
A
bet sitting between the two transactions isn't stuck β it
resolves automatically, and if something goes wrong and it sits unresolved too
long, a built-in reclaim() hands your full stake back. The coin flip
is the one exception: it's a single transaction, result and all, no second step. π°
π€ the nerd stuff
Dice, plinko, wheel and crash all share the same commitβreveal shape: the bet transaction escrows the stake and records the block it landed in; once 2 more blocks have passed, anyone can trigger the resolve transaction, which derives the outcome from that later block's own hash β a value that plainly did not exist when the bet was placed.
Each game also carries an owner-switchable mode that can swap that
block-hash source for a VRF (verifiable random function) instead; whichever mode
is active, the shape stays commit-then-reveal. If a bet goes unresolved for more
than 250 blocks, reclaim() refunds the stake in full β a bet can never
strand.
We're not going to put a number on any single game's odds here; read π° The Casino for the full payout tables instead.
π Swaps β pool trades read back too
π₯± degen tl;dr
Since 2026-08-31 BLAZE trades on real pools, so a swap is a receipt you will
actually meet now: one transaction, several log entries. Your BLAZE (or wS)
goes in, the pool fires its own Swap event, and the other token
comes out β all in the same receipt. π
BLAZE's 0.042% burn rides along on the way in, same as any transfer β the pool receives a hair less than you sent, and an honest swap UI (ours included) quotes around that instead of pretending it isn't there. π₯
π€ the nerd stuff
A swap receipt is composed transfers: a Transfer leg into the
pair, the pair's Swap event naming amounts in and out, and a
Transfer leg back to you. Token amounts only, never a dollar
figure β pricing them is π The Price's job,
not the receipt's.
Because BLAZE burns on transfer, a router has to use the fee-on-transfer
swap variant, which settles on the pool's balance delta rather
than trusting the quoted input β that is why the Swap event's
amount-in always reads a touch smaller than the transfer you signed.
Decode one yourself in π§Ύ The Receipt.
β Reverts β failed, but still honest
π₯± degen tl;dr
A transaction that reverts still happened β it's still on the chain, still costs gas, and still has a receipt. "Failed" doesn't mean "invisible." Whatever the intended action was (a transfer, a bet, an approval) didn't take effect, but the attempt itself is permanent public record, same as a successful one.
A decoder that only shows you successes would be lying by omission β a failure is still the truth, and it still gets shown. β
π€ the nerd stuff
When a transaction reverts, the EVM rolls back every state change it made β balances, storage, everything β back to how they were before it ran. What does not roll back is the gas already consumed getting to the revert point, and the transaction record itself: it's still mined into a block, still carries a real hash, and its receipt still reports a status of failure rather than success.
A decoder reading that receipt reports exactly that β what was attempted, what it would have cost to succeed, and that it didn't.
π₯± degen tl;dr
That's the whole anatomy. Paste any Sonic transaction hash into π§Ύ The Receipt and it walks the receipt back for you in plain English β what moved, what it cost, what it means. Then, if you want the primary source, paste that same hash into sonicscan.org and check it against what the decoder told you. We show you what moved. You stay the judge. π