An address on a public blockchain cannot refuse mail. Anyone can send coins to it, anyone can attach data to the transaction that does so, and nobody — not the owner, not the miners, not the explorer — can stop them or take it back. That property is the whole point of a permissionless ledger, and it has a consequence people discover only when an address becomes famous: the moment an address matters, its transaction count stops measuring anything you care about.
This guide exists because that happened this weekend to one of the most closely watched addresses in Bitcoin. The address holding 598.5 bitcoin taken from Blockstream’s Liquid sidechain carried 296 confirmed transactions at 06:10 UTC on Friday 11 September. At 06:10 UTC on Sunday 13 September it carried 1,426. A reader glancing at an explorer would reasonably conclude that a great deal had happened. In fact nothing had happened: the coins have not moved since 7 September, and 1,110 of those 1,426 transactions belong to an unrelated token sale that writes a 330-satoshi output to the address in every mint. The desk documents that in today’s lead article. This guide is the general method.
Six checks, in order. Each one is cheap, each one can be done in a browser with a public explorer, and each one is scored below against the flood that arrived this weekend so you can see what a pass and a fail look like on real data. Nothing here requires a paid tool.
Check 1 — Read the value, not the count
A transaction count is a count of envelopes. It says nothing about what is inside them. The first thing to do with any address is stop looking at the number of transactions and look at three amounts instead: total received, total sent, and current balance. On most explorers these are labelled directly; on the underlying data they are computed from the funded and spent output sums.
The question you are answering is: has value actually moved? An address whose balance is unchanged has not paid anybody, no matter how many transactions have arrived. An address whose received total has risen by a few thousand satoshis has received nothing of consequence, no matter how many senders were involved.
Scored on the weekend. The whitehat address went from 598.50048115 BTC on Friday to 598.50425429 BTC on Sunday. That is a rise of 377,314 satoshis — about $291 at Saturday’s close of $77,269.22 — spread across 1,130 new transactions, an average of 334 satoshis each. Outgoing: zero, with no spend since 16:09:25 UTC on Monday 7 September. Two numbers, ten seconds, and the entire flood is correctly classified as noise before you read a single transaction. Compute the difference in satoshis using arithmetic, not by eyeballing two eight-decimal figures. 0.00377314 BTC is 377,314 satoshis; the desk has previously misread a figure of this shape by three orders of magnitude, and the fix is to subtract the two balances in a calculator every time.
Check 2 — Sort the incoming amounts and look for a repeated constant
This is the single highest-yield check on a flooded address, and almost nobody does it. Take every output that paid the address and tabulate the distinct amounts with a count of how often each occurs. Then ask whether one value dominates.
Human payments are heterogeneous. People send round numbers, fee-adjusted remainders, and whatever a wallet computed — the distribution is ragged. Software is homogeneous. When a single exact satoshi value appears hundreds or thousands of times, you are not looking at hundreds of decisions; you are looking at one decision, made once, in a line of code, and executed repeatedly. That is what the desk means by a protocol marker: an output that exists because a program puts it there, carrying no economic intent toward the recipient at all.
Scored on the weekend. The amount table for the whitehat address is overwhelming: 330 satoshis appears 1,117 times — 1,110 of them the ico-20 deploy and mints, seven from unrelated senders — followed by 300 satoshis nineteen times, 546 nine times, 550 nine times, 1,000 five times, and a handful of singletons. One value, more than a thousand repetitions, nothing else close. The 330-satoshi figure is itself a tell: it is a common dust threshold for certain output types, which is to say it is the smallest amount software will bother to create. Nobody chooses 330 satoshis as a gift.
The useful generalisation: a repeated constant near the dust limit means a program, and a program means the recipient is probably incidental to whatever the program is for.
Check 3 — Decode the OP_RETURN, and decode all of them
An OP_RETURN is a provably unspendable output that exists to carry data. Explorers usually render it as hexadecimal; converting that hex to text takes one line of code or any online hex-to-ASCII tool. As Field Guide #44 set out when the Liquid negotiation began, this is how a blockchain becomes a message board.
The mistake is to decode one and stop. Decode all of them and group identical payloads, because the shape of the distribution is the finding. A handful of distinct, hand-written messages is a conversation. One payload repeated a thousand times is machinery. Both can coexist on the same address, and telling them apart is the whole job.
Scored on the weekend. Of the OP_RETURN payloads on the whitehat address, 1,109 are byte-identical: {"p":"ico-20","op":"mint","tick":"LEAF"}. One is a matching "op":"deploy" payload with the sale’s parameters. A further 307 transactions carry an assortment of genuinely distinct messages — some of them the PGP-signed negotiation the address exists for, some of them advertising for unrelated tokens, and some of them abusive material about real people that this publication will not reproduce. That last category is worth knowing about before you open the address in front of a colleague.
Two practical notes. First, if a decoded payload begins with a recognisable magic string, look it up rather than guessing: the desk identified encrypted Blockstream messages last week only because the base64 body began QklFMQ, which decodes to BIE1, the header of a particular encryption scheme. Second, a signature and a plaintext are different claims. A message can be cryptographically signed and still be unreadable to you.
Check 4 — Follow the other outputs to find out who the transaction is actually for
This is the check that converts a suspicion into an answer. A transaction that pays your watched address 330 satoshis almost certainly pays somebody else properly. Open one of the transactions and read every output: the amounts, the addresses, and which of them is the largest.
If the largest output goes somewhere other than your watched address, then your watched address is not the point of the transaction. Follow the largest output to its address, look at that address’s totals, and you will usually find the real story in under a minute.
Scored on the weekend. A representative mint — 1,105 of the 1,109 take this shape — has six outputs: a payment to a treasury address, the OP_RETURN, 330 satoshis back to the sender, 330 satoshis to a second address, 330 satoshis to the whitehats, and change back to the funding address. The treasury output is the largest in every case. Following it to its own address gives the actual scale of the event: 1.3790679 bitcoin received across 1,111 incoming transactions — of which 1.37870546 BTC, roughly $106,532, came from the 1,109 mints. Measured per mint, the median commitment was 30,000 satoshis — about $23 — the largest of the 1,109 in the snapshot was 6,400,000 satoshis, or about $4,945, and eighteen mints committed nothing but the 330-satoshi dust. So: a token sale of about a hundred thousand dollars, with a typical buyer risking twenty-three. That is a proportionate description, and you cannot arrive at it from a transaction count.
Check 5 — Price the fees against the delivery
Every transaction pays a miner fee. Summing the fees of a cluster of transactions and comparing that total against the value they delivered to your watched address gives you a ratio, and the ratio is a statement about motive.
If the fees are a small fraction of the delivered value, the transactions are payments and the fee is a cost of doing business. If the fees exceed the delivered value, the delivery was never the objective. Nobody spends more to send a message than the message is worth unless the message — or the side effect — is the entire purpose.
Scored on the weekend. The 1,110 ico-20 transactions paid 1,311,938 satoshis in miner fees to deliver 366,300 satoshis to the whitehat address: a ratio of 3.58 to one. Three and a half times more coin went to miners than to the recipient. That settles it. Whatever these transactions are for, paying the whitehats is not it.
The same arithmetic is worth doing in bytes when you want to know whether a flood is congesting the network or merely cluttering an address. These transactions occupied 755,139 virtual bytes across 78 blocks, an average of about 9,681 vB per block, or 0.97% of a one-million-vB block. Under one percent. Fees over the same period were 3 satoshis per virtual byte for the fastest tier at 06:10 UTC and 1 for everything slower. A flood that clutters an address is not the same thing as a flood that congests a chain, and conflating them is how “spam attack” headlines get written about events that cost a thousand dollars.
Check 6 — Compare addresses in full, character by character
The habit almost every crypto user has been taught — check the first four and last four characters — is not safe on a flooded address, because a vanity-address generator can produce a string matching both ends of a target for very little compute. Two addresses can look identical in every abbreviated rendering an interface will show you and be entirely different addresses.
The rule is simple and non-negotiable: copy both strings into a place where you can compare them in full, and compare them mechanically rather than visually. A diff, a string-equality check, or at minimum a side-by-side paste in a monospaced font.
Scored on the weekend. One of the two non-treasury addresses receiving 330 satoshis in every mint is bc1ql4mad6nxx43t79u7wadwqhtu0hx54ssg6mjlte. The whitehat address is bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte. Both are 42 characters. They share a seven-character prefix (bc1ql4m, of which bc1q is free on every address of this type and l4m is not) and a four-character suffix (jlte). Any interface abbreviating to bc1ql4m…jlte renders them identically. The sale’s treasury address is separately a vanity construction, ending in the letters sypleaf — which at least tells you the operator has the tooling and the inclination.
The three categories, stated plainly
Everything arriving at a watched address falls into one of three buckets, and the six checks above are simply the fastest route to sorting them:
- A payment. Value that someone intended the owner to have. Test: the amount is material relative to the balance, the fee is a small fraction of the amount, and the largest output in the transaction is the one paying this address.
- A message. A minimal payment whose purpose is the attached data. Test: dust-sized value, a distinct OP_RETURN payload, few repetitions, and a fee proportionate to the data size. A signed message from an identifiable party is the high-value case; advertising and abuse are the same category with nothing worth reading in it.
- A protocol marker. Value that exists because software put it there. Test: one exact amount repeated many times, one byte-identical payload repeated many times, the largest output going elsewhere, and fees exceeding delivery. The recipient is incidental.
The reason to separate them explicitly is that the three degrade differently over time. Payments are permanent facts. Messages accumulate slowly and each new one may matter. Markers arrive in bursts that start and stop for reasons having nothing to do with the address — this weekend’s flood went from 381 mints in the 00:00–01:00 UTC hour on Sunday to 39 in the 03:00 hour and three across 04:00–06:00, a collapse of roughly 99% over five hours. Any conclusion you draw from a marker burst has a shelf life measured in hours. Any conclusion you draw from a spend is permanent.
What this does not tell you
Four limits, stated so nobody over-reads the method.
It does not tell you who owns anything. Address clustering is a separate discipline with its own error rates. That a transaction pays a treasury address tells you where coins went, not who controls them.
It does not establish intent. Finding that 1,109 of 1,109 mints pay a particular address 330 satoshis is a fact about transactions. It is consistent with the value being hard-coded in a client, and it is not proof that any published specification requires it, nor evidence about why. The desk verified the chain; it did not verify a spec, and it will not narrate a motive it cannot source.
It does not tell you that a flood is hostile. An address can be used as a beacon by people with no interest in the address at all. Dust arriving at an address is also, separately, a known privacy hazard — small unsolicited outputs can be used to link addresses together when later spent, which is why the standing advice for anyone who finds unexplained dust in a wallet is to leave it unspent rather than sweep it.
It does not survive its own timestamp. Every figure in this guide is stamped 06:10 UTC on Sunday 13 September 2026. Re-pull before relying on any of it. And when you do, follow the rule the desk adopted after getting it wrong twice: 00:00 UTC on a date is the start of that date, not the end of the one before, so print the weekday alongside every deadline you set rather than inferring it.
The checklist
- 1. Read balance, total received and total sent. Compute differences in satoshis with a calculator.
- 2. Tabulate distinct incoming amounts with counts. A repeated constant near the dust limit means software.
- 3. Decode every OP_RETURN and group identical payloads. Count the distinct ones, not the total.
- 4. Open one transaction, read all outputs, follow the largest one, and look at its address’s totals.
- 5. Sum the fees and compare to the delivered value. Fees above delivery means delivery was not the point. Separately, sum virtual bytes per block before calling anything congestion.
- 6. Compare every address in full and mechanically. Never on four characters at each end.
This is the forty-seventh entry in the Bitcoin Mastery field guide series. It follows #44 on sidechain peg incidents, #45 on whitehat bounty demands and #46 on blockchain rollbacks, which together cover the incident this guide’s examples are drawn from. The full index is in the Reading Room.
Marker AG1 for this guide, so the method is tested rather than asserted: the desk will re-pull the whitehat address at 06:10 UTC on Wednesday 16 September and publish the ico-20 share of its lifetime transaction count. Today it is 77.8%, on 1,110 of 1,426. If the share has risen materially the flood continued; if it has barely moved, check 5’s fee arithmetic predicted the stall correctly and the burst was as shallow as its economics suggested.
Method: prices, funding, open interest, basis, mining and on-chain figures in this article are pulled directly by Bitcoin Mastery at the timestamp stated — Bitstamp BTC/USD daily candles for closes, Binance BTCUSDT spot and USDT-margined perpetual for intraday, open interest, funding and account ratios, Binance COIN-M quarterly contracts for basis, mempool.space for difficulty, hashrate, pool shares, fees, address balances and individual Bitcoin transactions, blockstream.info’s Liquid API for sidechain block heights, hashes, timestamps and transaction counts, alternative.me for the Fear & Greed series, CoinGecko for altcoin daily prices, Farside Investors’ table for ETF flows and US Treasury CMT par yields for rates. Transaction counts, fee totals, byte totals and OP_RETURN payloads are recomputed from the full confirmed transaction list of the address concerned, not read off a summary. Where a third-party figure is cited we name the source and its date; where two sources disagree we print both. Every streak or extreme figure is published with the first date of its series in the same sentence.
Disclaimer: This article is for informational purposes only and does not constitute investment advice. Cryptocurrencies are volatile and you can lose money. Nothing here is a recommendation to buy or sell any security, digital asset, token or exchange-traded fund, including MSTR, L-BTC, HYPE, ORDI or the LEAF token where discussed above. Token sales of the kind described in this article are unaudited, frequently anonymous and have no obligation to deliver anything in return for a payment; treat any coin sent to one as capable of going to zero. Do your own research and consult a licensed financial advisor before making investment decisions.