Digital forensics for dead tokens

Every rug leaves a timestamp.

When a token dies, the explanation usually arrives as rumor: a screenshot, a deleted post, a group chat arguing about who moved first. The chain has the answer the whole time, written in order, signed, and permanent. Afterburn Protocol reads that record and returns it as a report you can hand to someone else.

Each case reconstructs the full sequence: when the pool was at its deepest, which wallet sold into it first, how many blocks passed before liquidity was withdrawn, and where the proceeds went after the pool was empty.

Buy $BURN Open the sample case

REPORT COMPILED 0000-00-00 00:00:00

Resolution One block Every event is placed at the block it settled in, not the minute it was noticed.

Source Chain state only Pool reserves, swap logs, transfers, authority changes. No social feeds, no claims.

Output A written case file Ordered timeline, wallet annex, classification, and the queries behind each line.

When a token dies, know why

A clear record after the fact is worth more than a warning that arrived too late.

Most token failures are never explained. Trading stops, the chart flatlines, the project account goes quiet, and within a day the people who lost money are arguing about a version of events nobody can check. That argument tends to settle on the loudest account rather than the correct one. Someone decides it was a slow bleed. Someone else is certain the team sold. Both are guessing from the same screenshot.

The uncomfortable part is that the answer already exists. Every removal of liquidity is a transaction. Every sale is a transaction. Every transfer of authority over the contract is a transaction. They are ordered, signed, and cannot be edited after the fact. What is missing is not the data. What is missing is somebody willing to read the data in order and write down what it says.

That is the entire job of a post-mortem. It does not recover anything. It does not accuse anybody of a crime. It establishes a sequence: this happened, then this, and there were four seconds between them. Once a sequence exists, the conversation changes shape. Instead of who to believe, the question becomes what the record supports.

A written record also outlives the moment. Six months after a failure, the group chat is gone and the screenshots are unsourced, but a case file still names the wallets, the blocks, and the amounts. If the same funding cluster shows up behind a new launch, the old report is the thing that makes the pattern visible rather than a vague feeling that the name sounds familiar.

There is a quieter reason to want one. Losing money to a failure you do not understand is a different experience from losing money to one you do. The first leaves you suspicious of everything, including your own judgment. The second is simply an expensive fact with a date attached. A post-mortem cannot return the position, but it can end the part where you keep re-litigating it.

A post-mortem is not an accusation. It is a sequence with the times filled in.

What we reconstruct

Four layers are pulled for every case. Each one is assembled from chain state alone and each one is reported with the query that produced it, so a reader can go check.

Liquidity removal timing

The pool is read block by block across the life of the token, so depth is a curve rather than a single number. Every mint and burn of LP tokens is matched to the wallet that signed it and to the reserve change it caused, which separates a genuine withdrawal from a routing artifact or a rebalance.

The number that matters most is rarely the size of the removal. It is the interval: how many blocks sat between the last liquidity added and the first removed, and whether the removal was split into pieces small enough to avoid attention. A pool drained in one transaction and a pool drained in nine over twenty minutes look identical on a chart and read very differently in a report.

LP mint and burn events, per wallet
Reserve delta per block across the full window
Interval between final add and first removal
Share of depth removed per transaction

Sell pressure and price impact

Swaps are grouped by the wallet that originated them and measured against the depth of the pool at that exact block, not against the daily average. A sale is only large if it is large relative to what the pool could absorb at the moment it landed, and that ratio is what gets recorded.

Each sale carries its realized price impact and the slippage tolerance the sender was willing to accept. A wallet that sets a wide tolerance right before a collapse has told you something about what it expected. Ordering those tolerances against the removal timestamp usually produces the clearest line in the whole report.

Swap volume by origin wallet, per block
Trade size as a share of pool depth at execution
Realized price impact per transaction
Slippage tolerance set by the sender

Wallet flows and funding clusters

Each wallet involved in the exit is traced backwards through its funding history until it reaches an exchange deposit, a bridge, or a wallet that funded several other participants. Shared funders, matching deposit sizes, and addresses created within minutes of each other are the three signals that turn twenty separate sellers into one actor operating twenty keys.

The trace continues forward after the pool is empty. Proceeds are followed through consolidation hops until they reach a bridge, a mixer, or an exchange, and the report states plainly where the trail becomes unreadable rather than implying it continued somewhere convenient.

Backwards funding graph to first external source
Shared funder and common-origin detection
Wallet creation time relative to launch
Forward consolidation path and exit venue

Contract permissions and changes

The contract itself is read for what it allowed. Ownership, upgrade rights, mint and freeze authority, transfer restrictions, and any adjustable fee are captured at deployment and then diffed against their state at the moment of the incident.

A permission that is quietly restored an hour before the collapse is one of the few findings that is close to unambiguous. It is also the layer most often skipped, because it requires reading the contract rather than the chart, and it is frequently where a failure was arranged well in advance of being executed.

Authority state at deployment
Ownership and upgrade transfers, timestamped
Fee or transfer-restriction changes before the event
Diff of permissions at deploy versus at incident

03 CASE FILE 000247 · ILLUSTRATIVE SAMPLE

The incident timeline

Every report opens with a timeline like this one. Select any entry to open the trace behind it: the block it settled in, the wallet that signed it, and the reading the analyst recorded. Entries open independently, so two moments can be held side by side.

00:00:00 BLOCK 4 812 006

Token contract deployed by a wallet created eleven minutes earlier. The first liquidity pool is funded in the same block. Mint authority is retained at deploy, which is common and not a finding on its own.

