Funding Paths and First Deposits: Walking Backwards

Funding path analysis means finding the transaction that first credited an account, identifying what kind of address sent it, and stepping backwards a fixed number of hops while recording how much weight each hop can carry. The first deposit is high-value because it is unique: an account has exactly one, it dates the account activation, and it names one counterparty that had funds and chose to send them here.

It is also the single easiest place to overstate a finding. A shared funder feels like a discovery and is usually a coincidence of infrastructure, because the addresses that fund the most accounts are services used by very large numbers of unrelated people.

Why the first deposit matters

Three properties make the first credit worth the effort. It is unambiguous, in that an account either had a balance or did not. It is dated, so it anchors everything else in the history to a moment. And it is directional, since somebody had to already hold value in order to send it, which means the funder is a strictly older object in the graph than the account you started from.

That last property is what makes backwards walking productive. Forward tracing branches: an account can send to many places. Backwards tracing at the first deposit does not branch at all, because there is exactly one first credit. You get a single defined step instead of a fan, and single defined steps are what a defensible chain is made of.

The value decays quickly with distance, though. The first funder of your account is one hop and strongly connected to the question. The funder of that funder is two hops and might be an exchange serving millions. By three hops you are usually describing market infrastructure rather than anything about your original account.

Finding the genuine first credit

Signature histories come back newest-first, so the beginning is the part you have to work for. Page backwards through the RPC methods until an endpoint returns nothing, then apply two checks before you believe what you have. First, is the oldest signature you found close to your endpoint's retention edge? Second, does the account have token accounts whose own histories start earlier than the system account's visible history?

The second check catches a common trap. A wallet's associated token account is a separate address with a separate history, and it can be funded and used while the system account itself sees very little. An account that looks dormant in a system-account view can be busy in token terms, and its real activation date can be considerably earlier than the one you first wrote down.

Once you have a candidate, open the transaction and confirm it is a credit rather than a creation artefact. Account creation, rent deposits and token account initialisation all appear near the beginning of a history and none of them is the funding event you are looking for, although the rent deposit does tell you who paid to bring the account into existence, which is often the same party.

Walking backwards, hop by hop

1. Fix the hop budget. Write the number before you start. Two or three hops answers most questions and anything beyond that needs a stated reason.
2. Establish hop zero. The account, its activation date in UTC, and the amount of the first credit in lamports.
3. Identify the sender. Fetch the transaction with getTransaction and read its account list and balance deltas to find which address actually decreased, which is not always the fee payer.
4. Classify the sender. Ordinary account, service address, program-derived address or custodial address. This classification decides whether the next hop is worth taking at all.
5. Score the hop. Write down what this hop can support on its own. Usually the honest answer is "value moved from here to there on this date" and nothing more.
6. Stop or step. Stop at any custodial or high-fan-out address. Step only when the sender looks like an ordinary account and your written question still needs the answer.
7. Record the chain. One row per hop: address label, date, amount, classification, and the sentence that hop supports. The table is the finding.

What kind of funder is this?

Classification is the step that determines whether the rest of the analysis means anything, and it can be done from public behaviour alone. You are not identifying who runs an address; you are describing how it behaves, which is a property of the record.

The counting that supports this classification is simple and worth doing yourself: how many distinct addresses has the funder sent to, over what period, and how concentrated are the amounts. An address with thousands of unique recipients is infrastructure. An address with four is not, and the difference in what a shared funder means between those two cases is enormous.

The exchange wall

Sooner or later a backwards walk reaches a custodial platform, and that is the end of the public path. Custodians pool customer funds and pay out from addresses they control on behalf of many people. The transaction shows the platform's address sending to your account; what it does not and cannot show is which customer requested it, or whether a customer requested it at all.

This is a structural boundary rather than a puzzle. Treat it as a terminator, write it down as one, and stop. Attempts to push past it by correlating withdrawal timing and amounts against other public activity are exactly the class of technique this desk leaves out, because its realistic use is identifying an individual customer rather than understanding a market.

Rent, the smallest deposit of all

Not every early credit is funding. Solana requires accounts to hold a minimum balance for their data size in order to stay resident, and that rent-exempt minimum sits with the account rather than being consumed. A standard SPL token account requires approximately 0.00204 SOL, and the small SOL amounts appearing around the start of a history are often exactly this.

