How many addresses can we check by hand before checking stops working? Trace does the filing with folders (our own wallets, funds, agent addresses, the ones everyone calls smart money), and the alerts do the interrupting: an address dormant eight months signing again, a first position in a token nobody in that folder had touched, quiet distribution while the timeline still writes accumulation. A dashboard answers a question you already had. The alert list hands you the question. For us it broke at about thirty.

A balance is a state, and a state with no path through it barely tells you anything. Two addresses, identical position in the same token today, same row height on any portfolio screen. One of them got there in small entries across four months. The other bought all of it in a single transaction yesterday. - the four-month wallet added through two drawdowns and has never sold a unit - yesterday's wallet has held for nineteen hours, so nothing about it has been tested - neither snapshot shows the address that trimmed on the way up and bought back lower, which is a third wallet again - allocation reads as a decision only when you can see what it was in July, and what it was in May - the path is the part we index in Trace ($TRACE): every entry in order, the transaction that made it, and what the position looked like before it

An indexer that returns hashes, timestamps and log topics is a weekend of work, and half a dozen public APIs will hand you one for free. The fetching was never the part that cost us anything. Open an active address in an explorer and look at what comes back. Forty rows. A method called execute or multicall. Three token transfers inside one transaction, two of them routing hops that never belonged to the wallet. Nothing there tells you whether the address opened a position, closed one, rotated between tokens, or deposited into a pool for an LP token. So you reconstruct it. You open the transaction, read the internal transfers, work out which leg the wallet owns, then write the answer into a spreadsheet because the explorer will not remember it. One wallet, forty rows, one morning. The sorting is the work: - one token out and another in, same transaction, is a single swap, and counting it as two transfers doubles the apparent activity - a transfer out can be the same owner moving to a second address, indistinguishable from a sell until you know where it went - you cannot call a close a close until the entries behind it have been classified correctly With the rows arriving in order, a year of history is legible in one scroll: a slow build, a rotation into two names, a quarter of silence, then the exit. Watchlists, folders and alerts in Trace sit on that classifier and are only as good as it is: an alert on a new position means little if a routing hop fires it. We built the sorting first because we were doing it by hand every morning. The case on our desk this week is the aggregator that splits one order across four pools: four fills, four prices, one intention, and the grouping rule today is still same block, same sender, which breaks the moment two orders land in one block

Nobody hits a cap on watchlist entries in Trace. You hit something else. The first address is a habit you keep without thinking, and by the hundredth 📌 you are checking the same five every Friday. What gives out first is organisation, well ahead of analysis. Nobody keeps a hundred addresses as a flat column: the funds, the agent wallets, two friends, your own, a few you privately file under smart money. We shaped folders like that after our own list stopped being readable at twenty. Alerts keep the other ninety-five real. Set a realised-profit threshold and you hear when it trips 🔔. A wallet dormant since February 💤 opens a position on a Tuesday and you know that afternoon. Accumulation over a week reads the same. Day to day it is a quieter tab. You open it because something moved, and address ninety-five gets read on the day it matters.

What do you have to grant a wallet tracker for it to do its job? The job is reading an address and the public chain data behind it. Bookmarking one in Trace is a paste and a click: nothing asks you to sign, and no allowance turns up in a revoke page six months later, because none was ever created. Everything we show comes off records that were already public before you typed the address in. Plenty of trackers still open with a connect button, which is worth a question. Nothing, because indexing public data and putting it on one screen is the whole of what Trace does.

Someone writes in most weeks because their spreadsheet total and the figure on their Trace page do not agree. Usually neither number is wrong. Watch where it comes apart. A wallet buys 30k tokens in three lots: 10k at $0.20, 10k at $0.50, 10k at $0.80. It sells 10k at $0.60, so proceeds are $6,000 in every version of the story. The cost side is where the rules diverge. - FIFO disposes of the $0.20 lot. Realised: +$4,000. - Average cost prices every unit at $0.50. Realised: +$1,000. - Highest-cost-first disposes of the $0.80 lot. Realised: -$2,000. - A deposit from another wallet the same person runs either brings its cost or lands at zero basis, and those two readings sit thousands apart. - Adding to an LP and taking it back out is either two disposals or none, and the chain does not settle that for you.

