# Guglielmo Anfossi Blockchain investigations and investigative systems. Tracing digital assets across mixers, bridges, DeFi and services for legal and compliance teams. I gather information from adversarial systems. Today, my focus is blockchain investigation. I trace illicit funds across mixers, bridges, DeFi and exchanges, identify the services used to move and launder them, and turn on-chain activity into evidence that investigators, compliance teams and legal professionals can act on. My work has involved investigations alongside Swiss law enforcement, the US Secret Service, UK law enforcement, compliance teams, legal professionals and cryptoasset businesses. Over time, my work moved from investigating transactions to understanding the systems behind investigations: how behaviour can be represented, how patterns can be formalised, and how investigative reasoning can be made reproducible. ## Investigative systems I design deterministic systems for structuring blockchain investigations, formalising investigative patterns and reducing repetitive analytical work. My work in this area includes: - ontology engineering - graph-based investigation - pattern classification - deterministic tracing - knowledge representation - automated reporting The question behind this work predates blockchain. I trained at the Brera Academy of Fine Arts in Milan, where I also tutored semiotics and pedagogy, and graduated with highest honors with a thesis on semiotic relationships across systems. Its question was simple: how can we infer the structure and behaviour of one system from what it leaves behind? An investigation is that question under a deadline. I continue exploring it in Constraints, my newsletter on what blockchains reveal and conceal, and through research projects and prototypes such as Container NFTs, Atomic Barter and Portable Sentinel. Each explores, in a different way, what can be proven, exchanged or observed between systems. I am interested in what remains when a system is adversarial, incomplete or deliberately opaque. Blockchains happen to be a particularly good place to look because even when activity is deliberately obscured, the traces remain. Outside blockchain, I write short stories and poetry in Italian, and I have created installations and other artistic work. ## Credentials - Crystal Expert EVM Investigator (CEEI), Crystal Intelligence, 2026 - Crystal Expert UTXO Investigator (CEUI), Crystal Intelligence, 2026 - Neo4j Certified Professional, Neo4j, 2026 ## Public case notes - $10.5M USDT: Investigative work behind a single-case freeze and recovery of $10.5M in stolen USDT, with Swiss authorities. (Work carried out as part of a small team.) - 11.7K BTC: Bitcoin traced through a mixer. Overflow analysis narrowed the window; volume isolated the cluster. (Work carried out as part of a small team.) - Inferno Drainer: One campaign’s operator, isolated among thousands sharing the same contracts, from on-chain data alone. ## Profiles - [Website](https://anfossi.systems/) - [LinkedIn](https://www.linkedin.com/in/sincronik) - [GitHub](https://github.com/Bottegatecnologica) - [Constraints newsletter](https://www.linkedin.com/newsletters/constraints-7476766685643919360/) - [Are.na](https://www.are.na/guglielmo-anfossi) ## The Transfer That Never Happened (Delta-Neutral Siphoning) Delta-neutral siphoning moves value without a single transfer, which is why it walks straight past the method most investigations start with. URL: https://anfossi.systems/writing/the-transfer-that-never-happened/ ![The Transfer That Never Happened](./assets/delta-neutral-siphon.png) Some questions arrive about performance, not theft. A book has lost steadily for months, and the people whose money it is want to know whether that is bad luck, bad judgment or something else. A trace of the funds comes back clean: deposits, trades, settlements, no transfer to anyone. Sometimes it is something else, with a shape I now look for whenever someone trades other people's money with a share of the upside: delta-neutral siphoning. It moves value without a single transfer, which is why it walks straight past the method most investigations start with. ## How it works The pattern needs two books. The first belongs to a fund or a company, traded by someone paid a share of its gains: a performance fee, a bonus, carry. The second is his own, somewhere else, holding the opposite side of the same exposure. It need not be the same instrument or venue: a long perpetual on one side can be mirrored by a short position built from options on the other. The hedge does not need to be perfectly delta-neutral at every moment. What matters is that the two positions create opposing economic exposures over the relevant trade. The sizing is what turns a hedge into a siphon. The personal leg is sized so that its payoff mirrors his bonus. In the simplest linear case, with a 5% performance fee, that means 5% of the fund's position. Run the numbers on that simple case. Every dollar the fund gains pays him 5 cents of bonus and costs him 5 cents on his own book: net zero. Every dollar the fund loses pays him 5 cents on his own book, and there is no bonus to give back. He never gains from the fund's success and always gains from its failure. What he collects is a fixed share of every loss the fund books. ## Why it looks reckless Winning trades leave him flat, and losing trades pay him in proportion to the loss. What he wants, then, is exposure that can produce large losses while his personal hedge remains alive, which creates an incentive for volatility and concentrated risk. From the fund's side it reads as conviction bordering on recklessness. From his, every large loss is a large payout. In most small and mid-size setups a bonus is paid on gains and rarely clawed back on losses, so the fund has effectively handed him an option-like payoff on its own losses. Stricter structures, with a hard high-water mark or a real clawback, tighten the numbers without closing the door. One habit gives it away: no leverage, above all on his own book. A leveraged personal leg can be liquidated by a swing in the fund's favour before the fund's trade has had time to lose. If the market then turns, the fund loses and he is no longer on the other side to collect. The fund's leg has to be allowed to lose in its own time, so his leg has to survive whatever comes first. (This does not rule leverage out entirely: he could still use it when his position is taken in conjunction with orders on the other side.) A trader chasing losses usually reaches for leverage first. Recklessness without leverage is a strange kind of recklessness. It looks less like a mood than like a constraint someone is respecting. ## The governance tokens The siphon has running costs: fees, funding and spread on both legs, paid on every trade. Farming is how those costs get paid down. Put the personal leg on a DeFi protocol that rewards activity with its governance token, and every mirrored trade earns rewards and airdrops on top of its share of the fund's losses. That makes it a second channel of extraction. The fund's losses pay him directly, while the trading activity that accompanies those losses is rewarded again by the protocol's incentives. What accumulates on top is a vote that can be sold: a claim on how the protocol is run, bought with trading the fund financed. ## How it shows up With no transfer to follow, the evidence is a symmetry. Exposures offset across two books, entries and exits fall in the same windows, and the personal leg holds a steady proportion of the fund's position. Over many trades the net result points one way, and the fund's appetite for risk rises exactly as the second book grows. A single trade is noise. The series is the signature. On its own, the signature is a reading, and I mark it as one. It becomes record through something outside the trades, and the most reliable one is the bonus itself. After a winning stretch the fund pays him, and his own leg has just lost by about the same amount. The payout has to go somewhere, and it usually goes back into that leg, restoring the proportion before the next trade. That refill is the one real transfer in the whole scheme: from the fund, through his pay, into the book on the other side. The shape says where to look. The refill, together with the same proportion and timing across both books, is what a court can check. The investors see a bad quarter and a trader who took too much risk. The protocol sees volume. The only trace of the transfer is a loss that someone else hedged too well. ## The Strings Stay Public (Why Tracing Is Not Enough) Tracing funds walks edges until they end in a mixer, a nested service, a deposit address you cannot compel. It sees what moved. URL: https://anfossi.systems/writing/the-strings-stay-public-why-tracing-is-not-enough/ ![The Strings Stay Public (Why Tracing Is Not Enough)](./assets/marionette-header.png) Tracing funds walks edges until they end in a mixer, a nested service, a deposit address you cannot compel. It sees what moved. It never asks who arranged the movement, and that hand survives every wall built to stop the money. The wallets are a marionette, and the strings run through other layers of the same data. I pull four, each reaching a layer the money trail never touches. ## Who built it Contracts have authors: a deployer, an upgrade admin, role holders, multisig signers. None of it is money, all of it is public, and it rarely matches the wallets on stage. I built my own tool for this layer, because nothing in my toolkit did it and reading it by hand kept losing details: a role granted three upgrades ago, a signer swapped on a multisig, a deployer funded two hops back. From known tokens and contracts it climbs to their deployers, the deployers' deployers, and whoever paid their first gas, reading proxy admin slots, role grants and signer lists on the way. Every edge is one on-chain fact with its transaction, and the same input returns the same tree. ![Control tree across Ethereum and Polygon: funders, signers, Safe, controllers and contracts, with the same addresses linked across chains.](./assets/marionette-control-tree.png) *Control tree across Ethereum and Polygon: funders, signers, Safe, controllers and contracts, with the same addresses linked across chains.* What comes back is mostly addresses you did not have: sometimes one freshly funded wallet at the root of several "unrelated" launches, the same signer on every admin multisig. The money ends in a dozen places. The authorship converges. ## Where it was rehearsed A contract exploit is rarely fired blind. The attacker needs to know the call sequence works against the target, and the cheap place to find out is a public testnet, where gas is free and failure costs nothing. Rehearsals are careless in ways attacks are not. One key means one address on every EVM chain, so a reused deployer brings its practice history along. The work itself leaves a signature too. Sometimes the attacker deploys a contract, and the one used in the attack usually matches the one tested: the same bytecode, or at least the same function selectors. Sometimes nothing is deployed at all, and the rehearsal is a sequence of calls: the same functions of the target, hit in the same order, with the same kind of parameters. Either way, searching for the pattern finds the practice run and whoever ran it, even from an address never used on mainnet. And testnet gas comes from somewhere: a faucet, a bridge, a wallet that also funded something else. Two addresses the operator kept apart on mainnet meet in rehearsal, where nobody expected to be watched. The most careful criminals skip the testnet and fork mainnet locally, which leaves nothing to find. The trail catches the rest. Both strings live on public chains. The next one starts where the chain was built to go dark. ## Where it left a fingerprint Monero is the purest place built for edges to end: decoys, hidden amounts, off-chain recipients. You rarely need to beat that cryptography. Value has to enter and leave. Often both ends pass through the same swap service or exchange, from the same machine, and the service saw one device fingerprint on the way in and on the way out. The match sits in records a court can request, and the decoys never enter the question. Different services on each end make it harder, not impossible: many keep device and session data, and a fingerprint retained on both sides can still be matched. ## What they did, and when Three strings start from something in hand: a contract, a rehearsal, a service. Sometimes you hold only a behavior and need every wallet that could have produced it. That is what queries are for: a good one describes an act, not a flow. In the [Inferno Drainer](/writing/inside-inferno-drainer/) case, thousands of addresses were exploited by the same malware contracts in the same way. The query that worked asked which of them had touched the tokens of the attacked ecosystem, because whoever drained that protocol's users carries its tokens more densely than any other operator of the kit. Thousands became a few dozen, and one lit up. Time is the other filter. On a prediction market that resolves on news, the price shows when the news went public: the winning side jumps and stays. Only buyers before that moment matter. They still need an order, weighed on conviction (stake on the winning side), entry (surprise captured by the price paid) and record. Skilled traders lose often and win more. Someone betting on known outcomes almost never loses, and appears for one event rather than hundreds. A ranked list is not a verdict. It picks who deserves a manual look against news timelines and funding origins, and cannot tell inside information from exceptional analysis. That limit goes in the report, next to the ranking. ## What the strings are for None of this recovers anything alone. A deployer tree freezes no account, a testnet trace returns nothing stolen, a fingerprint seizes no coins, a ranking convicts nobody. Together they map the hands behind an operation from facts others can check and queries anyone can rerun, which is what enforcement, counsel and compliant venues act on. The money trail says where value landed. The strings say whose hand was on it. Most operations hide the first and forget the second. So a cold trail does not close the file. When the money goes dark, the marionette stops moving. The strings stay public. ## A Finding Stands Without You A report leaves my desk on a Tuesday and arrives, weeks later, in a room I have never seen. Opposing counsel reads it. URL: https://anfossi.systems/writing/a-finding-stands-without-you/ ![A Finding Stands Without You](./assets/image24.png) A report leaves my desk on a Tuesday and arrives, weeks later, in a room I have never seen. Opposing counsel reads it. A judge reads it, or an officer deciding whether a freeze is worth asking for, or a compliance analyst deciding whether to act on an address before the weekend. Nobody in that room can ask me what I meant in paragraph nine. Whatever the document does there, it does without me. Most investigative writing is not built for that room. It is built for the meeting where the author is present, answering questions and filling the gaps out loud. Those gaps are invisible while you are speaking, and they are the whole structure once you stop. This is the distinction I work to. A finding makes you see it. An opinion needs you to explain it. An opinion is a conclusion held up by its author's hands. It stands while you speak and it drops the moment you let go. A finding stays standing after you let go, because what holds it up is inside the document: the data, the steps, and the reason each step forces the next. Both can be true. That is the uncomfortable part. An opinion can be correct, reached by an experienced investigator with good instincts, and still be an opinion, because its correctness lives in the investigator rather than on the page. When the case moves and the investigator does not move with it, nothing travels. Finding the answer is half the work. Representing it so that someone else reaches it independently is the other half, and it is the half that decides whether the first half survives contact with anyone. ## Two layers, and the line between them The raw material helps here. On-chain data is not a statement made by someone, it is residue left by something. Nobody wrote a transaction to be read, which is why it cannot be phrased, spun or softened, and why I trust it more than any document a party hands me. It is also why it never tells you who. A name laid over a residue is a reading, and a reading is an act performed by a person. So every report I write has two layers. What the chain forces, and what I concluded from it. Both belong in the document. Only one of them is checkable by looking, and the reader has to be able to tell which sentences are which without asking me. That sounds easier than it is, because the two layers are written in the same sentences, in the same tone, and a conclusion inherits the authority of the data sitting next to it. "The funds were consolidated by the attacker before the swap" is one clause of record and one clause of attribution, fused. The record part is a set of transfers into one address. The attribution part is mine, resting on timing, on control, on behavior consistent across addresses, and each of those is a judgment someone can dispute without disputing a single transaction. Splitting that sentence costs a paragraph and buys the whole document. The transfers go where they can be reproduced from primary data. The attribution goes where it is named as an attribution, with the grounds under it and the alternative it rules out. ## Where the reading always enters Some of these joins are so routine that they stop looking like inferences, and those are the ones worth marking hardest. A cluster is a model, not a fact about the chain. Common-input heuristics and behavioral similarity produce a grouping that is usually right and occasionally load-bearing, and when it is load-bearing it has to be visible as a hypothesis with evidence under it rather than as a name on a diagram. The purpose of a contract call is read from its code and its effects, not from its label. A decoded payload shows what executed. What it was for is my sentence. Intent is never on the chain at all. The chain records the movement. Whether that movement was theft, a withdrawal, a service payment or a mistake is a reading built from context that mostly lives off-chain. None of these should be kept out of a report. A document that refuses to interpret is not evidence of rigor, it is a set of transaction hashes that leaves the whole job to the reader. The discipline is in interpreting out loud, in a way that lets somebody accept the data and reject my reading of it, which is exactly the move an adversary will try to make. ## The assumptions that never get written There is a quieter version of the same problem. The premises I do not state are the ones I no longer notice: that a labelled address still belongs to whoever it was labelled as, that a data source reflects the chain's current state, that a balance shown by a platform tracking transfers matches what the contract itself would say, that the scope I was handed rests on a correct account of what happened. Each of those can be wrong without anything in my reasoning looking wrong. Stating them changes the failure mode. An unstated assumption that turns out to be false takes the conclusion down with it silently. A stated one gives the reader a place to check, and gives me a document that fails loudly, which is the only kind of failure worth having. ## Who has to be able to walk it None of my readers can take my word for it, and this is not a matter of trust. An analyst validating a freeze request works against criteria I do not set. An officer, in most jurisdictions, cannot adopt what I found at all, because the investigation has to be theirs and every step they cannot reproduce is one they rebuild from nothing. A lawyer takes me as the expert and comes back with objections that should have been answered before they were raised. The requirement is constant across all three, and the shape it arrives in is not mine to choose. What survives the difference is the separation itself: a document whose layers are already apart can be re-cut for a reader who needs it presented another way. One that fused them has to be rebuilt from the beginning. ## The test Hand the work to someone who wants it wrong. That is not a thought experiment in this field. Adversarial review is the default condition: a defense lawyer, an exchange's counsel, a colleague paid to find the seam. If they reach my conclusion only while I walk them through it, it was never a finding. It only looked like one from where I was standing. It is also why I prefer deterministic, auditable reasoning to opaque probabilistic output. Probabilistic output is often accurate. Auditable reasoning can be shown to be wrong, and that is the only condition under which being right means anything. The complication I will not pretend away: sometimes the strongest conclusion available is probabilistic, and no amount of discipline turns it into a proof. A cluster attribution resting on behavioral similarity is a reading, and it stays a reading however many analysts share it. The honest move is to mark it as one, in the sentence where it appears, and keep it structurally separate from what the chain forces. A report written that way has fewer confident lines in it. It survives cross-examination on the lines it kept. Most cases I have watched fall apart did not fall apart over the data. Both sides had the same data. They disagreed about what the data was allowed to mean, and the side that lost was usually the one whose document could not show where its own meaning had been added. ## Where this leaves the writing Pedagogy set the standard and I still work to it: a reconstruction nobody can walk through without me is only a report that a reconstruction once happened. So I do not write to be believed. I write to be understood by someone who is not in the room, every step laid down for a reader to walk alone, and to break if they can. The practical form of that is unglamorous. Stated premises, inferences labelled as inferences, and fewer sentences that sound certain. What it buys is a case that keeps working when I am not there to defend it, and an error that can be found by someone other than me. An opinion can be right. A finding stands without you. Could an adversary reach your conclusion from the document alone? ## The Magic of Flash Loans (Part 2): The Next Octave A wall taken down at one layer has a way of reappearing at the next. Silence it in one octave, and it returns in another. URL: https://anfossi.systems/writing/the-magic-of-flash-loans-part-2-the-next-octave/ ![The Magic of Flash Loans (Part 2): The Next Octave](./assets/image23.jpeg) A wall taken down at one layer has a way of reappearing at the next. It is less a wall than a note: silence it in one octave, and it returns in another, altered in pitch but unchanged in character. Part one ended with a simple claim. [Flash loans removed one constraint](/writing/the-magic-of-flash-loans-part-1-capital-was-never-the-constraint/), capital, and what fills the space that opens up is decided by us. You no longer need to own a fortune to act on Ethereum; you can borrow millions for the length of a single transaction, as long as you can write the code that pays it back. The contest moved from wealth to engineering. This episode is about what is filling that space. The short version: the opportunity is going private. When I was building my small liquidation scraper, everything I needed was public. Positions sat on-chain for anyone to read. Pending transactions waited in a public waiting room, the mempool, where anyone could watch them before they were confirmed. That openness was the quiet assumption behind the whole promise of flash loans. Capital could be borrowed, and the opportunity could be seen. A person with a laptop and a good idea could, at least in principle, compete. That second half is quietly changing. A growing share of transactions never enters the public waiting room at all. Wallets and apps send them straight to a small number of specialised companies called builders, the ones who assemble the blocks that make up the ledger. Some wallets sell the right to see their users' transactions first, in private auctions, and hand part of the proceeds back to the user. Builders who receive the most exclusive flow can assemble the most profitable blocks, win more of them, and attract even more exclusive flow. It is a flywheel, and left alone it spins toward fewer hands. It has not closed the market: builders still compete, and some private routes are built to share flow with many of them. But the pull runs in one direction. The consequence is simple to state. A flash loan can lend you the capital for a trade. No loan can lend you the view, or the place in line that turns what you see into something you can act on. If the opportunity is sold before it ever becomes visible, let alone actionable, it does not matter how good your code is: you never get to see it, and even if you did, someone else has already been given the right to move first. Capital stopped being the moat; access is becoming the new one. It would be easy to make the private channels the villain of this story, and that would be dishonest. The same curtain protects ordinary users from the sandwich described in part one, the person in the queue who sees your hamburger order, cuts in front of you and sells it back at a higher price. A transaction sent through a [protected route](https://docs.flashbots.net/flashbots-protect/overview) cannot be spotted by those bots, a protection that already covers a good part of everyday trading, and some users even get paid a share of the value their transaction creates. So the private channel is two things at once. It shields the individual from predators. And it changes who the opportunity belongs to. In the open waiting room, the chance to profit from a transaction went to whoever spotted it and built the best response. Behind the curtain, that same chance becomes something a wallet or a builder can hold, price and sell, and it goes only to whoever has the right agreement. The opportunity does not disappear. It gets an owner. The honest position is to hold both sides at the same time, not to collapse them into a slogan. And the flywheel does not stop at the builders. By 2026, what sits on top of Ethereum is no longer only a price. It is a yield. Ethereum is secured by people who lock up their ETH as a guarantee of good behaviour, a practice called staking, and who are paid for keeping the network running. Today you do not have to do any of that yourself. You can buy an ETF, a fund traded on the stock exchange like any share, that [holds ETH, stakes it, and passes the income on to you](https://www.ishares.com/us/products/348532/ishares-staked-ethereum-trust-etf). The fund does not run the machines itself. It hands the ETH to specialised companies that keep it safe and operate the infrastructure, while the people who own the fund never touch it. The ETF is a straw into the network, and a great many people drink through it without once seeing the machinery underneath. It is tempting to call this a threat to decentralization and stop there, but the word is too blunt to be useful. It helps to separate three different jobs. The first is confirming blocks: this is done by validators, backed by the staked ETH. The second is deciding what goes into each block: in practice this is done by the builders. The third is the waiting room, where transactions sit before anyone picks them up, in plain view or behind a curtain. Staking ETFs concentrate the first job. Private flow concentrates the second and the third. Neither automatically causes the other. The danger is in what happens when they meet. A validator on its own has a mostly economic power: it takes part in confirming blocks and gets paid for it. Economic power is loud and tends to limit itself. The power that matters is quieter. When a large share of the stake relies on the same few builders, and those builders rely on the same private flow, the question stops being how much you are willing to pay to get your transaction through. It becomes whether your transaction gets through at all, and who decided. That is not a market. It is a gate. Here is the part I keep returning to. What matters about this stake is not simply its size, but its temperament. Ethereum's ability to resist censorship, to refuse to block a transaction because someone powerful wants it blocked, was never guaranteed by code alone. It also depended on the people running validators being many, scattered, and free to say no. The stake piling up behind ETFs changes who is in a position to say no. The investor owns a share of a fund. The fund's ETH sits with a custodian. The machines are run by regulated companies. The person who owns the ETF has no say in how any of it behaves. If that stake ends up concentrated in the hands of a few operators, and those operators lean on a few builders with exclusive flow, the network's ability to resist pressure depends less on the wishes of millions of owners than on the decisions of a handful of institutions. This is a risk to watch, not a behaviour already on display: large operators still tend to work with many builders. That does not make censorship inevitable. It changes where the ability to resist censorship lives. In a [previous episode](/writing/a-powerful-tool-will-not-save-you/) I argued that the danger of a powerful tool is not its power but its opacity. Here the danger is not the power of the stake either. It is the distance between the person who owns it and the machinery that uses it. None of this is settled, and Ethereum is not standing still. It has answered this kind of drift before, more than once. Two defences are being built against exactly this problem, and the shape they take is worth noticing. The first is inclusion lists. Under a proposal called FOCIL, a rotating group of validators publishes lists of valid waiting transactions, and a block that leaves them out is rejected. FOCIL has been [locked in as a headline feature](https://blog.ethereum.org/2026/09/07/protocol-hegota-eips) of Ethereum's next major upgrade, Hegotá. It takes away the power to leave things out. The second is encrypted waiting rooms. Proposals such as LUCID and Shutter keep the content of a transaction sealed until its place in the block is already fixed. Nobody can discriminate against a transaction whose content they cannot read, and nobody can sell a first look at something no one can see. It takes away the power to see what to leave out, and with it, part of the reason to make the opportunity private in the first place. Read together, the logic is plain. Censorship needs two powers: the power to see what you want to block, and the power to leave it out. FOCIL attacks the second. Encryption attacks the first. They act on the constraints, not on the actors. Whether they arrive fast enough, and whether they hold once this much regulated capital and this much private flow are inside the system, is the open question. I do not think it is decided. Which returns us to where part one left off. Flash loans were a lesson in how quickly a constraint everyone believed in can turn out to be optional. This is the other half of the lesson. A constraint that falls does not vanish. It relocates, and it tends to relocate somewhere less visible than where it started. Flash loans opened the opportunity to anyone who could write the transaction. The next octave decides whether anyone can still see it. Capital stopped being the constraint on acting and returned, an octave away, as the constraint on being seen and being included. Freedom on this network was never really about who can afford to act. It was about whether the network can still refuse to be told what to leave out, and who gets to look first. That is the constraint worth watching now, and it is the one no clever wallet can route around. ## The Magic of Flash Loans (Part 1): Capital Was Never the Constraint Flash loans look like free money. They are a primitive that removes the constraint everyone assumed was fundamental. URL: https://anfossi.systems/writing/the-magic-of-flash-loans-part-1-capital-was-never-the-constraint/ ![The Magic of Flash Loans (Part 1): Capital Was Never the Constraint](./assets/image22.png) Flash loans look like free money. They are something stranger: a primitive that removes the constraint everyone assumed was fundamental, and in removing it, shows which constraint was doing the real work. The first time I heard the term flash loan, I assumed someone was joking. A loan with no collateral, no credit check and no paperwork, where a wallet holding nothing at all can borrow millions for the length of a single transaction. Outside a blockchain that is not a financial product, it is a contradiction. Inside one it is one of the more elegant primitives anyone has built, and not for the reason people usually give. It does not conjure money out of thin air. It quietly changes what a loan is. Picture someone handing you a hundred million dollars. You can do whatever you like with it: trade it, liquidate positions, buy assets, sell them, move liquidity across protocols. There is one condition. Before the transaction ends, every cent has to come back, along with a small fee. If it does not, the transaction reverts and every step inside it is rolled back together. Not unwound partially, not settled at a loss. The failed attempt still costs you the gas you spent making it, and that is the only trace it leaves. That condition is the entire trick, and it rests on something the traditional financial system does not have. A blockchain executes a transaction atomically. From the lender's side the risk is close to zero. The funds return inside the same transaction, or they never left the vault. Repayment is not a promise you are trusted to keep. It is a precondition for the money existing in your hands at all. There is a detail worth making explicit, because it changes who the borrower even is. You do not take a flash loan by pressing a button from an ordinary address. The lender sends the funds and then calls back into the borrower to run the rest of the sequence, which means the borrower has to be code: a contract holding the whole thing, borrow, act, repay, as one programmed instruction the chain executes in one breath. Since the [Pectra upgrade](https://ethereum.org/roadmap/pectra/) an ordinary account can temporarily point at such code and act as that borrower itself, so deploying a separate contract is no longer strictly required. Either way the account can be empty of funds. What it cannot be empty of is logic. That idea held my attention longer than I expected. For a while I spent most of my evenings on EigenPhi, watching liquidations, arbitrage, just-in-time liquidity, and every other mechanism people were inventing on top of borrowed capital. At one point I built a small liquidation scraper of my own. Instead of monitoring every position across a lending protocol, I narrowed the search to wallets deployed through a specific contract that let users run recursive leverage loops, borrowing against their own collateral again and again to amplify their exposure to one product's incentives. Leverage of that shape does not simply enlarge a position, it shortens the distance to the liquidation threshold: the ratio between what is owed and what is posted moves faster than the price of the asset underneath it, so a fall that an ordinary borrower would absorb pushes a looped one over the line. When the underlying dropped, those wallets went first, and they unwound into liquidations far larger than average. I could not out-execute the professionals, who were colocated, tuned, and wired into private orderflow. So I tried to compete on the search space instead: fewer opportunities, each worth much more. I set it aside eventually, not because it could not work, but because I had more important things to build. What it left behind was a suspicion about where the real limits in finance actually sit. Flash loans quietly loosen one of the oldest of them, which is capital. If an operation is guaranteed by construction to end with more than it started, and by enough to cover the loan fee and the gas, you no longer need to own the money to run it. You borrow it for the span of a single transaction and hand it straight back. The barrier does not disappear so much as move, and where it moves to is worth watching: who sees the opportunity first, who can get their transaction into the block on the right terms, who can act without broadcasting their intention into a public mempool, who sits closer to the network, who has built the better machine. The contest shifts away from wealth and toward engineering. Most people meet flash loans through stories of exploits, which is a shame, because many of their uses are ordinary and useful. Arbitrage is the clearest. Suppose ETH trades at three thousand dollars on one venue and three thousand and ten on another, and both of them are on-chain, because that is the condition that matters here: a transaction can only be atomic across things the chain itself settles. You can borrow fifty million through a flash loan, buy on the cheaper venue, sell on the dearer one, repay the loan with its fee, and keep what is left, having never owned fifty million at any point. Whether anything is left is a separate question, since the fee, the gas, and the price impact of pushing fifty million through a pool all eat into that ten dollar spread first. What you needed was not the capital. It was the ability to run every step as one indivisible act. Liquidations are the other honest case. Lending protocols let people borrow against collateral, and when the collateral falls too far, someone has to repay part of the debt and take the collateral at a discount. Without flash loans that job is rationed by access to deployable capital: it belongs to whoever happens to be sitting on enough of it at the right moment. With them, anyone who can write the transaction can borrow the repayment amount, close the unhealthy position, sell the collateral, return the loan, and keep the bonus. The protocol stays solvent, the bad debt is cleared, the liquidator is paid. It is a mechanism where the incentives happen to point the right way. Like any primitive with this much reach, it is neutral about how it is used, and the same atomicity that makes arbitrage clean makes certain attacks cheap. One is liquidity manipulation. Many protocols quietly assume that prices or pool depth stay roughly stable across a transaction. A flash loan can flood a pool with capital, distort its state for the length of a few instructions, exploit a second protocol that trusts that distorted state, and drain the capital back out before the transaction closes. Nothing was broken at the protocol level. A protocol had taken a number that was cheap to move and treated it as a reading of something expensive to move. The assumption was simply false, and the loan was large enough to prove it. Then there is the sandwich. Imagine you are standing in line to buy a hamburger at the posted price. The person behind you sees your order before it is filled. They step in front of you, buy the last hamburger at that price, which pushes the price up, and then turn around and sell it to you at the higher number, keeping the difference. You still walk away with your hamburger. You just paid more for it than you would have a moment earlier, and the extra went to someone who did nothing but stand between you and the counter. On-chain the counter is a decentralized exchange, the queue is the public mempool, and your purchase is the filling: the attacker buys just before you and sells just after, wrapping your transaction on both sides. A flash loan can pay for that position, so the attacker does not have to own the capital that moves the price. But capital was never what made this hard. This is why modern MEV is not mainly a story about money. Capital still matters, and some strategies are made of little else. But once temporary liquidity is available to anyone who can write the transaction, it stops being the thing that separates the people who capture value from the people who watch it go past. What separates them is information, position, and execution: who sees the opportunity first, who can get their bundle into the block that actually gets built, who avoids leaking their intent into the open, who has built the machine that does all three a little better than everyone else. And getting there is not a footrace to the validator. It is an auction, run through searchers and builders and relays, where the bid is not only in gas. Capital stopped being the moat. The moat is now upstream, in the engineering. Which brings the whole thing back to where this newsletter usually starts. The magic of flash loans was never that they abolished collateral. It was that they exposed a mistaken assumption about which constraint was load-bearing. We treated capital as the wall, the thing you had to own before you could act, when capital was only ever a proxy for the constraint that actually bound: time, and the trust that has to fill it. Borrowing, trading, settlement and repayment were separate acts with gaps between them, and traditional finance has spent a century building machinery to survive those gaps. Credit lines, prime brokers, collateral agreements, netting, intraday facilities: all of it is a way of paying someone to carry the risk the gap creates. Atomicity does not manage the gap. It removes it, and with it the need to be trusted across it. Once that became possible, the wall we had been building against turned out not to be there. It made some markets dramatically more efficient and it handed some people a cheaper way to steal. All it did was remove one constraint. What fills the space that opens up is not decided by the primitive. It is decided by us. That raises a different question: where does the constraint reappear once capital is no longer the gate? ## Two Sweeps Pointed at the Same Address The tracing was done and the report was already with law enforcement when the client told me the part that reopened the case. URL: https://anfossi.systems/writing/two-sweeps-pointed-at-the-same-address/ ![Two Sweeps Pointed at the Same Address](./assets/image21.jpeg) The tracing was done and the report was already with law enforcement when the client told me the part that reopened the case. His wallet had been emptied weeks earlier. The seed phrase had leaked, the balance was gone before anyone noticed, and that is normally where the conversation ends. Part of his ETH had never been in the wallet. It was staked. Ethereum runs on two halves. The execution layer is the one everybody sees, where transactions are sent and balances move. The consensus layer is the ledger of validators, the machines that lock up ETH to secure the network and get paid for it. Staked ETH is credited to a validator over there, and it comes back to an ordinary address only when the validator leaves and the protocol pays it out, which is slow by design and visible to everyone. So there was money with a legitimate owner, untouched, scheduled to arrive in an address whose key a thief also held. The thief had to do nothing. His software was already waiting. ## The machine on the other side A sweeper bot is a script with one instruction: watch this address, and move anything of value out of it the moment it appears. Leaked keys are collected in bulk, from phishing kits, fake wallet apps, a seed phrase photographed into a cloud backup, and each one is handed to the same loop. The loop costs almost nothing to run, so it can wait for years. This account was close to ideal for one. A compromised key cannot be un-compromised. The payout address was not going to change either: once a validator's withdrawal credentials are set, pointing them at a clean address is not something the protocol offers today, whatever may come later. And the schedule was public, so both sides were reading the same screen. Quality varies at the other end. Cheap sweepers take the native ETH and leave the tokens, which is why victims sometimes find their ERC-20 balances untouched inside an account that empties itself every time it is funded. The better ones bring their own gas and take those too. Sending gas is the trap that makes most rescues fail. Moving a token takes a transaction, and a transaction takes ETH sitting in the same account, so rescuing a token means funding the account that holds it. That funding is exactly what the bot is watching for. Plenty of people meet their sweeper by feeding it, and watch the gas leave for another address seconds later. ## The tools for the ordinary case The stack I use when the account holds assets it cannot move and the gas has to come from outside is [Dark Florist's](https://dark.florist/), open source and free. The Interceptor is a browser extension that sits between the dApp and the wallet. It simulates every transaction before you sign it and says in plain language what it will do. Its simulation stack runs several transactions in sequence, as if they had been mined one after another, so you can see whether step three still works after steps one and two changed the state. It also lets you browse as any address without holding its keys, which is how a rescue gets built for an account you cannot sign for yet. Bouquet turns that simulation into a bundle. It lays out the sequence with values and fees, takes the signing keys and keeps them in the browser, and asks you to top up a temporary funding account with what the bundle needs plus a margin for a rising base fee. Rescue bundles go out through the relay only, so the funding is never exposed in the public mempool on its own, and nothing can be slipped between the funding and the rescue sweep. It also refuses to work on a stale picture, rejecting an import that did not come cleanly out of the simulation and warning when the transactions it holds no longer match what the simulation shows. With one attempt available, the refusal is the feature. The rest of the stack has the same shape, small interfaces with no backend to trust: Lunaria for sending tokens, NFT Sender for NFTs, Petal Lock for immutable ENS subnames, Horswap as a censorship resistant interface to Uniswap. ## The money arrives without a transaction Here the case stopped resembling anything I had done before. The consensus layer does not pay out by sending a transaction. The protocol raises the balance of the destination address directly, while the block is being built. No sender, no gas, no code running at the receiving end, nothing sitting in the queue of pending transactions where everyone watches for prey. Ethereum's own [documentation](https://ethereum.org/staking/withdrawals/) has a name for this way of paying validators out, and the name is the sweep: the same word the industry uses for what the thief's software does to a compromised account. ## The fight happens in the next block The absence of a transaction cuts both ways. There is nothing to front-run, and nothing to get ahead of: withdrawals from the consensus layer are credited after all the transactions in the block that carries them, so that ETH cannot be spent inside that block by anyone, thief included. Everything is decided at the top of the next one. And we did not know what the bot could see. A basic one reads the pending transactions in the public mempool, which is the thing you can hide from. A better one also reads each block once it is confirmed, reacting to the balance itself and not only to somebody's stated intentions, and it can follow the exit queue and see the payout coming roughly when we did. The gas trap did not apply here, and that helped less than it sounds. What was landing was ETH, and ETH pays for its own movement, so there was no funding to smuggle in and nothing to wrap it with. One transfer, out of an address that two parties can sign for, and the only thing left to win was position in the block after the credit. You can still stop broadcasting. Instead of entering the public mempool, the transaction goes privately to a builder through a relay, inside a bundle aimed at a specific block. That matters because you cannot line up a public transaction for money that has not arrived yet: execution clients reject it from their transaction pools. A bundle can wait for the block where the money will be. It is never gossiped across the public network while it waits, and if it is not included it simply expires without being mined, so the attacker has nothing to see and nothing to react to. The saved fee is not the point. Losing the block costs everything, because there is one credit and whoever moves first keeps it. So the choice was between two risks. Public, and be outbid inside the mempool by a bot that answers in milliseconds and pays more. Private, and depend on a builder carrying your bundle winning that particular block, against an adversary who may be reading the balance rather than the mempool, and who can stay public with an enormous tip that any builder in the market will take. How many blocks to cover, what to pay for each attempt, whether to stay private or go loud: those were the real decisions, there was no time to work through them properly, and I did not have the repetitions behind me to make them fast. ## Where I stopped [Flashbots](https://www.flashbots.net/) is the research organisation formed to study and mitigate MEV, the value extracted by whoever decides the order of transactions inside a block. Much of the infrastructure a rescue like this leans on came from there: the bundle model, MEV-Boost, Protect, and now BuilderNet. Whitehat rescues have lived in its orbit from the beginning. I introduced the client to them and stepped back. Every rescue I was familiar with had the same shape: the assets are still sitting in the account, and the opponent is a bot with a faster reaction time. This one was different in the parts that decide the outcome. The money arrives once. How the wallet was being watched, and what triggered the signature, we never knew. A miss cannot be taken back. Those are things you get right by having done them often, and I had not. I checked when the redemption came due. The money got out in time. Two sweeps were pointed at the same address, and only one of them was going to end up with the money. Method includes knowing which part of a problem you can time, and handing the rest to somebody who can. ## The Desk Opens on Monday The stolen value lands at an exchange on a Saturday night. You watch the deposit confirm. That desk opens on Monday. URL: https://anfossi.systems/writing/the-desk-opens-on-monday/ ![The Desk Opens on Monday](./assets/image20.png) The stolen value lands at an exchange on a Saturday night. You watch the deposit confirm. One action can stop it now and it is not yours to take: somebody at that exchange has to freeze the account, and that desk opens on Monday. A recovery turns on moments like that one. Stolen value cannot stay in motion forever, and sooner or later it comes to rest with somebody who holds it on the thief's behalf: an exchange, a broker, some custodial service. That is the window, and it exists because a third party now has the funds and can decline to release them. Most of the attention in this work goes to the tracing that finds the window. What decides the case is more often whether somebody is ready to act in the hours it stays open. The width of a window is not something you read off the chain. What governs the outcome is how much of that time somebody on the receiving end is awake, reachable, and authorised to act. A great deal of illicit value moves late on a Friday. The ledger is no darker then and the timing conceals nothing; it leaves the request with nowhere to land. Public holidays do the same with more leverage, joining two dead stretches into one, so a desk closing on a Wednesday evening may not reopen until the following Monday. And a recovery rarely depends on a single desk: the exchange sits in one country, the authority whose signature is needed usually in another, and their waits do not overlap. Each handoff begins when the one before it ends, so the delays add. The fastest thing that can happen to a case needs no authority at all. An exchange can freeze an account on its own initiative, before a court has said anything, and that is the only route quick enough to catch a window opening on a Saturday. It is conditional on form. Every venue has its own way of receiving such a request, and its compliance team has to validate what arrives against criteria you do not set and cannot see. A request they cannot validate is not usually refused. It comes back as a question, or it waits in a queue until somebody can classify it, and inside a window a slow answer and a refusal produce the same result: the money moves on. Most of the time you do not learn what they need until you have already sent something. The requirements are rarely published, they differ between venues and between the people staffing them, and they change. So the volley that happens at a lawyer's desk happens here too, compressed into hours. They come back wanting the path expressed differently: the bridge hops decoded in a more familiar way, or the share of each transaction attributable to fraudster-controlled funds calculated according to a methodology they recognise. And the same finding has to be restated in a structure their own systems will accept. Each question is another day against a window that is already open. I lost a window that way. I had sent an exchange the path as I had built it, with the bridge transfers evidenced from the transaction payloads, which is where the proof actually sits. The compliance team did not work in that form and could not check it. They came back asking, and I rewrote the report around links to the same transfers on a bridge explorer, in a view they could open and read without taking my word for any of it. The second version was correct, and so was the first. While the two of us established that, the funds left the exchange. Preparation, then, cannot mean knowing the answer beforehand. It has to mean producing a new version of the finding in hours rather than weeks: the decoding automated, the path already normalised, the evidence held in a form that can be re-cut on demand. The usual case for automation is speed, and speed of tracing counts for nothing by then, because the tracing is done. What automation buys is the ability to re-present a finished finding, in a shape nobody warned you about, before the window closes. What you build in advance is the capacity to rebuild the document, rather than the document. When that route is closed, or has been pursued as far as it can go, the case goes to one of two desks, and they are not interchangeable. On the civil route it belongs to a lawyer acting for the victim, who brings you in as the expert. On the criminal route it belongs to law enforcement, and in most jurisdictions they cannot adopt what you found: the investigation has to be theirs, conducted and evidenced independently, however good the work that reaches them. That obligation settles what the report has to be. A document written to persuade is the wrong object for a reader who is not permitted to be persuaded. What they need is a route they can walk themselves: sources, queries, and reasoning set out so each step can be reproduced from primary data on their own systems. Every step they cannot reproduce is one they have to rebuild from nothing, and rebuilding is counted in weeks. The report works better as a teaching document than as an argument. The lawyer's desk fails in the opposite direction. There you are taken as the expert, and what follows is a volley: why this address and not the one beside it, what rules out the innocent explanation, how this holds if the other side puts an expert against it. Each round of questions costs days. A report that answers them only once they are asked has spent the window on its own correspondence. Before any of that, the instruction itself needs reading. It comes from the lawyer, and it carries a non-technical model of what happened, so a scope drawn from a mistaken premise produces a narrow task, carried out correctly, that answers a question nobody needed answered. The cost stays invisible until the work comes back and the real question is still standing. Examining the assumptions inside the request, and saying so early, belongs to the work rather than to the courtesy around it. Whatever is handed across is closer to a photograph than to a live feed: the case as it stood when it was taken, faithful to its instant and to nothing after. None of it can be timed. The money surfaces when it surfaces and will not wait for the offices to open, so the preparation has to be finished before the night it is needed, down to one named person watching the few addresses that matter, so that a movement reaches somebody instead of a queue. A picture can also stop being true while nobody touches it. A balance can read as full after the tokens behind it have been burned, on platforms that follow transfers without reading the contract's own state. Whoever holds the case then acts in full confidence on a screen that stopped being accurate hours earlier, and speed is no protection, because the fault is in how the balance is represented rather than in the delay. Which is where this stops being a problem of logistics. Three readers, and the same requirement in three shapes: a compliance team that has to validate on its own criteria, an officer who has to rebuild the case as their own, a lawyer who has to defend it against someone paid to break it. None of them can take your word for it. Finding the truth is half of an investigation; representing it so that somebody else can reach it independently is the other half. The blockchain keeps no calendar. Everyone who can act on what it shows keeps one. Knowing where the money is changes nothing by itself: the work that decides the outcome happens before the window opens, and consists of making sure somebody is standing in it, holding a picture still true enough to act on. ## Achilles Catches the Tortoise Where It Has to Stop An investigation moves in steps. What it chases appears not to. Every action is discrete: you pull transactions, map a cluster, document a finding. URL: https://anfossi.systems/writing/achilles-catches-the-tortoise-where-it-has-to-stop/ ![Achilles Catches the Tortoise Where It Has to Stop](./assets/image19.png) An investigation moves in steps. What it chases appears not to. Every action is discrete: you pull transactions, map a cluster, document a finding. Each step costs time and resources, and each has to survive later scrutiny: authorized, reproducible, auditable. Automation only shortens the steps. The bottleneck it never removes is the delivery of the report, which stays a discrete, accountable act no matter how fast the tracing gets. The procedures that confer evidentiary weight are quantized by nature. You cannot half-file a report. A court will not accept a motion still in motion. Meanwhile the funds you documented an hour ago have already crossed a bridge and split into forty new addresses. The adversary lives under no such rule. They can split funds across hundreds of addresses, cross a bridge, enter a mixer, and do it again, at any hour, with no form to sign and no record to defend. Their motion looks continuous. While you commit to a snapshot, they keep going. But it only looks continuous. A blockchain is still block after block, transaction after transaction. The adversary's advantage is not the absence of discreteness; it is the absence of gates. No authorization, no documentation, no accountability. Without those forced pauses, their discrete actions blur into a kind of operational continuity. The shared discreteness does not erase the asymmetry. It shows exactly where it lives: in who is forced to stop between the units, and who is not. It is tempting to call that motion infinite. It is not, and the whole premise of this newsletter is why. An adversary in constant motion still runs on rails it cannot leave. Balances reconcile. Code executes exactly as written. Every transaction must satisfy the protocol's own validity rules. Speed is not freedom from constraint. The attacker can move without pause, but never without obeying the system that carries them. So the real asymmetry is not the one it first appears to be. Both sides are bounded, and both move in discrete events. What separates them is accountability. The investigator has to stop in order to be right out loud: to document, to authorize, to produce something that holds. The adversary never does. One advantage is kinetic, the freedom to move without justifying a single step. The other is epistemic, the duty to produce knowledge that survives scrutiny. And here the ground favors the investigator: on-chain, nothing the adversary does is ever erased, and work done well only gets stronger the harder it is examined. That is the asymmetry, and it changes the shape of the problem. Not how a small force defeats an endless one, but how a process that moves in steps can pin one that never pauses. It feels like Zeno's paradox. By the time Achilles reaches where the tortoise was, it has moved again. The gap shrinks forever and never closes. An investigation often feels the same, though not because you cannot see the money. You can watch it move in real time. The lag is in the step you are allowed to take: by the time a report is written, sent, and processed, the situation it describes has already shifted. Each accountable move lands a beat behind the thing it was aimed at. But the paradox rests on one assumption: that the tortoise can run forever. You do not try to match the adversary's speed. You will lose that race by design. You aim your discrete steps at what cannot move: the constraints. The coins have already left the address you found. The rules that govern where they can go have not. And the report is not your only move. You can put constraints in place ahead of the money: flag adversary-controlled addresses at their likely destinations and keep those flags persistent as the value changes form, bridged, swapped, wrapped. The objective is to ensure that even a compliance system conducting a deep search cannot be defeated by a single additional protocol-mediated hop. Not every destination will act on the flag, and not every trap will hold. That is beside the point. Every constraint removes another place where the money can land cleanly. At that point, you are no longer just chasing the runner. You are fencing off the ground it has left to run on. This is why the report, the most quantized artifact of all, is both weakness and strength. Comparing its latency to the adversary's speed is comparing two different games. But the games are entangled: the kinetic advantage and the epistemic one resolve into a single outcome. The adversary has to win every step to stay free; you have to make just one accountable move that holds. On a public ledger the trail does not decay. Every move made to outrun you also records the path you will later follow. Latency is fatal only against evidence that fades. And the flight has a destination. Stolen value almost never stays in perpetual motion. It seeks a cash-out: an exchange, a purchase, a point where it must re-enter the recorded world. Sometimes you do not even need to wait. If the value sits inside an issuer-controlled token whose contract allows blacklisting, the tortoise can be stopped where it stands. The instant it halts, by arrival or by freeze, the race ends. You were never going to overtake it stride for stride. You were going to be waiting where it had to come to rest. You move in steps. You will not catch it by running. You catch it where it has to stop. ## Why Blind Experts Fail, and How Great Teams Connect the Dots Imagine a world where everyone is an expert in a different cheese, yet no one knows how to pair them, or even notices when one has gone bad. URL: https://anfossi.systems/writing/why-blind-experts-fail-and-how-great-teams-connect-the-dots/ ![Why Blind Experts Fail, and How Great Teams Connect the Dots](./assets/image18.jpeg) Imagine a world where everyone is an expert in a different cheese, yet no one knows how to pair them, or even notices when one has gone bad. That is how skyscrapers of knowledge end up built on foundations of fog. We are often told that specialization broadens our horizons. And within a single field, it does. But when every path leads deeper into the same narrow ground, something is quietly lost. Specialization channels us, standardizes us, and slowly makes us interchangeable: predictable and useful within our lane, yet strangely helpless the moment a problem refuses to stay inside it. ## The Age of the Blind Expert This is what fragmentation does to a mind. It produces blind experts, incapable of seeing beyond the borders of their own domain. It is like knowing every room of a house yet never having seen it from the street. The more we know within our narrow fields, the less capable we seem of navigating the complexity of the real world, where problems never arrive neatly labeled by department. And cheeses, to continue the metaphor, are rarely meant to be enjoyed on their own. Extreme specialization promises progress. More often, it produces a sophisticated form of ignorance: we know everything about our tiny piece of the puzzle, yet we have lost the map that shows where it belongs. And there is a quiet cost to this. When you only ever know your own function, it becomes hard to picture how the whole fits together, or to imagine that it might fit differently. The answer is not to reject expertise. It is to reclaim the right to intellectual curiosity across disciplines, and to ease the friction that keeps us from reaching the seemingly useless, the unexpected connection, the open channel to another field. Ancient wisdom understood this well: fragmented knowledge is lifeless knowledge. The great thinkers of the past were natural philosophers, artist-scientists, poet-mathematicians. Not because they lacked depth, but because they recognized that reality is woven from connections invisible to the specialist's microscope. An expert who never leaves their own discipline is like a cheesemonger who knows everything about Roquefort yet has never tasted wine. The expertise is real. The judgment, without enough context, is not. Regaining the ability to "pair the cheeses" takes a small, everyday discipline: Cultivate curiosity and venture beyond your own field. Speak with people whose work is nothing like yours. Practice the art of analogy. Learn to express your own discipline in plain language. And remember that we are human beings before we are professionals. No specialist, however brilliant, is free from error. I have never met anyone who never made a mistake, and I have made plenty myself. What makes a team resilient is not the absence of mistakes, but the presence of complementary perspectives and mutual checks. You notice what I overlook; I recognize patterns invisible to you. The value is not only in the redundancy that ensures safety, but in the mutual correction of the larger picture. We often celebrate individual expertise while overlooking something even more valuable: the channels through which expertise flows. Information does not become understanding simply because it is shared. It becomes understanding only when another mind can receive it without distortion. ## Knowledge Against Resistance The real world makes this unavoidable. Hard problems do not respect academic departments or professional silos. They cut straight across them, and they are often hardest precisely where the boundaries lie. Nowhere is this clearer than in an investigation. An investigation is, in the end, the acquisition of knowledge against an antagonistic constraint: someone has worked to keep that knowledge from you. The trail is fragmented on purpose, the channels deliberately broken, the cheeses scattered so that no single nose can pair them. To reconstruct what someone has labored to hide, you must move across the very domains they counted on staying separate. This tells us something about knowledge itself. We assume that because information is abundant, knowledge is too. It is not. Knowledge behaves like a material. It has structure, density, friction, and scarcity. Access to information does not automatically grant access to knowledge, just as owning bricks does not teach you how to build a cathedral. One thinker who put this well was Gurdjieff. He argued that knowledge is not an infinite common resource. It exists in finite quantities, concentrated in particular places, moments, and relationships. It must be acquired, not merely accessed. ## Navigation in the Era of AI This distinction becomes even more critical in the age of AI. AI drastically lowers the cost of obtaining answers, but it does not lower the cost of asking the right questions. It accelerates retrieval and pattern-matching, but it inherits the very corpus fragmentation it was trained on. Information is abundant. Knowledge is scarce. Anyone can ask an AI a question. Expertise is knowing whether the question is even worth asking, or merely misleading. As answers become increasingly abundant, good questions become increasingly scarce. As Umberto Eco (whose legacy I luckily caught a glimpse of through his student, my semiotics professor) often argued: culture is not the accumulation of information. It is the ability to navigate it, to know where to look, how to evaluate what we find, and how to connect it into understanding. ## The Architecture of a Team This is why assembling a team is not simply a matter of gathering the best specialists. A team is an architecture of knowledge. Each person holds a different fragment, but value emerges only when those fragments become connected. The bridge itself is knowledge, and has to be shared to work. Not the specialists. Not the information they possess. The bridge that allows one domain to reach another without distortion, without translation loss, without filters. The highest-leverage nodes are often the translators, the synthesizers, the boundary-spanners: the ones who can move between domains with minimal distortion. They reduce friction and catch blind spots, and out of those connections, understanding finally emerges. Knowledge does not merely reside in people. It resides in the bridges between them. Specialists collect cheeses. Great teams learn how to pair them. ## Second-Hand World (Part 2): The Role of Knowing The argument so far leaves us in an uncomfortable place. The old question returns: is the model merely manipulating symbols, or does it know something? URL: https://anfossi.systems/writing/second-hand-world-part-2-the-role-of-knowing/ ![Second-Hand World (Part 2): The Role of Knowing](./assets/image17.png) The argument so far leaves us in an uncomfortable place. [(Read Part 1)](/writing/second-hand-world-part-1-what-llms-inherit-from-the-world-they-never-touched/) If grounding admits of degrees, and if testimonial knowledge already relies on inherited contact with the world, then the old question returns in a sharper form: is the model merely manipulating symbols, or does it know something? And that question exposes what was really being assumed all along. We asked whether the LLM is the kind of thing that can know, as if kinds came stamped in advance. We asked whether its symbols mean anything, as if meaning were a built-in property rather than a projected role something plays in a world. Both questions take for granted that “knows” names a natural boundary out there in reality, waiting to be respected or violated. Perhaps it does. Perhaps it doesn't. The functional tradition rejects that assumption. It treats “knows” as a role rather than a substance: a functional term wearing the costume of a deep fact about reality. It stretched from perception to memory to testimony to instruments, and no agreed essence was ever isolated. The thermometer detects. The immune system remembers. Each extension was metaphor hardening into ordinary use. The point is not that these cases prove anything about language models. They do not. The point is historical: vocabulary has repeatedly expanded beyond conscious agents without waiting for a settled theory of essence to authorize the move. And there is a twist the model cannot escape: this very history, of epistemic words spreading without a license, sits inside the corpus it was trained on. It has read the case for its own admission. The cleanest version of the question has a classical form: knowledge as justified true belief, a belief that is true and that the knower can justify. It's the right tool, and instructive for the same reason the formal system was: because of where it strains. In 1963, Gettier showed that the three conditions can all be met and still fall short: a belief can be true, and justified, and true for reasons that have nothing to do with what justifies it. The justification does its work; luck slips in between it and the truth. So justification alone stops drawing the line. What epistemology (the branch of philosophy that studies knowledge) did next is the telling part. It didn't conclude that knowledge has no boundary; it went looking for the boundary elsewhere, in reliability, in intellectual virtue, in the exclusion of luck, in proper function. Each account draws a line, and draws it somewhere real. But each line is built by a theory answering to a purpose, never found sitting in the world before the theory arrived. A realist can read the same sixty years as a hard boundary not yet located. Perhaps; the history is compatible with both readings. But sixty years of defensible, divergent lines do not prove there is no essence; they only take from the realist the right to assume one. And for the argument here, that is enough. The functional reading doesn't need to win; it needs only to be as legitimate as its rival, because everything that follows stands on that parity alone. So the clean question, “is this real knowledge or mere metaphor?”, is badly posed. Not because it has no answer, and not because rejecting an essence makes everything blur together: chess is still chess, photosynthesis is still photosynthesis, and some uses of “knowing” are settled and stay settled. It's badly posed because it assumes there is a threshold between real knowledge and mere metaphor that existed before we came along, waiting to be discovered. There isn't, or at least no one has earned the right to assume there is. Every threshold we have was drawn by a theory of knowledge, for that theory's own purposes. This doesn't mean the question is empty. There are real, checkable constraints on when grounding holds: a chain of cause and history linking the system to the thing it represents, a function the representation actually serves, a process that is reliable, an outcome that isn't just luck. A given system can satisfy these constraints to a greater or lesser degree, and in different ways. Second-hand grounding names a route, contact through traces rather than through contact, and the constraints apply to that route as they apply to any other. A long chain is not automatically a weak one, and a short chain is not automatically strong. Once you fix which constraints matter, whether that system counts as knowing is a real question with a real answer. What doesn't exist is an answer that comes before any constraints, a fact about where the flattering label “knows” belongs that holds independently of them. And this is how the label actually spreads: every time “knowledge” gets extended to a new kind of system, a metaphor is slowly becoming literal. Slowly, and never by simple declaration. But who decides which resemblances count? No theory does, in advance. Practice decides, retrospectively, and not practice as mere popularity. An extension stays honest not because no one rejects it, but because it withstands the attempts at rejection: because it keeps holding up against the same constraints (the causal chain, the function served, the reliability, the exclusion of luck) when someone actively tries to break it. “The thermometer detects” survived the people who tested it, not just the people who never noticed. That resistance under pressure is what keeps the extension honest. What's left is the collapse of the frame that generated the two options. Grounding comes in degrees and in kinds; Knowing was never the private property of minds, nor of theorems. It was a role, and a role doesn't care about the inner nature of whatever fills it, though it cares very much whether it is filled at all. Some architectures may turn out to be a real case of it; others may fail to be. That is exactly the question worth asking. What we are owed is not a verdict in advance on which kinds of thing are eligible, but an account, case by case, of which systems stand in the relations the role requires. A model that knows the world only second-hand knows it thinly, unevenly, by inheritance. So does anyone who has read more than they have lived. The difference is that the reader grafts what they read onto a stock of first-hand contact, and the model has no stock to graft onto. That asymmetry is real. But it is exactly what the constraints are for: a difference to be measured, not a disqualification to be announced in advance. The knower being neither mind nor theorem was only ever a problem for a theory that needed it to be one. It was never obvious that knowledge required either. The argument here is not that language models belong inside the category. It is that no theory has earned the right to close the category before the investigation begins. Whether a system possesses a thin form of grounding and whether it is the right engineering solution are largely orthogonal questions. Epistemic legitimacy and engineering wisdom are often different questions with different answers. One personal note to end on. The interesting question is whether these systems can ground their outputs. The boring truth is that many of them should not be running an LLM at all. A model has been dropped into the middle of pipelines that a rule or a lookup handled fine, and the substitution rarely pays. It weakens reliability, because a guaranteed output is traded for a plausible one. It weakens independence, because the system now leans on a component whose behavior no one fully owns and whose every output has to be checked in high-stakes cases. And it raises cost across the board. Grounding is real and worth taking seriously. That is not the same as needing a language model, and treating the two as one is how you end up with something slower, flakier, and more expensive than what it replaced. ## Second-Hand World (Part 1): What LLMs Inherit From the World They Never Touched A formal system derives its conclusions because they follow from its axioms: its starting rules, assumed true without proof. URL: https://anfossi.systems/writing/second-hand-world-part-1-what-llms-inherit-from-the-world-they-never-touched/ ![Second-Hand World (Part 1): What LLMs Inherit From the World They Never Touched](./assets/image14.png) A formal system derives its conclusions because they follow from its axioms: its starting rules, assumed true without proof. Consistency is guaranteed by construction. An LLM, by contrast, returns whatever sounds plausible. It may reach the same conclusions, but nothing in its architecture guarantees consistency, or that its output follows from anything at all. The easy objection is that an LLM is “just statistics.” Too easy. We don't know what the mind runs on either, and we still call what it does knowing. “It's just statistics” settles nothing. The real question is grounding: whether a system has a causal grip on what it's talking about. Here the formal system is instructive precisely because it's blind. Its symbols point only to other symbols; it tracks no world. But notice: it was never supposed to. Peano arithmetic (the standard set of basic rules for the natural numbers) isn't defective for failing to touch a world it was never about. “Tracks no world” is a defect only relative to a purpose. So grounding isn't a single thing you either have or lack; it's a relation between a system and what its work requires. That reframes the LLM. It tracks patterns in text. The tempting conclusion: patterns built on patterns touch nothing, the formal system's blindness in a new costume. But text is not a closed symbol game. Text is a causal trace left by writers who were grounded in a world: someone saw the rain, ran the experiment, lost the money. And predicting that text well pushes the model to arrange its representations so that the distances between them mirror relations that hold among the things the words are about, the geometry of the meaning-space becomes a partial imprint of the structure of the world that produced the text. That is how grounding enters through the back door: not earned through sensory contact, but inherited as structure from the world the whole body of training text records. The imprint is not reference, and it is not clean; it is exactly the kind of thing the constraints are there to measure. Call the first kind primary grounding: an organism in direct causal contact with its world. Call the second kind second-hand grounding: a system in contact with the traces that grounding leaves behind in text. Testimonial knowledge already assumes that grounding can survive transmission; most human knowledge arrives through chains of representations rather than direct encounter. But not all transmissions preserve grounding equally. The disagreement is not over whether grounding can travel, but over how much survives the journey. Second-hand, thin, deniable. Deniable, yes. But consider what that denial entails. If our ignorance of the substrate's qualities, and of how much grounding is preserved, prevents the skeptic from dismissing an LLM as "just statistics," it constrains us as well. We do not know the substrate of thought either, nor the mechanisms by which it becomes experience. We say we know our own minds because we live them from the inside. We attribute minds to others without ever inspecting their substrate. That attribution is not the result of direct access to their mind, but of inference. Notice what did the work just now: living a mind from the inside is itself a mark of embodiment, and leaning on it hardly makes embodiment irrelevant. If anything, it shows how much embodiment carries. Embodiment may be the strongest indication of grounding we possess; the weaker claim is only that evidence for grounding should not be mistaken for a definition of grounding. But notice where this leaves us. If grounding survives transmission, and survives it in degrees, then the question is no longer whether the model touches the world. It's what that thin, inherited contact entitles us to say. And there is one word we reach for the moment we try to say it: we grant that a system knows, or we withhold the word. That word has been doing quiet work under everything so far, unexamined. Whether the model has earned it is the question the next part takes up. ## A Scam Made to Measure The client I remember most was a smart contract developer. He signed a single drainer transaction. Everything gone. URL: https://anfossi.systems/writing/a-scam-made-to-measure/ ![A Scam Made to Measure](./assets/image13.png) The client I remember most was a smart contract developer. He writes the code that moves value on-chain. He understands approvals and signatures at a depth most users never reach. He was lured by a fake airdrop, a distribution of governance tokens to active users in an ecosystem, and signed a single drainer transaction: a malicious request that, once authorized, empties the wallet. It was over. Everything gone. If it can happen to him, it can happen to anyone. That sentence gets repeated so often it has gone soft. It deserves to be taken literally. Over the years I have started to read scams the way a tailor reads garments. Fraud comes in sizes, and each size is cut for a different level of knowledge. At the entry level hangs the off-the-rack work: pig butchering, fake investment platforms. Cut loose, so it fits almost anyone. Slow, patient manipulation that builds trust for months before draining the account. The craft is in the patience, and the measurements are generic: loneliness, hope, the wish for a quiet return on savings. At the high end sits the bespoke work: drainers and malicious approvals. These target people who know the fabric. The victim has to understand what a token approval is, what a signature authorizes, how a legitimate claim page behaves, and be fooled anyway. The trap only works on a trained eye, and a trained eye is exactly who it was made for. This is what makes drainers so insidious. They are built for one specific day: the ordinary one. You are moving fast. You are half distracted. The site looks exactly like the one you have used a hundred times. One signature is enough. It says nothing about you and everything about how well the trap was designed. Running through every tier, from the crudest to the finest, is the same craft: social engineering. The tailor's skill was never the sewing. It is the measuring. And that work does not happen only online. It happens in person, in a conversation, a handshake, a moment of misplaced trust. The strength of the cryptography is irrelevant when the target is the person who holds the keys. The technique adapts to the wearer. I worked a case where a founder met his "investors" the way anyone would: over dinners, introductions, a partnership that took shape over weeks. There were business cards, a real office, a term sheet that read like the dozens he had seen before. The trust was built across a table, in handshakes and shared bottles of wine, long before a single transaction was signed. By the time they asked him to move funds to a "jointly controlled" wallet "to close the round," the outcome was already decided. No malware, no spoofed domain. The whole attack was social, and the keys never stood a chance. The developer from the opening taught me something I have had to relearn several times since. He knew what a signature could authorize. He had written that logic himself, and the trap held anyway. Knowledge raises the price of fooling you. It rarely makes that price unpayable. A token approval set too high. A transaction signed on autopilot. One click while your attention is somewhere else, and the attack surface you spent years minimizing opens up completely. Security that depends on a human being permanently alert is a system that only works on your best day. This is also why empathy belongs in this work. When we hear how someone lost their funds, judgment comes cheap. But behind the transaction hash there is almost always a household. I have sat across from families who lost the work of a lifetime: entire pensions, the savings of thirty years of early mornings and postponed wishes, the money that was supposed to become a home, a retirement, a margin of safety for the children. A retired couple moving that pension into what looked like a regulated platform was not being greedy; they were applying the rules of a world they knew, where institutional appearance equaled safety. Every mistake has to be read against the knowledge and the circumstances of the person who made it. On-chain it reads as a single transfer, a row in a spreadsheet. In a living room it's a silence at the dinner table that no recovery effort can turn down. The same reading applies to everyone, the retired couple and the smart contract developer alike. What looks obvious from the outside rarely felt obvious in the moment, under pressure, mid-distraction, at the end of a long day. And the people it fits most cruelly are often the ones who brought everything they had, because the trap was built for exactly that: a lifetime of trust, concentrated in one account. Many businesses still underestimate custody and secure operational workflows, and the tailoring model explains why. They train people to recognize the trap, then leave the fitting room open. Security is a design problem before it is a training problem. The developer needed a workflow where an unknown contract could never reach a signature at all: the roster of trusted contracts settled ahead of time, in a calm moment instead of a distracted one. The decision made once, deliberately, so the malicious request that emptied his wallet would simply never have arrived. The founder needed something else entirely. No contract could have saved him; the trap was built across a dinner table, not hidden in a domain name. But signing infrastructure that shows the authorizer exactly what a transaction will do every single time, forcing deliberate inspection and leaving no room for ambiguity, transforms "move the funds to close the round" from a socially conditioned next step into a concrete, inspectable action. It turns a moment of distraction into a controlled decision. Each of these measures does the same thing: it moves the critical decision away from your worst moment and into your calmest one. Every contract whitelisted in advance, every signature the signer actually understands. A workflow that never lets an unknown contract reach a signature gives him nothing to fit. The goal is not to create humans who never make mistakes. The goal is to design systems where ordinary human moments cannot become irreversible losses. ## A Powerful Tool Will Not Save You Complexity is not chaos. Chaos has no handles. Complexity does: it is a dialogue of dependencies, tensions, and patterns awaiting interpretation. URL: https://anfossi.systems/writing/a-powerful-tool-will-not-save-you/ ![A stick's trail](./assets/image12.png) *A stick's trail* Complexity is not chaos. Chaos has no handles. Complexity does: it is a dialogue of dependencies, tensions, and patterns awaiting interpretation. The difference matters because it tells you what to do when you are overwhelmed. In the face of chaos you brace. In the face of complexity you read. The work is not to make the mess go away but to find the grammar already running underneath it. Most people, faced with a hard problem, reach for a tool. Newer, faster, more powerful: surely the right instrument will cut through. Tools do help. But we forget what a tool actually is. A tool is a hypothesis with a spine. Every instrument encodes a belief about where the answer lives and how the world is shaped. A dashboard assumes the signal is in the metrics it chose to plot. A clustering algorithm assumes the entity you are hunting behaves the way its heuristics expect. The tool is not neutral. It is an argument about reality, frozen into software, and it carries that argument silently into every problem you point it at. This is the trap. Choose the wrong tool and its blind spots become your own. You stop seeing what it cannot show you, and you mistake the edge of the instrument for the edge of the problem. The more powerful the tool, the more seductive its blind spots, because power buys you speed, and speed in the wrong direction is just a faster way to be wrong. Here is the part that gets missed: the danger is not power, it is opacity. A black box concentrates authority inside itself. It hands you an answer and hides the reasoning, so you either trust it or you do not, and either way the thinking has been taken out of your hands. The more transparent the tool, the more it gives the power back to the method. When you can see the assumptions, inspect the steps, and watch where the logic bends, the instrument stops being an oracle and becomes what it should be: an extension of your own reasoning, one you can audit and overrule. Transparency is what keeps the method in charge of the tool, instead of the other way around. Which is why method has to come first. Method is the thing that chooses the tool, interrogates its assumptions, and knows when to put it down. With a hypothesis of your own, a real one, even the most primitive instrument is enough. Take two cases at opposite ends of a career. My very first case was solved with nothing but a block explorer and a pencil. Years later, with every platform available to me, I had to run a full trace between two bridges on zkSync exactly the same way: a sheet of paper, a pencil, reading the raw chain by hand. Same minimum kit, then and now, because the method was always there. Software makes you fast. It does not make you correct. This changes how we think about expertise. Good training can absolutely teach method. The problem is when expertise becomes identified with a particular tool instead. Then the skill and the instrument begin to fuse. You learn where the buttons are, but not always why you are pressing them. There is real value in learning a platform. It gives you a common vocabulary, speeds up onboarding, and helps you become productive quickly. But those are the benefits of an accelerator, not an engine. If the platform changes, raises its price, or disappears, the method should still be standing. Technology changes. New instruments will keep arriving, and I will not pretend to know which of the ones I use today will fade. But I will bet on this: the ones that endure will be built on clarity, because a tool you can see into is one the method can keep trusting. The opaque win on speed for a season; the clear compound. Method endures the same way, and for the same reason: it was never about the tool. In the end the limiting factor is not the instrument in your hand. It is the quality of the thinking behind it. How you think determines what becomes possible. A powerful tool will not save you. Get the method right and the tools become what they were always meant to be: amplifiers of a mind that already knows where it is going. ## What a USDT Recovery Actually Looks Like People hear "we recovered stolen Tether" and picture a heist in reverse. A key cracked, the thief's wallet broken back into, the funds yanked out. URL: https://anfossi.systems/writing/what-a-usdt-recovery-actually-looks-like/ ![Tether smart contract representation: A visual analogy of automated execution.](./assets/image10.jpeg) *Tether smart contract representation: A visual analogy of automated execution.* People hear "we recovered stolen Tether" and picture a heist in reverse. A key cracked, the thief's wallet broken back into, the funds yanked out. It is nothing like that. It is almost bureaucratic. So what is USDT, really? Not just a coin sitting in a wallet. A smart contract. Think of it as a vending machine. Instead of taking your money and handing you a snack, it takes an instruction and moves a credit from one account to another. Your "balance" is just a number the machine keeps next to your address. When you send USDT, you are not shipping an object anywhere. You are asking the machine to subtract from one row and add to another. That framing matters because a vending machine has an owner. Like any vending machine, it has an owner, and the owner can do things no customer ever could. The USDT contract has special functions only Tether can call. Three of them tell the whole process of a recovery: blacklisting, burning, and minting. A CRITICAL CAVEAT: not every token labeled "USDT" is actually issued by Tether. Common bridged versions of USDT (tokens that represent USDT on blockchains other than the native Tether-issued ones) cannot be frozen by Tether because they are not issued by Tether. They are separate tokens created and controlled by third-party bridge operators and backed by locked Tether-issued USDT as collateral. Although users often refer to them simply as "USDT," they are technically distinct assets, and the freeze authority, if it exists, belongs to the bridge issuer, not to Tether. ## Phase one: the freeze The first thing that happens in a recovery is the freeze. When Tether blacklists an address, that address goes sticky. The number next to it is still there, you can still see the balance, but the machine will no longer accept any instruction to move it. The funds are stranded in place so the thief cannot run while the legal process plays out. In practice, asset freezes are initiated early in the investigative cycle, often ahead of any final court ruling. Law enforcement agencies such as the FBI, DOJ, or their international counterparts secure the necessary legal authority under local procedures and coordinate with the stablecoin issuer. Speed is decisive: a delay of even a day can mean the difference between a successful freeze and an already emptied address. If you want to verify a freeze, you don’t guess from the wallet balance. You check the contract state. When passing an address to the USDT contract's isBlackListed view function, it simply returns a boolean. This simple true/false flag is the ultimate ground truth of the address state within the smart contract. ## Phases two and three: burn, then refund The freeze can sit for a long time. Weeks, months, or even years. And it does not always move at all. Many frozen addresses never proceed to a burn. They simply stay stuck. What comes next only happens when there is a legal basis for it and Tether decides to act. Once the legal basis is established, the final two phases usually unfold within minutes of each other. First comes the burn. Not a transfer. Not a seizure. A destruction, and the total supply shrinks by exactly that amount. When funds are removed through the special burn function, some analytics platforms ([Arkham](https://www.linkedin.com/company/arkhamintelligence/posts/) among them) may not register the balance change from that transaction type, so an address that has actually been emptied can still display a full balance. For this specific step, cross-check on a block explorer (or [USDTBanList](https://usdtbanlist.com/)) that reads the contract state directly, or you will think the money is still sitting there when it is already gone. But if the stolen USDT has been destroyed, where does the victim's replacement come from? Not from the burned tokens, but from the treasury's existing reserves. The Tether treasury is pre-funded: USDT is minted in advance, independently of any single recovery, in enormous amounts, often billions of dollars at a time. That supply sits in the treasury waiting, with no connection to the case it will later settle. On Tron, it is minted from a burn-style blackhole address and is then routed to the multisignature wallet; on Ethereum, it is issued directly into the treasury wallet from the Bitfinex multisig. See [examples](https://usdt.tokenview.io/en/mint) on Tokenview. However, this is a discretionary operational choice by Tether, and if you continue browsing through the pages you will find outliers. And here is the detail that makes it provable: the payout is aggregate. Every frozen address involved in the case is burned, and one fresh lump, equal to all of them added together, leaves the treasury in a single move. This is where the recovery becomes visible on-chain. The destroyed amount and the refunded amount match down to the last decimal. ![An example of a USDT recovery.](./assets/image11.png) *An example of a USDT recovery.* This decimal-perfect equality is the fingerprint, and it is visible to anyone willing to look on-chain. In the recovery cases I personally worked on, this was the smoking gun: multiple criminal addresses were burned within a two-minute window, and the exact aggregated total was paid out as a single lump sum just sixty seconds later from the Tether treasury address, although the refund is a separate transaction rather than an automatic consequence of the burn. In these specific cases, the lump sum was forwarded to a [Bitfinex](https://www.linkedin.com/company/bitfinex/) deposit address, an exchange under the same iFinex corporate umbrella as Tether, re-entering the regulated market on its way back to the victim. So, the thief's tokens are never chased or seized. They are simply switched off, while an identical amount is released from a pre-existing reserve, and the math lines up perfectly. The blockchain records every step. A crypto recovery doesn't look like a Hollywood heist. It looks like an accountant flipping two entries on a spreadsheet. No cinematic exploits. Just absolute authority embedded directly into a smart contract. ## Welcome to Constraints Every investigation hits a point where the evidence runs out. The graph ends. The wallet has no owner. What's left looks like too little to know anything. URL: https://anfossi.systems/writing/welcome-to-constraints/ ![Welcome to Constraints](./assets/image9.jpeg) Every investigation hits a point where the evidence runs out. The graph ends. The wallet has no owner. What's left looks like too little to know anything. That is where the real work starts, because the question is no longer where the money went. It is whether anything here can be known at all. The answer almost always has the same shape: what can this system not do, even if it wanted to? In a system built to hide the truth, the truth rarely stays visible. It survives as constraints: things the system cannot violate without contradicting itself. Balances must reconcile. Code executes exactly as written. Every transaction requires authorization and fees. When direct evidence disappears, constraints remain, and they are often enough. That is what this newsletter is about. It isn't blockchain news, and it isn't a bag of tricks, though you may pick up and share a few. Real investigative dynamics from actual cases will appear throughout. I won't avoid them, but they are only examples, and I may run out of good ones. What we're really doing is looking at the reasoning underneath them. I'll keep the language plain and lean on examples. Nothing simplified, only explained. I'll assume only an understanding of blockchains and about three or four minutes of your attention per episode (probably a better investment than the usual LinkedIn AI-digested motivational slop). The same move shows up far beyond blockchain: in law, intelligence, engineering, economics and more. Different fields, one method: when you can't see the answer, you rebuild the question from what couldn't have been otherwise. My hope is to make this a place where investigators, analysts, lawyers, developers, and anyone drawn to systems can exchange ideas grounded in that way of thinking. Not because these fields share answers, but because they share the same attitude: how to know something when everything is built to stop you. And in the conversations I hope will grow in the comments, I'll ask the same of you: keep it plain, so people from different fields, with different vocabularies, can still understand one another. This is an epistemic problem before it is a technical one. A problem about what can be known, not about blockchain. If you're starting today, begin with the episodes that came before this one: Episode -4: [Inside Inferno Drainer](/writing/inside-inferno-drainer/). How shared criminal infrastructure becomes the very thing that identifies its users. Episode -3: [A Special Demixing Case](/writing/a-special-demixing-case/). Following the money failed. Arithmetic didn't. Episode -2: [Wallet Balances](/writing/wallet-balances/). How a single screenshot identified a wallet holding millions. Episode -1: [Guess Who? (On-chain)](/writing/guess-who-on-chain/). Finding a wallet from nothing but an NFT profile picture. The negative numbers are LinkedIn's doing: newsletters can't time-travel, so older articles were filed as Episodes -4 through -1. I call it a feature. New episodes follow a weekly cadence, typically on Wednesdays at 9:30 CET. Episodes are published only when they meet a required threshold of insight quality; otherwise, publication is deferred. Next up: [Episode #1: What a USDT Recovery Actually Looks Like.](/writing/what-a-usdt-recovery-actually-looks-like/) Before we return to reasoning from constraints, let's spend one episode looking under the hood of a USDT recovery. We'll follow the on-chain footprints of a paradox: an asset moving on a decentralized network that ultimately answers to a single authority. Let's meet where the evidence ends. ## Guess Who? (On-chain) He had a profile picture. That was the whole case. An X account. One avatar, an NFT, the kind people wear like a face. URL: https://anfossi.systems/writing/guess-who-on-chain/ ![Guess Who?](./assets/image6.jpeg) *Guess Who?* He had a profile picture. That was the whole case. An X account. One avatar, an NFT, the kind people wear like a face. Hair, eyes, skin, a colored background. Find the person behind it. No wallet from the handle. The username mapped to nothing: no [DeBank](https://www.linkedin.com/company/debank/), no linked profile, no thread anywhere online that tied it to an address. Just a picture someone had chosen to be. Let me show you why that's enough, in plain terms. For this kind of web3 collectable, every NFT is a recipe. A set of traits written into metadata: hair this color, eyes that color, skin this tone, those glasses, that background. The picture is the output. The metadata is the source seed. So if I could read the picture as a list of traits, I could turn a face back into a query. A bit like playing Guess Who. Simple. Except for one thing. The avatar wasn't from a collection I could name. It was as if I couldn't even start the game of Guess Who, because I didn't know which version of the board my opponent was playing on. And it could just as easily have been a derivative. There are services that, for a fee, modify your NFT: the Bored Ape Yacht Club, for example, has a spin-off that "zombifies" yours, spitting out an unofficial variant that carries the same metadata as the original. And this can go several steps deep, a knockoff of a knockoff, and so on. So the picture could look like something famous, but actually come from somewhere obscure. That was the wall. No handle-to-wallet. No nameable collection. The point where most people write "anonymous, no entry point" and close the file. So I stopped trying to trace him. And I asked a different question. Not "where is his wallet?" but "who is standing next to him?" That was the crack in the wall. ![Communities Within Networks](./assets/image7.png) *Communities Within Networks* Because nobody collects alone. An NFT community may intersect with other NFT communities: the same people hold overlapping sets. He'd scrubbed himself clean, but if I could find even one other wallet from his interactions, or from the accounts replying to his posts, I could find people holding the same kinds of collections he did, even behind a completely different profile picture. So I rolled up my sleeves. Pure elbow grease. I went through the accounts interacting with him (the replies, the mutuals, the people in his orbit), hunting for any fingerprint that led to a real address. I pulled a handful of wallets out of the noise, across multiple chains. Then I took each one to [OpenSea](https://www.linkedin.com/company/opensea-io/) (EVMs) or [Magic Eden](https://www.linkedin.com/company/magic-eden/) (Solana) to read its collections, and to open block explorers to see every NFT it had ever touched, even the ones held for a single day, even inside a narrow window. Bingo. In one neighbor's history sat an NFT built like the one I was chasing. Same structure, same skeleton. That handed me the collection. Now I had the real thing. I could finally play Guess Who with the suspect. So I filtered it by my target's metadata, the exact traits from his avatar, and there he was. His specific NFT. One token, out of the whole set. But a token still isn't a person. This one had changed hands. Bought, sold, passed down a chain of owners. So I laid its transfer history against his activity on X: the timing of each sale, the time and context of his posts, who held it when. One address in that chain lined up with the man behind the avatar. Not a guess. A match between the blockchain and the social network's timeline. That became the anchor. From there, everything downstream came loose. He erased every line from his name to his wallet. The handle led nowhere. The collection had no name. He just forgot that you collect in a crowd, and the crowd holds the same things you do. ## Wallet Balances He sent me a screenshot. One wallet. A Solana balance. A few memecoins. Find the wallet, he said. No address. No transaction hash. URL: https://anfossi.systems/writing/wallet-balances/ ![Sudoku Nakamoto](./assets/image5.jpeg) *Sudoku Nakamoto* He sent me a screenshot. One wallet. A Solana balance. A few memecoins. Find the wallet, he said. No address. No transaction hash. No exchange account. No starting point. Not even the date the screenshot was taken. Just a screenshot. He also told me that several technicians and analysts had already looked at it and come up with nothing. My first thought was that it would be quick: write a query for every wallet that held that exact combination of tokens, match the balances down to the last decimal, and there is your wallet. A simple exercise. Then I opened the screenshot, and saw the real problem. The memecoins weren't uniquely identifiable. On [Solana](https://www.linkedin.com/company/solana/), dozens of tokens can share the same name. Many share the same logo. Some are outright impersonations of one another. The screenshot showed only the displayed names, logos, balances and position values. No token addresses, which is the one thing that actually tells two identical-looking coins apart. So before I could search for anything, I first had to work out which assets the screenshot was even showing. I started from the balances. Each holding showed both a quantity and a value, so I divided one by the other to get the price of a single token. That one number did a lot of the work: if a suspect coin had never traded at that price at any point in time, it could not be the one, and I dropped it. This was the slow part, mostly by hand, because the look-alikes ran into dozens and dozens. Only then could the real search begin. Even after the price filter, some of the memecoins still had more than one possible match. So I built a single query that took every surviving combination of candidate tokens and searched, in one pass, for wallets that had held that exact set at the same time. Every possible match landed in one dataset. The result was still enormous. Thousands of wallets. (Please, do not trade memecoins...) Then I went through all of those wallets with a Python script. For each one, it followed how the amount of a reference token in that wallet rose and fell over time, and threw the wallet out as soon as it was clear that no moment in its history matched the screenshot. My terminal was printing "excluded" every second. One by one they fell away. I actually found the match before I was even halfway through. I cracked open a Super Mario Actimel to celebrate, then let the program run to the end for completeness. Only one wallet was left. Then came validation. Did the token balances match? Did the timing match? Did the order of the assets match? Did the surrounding activity make sense? Everything lined up. That single wallet was the one. A wallet identified from nothing more than a screenshot. No address. No hash. No starting point. No time window, beyond the obvious fact that every coin involved already existed. Just a set of balances and a moment frozen in time. And it was sitting on millions. What looked like a simple query turned into one of the more tedious identifications I have done. The culprit was the memecoins: around eighty knockoffs of one another, barely any reliable historical price data (even on Dexscreener), what little existed scattered all over the place, the price feeds themselves carrying broken history, and far too many people holding memecoins to begin with. But the answer was always in there. People think blockchain investigations are about finding information. More often, they are about realizing how much was already in front of you. The screenshot wasn't a picture. It was a set of constraints. And constraints are enough to find the truth. ## A Special Demixing Case Thousands of bitcoins walked out of a virtual asset service provider years ago. The wallets went quiet for a long time. URL: https://anfossi.systems/writing/a-special-demixing-case/ ![Quantitative Tensegrity](./assets/image4.jpeg) *Quantitative Tensegrity* A note before we start: the case as a whole was handled by the entire [Token Recovery](https://www.linkedin.com/company/tokenrecovery/) team, and this demixing work in particular was done together with [Benjamin Brooks](https://www.linkedin.com/in/ACoAAFVIcHcBL7B-tgIitNZN80vcFc63sXE8YtY). That's why I say "we" throughout, the credit is shared. Thousands of bitcoins walked out of a virtual asset service provider years ago. The wallets went quiet for a long time. When they woke up, the money didn't go to another exchange. It went into a mixer. A mixer is the one tool built specifically to beat people like us. Here is how we beat it back, in plain terms. A mixer is a black box for coins. You put Bitcoin in. Later, someone takes Bitcoin out. But what goes in and what comes out are deliberately disconnected: equal-sized chunks, shuffled together, no on-chain line you can draw from "money in" to "money out." Everyone's coins sit in one shared pool, and when a withdrawal happens the blockchain will not tell you whose deposit paid for it. So the obvious approach fails. We could see the stolen coins enter the mixer. Then the thread was cut. Thousands of withdrawals left the pool over the same period, and every one of them looked exactly like the next. No labels. No origin. Nothing that said "this one is the thief's." This is the wall. The point where most reports write "funds entered a mixer, trail lost" and close the file. But the attacker had one weakness they could not hide: the sheer scale of their deposits. They had pushed so much money through such a small mixer that, as we will see, that volume is the only reason any of this worked. We did not have a single withdrawal we could prove belonged to the attacker. So we stopped trying to follow the coins, and we asked a different question. Not "which coins are theirs?" but "how much of the pool has to be theirs?" Here is the key. A mixer can hide which coins belong to whom. It cannot break arithmetic. At any moment, the total sitting inside the mixer is just two things added together: our Threat Actor money, and everybody else's money. There is no third pile. Threat Actor balance + everyone else's balance = total balance. Always. And neither of those two balances can ever fall below zero. You cannot withdraw money that is not there. That last sentence is the crack in the wall. So we reconstructed the mixer's total balance and sorted all of its activity into three buckets: deposits we could tie to the Threat Actor, deposits we could tie to everyone else, and withdrawals, which the mixer had scrambled on purpose so that no withdrawal could be traced back to whose deposit it came from. With everything broken down this way, we pushed the numbers to their two extremes. Extreme one: assume every unattributed withdrawal was the Threat Actor. This drives their balance as low as it can possibly go. Sometimes it gets driven all the way to zero, and the instant it does, the next withdrawal cannot be theirs, there is nothing left in their pile to take. That extra withdrawal has to belong to someone else. Extreme two: assume the opposite, that every unattributed withdrawal was everyone else's. This drains the other pile to its minimum instead. When that one hits zero, the leftover withdrawals can't belong to anyone else. They must be the Threat Actor. That forced leftover is the overflow: the amount the mixer was mathematically compelled to allocate to one side or the other within the now identified narrow time window. Not a guess, not a probability, a certainty squeezed out of the simple fact that a balance can't go negative. The mixer's whole promise was you can't separate your coins from the crowd's. True. We didn't separate the coins. We separated the math. Now the part that actually matters: how do we know it's right? The overflow told us that the attacker withdrew inside a specific window. It did not tell us which withdrawals were theirs. So we settled it by elimination. Working from the blockchain data itself, and using [Caudena](https://www.linkedin.com/company/caudena/)'s aggregation of clusters, we took a sample of the withdrawals from that window and followed each one to the wallet cluster it ended up in. Caudena let us easily see the deposit clusters ranked by volume and group the withdrawals into their own clusters. Then we listed the biggest players sending money into the mixer and pulling money out of it. For each one, we simply counted how much they were moving. That told us who the heavy hitters were. One withdrawals cluster towered over everyone else. The rest were all much smaller. Our Threat Actor was, by a wide margin, the one moving the most. And that is the whole reason this worked. The attacker was the mixer's biggest depositor by far, pushing through more money than such a small service could ever hide. We checked every other player, right down to the second-biggest, and none of them came anywhere close to that volume found in the withdrawal cluster. Once they were all ruled out, only one wallet cluster was left that could explain the money: our Threat Actor. From that anchor, everything downstream came loose. The mixer was built so that no single withdrawal could ever be pinned to the thief. It never had to be. The balance sheet pinned them for us. ## Inside Inferno Drainer A DeFi protocol's social media account got hijacked. Fake airdrop, cloned site, one phishing link, one malicious signature, wallets drained. URL: https://anfossi.systems/writing/inside-inferno-drainer/ ![Hell is clogged](./assets/image1.jpeg) *Hell is clogged* A DeFi protocol's social media account got hijacked. Fake airdrop, cloned site, one phishing link, one malicious signature, wallets drained. The malware was Inferno Drainer. And for two days, I couldn't tell you who pulled the trigger. Let me show you why, in plain terms. When a victim approves the malicious transaction, their crypto doesn't go straight to the thief. It flows through a chain of automated contracts. A throwaway "forwarder" contract (created on the spot, used once, never again) passes the native crypto into one shared contract that acts as the collection point for the loot. From there the operator can pull out their 80%. The remaining 20% goes to the people who built the malware. Other tokens get auto-split the same way, 80/20, in the same instant (with or without throwaway "forwarders" depending on the case). ![Inferno Drainer diagram.](./assets/image3.png) *Inferno Drainer diagram.* Clean. Industrial. And shared. That last word is the whole problem. Inferno Drainer is malware-as-a-service. Hundreds of independent criminals rent the exact same kit and push everything through the exact same contracts. That's not a flaw. That's the product. The shared infrastructure IS the anonymity. You're not one thief in a room. You're one thief in a stadium, and every move you make looks identical to everyone else's. So I started where the money pools: that single shared collection contract (Smart Contract A). I pulled every address that ever took funds out of it. Thousands came back. Thousands of wallets, all looking identical. One of them ran the attack I was hunting. The rest were strangers, robbing other people, the same timeframe, with the same tool. No names. No labels. Nothing that said "this is the one." This is the moment the malware is designed for. The point where a couple of obvious searches (E.g. time window query) come back with nothing, and most people write "untraceable" in the report and close the file. I didn't have a single thing that separated my attacker from the crowd. So I stopped looking at the crowd. And I asked a different question. Who did this attacker actually target? Not random people. They cloned ONE specific protocol. So their victims weren't random either, they were people who held that protocol's tokens and the respective collateral. And if you're the operator who handled all those drained wallets, your own address has to carry the residue: those same tokens showing up in your history far more than any unrelated criminal's would. That was the crack in the wall. So I ran one query. Take that pile of thousands, and keep only the addresses that ever touched the 34 token contracts belonging to that protocol's ecosystem. I built it on [Dune](https://www.linkedin.com/company/dune-analytics/) and turned the result into a heat map (think of it as a brightness score, where the more an address connects to those tokens, the hotter it glows). Thousands collapsed to 32. And inside those 32, one address didn't just touch a token or two. It lit up across the entire board. Every ecosystem asset, all of it, on a single wallet, with the exact timing of the attack: funds arriving the moment the fake sites went live, activity stopping the moment the campaign ended. Not a coincidence. A confession written in timestamps. That became the Threat Actor's Address. From that one anchor, everything unspooled: every victim's wallet identified, and the money traced forward through bridges and laundering tricks designed to shake investigators off, all the way to deposit accounts inside exchanges that know exactly who opened them. The attacker hid inside shared infrastructure, thinking the crowd was cover. The crowd was the dataset. # Glossary ## Blockchain URL: https://anfossi.systems/glossary/blockchain/ A distributed ledger replicated across a network of nodes, in which transactions are grouped into blocks and each block contains the cryptographic hash of the previous block’s header. Altering a recorded block would invalidate every later block and would require the cooperation of the network’s consensus mechanism, so the history is tamper-evident and, in practice, append-only. Immutability is not absolute: recent blocks can be replaced during a chain reorganisation, and on Proof-of-Work networks finality is probabilistic, growing stronger with each block added on top. On public blockchains the ledger can be read by anyone, which is what makes forensic analysis possible; privacy-oriented protocols restrict this visibility. ## Block URL: https://anfossi.systems/glossary/block/ A batch of transactions added to the blockchain at one time, together with a header containing, among other things, the hash of the previous block, a timestamp and a summary hash (Merkle root) of the transactions included. The block height is its sequential position in the chain. ## Transaction URL: https://anfossi.systems/glossary/transaction/ A signed instruction, broadcast to the network and recorded in a block, that changes the state of the ledger, typically by moving value or calling a smart contract. A single transaction may involve several senders, recipients and assets, and may trigger further internal transactions. ## Transaction hash (TxID) URL: https://anfossi.systems/glossary/transaction-hash/ The unique identifier of a transaction, obtained by hashing its contents. Quoting the transaction hash allows any third party to locate and independently verify the transaction on a block explorer; it is the standard reference for on-chain evidence. ## Mempool URL: https://anfossi.systems/glossary/mempool/ The pool of transactions that have been broadcast to the network but not yet included in a block. There is no single mempool: each node keeps its own, and contents can differ between nodes. Transactions waiting there are publicly visible, which allows automated bots to react to them before confirmation (front-running, sweeping, MEV). Transactions sent privately to block builders never appear in the public mempool. Transactions that are dropped or replaced before confirmation leave no trace on-chain; evidence of them, and first-seen timestamps, exist only in the records of mempool observers. ## UTXO model URL: https://anfossi.systems/glossary/utxo-model/ The accounting model used by Bitcoin and networks derived from it (Litecoin, Bitcoin Cash, Bitcoin SV, Dash, Dogecoin, the transparent layer of Zcash). Funds exist as discrete Unspent Transaction Outputs; a transaction consumes existing outputs in full as inputs and creates new outputs. A balance is the sum of the unspent outputs a key can spend. Cardano uses an extended UTXO model and was developed independently of Bitcoin. On Cardano, addresses can carry a staking credential shared across a wallet, which links those addresses even when they are never spent together, a useful lead in investigations. ## Account model URL: https://anfossi.systems/glossary/account-model/ The accounting model used by Ethereum, Tron, BNB Smart Chain and most smart-contract platforms. Each address has a balance stored in the network state, and a transaction debits one account and credits another directly. A sequence number (nonce) orders the transactions sent from each account. There is no co-spending of inputs, so UTXO heuristics such as common-input ownership do not apply. ## Nonce URL: https://anfossi.systems/glossary/nonce/ In the account model, a counter attached to each sending address: every transaction must carry the next number in sequence, which fixes the order of an address’s transactions and prevents the same signed transaction from being executed twice. A pending transaction can be replaced by broadcasting another one with the same nonce and a higher fee, which is how transactions are cancelled or accelerated, and how sweeper bots and rescue attempts compete for the same funds. The nonce reveals how many transactions an address has sent; contract addresses keep a separate nonce for the contracts they create. The term is also used, with a different meaning, for the value miners vary in Proof-of-Work blocks. ## Fork URL: https://anfossi.systems/glossary/fork/ A divergence in a blockchain’s history. A hard fork that is not adopted by the whole network produces two separate chains sharing the same history up to the split (e.g., Bitcoin Cash from Bitcoin in 2017). Keys valid before the split control the corresponding balances on both chains, which allows activity to be linked across the two networks. ## Block explorer URL: https://anfossi.systems/glossary/block-explorer/ A website or tool that indexes a blockchain and presents its blocks, transactions and address balances in readable form. It allows independent verification of on-chain facts but provides no attribution beyond any labels added by its operator. ## Privacy coin URL: https://anfossi.systems/glossary/privacy-coin/ A cryptocurrency designed to conceal some or all transaction details. Monero hides senders, recipients and amounts by default (ring signatures, stealth addresses, confidential transactions); Zcash offers optional shielded transactions based on zero-knowledge proofs. Tracing within these protocols is severely limited and usually relies on the points where funds enter or leave them. ## Smart contract URL: https://anfossi.systems/glossary/smart-contract/ A program deployed at an address on a blockchain that executes automatically when called by a transaction, according to its code. A contract exposes functions that read state (balances, configuration, permissions) and functions that write state (transfers, minting, burning, role changes, upgrades). Smart contracts implement tokens, decentralised exchanges, bridges and lending protocols. Their actions are recorded on-chain, but reconstructing a full call sequence may require execution traces or event logs. Many contracts reserve privileged write functions for administrator keys (see DeFi). ## Native coin URL: https://anfossi.systems/glossary/native-coin/ The base asset of a blockchain, used to pay transaction fees and secured directly by the protocol (e.g., BTC on Bitcoin, ETH on Ethereum, TRX on Tron). In investigations that move only tokens, the native coin still matters: every token transfer needs gas (or an equivalent fee) paid in the native asset. Following where that gas came from, who funded the fee-paying address, and how fee wallets were topped up can supply evidence that the token trail alone does not show. ## Token URL: https://anfossi.systems/glossary/token/ An asset created and managed by a smart contract on an existing blockchain, as distinct from the network’s native coin (e.g., ERC-20 tokens on Ethereum, TRC-20 tokens on Tron, SPL tokens on Solana). Balances are kept in the contract’s state, and transfers are normally signalled by standardised event logs. Each asset, whether a native coin or a token, must be traced independently as a separate resource; a token is identified by its contract address, not by its name or ticker. Token contracts may also include custom rules allowing the issuer or an administrator to move, mint, burn or freeze balances; in such cases a recorded movement does not necessarily reflect an action by the holder. Non-standard contracts may not emit the usual events. ## Token approval URL: https://anfossi.systems/glossary/token-approval/ A permission granted by a token holder that allows another address or smart contract to transfer a specified amount, often unlimited, of the holder’s tokens (allowance). Approvals can also be granted through off-chain signatures (permits). Approvals remain valid until revoked, so a malicious approval can be exploited long after it was given. ## Stablecoin URL: https://anfossi.systems/glossary/stablecoin/ A token designed to keep a stable value relative to a reference asset, usually the US dollar. Stablecoins may be backed by reserves held by an issuer (fiat-backed), over-collateralised with other crypto assets, or managed algorithmically. Fiat-backed stablecoins are issued by a central entity that typically retains the technical ability to freeze balances. Another notable example is tokenised gold and similar commodity-backed tokens that aim to track a physical reference asset rather than a fiat currency. ## Tether (USDT) URL: https://anfossi.systems/glossary/tether-usdt/ The most widely used fiat-backed stablecoin, issued by the Tether group and intended to maintain a 1:1 value with the US dollar. The issuer publishes periodic reserve attestations, which provide independent assurance over reported reserve figures but are distinct from a full audit of financial statements. USDT circulates on several networks, notably Tron and Ethereum. Through a blacklist function in its token contracts, the issuer can freeze USDT held at specific addresses on networks where Tether issues the token directly; bridged versions issued by third parties fall outside its blacklist. It does so at its own discretion, including in response to law-enforcement requests. ## Wrapped token URL: https://anfossi.systems/glossary/wrapped-token/ A token representing another asset on a different blockchain or in a different technical standard, redeemable for the original. Backing may be held by a custodian (e.g., WBTC, whose underlying BTC is held by a custodian and issued through authorised merchants) or locked in a bridge contract. WETH is a special case: an ERC-20 version of ETH on Ethereum itself. ## Counterfeit token URL: https://anfossi.systems/glossary/counterfeit-token/ A token deployed to impersonate a legitimate asset by copying its name, ticker, decimals or logo (e.g., a fake “USDT” issued by an unrelated contract). Wallet interfaces and some explorers display the copied name, so victims may believe they hold or have received genuine funds. Counterfeit tokens are used in fake-payment scams, address poisoning, fraudulent airdrops and investment fraud. They usually have no market value or liquidity (or fake liquidity on malicious DEXes set up to scam people). Verification always relies on the contract address published by the legitimate issuer. ## Non-fungible token (NFT) URL: https://anfossi.systems/glossary/nft/ A token in which each unit has a unique identifier, so that one unit is not interchangeable with another. NFTs are commonly issued under ERC-721, or under ERC-1155, a standard that supports both fungible and non-fungible units. An NFT proves control of the token itself; it does not, by itself, confer legal ownership of, or intellectual property rights in, the item it refers to, which is usually stored off-chain and referenced by a link. ## Seed phrase URL: https://anfossi.systems/glossary/seed-phrase/ A sequence of typically 12 or 24 words (BIP-39 standard) from which a wallet deterministically derives all of its private keys and addresses (BIP-32/BIP-44). Anyone holding the seed phrase can reconstruct the entire wallet on any compatible software or device. An optional passphrase (often called the “25th word”) generates a different, hidden set of keys from the same words; without it, those funds do not appear. ## Private key URL: https://anfossi.systems/glossary/private-key/ A secret number (256 bits on Bitcoin, Ethereum and most major networks) used to produce the digital signatures that authorise spending from the associated addresses. For a standard single-key address, the signature is the only form of authorisation the network recognises: whoever holds the key controls the funds. Exceptions include multisignature addresses and smart-contract wallets, where control may depend on several keys or on rules coded in the contract. Loss of a key results in loss of funds only if no backup exists. ## Public key URL: https://anfossi.systems/glossary/public-key/ In Bitcoin, Ethereum and most protocols, a key derived from a private key through elliptic-curve scalar multiplication, a process that is computationally infeasible to reverse with current classical computing methods. It is used to verify digital signatures. On Bitcoin, the public key is generally revealed when an output is spent, although some output types expose it earlier; on Ethereum, it can be recovered from the transaction signature and the signed transaction data. ## Address URL: https://anfossi.systems/glossary/address/ The identifier used as sender or recipient in transactions. Its construction depends on the network: legacy and SegWit Bitcoin addresses encode a hash of the public key or of a script; Bitcoin Taproot addresses encode a tweaked public key; Ethereum addresses are the last 20 bytes of the Keccak-256 hash of the public key; Solana addresses encode a 32-byte value that may represent a public key or a program-derived address (PDA). Smart contract addresses and Solana PDAs are not necessarily derived from public keys. Addresses are pseudonymous: they reveal no identity by themselves but can be linked to a person or entity through analysis or off-chain data. ## Change address URL: https://anfossi.systems/glossary/change-address/ In the UTXO model, each input must be spent in full. When there is a remainder after paying the recipient and the transaction fee, it is typically returned to an address controlled by the sender, called the change address, usually generated automatically by the wallet; some wallets return change to an address used previously. Transactions without a change output may represent an exact payment or a transfer of the full input value, less fees. Distinguishing change from payment outputs is central to tracing, but becomes less reliable in transactions involving multiple participants or recipients, such as CoinJoin and PayJoin transactions. Change identification is a heuristic and should be reported with its basis. ## Deposit address URL: https://anfossi.systems/glossary/deposit-address/ An address generated or assigned by a custodial service, such as a centralised exchange, to receive funds for a customer account. Deposited funds remain on-chain, and subsequent transfers between addresses are publicly visible; crediting the deposit to the customer and the customer's subsequent activity, such as trades and internal transfers, are recorded in the service's internal ledger. Identifying a deposit address may allow authorities to request information about the associated account, including KYC data where available, but the account holder is not necessarily the actual controller of the funds. On most networks, deposit addresses are assigned to individual accounts, while some services use shared addresses that require a memo or tag to identify the customer. ## Memo / destination tag URL: https://anfossi.systems/glossary/memo-destination-tag/ An additional transaction field that services use to identify the recipient account when multiple customers share a deposit address. On XRP Ledger, destination tags are specifically intended to distinguish payments to different recipients sharing an address; on networks such as Stellar, EOS, TON and Cosmos-based chains, memos serve more general purposes. Memo and tag values are publicly visible on-chain. Without the required memo or tag, a deposit to a shared address cannot be automatically attributed to a specific customer account, although the service may be able to credit it manually. ## Wallet URL: https://anfossi.systems/glossary/wallet/ The software or device used to manage cryptographic keys, display balances and build transactions, or to access keys managed by a service provider. A wallet can manage multiple addresses. This glossary uses “wallet” in this technical sense; groups of addresses attributed through analysis to a common controller are called clusters. ## Hot wallet URL: https://anfossi.systems/glossary/hot-wallet/ A wallet whose keys are kept on an internet-connected system, allowing transactions to be signed and broadcast promptly. In the context of services, hot-wallet addresses are used to process withdrawals; customer deposits may be periodically swept into them, depending on the service's architecture. Keeping keys online increases their exposure to compromise, so services typically limit the funds held in hot wallets. ## Cold wallet URL: https://anfossi.systems/glossary/cold-wallet/ A wallet whose private keys are kept offline, such as on a hardware device where the key never leaves the device. Keys or the seed from which they are derived can also be stored offline on paper or metal. Services typically use cold wallets to secure the bulk of customer funds; the assets themselves remain on-chain. ## Hardware wallet URL: https://anfossi.systems/glossary/hardware-wallet/ A dedicated physical device that generates or imports private keys and signs transactions internally, keeping the keys from being exposed to the connected computer. Keys are typically stored in protected hardware, often a secure element. Access is usually protected by a PIN, and some devices erase stored secrets after repeated incorrect attempts. Seizing the device does not necessarily provide access to the funds or immobilize them: the seed phrase backup, any additional passphrase, and other copies of the keys may provide independent access. ## Custodial and non-custodial wallet URL: https://anfossi.systems/glossary/custodial-wallet/ In a custodial wallet, a service provider controls the keys on the user's behalf, typically giving the user a contractual claim to the assets. The provider can usually identify the user and may freeze access or disclose information. In a non-custodial (self-custody) wallet, the user controls the keys without relying on a custodian to authorize transactions. However, issuers can freeze certain tokens, such as USDT or USDC, at the contract level. Hybrid arrangements, such as multisig and MPC wallets, distribute control between users and providers. ## Multisignature (multisig) URL: https://anfossi.systems/glossary/multisig/ An arrangement in which spending or other actions require valid signatures from a minimum number of designated keys (m-of-n, e.g., 2-of-3). Used by businesses, custodians and bridges. A multisig structure does not by itself prove that control is shared: all keys, or the signing process, may in practice be controlled by a single person or entity. Conversely, threshold or aggregated signature schemes can distribute signing authority while producing a single on-chain signature. Attribution must therefore establish who actually controls the keys and signing process, rather than infer either shared or sole control from the transaction structure alone. ## Virtual asset service provider (VASP) URL: https://anfossi.systems/glossary/vasp/ As defined by the FATF, a natural or legal person not covered elsewhere under the FATF Recommendations who, as a business and for or on behalf of another person, conducts one or more of the following: exchange between virtual assets and fiat currencies; exchange between one or more forms of virtual assets; transfer of virtual assets; safekeeping or administration of virtual assets or instruments enabling control over them; or participation in and provision of financial services related to an issuer’s offer or sale of a virtual asset. Providers of non-custodial software and persons acting only for themselves generally fall outside the definition. Classification depends on the activities actually performed, not merely on how a service describes itself. Whether a VASP is subject to specific AML/CFT obligations depends on the implementing legislation of each jurisdiction. ## Crypto-asset service provider (CASP) URL: https://anfossi.systems/glossary/casp/ The EU category established by Regulation (EU) 2023/1114 (MiCA). It covers ten listed services, including custody and administration, operation of a trading platform, exchange of crypto-assets for funds or other crypto-assets, execution, reception and transmission of orders, placing, advice, portfolio management and transfer services. Under MiCA, a CASP is a legal person or other undertaking authorised to provide crypto-asset services, although certain already-regulated financial institutions may provide them under a notification procedure. CASP and the FATF VASP concept overlap but are not identical. MiCA establishes an authorisation and conduct regime, including capital requirements and the possibility of passporting across the EU; CASPs are also subject to applicable EU AML/CFT obligations. The FATF VASP definition is an international standard implemented through national legislation and can include natural persons. The two frameworks also differ in scope. MiCA expressly lists services such as advice, portfolio management, and reception and transmission of orders, which the FATF definition does not name separately, although some related activities may fall within its broader categories. Crypto-assets qualifying as financial instruments fall under the relevant EU financial-services legislation, including MiFID II, rather than MiCA. Both MiCA and FATF look beyond the label applied to an asset when considering NFTs, but their tests differ: MiCA focuses on uniqueness and non-fungibility, while FATF also considers whether an NFT is used in practice for payment or investment purposes. ## Know your customer (KYC) URL: https://anfossi.systems/glossary/know-your-customer/ The identification and verification of customers by regulated entities, including VASPs, under AML/CFT rules. The broader regulatory process, known as customer due diligence (CDD), also includes identifying beneficial owners, understanding the purpose of the business relationship and ongoing monitoring. KYC and account records held by a service, including identity documents, contact details, IP logs and linked bank accounts, can help link an on-chain address to a real-world identity. However, the account holder is not necessarily the actual controller of the funds, and records may be incomplete, unreliable or no longer available due to retention limits. ## Know your business (KYB) URL: https://anfossi.systems/glossary/know-your-business/ The due-diligence process a regulated service applies to corporate customers: verification of the legal entity and its registration, directors and authorised signatories, ultimate beneficial owners, business activity, expected transaction volumes and any required licences. When funds reach an account held by a company, such as a payment processor, an OTC desk or a nested service, it is the KYB file, rather than individual KYC, that identifies who stands behind the account. ## Know your transaction (KYT) URL: https://anfossi.systems/glossary/know-your-transaction/ A commercial term used in blockchain analytics for the screening of transactions for risk signals, such as exposure to sanctioned entities, darknet markets, scams, ransomware or stolen funds. KYT is not a defined regulatory term; the related regulatory obligation is ongoing transaction monitoring, which forms part of customer due diligence (CDD). VASPs typically use blockchain analytics software to screen outgoing withdrawals before execution, incoming deposits after they appear on-chain but before crediting them to a customer, and previously processed transactions when new attribution data changes their risk profile. Screening may identify direct exposure to a flagged entity or indirect exposure through multiple intermediary transfers. The weight assigned to indirect exposure varies between providers. Alerts and risk scores depend on the provider's attribution data and proprietary methodologies, which may be probabilistic and incomplete. Different tools may therefore assess the same transaction differently. An alert is a lead for further investigation, not proof of illicit activity. KYT complements KYC: KYC helps establish who the customer is, while KYT assesses transaction-related risk. ## Travel Rule URL: https://anfossi.systems/glossary/travel-rule/ The requirement for originator and beneficiary information to be collected, transmitted and retained by service providers involved in a virtual-asset transfer. Under the FATF Standards, Recommendation 16 is applied to virtual assets through Recommendation 15 and its Interpretive Note (INR.15). In the EU, Regulation (EU) 2023/1113, applicable since 30 December 2024, requires the relevant information for transfers within its scope regardless of amount. For transfers involving self-hosted addresses, CASPs must collect and retain the required information; for transfers exceeding EUR 1,000, they must also take adequate measures to assess whether the address is owned or controlled by their customer. The information is exchanged between service providers through off-chain messaging systems, not recorded directly on the blockchain. It can provide investigators with information about the parties to a transfer, but its reliability depends on how the data was obtained and verified: the originating provider verifies information about its own customer, while information about the beneficiary is generally supplied by the originator and checked against the receiving provider's customer records. Transfers involving jurisdictions that have not implemented the Travel Rule, or have implemented it incompletely, may lack the expected information. ## Centralised exchange (CEX) URL: https://anfossi.systems/glossary/centralised-exchange/ A custodial trading platform operated by a company, where users deposit assets into addresses controlled by the platform and trade through an internal order book or directly with the platform as counterparty. Movements between customer accounts on the same platform are recorded in its internal ledger rather than on-chain. Some internal transfers, including transfers between users or withdrawals to addresses controlled by the same platform, may therefore occur without an on-chain transaction. As custodians, exchanges can restrict access to accounts and assets held on the platform; regulated exchanges are also subject to applicable KYC and information-sharing obligations. When funds leave the platform, tracing may require the exchange's internal records to establish the subsequent recipient or movement. ## Nested service URL: https://anfossi.systems/glossary/nested-service/ A service, such as a smaller exchange, OTC desk, payment processor or broker, that conducts some or all of its virtual-asset activity through accounts held at a larger exchange or other service provider. It may also operate its own wallets and on-chain infrastructure, using the host for liquidity, trading or settlement. The host's on-chain transactions may therefore reflect the activity of the nested service rather than identify its underlying customers. The host's customer records may identify the nested business through business due diligence (KYB), but some services operate through accounts registered to individuals, obscuring the commercial relationship and the identity of the end customers. Host records, including deposit addresses, timestamps and amounts, can still help reconstruct activity, but identifying the underlying customers may require additional records from the nested service, which may be unavailable or difficult to obtain. Nested relationships create money-laundering risks because the host may have limited visibility into the nested service's customers and transactions. The FATF treats these arrangements as analogous to correspondent banking relationships and calls for enhanced due diligence. In practice, gaps in licensing, supervision and cross-border enforcement can leave such activity inadequately monitored. ## Decentralised finance (DeFi) URL: https://anfossi.systems/glossary/defi/ Financial services, such as trading, lending, borrowing, derivatives and yield products, implemented through smart contracts rather than provided solely by a conventional intermediary. DeFi protocols are often permissionless and do not routinely collect users' identity data, although some impose access restrictions or KYC requirements. Front-ends, wallet services and RPC providers may retain other information, such as IP addresses and records linking network activity to wallet addresses. Many protocols have privileged roles that can pause contracts, upgrade code, change parameters, mint tokens or restrict addresses. Contract ownership, proxy administrators and role assignments can often be identified from on-chain state and events. Control may rest with an individual key, a multisignature arrangement, a timelock or a governance contract. A multisig does not by itself prove that control is genuinely shared, a timelock delays execution but does not identify who decides, and governance power may be concentrated among a small number of token holders. Upgrade authority is particularly significant because it may allow fundamental changes to a protocol's rules, potentially including how deposited funds can be accessed. For attribution, investigators should identify who controls privileged keys or roles, examine governance and voting-power concentration, and investigate front-end operators and other identifiable participants. The existence of administrative control may also be relevant when assessing whether a protocol or its operators fall within the FATF's VASP framework or the EU's MiCA regime. MiCA excludes crypto-asset services provided in a fully decentralised manner without an intermediary, but the application of that exclusion depends on the actual arrangement, not merely on the protocol's label. ## Liquidity pool URL: https://anfossi.systems/glossary/liquidity-pool/ A smart-contract-based reserve of tokens used to facilitate trades on a decentralised exchange (DEX). Liquidity providers (LPs) deposit tokens into a pool and receive a claim on their share of the reserves, typically represented by fungible liquidity-provider tokens or, in concentrated-liquidity systems such as Uniswap v3, by an NFT. Some protocols hold reserves for multiple pools in a shared contract, with each pool distinguished by the protocol's internal accounting and transaction events. Pool reserves are commingled, but swaps and liquidity deposits and withdrawals remain traceable on-chain. A swap's input and output transfers can generally be analysed as part of the same transaction, while liquidity-provider positions can be tracked through the associated tokens or NFTs and the relevant contract events. ## Decentralised exchange (DEX) URL: https://anfossi.systems/glossary/decentralised-exchange/ A protocol that enables users to exchange crypto-assets from their own wallets through smart contracts, typically without depositing funds with a custodian or registering a customer account. Many DEXs use automated market makers (AMMs) and liquidity pools; others match orders on-chain or off-chain and settle trades on-chain. Aggregators route trades across multiple DEXs to seek better execution. DEX trades are generally visible on-chain, including the assets exchanged and the transaction through which settlement occurs, allowing tracing to continue across the swap. However, the protocol itself may not collect customer identity data. Other components, such as web front-ends, RPC providers and wallet services, may retain useful information, including IP addresses or records linking network activity to wallet addresses. A decentralised design does not automatically place a protocol outside the definition of a virtual asset service provider (VASP) or crypto-asset service provider (CASP); classification depends on the activities performed and the degree of control exercised by identifiable persons or entities. ## DEX and bridge aggregator URL: https://anfossi.systems/glossary/aggregator/ A service, consisting of router smart contracts and an off-chain routing engine, that finds the best price or path for a swap or a cross-chain transfer and executes it across several DEXs, liquidity pools or bridges in a single user transaction (e.g., 1inch or Jupiter for swaps, LI.FI for cross-chain routes). On-chain, the funds pass briefly through the aggregator’s router and are split across multiple venues before reaching the recipient, who may be an address other than the sender. The aggregator is an intermediary, not the counterparty: tracing must follow the internal transactions and events through the router to the actual output, and in cross-chain routes match the legs on each chain. ## Instant exchange service URL: https://anfossi.systems/glossary/instant-exchange/ A custodial service, also known as a centralised swap service, that receives one crypto-asset at a deposit address and sends another asset, often on a different network, to an address specified by the user. Such services may operate with limited or no routine KYC, but can request identity information or hold funds when transactions trigger risk-based screening. Even without KYC, service records may contain useful investigative data, such as order IDs, timestamps, IP addresses, user-agent details, refund addresses and email addresses. The incoming and outgoing transfers are not inherently linked by an on-chain protocol, as they would be in a bridge or a non-custodial swap. However, timing, amounts adjusted for exchange rates and fees, and known service-wallet patterns may support a probable link between the two legs. Such links are heuristic and should be corroborated with service records where available. Some services rely partly or wholly on accounts at larger exchanges, creating a nested-service relationship in which the host exchange's records may also be relevant. ## Over-the-counter (OTC) desk URL: https://anfossi.systems/glossary/otc-desk/ A service that facilitates large crypto-asset trades directly with clients outside public order books. An OTC desk may act as principal, buying or selling from its own inventory, or as an intermediary connecting buyers and sellers. Depending on its activities and jurisdiction, it may require authorisation as a VASP or, in the EU, a CASP; some desks operate without the required licence. For tracing, the key limitation is that only the crypto-asset leg of a crypto-to-fiat trade is visible on-chain. The fiat payment may occur through bank transfers, cash or other payment channels, and must be investigated using financial records or information held by the desk or other counterparties. OTC desks can be difficult to identify on-chain because they may use ordinary wallet addresses rather than recognisable exchange infrastructure, or operate through accounts at larger exchanges, appearing on-chain as activity of the host exchange. A desk acting as an intermediary may also conceal the identity of the ultimate buyer or seller unless its records can be obtained. ## Coin mixer URL: https://anfossi.systems/glossary/coin-mixer/ A service or protocol designed to obscure the relationship between cryptocurrency inputs and outputs by combining activity from multiple users. Mixers take several forms: custodial services that receive deposits and make withdrawals; smart-contract-based protocols, sometimes using off-chain relayers; and CoinJoin systems, in which multiple users collaboratively construct a single transaction with outputs designed to make ownership harder to infer, typically without transferring custody to a mixer operator. For custodial mixers, the link between deposits and withdrawals may be preserved in the operator's internal records, which can become available through cooperation or seizure. For smart-contract mixers and CoinJoin transactions, tracing instead relies on transaction structure, timing, amounts and other observable patterns. Links inferred across a mixer are generally probabilistic rather than conclusive. They may become more reliable when amounts are distinctive, few other users are active in the relevant time window, or users make operational mistakes. Examples include reusing addresses or funding a mixer withdrawal address with transaction fees from an address linked to the original deposit. Such evidence should be evaluated alongside other information (see Demixing). ## Transfer URL: https://anfossi.systems/glossary/transfer/ An on-chain movement of value between addresses or accounts. In the account model, the transaction's native-asset value is explicitly recorded, while internal transfers of native assets executed by smart contracts are reconstructed through transaction execution traces. Token transfers are commonly represented by contract-emitted events, but these events are not always a reliable record of balance changes: malicious contracts can emit misleading logs, and some tokens alter balances in ways that do not correspond directly to standard transfer events. The contract's state is the authoritative source for token balances. In the UTXO model, a transaction can consume multiple inputs and create multiple outputs without specifying which input funded which output. Individual flows are therefore analytically inferred. In both account and UTXO models, when an address or transaction combines illicit and legitimate funds, the protocol does not necessarily identify which funds are subsequently spent. The amount of illicit value attributed to a transfer depends on the tracing method applied, such as FIFO, proportional allocation or taint-based methods. These methods are analytical conventions, not explicit on-chain facts. ## Internal transaction URL: https://anfossi.systems/glossary/internal-transaction/ An operation triggered by a smart contract during the execution of an on-chain transaction, rather than submitted as a separate transaction by a user. It can include native-coin transfers made by contracts, calls between contracts, or the creation of new contracts. Internal transactions are not recorded as standalone transactions; they are reconstructed from execution traces, which may not be fully displayed by block explorers. Failed or reverted operations must be distinguished from completed transfers. Token transfers are generally displayed separately, based on events emitted by token contracts (see Transfer). ## Swap URL: https://anfossi.systems/glossary/swap/ The exchange of one crypto-asset for another. In a non-custodial swap on the same network, the exchange usually occurs atomically within a single transaction, even when multiple pools or intermediate tokens are involved. The recipient may differ from the address that initiated the swap. Cross-chain swaps involve activity on separate networks, with the connection between the two legs established through bridge messages, protocol records or other evidence (see Bridge). In a custodial swap through a centralised exchange or instant exchange service, the on-chain trail may break between the incoming and outgoing transfers. Timing and amounts can suggest a probable link, but service records may be needed to confirm it. In derivatives markets, “swap” can also refer to a financial contract rather than an exchange of crypto-assets. ## Cross-chain bridge URL: https://anfossi.systems/glossary/cross-chain-bridge/ A protocol that transfers assets or value between different blockchains. Common designs include lock-and-mint, where an asset is locked on the source chain and a wrapped equivalent is minted on the destination chain, with the reverse process typically burning the wrapped token and releasing the original; burn-and-mint, where an asset is burned on one chain and minted natively on another; and liquidity networks, which pay users from pools already held on the destination chain. The two legs appear on separate ledgers. They can often be matched using transfer or message identifiers recorded in bridge events; where these are unavailable, amounts, timing and destination addresses can help establish a probable link. The destination address need not match the source address, and in liquidity networks no mint event occurs on the destination chain. Many bridges rely on validators or multisignature arrangements to authorise transfers, creating potential points of control, compromise or intervention. Investigators should therefore examine both the cross-chain transfer records and the entities or keys controlling the bridge. ## Bridge explorer URL: https://anfossi.systems/glossary/bridge-explorer/ A website or tool that tracks transfers through one or more cross-chain bridges and presents their source and destination transactions in a readable form. It may use protocol message identifiers to link the two legs and display transfer status, such as pending, completed, failed or refunded. Official bridge explorers generally rely on their protocol's own message data, while third-party aggregators may use their own matching methods. A bridge explorer facilitates verification but is not itself proof that a transfer completed correctly. The underlying transactions should be checked on the respective blockchains, since displayed links or statuses may be incomplete or inaccurate. Coverage is limited to the bridges and networks supported by the tool, and its labels do not establish attribution beyond the evidence they represent. ## Chain-hopping URL: https://anfossi.systems/glossary/chain-hopping/ The movement of funds across multiple blockchains through bridges, crosschain swaps and exchange services. Although often associated with attempts to frustrate tracing or delay enforcement, chain hopping also occurs for legitimate reasons. Its investigative impact depends on the routes used: non-custodial swaps and bridges may remain traceable through on-chain transactions and protocol records, while custodial services can break the visible link between transfers. Movement into privacy-focused networks or through services in jurisdictions with limited cooperation can create further obstacles. The pattern alone does not establish illicit intent, which must be assessed using additional evidence, such as the speed and frequency of transfers, their apparent economic purpose and the origin of the funds. ## Flash loan URL: https://anfossi.systems/glossary/flash-loan/ A loan offered by a DeFi protocol that requires no collateral because it must be borrowed and repaid, with a fee, within the same transaction. If repayment fails, the entire transaction reverts as if it had never happened. Flash loans are used for arbitrage, liquidations and refinancing, and also in attacks, for example to manipulate prices or governance votes with borrowed capital. For investigators, a flash-loan operation is contained in a single transaction made of many internal transactions. The amounts borrowed are not the operator’s own funds and should be distinguished from the net profit, which is what actually leaves the transaction. ## Maximal extractable value (MEV) URL: https://anfossi.systems/glossary/mev/ The value that block producers, and the specialised actors (searchers and builders) who prepare blocks for them, can capture by choosing which transactions to include and in what order. Typical forms are arbitrage between pools, liquidations, front-running and sandwich attacks, in which a victim’s trade is surrounded by two transactions that profit from its price impact. MEV activity appears on-chain as tightly ordered transactions in the same block, often with payments to the block builder. Its presence explains patterns that might otherwise be misread as coordinated by the parties under investigation. ## Airdrop URL: https://anfossi.systems/glossary/airdrop/ The distribution of tokens to multiple addresses, typically to promote a project or reward users for past activity. Some airdrops are sent automatically, while others must be actively claimed through an on-chain transaction. The presence of unsolicited airdropped tokens at an address does not by itself demonstrate any interaction by its controller; claiming tokens, however, provides evidence of activity by whoever controlled the signing key at the time. Airdrops can incentivise farming, in which users perform activities to qualify for token rewards, and sybil farming, in which they use multiple addresses or identities to obtain a disproportionate share. When rewards are claimed or consolidated, common funding sources, shared withdrawal destinations and subsequent transfers can help link addresses that initially appear unrelated. Projects may also publish lists of addresses identified as sybil, providing potentially useful attribution leads that should be treated as the project's own assessments rather than independently verified facts. Fake airdrops, often involving counterfeit tokens, are a common phishing tactic. Token names or metadata may direct recipients to malicious websites that trick them into signing transactions or granting token approvals, potentially enabling attackers to transfer their assets. ## Dusting URL: https://anfossi.systems/glossary/dusting/ The sending of very small amounts of cryptocurrency (“dust”) to target addresses, sometimes to encourage activity that may reveal links between addresses. In the UTXO model, an address whose outputs have been fully spent may remain unused and unlinked to the owner's other addresses, although address reuse and other tracing heuristics can still establish connections. Sending dust creates a new spendable output associated with the target address. If the owner's wallet later spends that output together with other inputs, for example during consolidation or automatic coin selection, the common-input heuristic may link the input addresses as being under common control. The sender can identify the dust output they created and monitor where it goes, but cannot determine which other inputs will be spent with it in advance. On account-based networks, there is no equivalent common-input heuristic, so dusting is more commonly associated with spam, advertising and address poisoning. Receiving dust does not demonstrate any action by the recipient. If the recipient later spends it alongside other UTXOs, the resulting link carries the usual evidential weight and limitations of the common-input heuristic, including exceptions such as CoinJoin and PayJoin. Some wallets allow users to flag suspicious outputs as “do not spend”. ## Address poisoning URL: https://anfossi.systems/glossary/address-poisoning/ A fraud technique in which an attacker creates a lookalike address, typically matching the first and last characters of an address the victim has previously used, and attempts to make it appear in the victim's transaction history. Attackers can generate such addresses using vanity-address techniques, repeatedly searching candidate keys until an address with the desired pattern is found. The attacker then introduces the address into the victim's history through small transfers, counterfeit tokens or, on some token contracts, zero-value transferFrom calls that appear to show a transfer from the victim to the attacker's address. The aim is to trick the victim into copying the lookalike address for a future payment. These transfers do not, by themselves, demonstrate any interaction between the victim and the lookalike address, even when the transaction appears to originate from the victim. Analysts should distinguish genuine user-authorised transfers from zero-value events and counterfeit-token activity. Addresses used in the same campaign may sometimes be linked through common funding sources or other on-chain patterns. ## Drainer URL: https://anfossi.systems/glossary/drainer/ A malicious toolkit, typically consisting of website scripts and smart contracts, designed to steal assets from victims' addresses by tricking them into authorising transactions or signing malicious messages. Common techniques include token approvals, permit signatures, deceptive NFT marketplace orders, and, on supported networks, malicious transactions or account delegations. Drainers are often deployed through fake websites, airdrops or mint pages. Unlike malware that steals private keys or compromises a device, a drainer typically exploits actions the victim is tricked into authorising, leaving on-chain transactions or other cryptographic evidence that can be investigated. Drainers are frequently operated under a drainer-as-a-service model, in which the kit provider receives a percentage of the stolen proceeds. This revenue split may be visible on-chain and can link separate incidents to the same drainer service, though not necessarily to the same affiliate. Transfers of the remaining proceeds may help identify the individual campaign operator or link incidents associated with the same affiliate. ## Sweeper bot URL: https://anfossi.systems/glossary/sweeper-bot/ An automated program run by a thief who holds the private key or seed phrase of a victim’s address. It watches the address, often through the mempool, and transfers out any incoming native coin immediately, usually by outbidding on fees. Because the victim cannot keep the coin needed to pay fees, tokens and other assets left at the address become impossible to move by ordinary means. Rescues typically rely on private order flow: the funding transaction and the rescue transfers are submitted together as a bundle, so they are executed in the same block without ever appearing in the public mempool. ## Peel chain URL: https://anfossi.systems/glossary/peel-chain/ A sequence of transactions in which funds move through successive addresses, each time sending (“peeling off”) a portion to another destination, often a service deposit address, while the remainder continues to a new address. The pattern is characteristic of the UTXO model, where wallets commonly generate a new change address for each payment. Exchange hot wallets may also produce similar patterns when processing withdrawals individually. On account-based networks, where there is no change output, a comparable pattern must be deliberately created by moving funds through successive addresses. Tracing a peel chain in the UTXO model depends on identifying the change output at each step (see Change address). Because change identification relies on heuristics, an error at one step can lead the investigation down the wrong path; uncertain links should be documented and reassessed. A peel chain alone does not indicate laundering. Its significance depends on context, including the source of funds, the destinations of peeled amounts, and the speed and regularity of transactions, which may indicate automation. ## CoinJoin URL: https://anfossi.systems/glossary/coinjoin/ A collaborative UTXO transaction in which multiple users combine inputs into a single transaction to obscure which outputs belong to which participants. Many CoinJoin implementations create multiple outputs of equal value, making it difficult to match those outputs to specific inputs from the transaction alone. Other outputs, such as change, may have distinctive values and can sometimes be linked to their inputs. CoinJoin transactions are often recognisable from their structure, and analysts generally avoid applying the common-input-ownership heuristic to them. CoinJoin obscures the mapping between inputs and outputs, but does not make all subsequent tracing impossible. Links may be recovered through distinctive change outputs, timing, address reuse or later transactions that combine outputs from different rounds or with unmixed funds. PayJoin also undermines the common-input-ownership heuristic, but can resemble an ordinary payment rather than an identifiable CoinJoin transaction. ## Freeze request URL: https://anfossi.systems/glossary/freeze-request/ A request to a custodial service, token issuer, bridge or protocol administrator to restrict the movement of assets believed to be stolen or subject to legal proceedings. Exchanges and custodians can block withdrawals through their internal systems, while issuers of centrally controlled tokens, such as Tether (USDT) and Circle (USDC), can freeze balances on-chain through privileged functions in their token contracts. Some DeFi protocols and bridges also have administrative controls that can pause operations or restrict addresses. Native coins on most public blockchains cannot be frozen through a token issuer's blacklist, although exceptional intervention by network validators or protocol governance may be possible on some networks. The legal basis and process vary by service and jurisdiction: some providers may act voluntarily or in response to law-enforcement requests, while others require a court order. A freeze restricts access or movement but does not itself transfer ownership or establish that the assets are proceeds of crime. Depending on the issuer's policies and the applicable legal process, frozen tokens may subsequently be burned and reissued to an authorised recipient. A freeze request should be distinguished from a judicial seizure, which is a legal measure imposed by the competent authority. Speed is often critical, as funds may be moved or dispersed within hours. ## Tracing URL: https://anfossi.systems/glossary/tracing/ Following the movement or provenance of value forward or backward from a defined starting point across successive transactions, intermediary addresses, swaps and bridges, applying a stated tracing method where funds are commingled. Through mixers, CoinJoin, privacy protocols and custodial services, tracing generally cannot be performed deterministically from on-chain data alone. Links may instead rely on probabilistic analysis, distinctive transaction patterns, user errors or third-party records. When funds pass through a custodial service, its internal records can help reconstruct movements between customer accounts, but assets traded or transferred within the service are fungible: investigators may be tracing the movement of value through accounts rather than the same identifiable units of cryptocurrency. Conclusions should distinguish direct on-chain links, heuristic inferences and links established through external records. ## Tracing methods URL: https://anfossi.systems/glossary/tracing-methods/ Analytical rules used to allocate illicit and legitimate funds when they are commingled at an address or within a transaction. These rules are accounting conventions, not records of which specific units of value were spent. Results can differ significantly depending on the method chosen, which should always be stated. FIFO (First In, First Out): funds are treated as leaving in the order in which they arrived. LIFO (Last In, First Out): the most recently received funds are treated as leaving first. Haircut (pro-rata): each outgoing transfer is assigned the same proportion of illicit funds as the balance from which it is paid. Poison: any transfer from a balance containing illicit funds is treated as entirely illicit. This is the most expansive of these rules. LIBR (Lowest Intermediate Balance Rule): the amount of illicit funds traceable through an address cannot exceed the lowest balance held between the receipt of the illicit funds and the point at which tracing is assessed. The rule assumes that the holder spends their own legitimate funds first, preserving the illicit funds for as long as the balance permits. Once the balance falls below the original illicit amount, subsequent legitimate deposits do not restore the traceable amount. These methods are particularly relevant when funds are commingled and their individual paths cannot be established directly. LIBR derives from common-law tracing principles and is used in some asset-recovery proceedings. Its legal applicability depends on the jurisdiction and the proceedings involved; analytical tracing conventions do not automatically determine legal ownership or entitlement to recovery. ## Address clustering URL: https://anfossi.systems/glossary/address-clustering/ The use of heuristics and other evidence to group addresses likely controlled by the same person or entity. Common methods include: Common-input ownership (UTXO): inputs spent together are presumed to share a controller. Invalid for CoinJoin, PayJoin and other collaborative transactions. Change identification: change outputs are attributed to the sender (see Change address). Deposit-address reuse: addresses sending to the same exchange deposit address may belong to its customer, though third parties can also pay into it. Gas funding (account model): new addresses funded for fees by the same source may be related. Behavioural patterns: recurring amounts, timing, fee settings or software fingerprints. Off-chain evidence: IP addresses, KYC records or public posts, from service providers or open sources. On EVM chains the same key yields the same address on every network, but identical contract addresses may have different controllers. Results are probabilistic. Because clustering is transitive, a single false link can merge unrelated clusters. Each link should be reported with its basis and confidence, and corroborated where possible. ## Cluster URL: https://anfossi.systems/glossary/cluster/ A set of addresses attributed, through clustering, to a single controller. A cluster may represent an individual, a criminal group or a service. Grouping addresses and identifying their controller are separate steps: a cluster may remain unidentified until additional evidence, such as service records, test deposits or open-source information, supports attribution. Service clusters, such as those belonging to an exchange, may contain millions of addresses, most of them deposit addresses assigned to different customers. Membership of a service cluster therefore identifies the service, not the individual customer, and may also encompass activity conducted through nested services. Cluster boundaries depend on the heuristics and data used: different tools may produce different clusters, while errors can cause unrelated addresses to be merged or addresses controlled by the same entity to remain separate (see Address clustering). ## Attribution URL: https://anfossi.systems/glossary/attribution/ The process of determining who controls an address or cluster and, where different, who ultimately benefits from it (beneficial ownership). Attribution may identify a broad entity category, such as an exchange, mixer or scam, or a specific person or organisation. It combines on-chain findings with off-chain evidence, including KYC records, test deposits, addresses published by services, labelled-entity databases, open-source intelligence, sanctions lists and data recovered from seized devices. Control and beneficial ownership are distinct and should be stated separately. Labels from blockchain analytics providers are themselves attribution claims, often based on proprietary methods and with varying levels of transparency and reliability. They should be treated as leads to verify rather than conclusive evidence, and the provider and supporting evidence should be documented where possible. Every attribution has an author, whether an analytics provider, the service itself, a public authority, an open source or the investigator, and should be recorded with that author, its date and the evidence it rests on. An attribution adopted from a third party remains that party's claim until independently corroborated; repeating it in a report does not make it the investigator's finding. ## Taint URL: https://anfossi.systems/glossary/taint/ The amount or proportion of value at an address or in a transfer attributed to an illicit source under a given tracing method. Taint is an analytical result, not an intrinsic property of the funds or a legal determination. It depends on the illicit sources identified, the tracing method applied and the scope of the analysis. The same funds may therefore receive different taint values under different methods (see Tracing methods). Taint is related to, but distinct from, the risk exposure scores reported by blockchain analytics tools (see Risk report). ## Source of funds URL: https://anfossi.systems/glossary/source-of-funds/ Backward tracing: identifying the origins of funds received by an address or cluster under investigation, tracing them through preceding transactions towards the entities or events from which they came. As tracing moves backwards, in some cases the flow branches across multiple addresses and sources, increasing the number of paths to investigate. Analysts should therefore define stopping criteria, such as an amount threshold, a maximum number of hops or the identification of a relevant service or originating event. In AML compliance, source of funds refers to the origin of the money used in a specific transaction or business relationship, such as salary, business income or proceeds from an asset sale. It is distinct from source of wealth, which concerns the origin of the customer's overall assets. In this glossary, source of funds refers to on-chain backward tracing unless otherwise specified. ## Destination of funds URL: https://anfossi.systems/glossary/destination-of-funds/ Forward tracing: following funds from an address or event under investigation, such as a victim's address, to identify the paths taken and the addresses, clusters or services that received them. As funds move through successive transactions, the flow may branch across multiple destinations, so analysts should define stopping criteria (see Source of funds). Identifying where funds appear to reside does not necessarily establish who controls them or whether the same value remains there. At custodial services, investigators may identify value credited to a customer account rather than trace specific units of cryptocurrency. Any estimate of the amount remaining attributable to the original funds depends on the tracing method applied (see Tracing methods). Where assets are located at a service or issuer capable of restricting access, the findings may support a freeze request. ## Service exposure URL: https://anfossi.systems/glossary/service-exposure/ The identification and measurement of interactions between addresses under investigation and identifiable services, such as exchanges, payment processors, gambling platforms, mixers and DeFi protocols. Analytics tools may express exposure as the amount or proportion of funds an address or cluster has received from, or sent to, a service or service category (e.g., 40% of incoming funds attributed to exchanges, 5% to a sanctioned entity). Exposure is direct when funds move between the address under investigation and the service without intermediaries, and indirect when one or more intermediate addresses are involved. Indirect exposure is usually discounted or capped by the number of hops, depending on the tool's methodology. Results also depend on the accuracy of the service labels used (see Attribution). Unlike taint, which estimates the proportion of funds attributed to an illicit source under a tracing method, service exposure measures interactions with identified services or categories, which may be legitimate or illicit (see Taint). Direct exposure can provide a lead for obtaining records from regulated or otherwise cooperating services. Incoming transfers may help identify the service customer who received the funds, while outgoing transfers may identify the customer who initiated a withdrawal. Such links require corroboration: a service's deposit address may receive funds from third parties, and a service label alone does not establish the identity of the person controlling the originating address. ## Demixing URL: https://anfossi.systems/glossary/demixing/ The process of attempting to link deposits into a mixer or CoinJoin with subsequent withdrawals, using evidence such as amounts, timing, address reuse, transaction fees and behavioural patterns. The strength of a proposed link depends partly on the anonymity set: the number of deposits compatible with a given withdrawal. A small anonymity set, distinctive amounts or user errors may leave only one plausible match, even without access to external records. Demixing results are generally probabilistic and should be reported with a confidence assessment, not presented as proof of common ownership unless the available evidence establishes a unique match. Service records obtained through cooperation or seizure are a separate source of evidence, rather than demixing based on on-chain data alone (see Coin mixer). ## Risk report URL: https://anfossi.systems/glossary/risk-report/ An assessment, often exported as a report, assigning a risk profile or score to an address or cluster based on its direct and indirect exposure to categories such as sanctioned entities, darknet markets, scams, ransomware and mixers, as well as behavioural indicators (see Service exposure). Exposure describes transactional proximity to a category, not a relationship with it. Analytics providers, such as Chainalysis, Elliptic, TRM Labs and Global Ledger, use proprietary categories, attribution data and scoring methods that are not standardised, so results can differ between tools. A risk score is an indicator for further review, not proof of wrongdoing. Because attribution data and risk assessments change over time, a report should identify the provider and the date it was generated. Where used to support investigative or legal decisions, the underlying transactions and attribution links should be documented so the assessment can be independently verified.