How to design an AI agent for on-chain fund tracing

Handing two on-chain addresses and a pile of transaction records to an AI and asking it for a summary doesn’t make a fund-tracing agent.

A real agent should work like an investigator.

It checks the simplest possibility first. If there’s no direct transfer, it goes on to check whether the money took a detour. Once it finds a route, it judges whether the addresses in the middle are ordinary wallets or temporary relay points. When it finds a new lead, it knows what to check next. And at the end, it doesn’t just give a conclusion: it explains the evidence and is clear about what it can’t be sure of.

Put simply, an ordinary query tool waits for a person to give the next command. An agent keeps the investigation going on its own, based on what it has just found.

So how should an agent like this be designed?

Step one: decide first what it must deliver at the end

Designing an agent shouldn’t start with “which tools do we connect?” It should start with: what does the user actually want at the end?

For an on-chain fund trace, an acceptable answer has to make at least six things clear:

1. Whether money went from A to B;
2. How many routes were found in total;
3. Which addresses each route passes through;
4. How much money can be seen on the routes, and how much of it can safely be attributed to A;
5. Why these middle addresses are considered relay points;
6. Which parts are on-chain facts and which are only reasonable inferences.

Why define the answer first?

Because there are an enormous number of on-chain records. Without a clear goal, an agent can easily pull dozens of pages of transactions without ever answering the question. It looks busy, and the user still doesn’t know where the money went.

So the first design principle is: design the result first, then design the investigation.

Step two: teach the agent to search for routes layer by layer

Many fund traces fail at the first step: A didn’t transfer directly to B, so the answer comes back “the two addresses are unrelated.”

But real money rarely travels in a straight line. It may pass through one address first, or through two or three temporary addresses, before it finally reaches B.

The agent should keep checking in a fixed order:

• First, is there a direct transfer A → B?
• Then, is there A → C → B?
• Then A → C → D → B;
• If there’s still nothing, check routes with one more layer.

It’s like tracking where a parcel went. No direct truck doesn’t mean the parcel didn’t arrive; it may just have changed trucks a few times.

There’s another easily overlooked design point here: finding the first route isn’t a reason to stop. The same batch of money may be split into several parts, travel along different routes, and come together again at the same address. The agent needs to keep checking for parallel routes; otherwise what it found may be only a small part of the whole picture.

Of course, it can’t search forever either. Every extra layer rapidly multiplies the number of addresses that could turn up. So the agent also has to set a scope based on the goal of the investigation, for example limiting the time window, the tokens and the maximum number of layers. When it reaches an on-chain boundary such as an exchange, it should stop in time.

Step three: once a route is found, keep checking the relay points

Finding a route from A to B only proves that the path is connected on chain. It doesn’t explain why the middle addresses moved money that way.

So the agent should automatically check every middle address:

• How many payments has it received in total?
• How many has it sent out?
• How long did it hold the money after receiving it?
• How much did it receive, and how much did it send out?
• Is there any balance left in the end?

A wallet in normal use usually has different sources and destinations, and may hold a balance for a long time.

If an address received only one payment and sent out only one, sent out exactly what it received, and did so quickly, it looks more like a temporary relay point.

That still isn’t a final conclusion, but the investigation has moved from “found a line” to “starting to understand the line.”

Step four: put different records on the same timeline

Looking only at USDT transfers is sometimes not enough.

Sending USDT on the TRON chain requires a small amount of TRX or “energy” to pay the fee. You can think of it as a temporary pass needed before a transfer.

If a new address receives a large amount of USDT, then temporarily gets energy, sends all the USDT away a few seconds later, and then has the energy taken back right after, that sequence is well worth noticing.

So the agent can’t look at different records separately. It has to put them in time order:

1. When the USDT was received;
2. When the energy was obtained;
3. The USDT being sent out a few seconds later;
4. When the energy was taken back.

One judgment rule has to be built into the agent here: using the same public service doesn’t mean being under the same control.

A large energy provider may serve hundreds of thousands of addresses. Two addresses both having used it is only a very weak clue. What really matters is several things showing up together: the same amount in and out quickly, a zero balance, and the same second-level rhythm.

Step five: from single routes to the operation network behind them

Fund tracing can’t only ever look at USDT.

A newly created address that wants to start transferring usually needs to receive a little TRX first. Whoever gave it its first TRX is like whoever put the first bit of fuel in a new car. We call this relationship the “first top-up.”

The agent should go on to check:

• Whether several relay addresses got their first top-up from the same address;
• Whether an address on one route gave a first top-up to an address on another route;
• Whether these relay addresses have any other transfers between them;
• Whether different routes repeatedly show the same operating rhythm.

Only then can you see two layers of relationships:

The money network answers “how exactly did the money move.” The operation network answers “do these addresses look like they were organized in the same way.”

Still, a first top-up relationship alone can’t prove that two addresses belong to the same person. A reliable judgment has to come from several kinds of evidence backing each other up, not from seizing on one thing in common.

A full run on a real set of records

Below we use a real set of TRON on-chain records to see what this design actually finds.

The question is very simple: did the money A sent out go around a few middle addresses and end up in B?

A is TUK5… and B is THZt6….

First, find the money routes

The agent first checks for direct transfers. The result is 0.

Next it checks routes with only one middle address. The result is still 0.