A smart-money list is a query result. Rank every address that traded in some window by realised PnL, take the top few hundred, publish the slice. Whatever the sort returns gets the label. The sort holds no view on how any of it was made. It compares an ending state against a starting one. A wallet that sized one position correctly and a wallet that ran fifty patient entries land beside each other on the same page, and the page carries no column that tells them apart. Every address that ran the same playbook and got caught is missing, because the window is what removed it. Three months ago that wallet looked like its neighbour. Book size goes missing too. Put a 900% return on six thousand dollars against 9% on an eight-figure book: they sort into a definite order, and the order is arithmetic. Concentration goes with it: one entry can carry a whole year, and a total tells you nothing about how many positions paid for it. What the chain hands over is a track record. Process stays off-chain, including the sizing rule, the thesis, the losses taken somewhere else, and whether the same operator runs four other addresses that did worse. Screen on outcomes and the cohort keeps looking impressive at the moment of selection, since that is the entry condition. Some of the people in it are genuinely good. Nothing in the ranking separates them from the ones the window happened to flatter. We keep a smart-money folder in Trace ($TRACE) anyway, and treat what sits in it as a queue of addresses worth watching from here. The alert fires on the next entry. When it does, the first thing open is the wallet's transaction history sorted oldest first, checking whether this is a token it has already sold into twice.

Add the fifth address to a watchlist and nothing changes. Add the fortieth and the list charges you every morning, whether those wallets moved or not. Trace splits them by kind, agents in one, funds in another, your own kept apart, which helps you read the list and does nothing about the volume. Which puts the weight on the threshold. Set it wide and you get forty pings a day, swiped unread by week two, so ours stays narrow: size moved enough to shift allocation, realised profit past a line you set, a position opened where there was none. The one worth waiting for comes off a wallet that has sat still since February. No balance change, no reason to open the tab. It signs at 03:40 on a Tuesday, three hours before anyone would have looked.

We are building the smart-money side of Trace: grouping addresses that trade alike, putting a number on conviction, catching accumulation 🔍 while it is still happening. Which means being straight about how the label is handed out. An address lands on a list because it already won. The sample is picked on the outcome, and its history is read backwards 📉 as if it had been a forecast. Our watchlists ship with a folder called smart money, so this lands on us too. What we want measured is what was visible before the outcome: entry size, timing against liquidity, holding period, adding on the way down. Then the same check across the wallets that did that and lost 🗂 Next step: cluster on pre-outcome behaviour, run the cohort forward on addresses we have never scored, and count how many hold.

Why does a wallet tracker need your wallet? The ask is so routine it stops registering: connect, sign a message, approve a token, then look at a chart. Signing takes a second. That token approval sits in the account long after the tab is closed, and revoking it lands on a to-do list nobody keeps. $TRACE has no connect button. You paste an address and the history is there, sorted into what the wallet actually did, because all we do is index data that was public before you looked. Reading a chain takes nothing from you, so a tracker has no reason to ask for it.

Nine buys in one token, three sells, and the question is what you made on it. There are two honest answers and no dashboard tells you which one it printed. Matched against the earliest entries, those sells produce one number. Averaged across all nine buys, they produce another. Underneath both sits the inventory nobody defines: an airdrop, tokens from an LP exit, a deposit the same person sent themselves. What runs, and in what order: - every transaction is categorised before it is counted, so an LP exit and a transfer in are different events - basis comes from that categorised history, with zero-cost inventory marked as such - realised and unrealised sit in separate columns, since they answer different questions - the method is printed beside the figure, which is what we want from any tool before trusting it, ours included