Signer
SAMPLE_DEPLOYER_A1

Initial depth
31.0 units

Wallet age
11 min

Authority
mint retained, freeze retained

READING Baseline established. No action required.
00:06:24 BLOCK 4 812 322

340 distinct wallets take a position in the first six minutes. Backwards tracing finds 19 of them funded within the same hour by a single upstream address, in near-identical amounts. They hold 14.1 percent of supply between them and none of them sell during this window.

Buyers
340

Shared funder
19 wallets, 1 source

Cluster supply
14.1 percent

Deposit variance
under 2 percent

READING Cluster noted. Not yet conduct, only structure.
00:41:12 BLOCK 4 814 060

Pool depth peaks at 118 units. This is the reference point every later figure in the report is measured against. No single wallet outside the pool holds more than 9.2 percent of supply at this block.

Peak depth
118.0 units

Largest holder
9.2 percent

LP adds to date
7

LP removals
0

READING Reference depth set for all later ratios.
01:51:40 BLOCK 4 816 851

The deployer calls a function that re-enables a transfer restriction which had been switched off shortly after launch. The change is announced nowhere and is visible only in the contract state. Six minutes later the first large sale lands, and it originates from an exempt address.

Caller
SAMPLE_DEPLOYER_A1

Change
restriction off to on

Exempt list
3 addresses

Lead time
6 min 23 s

READING Preparation. This is the earliest defensible marker of intent.
01:58:03 BLOCK 4 817 043

A wallet holding 9.2 percent of supply sells its full position in a single transaction with slippage tolerance set to 49 percent. The realized impact is 31 percent. Backwards tracing puts this wallet in the same funding cluster identified at 00:06:24.

Seller
SAMPLE_EXIT_C4

Size vs depth
0.42

Slippage set
49 percent

Realized impact
31 percent

READING Tolerance that wide is a statement about expectations.
02:03:47 BLOCK 4 817 215

LP tokens are burned and 96 percent of remaining depth leaves the pool in a single transaction signed by the deployer. Eighty-two minutes separate the final liquidity add from this removal. No portion is returned in any later block.

Signer
SAMPLE_DEPLOYER_A1

Depth removed
96 percent

Add to removal
82 min

Transactions
1

READING The pull. Single transaction, no attempt to obscure the size.
02:03:51 BLOCK 4 817 217

With the pool empty, every remaining sell reverts. Price freezes at the last executed trade, four seconds after the withdrawal settled. Proceeds are consolidated across three hops over the following hour and reach a bridge, where the trail becomes unreadable from this chain alone.

Reverted sells
214

Holders left
326

Consolidation
3 hops, 61 min

Trail ends
bridge contract

READING Case closes here. Where the trail ends is stated, not guessed past.

What the report looks like

The timeline is one page of the case file. The document around it carries the classification, the findings, the wallet annex, and the queries used to produce every figure. Below is the front sheet of case 000247.

AFTERBURN PROTOCOL · INCIDENT REPORT

Case 000247

CLOSED

Subject: SAMPLE_SUBJECT_0247
Chain: Solana
Window: block 4 812 006 to 4 817 217
Duration: 02:03:51
Classification: Liquidity withdrawal by deploying key
Confidence: High. Four independent layers agree.

Findings

F1
A transfer restriction was re-enabled by the deploying key 6 minutes 23 seconds before the first large sale, with three addresses left exempt.
F2
The first large sale came from a wallet inside a 19-address cluster funded by one upstream source before launch, in amounts varying by under 2 percent.
F3
96 percent of remaining depth was withdrawn in a single transaction 82 minutes after the last liquidity add, signed by the deploying key.
F4
Proceeds were consolidated over three hops in 61 minutes and reached a bridge contract, at which point the trail leaves this chain.

ANNEX A: 22 wallets, full funding graph ANNEX B: 41 queries, reproducible PAGES: 14

Case 000247 is illustrative. It is built to show the shape of a report and the level of detail each section carries, not to describe a specific token.

How a case is handled

The method is deliberately narrow. A report that overreaches once is worth nothing afterwards, so the discipline is in what gets left out.

STEP 01

Fix the window

The case is bounded by two blocks: deployment and the last executed trade. Nothing outside that window enters the timeline, and the boundary is stated at the top of the report so the scope cannot drift later.

STEP 02

Rebuild the state

Pool reserves, swap logs, transfers, and contract authority are replayed block by block across the window. Nothing is sampled and nothing is averaged, because the interesting intervals are usually shorter than any sampling rate would survive.

STEP 03

Separate fact from reading

Every line splits in two. The fact is what the chain recorded. The reading is what an analyst concluded from it. They are printed in different type so a reader can accept one and reject the other.

STEP 04

Publish the queries

Each figure ships with the query that produced it. A report nobody can reproduce is an opinion with a serial number on it, and the annex exists so a reader can run the work again and disagree with evidence.

What a report cannot tell you

It cannot establish who controlled a key. The chain records that an address signed a transaction. Whether the person behind it acted alone, was compromised, or was one of several holders of the same key is outside what any onchain record can settle.

Funds that pass through a bridge or a mixer are not followed. When the trail leaves the chain, the report says so in that sentence and stops. A confident guess about the other side is the fastest way to make every other finding unreliable.

It cannot prove intent. A permission restored before a collapse is a fact with a timestamp, and the report will say exactly that. Calling it a plan is a legal conclusion, and this is a forensic document, not a verdict.

It cannot recover anything. A post-mortem closes the question of what happened. It has no mechanism for returning a position, and any product that suggests otherwise is selling something other than forensics.