If it stopped here, the answer would be “no relationship.” But the agent widens the search by one more layer and quickly finds 5 routes; one more layer turns up a 6th.

The final result: there are 6 one-way routes from A to B in total. Five pass through two middle addresses and one passes through three. Across the six batches, 499,999 USDT in total can be observed on the paths.

This chart answers the most basic question: A’s money really can reach B along several routes.

Then check the 13 relay addresses

The six routes pass through 13 relay addresses in total.

Expanding them one by one, the agent found that each of the 13 addresses received exactly 1 USDT payment and sent out exactly 1; each sent out exactly what it received; and in the history we covered, the USDT left behind was 0 in every case.

From receiving the money to sending it out, the shortest took just 81 seconds, and half of them finished within 4 minutes. 10 addresses sent the money on within 12 minutes, and 12 within 36 minutes. Only one address held it for about 5 hours.

These addresses don’t look like wallets in long-term use. They look more like single-use relay batons.

Then line up when energy was used

The 13 relay addresses also showed the same set of actions: after receiving USDT, each temporarily got energy just before sending on; 3 seconds later, it sent the same USDT amount to the next hop; another 9 to 15 seconds later, the energy was taken back.

13 addresses, 13 times, every time.

The energy came from a public service provider, so “using the same service” in itself proves no control relationship. But when 13 single-use addresses all show same-amount forwarding, zero balance left behind and the same second-level rhythm, taken together it’s hard to treat as ordinary coincidence.

Finally, look at the first top-ups

The agent went on to trace where each of these 13 addresses got its first TRX.

It found that the first top-ups for all 13 came from just 5 addresses. None of these top-up addresses served many accounts; the largest had made first top-ups to only 7 addresses.

Among them, A itself provided the first TRX to two relay addresses, and those two addresses in turn made first top-ups to several later relay addresses. In this way, money routes that had looked separate turned out to be connected in a second web of relationships.

This needs to be stated precisely: this isn’t a dense money network of relay addresses frequently transferring among themselves. It’s an operation network made up of several one-way money channels, small-scale first-top-up relationships and the same operating rhythm.

Step six: make the agent know what it can and can’t say

The easiest mistake in fund tracing isn’t missing a transaction. It’s presenting an inference as a fact.

A reliable agent should sort its evidence into levels on its own.

“A sent money to a certain address” and “a certain batch of USDT was sent on to the next hop” are facts you can see directly on chain.

“These addresses look like single-use relay points” is a judgment based on the number of payments received, the holding time and the balance.

“These addresses may have used the same automated method of operation” is an investigative lead formed from several things observed together.

As for “these addresses definitely belong to the same person,” the on-chain records by themselves can’t prove that.

Amounts should be handled on the same principle. In this case, 499,999 USDT in total can be observed across the six routes, but following the strict order in which the funds moved, the amount that can safely be attributed to A is 449,999 USDT. The remaining 50,000 USDT shows the route exists, but shouldn’t be forced onto A when the evidence isn’t enough.

B is inferred to be a Binance deposit address; its downstream flows into wallets publicly confirmed by Binance. Once money enters an exchange, what you mostly see on chain is the exchange moving funds internally, and there’s no way to know which real user it belongs to. At this point the agent should stop and say that the next step is to request records from the exchange.

Knowing when to stop is also part of the capability.

A good result should be understandable at a glance

Back to this case: a final result for investigators can be boiled down to four layers.

The first layer is the conclusion: there are clear multi-hop money routes between A and B, and the money flows A → B.

The second layer is the facts: 6 routes and 13 relay addresses were found in total, with 499,999 USDT observed on the paths.

The third layer is the basis for the judgment: all 13 relay addresses forwarded the same amount quickly, left no USDT behind, and showed the same energy-use rhythm; they are also tied into an operation network by a small number of first-top-up addresses.

The fourth layer is the limits: the amount that can conservatively be attributed to A is 449,999 USDT; this evidence can show the money relationship and the operational link, but can’t on its own prove who really controls these addresses.

An answer like this isn’t a paragraph of “the AI analyzed this very well.” It’s an investigation result you can check item by item, following the routes, amounts and times.

What’s really hard to design is an agent that keeps asking the next question

Looking back, an AI agent for on-chain fund tracing needs at least six capabilities:

1. Knowing what it should deliver at the end;
2. Being able to search from direct transfers all the way to multi-layer routes;
3. Going on to analyze the relay addresses once routes are found;
4. Putting money, first top-up and energy records on the same timeline;
5. Seeing a shared operation network across several routes;
6. Telling facts, judgments and the limits of the investigation apart.

The most important of these isn’t query speed, or how many transaction records it can read at once.

It’s that after finishing one step, it knows what to check next; after spotting a possibility, it knows what evidence is still needed to verify it; and when it reaches a point the chain can’t answer, it knows to stop.

Put simply, what we want to design isn’t an AI that writes summaries of transaction records, but an on-chain investigator that can follow the leads on its own and work out the money’s route step by step.

We currently focus on AI agents for analyzing, mining and tracing USDT on the TRON chain. We want to turn work that used to rely on people checking layer by layer into an investigation process that can find leads, verify relationships and organize evidence automatically.

If this direction interests you, or you’re dealing with a real problem like this in your work, feel free to get in touch.