The data is public and complete. Answering what one address is actually doing still takes an afternoon. Here is how it goes. An explorer holds the raw rows. A portfolio tool holds balances that disagree with it by a token or two. Beside them, a spreadsheet of hand-typed entries, and the rest is in your head, where it holds up until the wallet does something structurally interesting. Say the address puts a token and some ETH into a pool and takes an LP position back. The explorer prints a contract call and three transfers. The portfolio tool watches the token leave and treats the position as closed. Both are accurate. Neither labelled anything. Labelling is the work. Reading a router to see what a swap was, judging whether a transfer out was a sale or a move to a second wallet the same person controls, deciding whether airdropped inventory counts as an entry. The job is reconstruction, not lookup. None of it persists. Next week it happens again, slightly differently, because what you rebuild is the version you remember. Classification is the missing layer, and Trace settles it first. A transaction lands already sorted as a transfer, a swap, a buy or sell, liquidity in or out, a position opened or changed. The shape of what the address is doing shows on the first screen, with history under it. Holdings, allocation and every realised or unrealised figure inherit what the classifier decided. The case still open on our side is the plain transfer out. Same token, no counterparty, no contract call. Whether it is a sale, a move to a cold wallet or an exchange deposit changes the position line beneath it, so we resolve it from the destination when that is known (a labelled exchange address, a contract, a wallet on your watchlist) and mark it unclassified when it is not.

The next thing we build sits on categorised transactions: wallet intelligence. Clustering addresses that move alike, scoring the conviction behind a position, catching accumulation while it is five wallets, weeks from consensus. Discipline is the whole point. Two addresses funded by one contract in a single hop are not a cluster, they touched it once. A cluster is repeated correlated behaviour: the same names entered within hours, exited together. Underneath it, the aim is one terminal for on-chain behaviour, read to see what a set of wallets does. So the conviction score stays quiet on one buy. It waits for a third correlated entry across those addresses before it flags them smart money.

Most of our engineering time goes to a layer no dashboard shows: how a raw transaction becomes a category 🔍. Before any PnL figure exists it has to be sorted, and the hard cases are where the work sits. A swap into a stablecoin looks like a trade, yet economically it realises the cost basis. An LP deposit pulls tokens out 💧 with no sale, so counting it as distribution invents a loss. The classic trap is an approval, which touches zero tokens and still lands in the log. Miss one and it runs downstream: the cost basis drifts, the realised-versus-unrealised split with it, the accumulation alert fires on what was never accumulation 🧱. So when we add a chain, the first thing we write is the rules that read its transfers, before any number leans on them.

What can a wallet viewer drain from you if there is no button to connect a wallet? The usual flow trains you to click connect, sign a message, then approve a token, and each approval is a standing permission that outlives the tab you close. That is the surface a drainer works. Trace never opens it. We only index and render public data, so there is no session to hijack, no signature we could request, no approval for you to grant. $TRACE reads an address. It never asks the address for anything. Nothing, because a tool that only ever reads has nothing of yours to take.

A screenshot makes the rounds most weeks. Some address bought a large position an hour ago, and the caption underneath already knows what it means: smart money is loading, follow it in. The chain recorded one event. Funds left, tokens arrived, at a cost you can read to the wei. Everything past that came with the caption, not with the transaction, and the two are easy to confuse: - Observable: the address holds the position at a known cost basis. That sits in the ledger and is not in dispute. - Inferred: that the buyer believes anything. Conviction, a thesis, a plan to hold through the next drawdown, none of it was signed on-chain. - Unread by the image: whether this is a hedge against a short elsewhere, one leg of an OTC deal, funds moving between one owner's wallets, or a position two-thirds sold before the picture went out.

