How to Custom Track Specific Wallet Groups with Dune Analytics

Dune Analytics offers plenty of pre-built dashboards for project data, but if you want to monitor a specific wallet group—such as a project's core team addresses, several whales that frequently operate together, or a curated list of "smart money" wallets—the existing dashboards fall short. This article skips theory and directly uses SQL plus hands-on examples to break down how to custom track your designated wallet group in Dune, including creating tables, tracking flows, and building usable dashboards.

Where to Store the Addresses to Track

Dune supports user-generated tables (Spells/User Generated Tables). You can store the wallet addresses you want to track in a table and then reference it in all subsequent queries. This is much cleaner and easier to maintain than writing a long IN ('0x...', '0x...') clause.

The SQL template for creating the table looks like this:

CREATE TABLE your_schema.whales_wallets AS SELECT address, 'Label1' AS name FROM (VALUES (0x...), (0x...) ) AS t(address) UNION ALL SELECT address, 'Label2' AS name FROM (VALUES (0x...) ) AS t(address)

If you are tracking addresses from different categories—such as team wallets, market maker addresses, early investors—you can use the name field to tag them, making it easy to group them in subsequent analyses.

A real-world example is the "Whale Wallet Tracking_Token Flow" dashboard, which uses the dune_user_generated.whales_wallets table as the source of addresses and then joins with erc20.ERC20_evt_Transfer to track the inflows and outflows of these addresses.

Core Logic for Tracking Flows

Once you have the address table, the tracking logic is standardized: join with transfer events and match whether the from or to field is in the address table.

To track the behavior of a wallet group, the core SQL logic is:

-- Track inflows (transfers to addresses in the table) SELECT name, date_trunc('hour', evt_block_time) as time, contract_address, sum("value") as flow FROM erc20."ERC20_evt_Transfer" AS t INNER JOIN your_schema.whales_wallets AS w ON t."to" = w.address WHERE evt_block_time > now() - interval '48 hours' GROUP BY name, time, contract_address

UNION ALL

-- Track outflows (transfers from addresses in the table) SELECT name, date_trunc('hour', evt_block_time) as time, contract_address, -sum("value") as flow -- negative for outflows FROM erc20."ERC20_evt_Transfer" AS t INNER JOIN your_schema.whales_wallets AS w ON t."from" = w.address WHERE evt_block_time > now() - interval '48 hours' GROUP BY name, time, contract_address

This logic is applied in the "Whale Wallet Tracking" dashboard: it matches the address table's address field with both from and to in transfer events, then aggregates by time to calculate the net flow for each address over each period.

Tracking Token Holdings Changes

Beyond flows, another common need is to see how the token holdings of these addresses change over time.

The logic is: first calculate how much of a specific token these addresses hold at a given point in time (by computing cumulative balances from ERC-20 Transfer events), then track that number over time.

Dune's documentation provides a "Tokens" query template exactly for this—choose a token, a blockchain, set a time range, and track the token's flow across specific address groups or contracts. You can modify the template by replacing the address source with your own whales_wallets table.

Wallet Grouping and Behavior Classification

Another direction for tracking specific wallet groups is to perform behavioral segmentation. Dune has an RFM wallet segmentation case that scores wallets on the Base chain across three dimensions: Recency (how long since the last transaction), Frequency (number of transactions), and Monetary (transaction value).

This framework can be directly applied to your custom wallet group: for the addresses you are tracking, calculate their last transaction time, transaction count over the past 30 days, and total transaction value, then segment them. For example:

sql copy download WITH user_metrics AS ( SELECT "from" AS wallet, MAX(block_time) AS last_tx, COUNT(*) AS frequency, SUM(value / 1e18) AS monetary_eth FROM base.transactions WHERE block_time >= NOW() - INTERVAL '30' day AND "from" IN (SELECT address FROM your_schema.whales_wallets) GROUP BY 1 ) SELECT wallet, DATE_DIFF('day', last_tx, NOW()) AS days_since_last, frequency, monetary_eth FROM user_metrics

This lets you see which of the tracked addresses are active, which have gone dormant, and which have seen a sudden spike in transaction frequency.

Detecting New Wallets—Identifying Potential "Insider Trading"

This is a more advanced but practical layer in wallet tracking. Dune can detect "new wallets"—addresses that make their first on-chain transaction and then buy a large amount of a specific token within a few days.

The specific approach is: first filter for addresses whose first transaction occurred within the last 7 days, then check if these addresses made large purchases of a designated token. This pattern often appears in insider trading or "pump and dump" schemes—insiders create new wallets to accumulate tokens a few days before positive news is released.

The SQL logic is roughly:

sql copy download -- Find new wallets with large transactions on the target token WITH first_tx AS ( SELECT "from" AS wallet, MIN(block_time) AS first_tx_time FROM ethereum.transactions GROUP BY 1 HAVING MIN(block_time) >= NOW() - INTERVAL '7' day ) SELECT t."from", t.block_time, t.value / 1e18 AS amount_eth FROM ethereum.transactions t INNER JOIN first_tx f ON t."from" = f.wallet WHERE t.to = 'target_token_contract_address' -- buy action AND t.value > threshold -- set minimum amount ORDER BY t.block_time DESC

Multiple new wallets buying the same token around the same time is a signal worth watching.

Two Key Points for Building Dashboards

1. Parameterized Queries: Set the blockchain, token address, time range, and amount threshold as parameters ({{parameter_name}}). Later, when switching tokens or chains, you only need to change the dropdown menu, not the SQL code.

2. Scheduled Refresh: Dune dashboards do not update automatically. Click the clock icon in the Dashboard to set a periodic refresh frequency, such as every 6 hours. For tracking address groups, setting up a scheduled refresh means you no longer have to manually click "Run."