The illustrative arithmetic is useful when you meet a fan-out. Suppose an operator prepares twenty fresh wallets, each needing one token account. The rent deposits alone come to twenty multiplied by 0.00204 SOL, which is 0.0408 SOL, recoverable if those accounts are later closed. Add a fee budget: at 5,000 lamports base per signature, twenty account creations cost 100,000 lamports, or 0.0001 SOL, before any priority fee.

The point of the arithmetic is not the total. It is that a funding pattern has a structure you can predict: setup transfers cluster around a specific small amount, because whoever built the tooling computed the same minimum you just did. When you see twenty transfers of a near-identical unusual amount, you are probably looking at provisioning rather than payments.

Three funding shapes and what they suggest

Fan-out. One address funds many fresh addresses in a short window with similar amounts. This is provisioning, and it is produced by trading tools, airdrop distribution, testing, payroll and any operation that needs several accounts. It suggests coordination of setup. It does not suggest concealment, and it says nothing about who coordinated it.

Chain funding, where each account funds the next in sequence, produces a line rather than a star, and it is more ambiguous. It occurs when someone moves funds through intermediate addresses for operational reasons, and it also occurs when several unrelated people happen to transact in sequence. The length of the chain is not evidence of anything by itself; the timing and amount regularity along it is what carries any weight.

Convergent funding, where many accounts eventually send to one destination, is the reverse pattern and it is the one most often over-read. Convergence on a single address is exactly what a deposit address, a market maker, an exchange or a merchant looks like. Before treating convergence as evidence of a common owner, check the destination's fan-in count, because a destination that receives from thousands of addresses tells you almost nothing about any of them.

What funding a wallet set costs

Provisioning has a price, and knowing roughly what it is helps you recognise provisioning when you see it. Each account needs rent for any token account it will use, a fee balance for the transactions it will sign, and a working balance for whatever it will trade. Multiply by the number of wallets and the total is a fixed overhead that exists before any activity happens.

Services that run wallet sets publish this arithmetic because their customers need it, which makes it useful reference material for an analyst too. A published Solana volume bot cost breakdown shows how funding requirements scale with wallet count and transaction volume, and comparing a funding pattern you have observed against a documented cost model is a far better test than assuming that a cluster of similar-sized transfers means something sinister.

Fan-out funding and disclosed automation

The most common source of textbook fan-out funding on Solana is ordinary, disclosed tooling. Anything that operates multiple wallets has to fund them, and it does so in exactly the shape that clustering literature describes as suspicious: one source, many fresh destinations, uniform amounts, tight timing. The shape is a consequence of the requirement, not of anyone's intent to hide.

Where Solana volume automation is run openly by a project, the same funding signature appears as it would for an operation nobody announced. That is the practical reason a funding finding should stop at description. "These twenty accounts were funded from one address within an hour, in amounts consistent with account provisioning" is accurate. Anything about motive is a story added on top of it.

The false-positive mode of shared funding

The failure this method produces is specific and it has a name worth remembering: the base-rate error. Shared funding is common because funding sources are concentrated. A handful of custodial platforms, distributors and popular tools fund an enormous share of new accounts, so any two randomly chosen accounts have a much higher chance of sharing a funder than intuition suggests.

The test is to ask how many other accounts share that same funder. If the answer is thousands, the signal carries essentially no weight for your pair. If the answer is four, and the four also share timing, behaviour and eventual destination, you have something worth writing down, though still with a confidence note attached. The full version of this reasoning is set out in false positives and honest conclusions.

Writing a funding finding

Keep the output in the language of the record. Write the activation date in UTC, the amount in lamports and in SOL, the funder classification with the counting that supports it, and the hop budget you used. Then write the sentence stating what you did not establish, because a funding finding without that sentence tends to be read as an ownership claim by whoever quotes it next.

A good funding paragraph reads something like this: the account was activated on a stated date by a credit from an address that has sent to several thousand distinct recipients, a pattern consistent with a custodial withdrawal, and the trail terminates there. That is a complete, checkable, and entirely unglamorous result, which is what most funding work honestly produces. Where the same funder appears across a set of accounts you are already studying for other reasons, the next step is clustering related addresses, where funding becomes one weighted signal among several rather than a conclusion on its own.

Questions this page gets asked