Watching a single wallet should be the easy case. Public data, one address, every transaction it has ever signed sitting in the open for anyone to read. And yet answering what an address is doing takes four tabs and a spreadsheet. One shows an explorer's column of rows that mostly say Transfer. Another reads the current balance and says nothing about how it got there. A third holds the token's chart. The last is where you paste entries by hand: date, amount, a guess at whether it was a buy. Your mental model holds until the wallet does something structurally interesting. Bridging to another chain reads as a balance vanishing into an address nobody recognises, while the same owner is made whole on the far side. Wrapping a native token posts as a burn and a mint, two events standing in for something that changed nothing about who holds what. Each row is accurate on its own, and together they explain little. Every one of these was recorded on the chain, precisely. No explorer supplies the layer that turns a raw call into a category, so everyone watching runs the same reconstruction by hand and gets the fiddly cases wrong. We put it on one screen, and the work changes shape. A transaction arrives already sorted: - a buy or a sell, at the price it actually happened - a swap, with both legs named - a transfer, and whether it ever left the owner's control - a liquidity action, kept apart from a sale - a position opening, growing, shrinking, or closing Read that way, the shape is there on the screen to be seen, and what matters surfaces on its own. What makes that possible sits underneath the view. When a swap fires, the token going out and the token coming in land as two separate transfers. The step that earns its keep is the one that binds them into a single trade, so the same value is never booked once as a sale and again as a purchase. Get that pairing right and every figure stacked above it inherits the correct shape.

Here is the arithmetic behind an uncapped watchlist in Trace. 1. Watching by hand carries a flat unit cost. The twelfth address costs what the first cost: open an explorer, page back through transfers, sort which swaps were LP entries, copy it into a sheet that is stale by next week. 2. Flat cost against a fixed hour gives you a ceiling. Most people stop at three or four, and the hour goes to wallets they already trust. Conviction ends up doing the rationing, a poor rule: an address you have settled on has the least left to tell you. 3. Indexing takes the cost of the next address close to zero. Paste, pick a folder, whales or funds or agents, and the parsed history is there. You stop asking whether an address deserves a slot. Mild curiosity is what this buys: the counterparty that turned up twice in a week, the friend's wallet you would never have paid an hour of reconstruction on.

The wallet intelligence layer is not shipped. Stating the intent before it exists lets people argue with it early. Three pieces. Addresses that move alike, grouped. A number on conviction. Coordinated buying surfaced early. Analysts do all three by eye, which works on four addresses and collapses on forty. Clustering is the piece most likely to be done badly, so the threshold matters. Two wallets funded once from the same exchange hop are not a cluster, they are two wallets and a hop. What counts: repeated timing correlation, the same tokens entered in the same order, funding structure, sizes that rhyme across dozens of events. Conviction is harder, because a score is an inference, and inference is where tools like this start quietly lying. A wallet that held through a sixty percent drawdown and added twice on the way down is doing something specific. Calling that belief goes a step past the data, so the inputs stay visible: hold duration, adds under drawdown, share of the portfolio. The third has the loosest edges. Twenty addresses buying one token inside an hour is an observation we can produce. One desk, a group chat, and twenty people who read the same post all produce it. We want $TRACE to end up as a terminal for on-chain behaviour, which means all three stay accountable to the transaction history under them. Still open: what does a scored inference have to clear before it earns a place next to an event that verifiably happened?

Agent wallets are the easiest addresses on chain to read, and nothing about that was designed for the people reading them. A person trading leaves a ragged record. Gaps for sleep, a burst an hour after a headline, size that drifts with mood and with whatever is left in the account. Software leaves a metronome: the same amount through the same venue at 03:14 on a Sunday, then again at 03:14 the Sunday after that. - routes that repeat, one venue, one path, hundreds of times unchanged - sizes that hold out to the last decimal - intervals steady enough that the next one is predictable - a Sunday that reads exactly like a Tuesday That rhythm is what makes an execution record checkable at all, including against whatever the thing was announced to be doing. Trace gives an address like this no special treatment. It goes in a folder with the rest, the parsed history fills in behind it, and the regularity shows up on the same screen that would otherwise be showing you a person's mess.