Nansen setup: why reports diverge from the network
An address label is a claim about the owner, not a fact from the network.
When Nansen setup is done “by eye” — from an exchange name in correspondence, from a counterparty’s first large transaction — foreign deposit wallets and the project’s internal cash desks get into the system.
After that, wallet analytics counts them as external flows, and the picture of fund movement stops matching what is visible in the network.
The second source of reports diverging from the network is address groups. If they are assembled on the basis of “similar amounts and timing,” different owners end up in one entity: treasury, market maker, team service addresses.
An internal transfer between own wallets starts being counted as an external inflow: turnover doubles, the share of external inflows is distorted, and staking and reporting decisions are made on wrong numbers.
This is fixed not by replacing the service, but by order in address labels. Each label must have a source — an exchange page, an official document, a confirmed transaction — and each group must have inclusion and exclusion rules for addresses.
Transaction verification goes by primary source: amount, counterparty, purpose and fee are reconciled with the network ledger, and the aggregate in the report is reconciled line by line with these records.
Until such reconciliation exists, the report looks convincing and diverges from the network by tens of percent. We break down how this is closed.
What verified flow and wallet analytics delivers
Analytics starts not with connecting a service, but with address labeling: treasury, contracts, vesting, liquidity pools, team wallets. Until these addresses are labeled, transaction tracking drowns in noise — incoming transfers mix with transit ones.
Nansen provides a ready base of labeled addresses, but project entities are described manually, for a specific token distribution scheme.
Next comes wallet profiling. Addresses are grouped by behavior: who holds a position for months, who enters before an announcement and exits on growth, who is connected by a common source of funds.
The address list turns into a participant map, and the appearance of a new large holder in it becomes an event, not a row in an export.
The third layer is alert rules: a threshold for outflow from a pool, a sharp change in one address’s share, a transfer from a team wallet, a spike in activity around a contract.
Each condition is set with a window and a multiplier, otherwise the signal triggers on normal transaction volume. Early risk alerting works exactly as accurately as the thresholds are set: narrow ones produce false positives, broad ones miss fund withdrawals.
Liquidity monitoring and management reporting are assembled from the same data. Export of metrics — volume in pools, holder distribution, large address activity — goes on a schedule into a table or dashboard, where periods are comparable with each other.
Modes of work: one-time audit, continuous access, closed perimeter
The three modes differ not by the set of metrics, but by the access model and the route by which data enters internal systems.
The same set of address labels can be captured one-time, put under continuous monitoring, or deployed inside your own perimeter — and the limitations of these options are fundamentally different. We collect blockchain analytics in Nansen and compare it with the project’s own data.
| Option | When it fits | Limitations |
|---|---|---|
| One-time wallet audit | Counterparty check, incident investigation, entry into a new market | Snapshot as of a date: relationship history cannot be reconstructed retroactively, no alerts |
| Continuous access to analytics | Monitoring fund flow, observing project addresses and large holders | Requires an alert triage policy and your own history storage |
| Closed data perimeter | Isolation requirements, mixing external labels with internal reporting, access separation | Separate infrastructure, maintenance and label updates on our side |
Data export to reporting and team collaboration are configured in any of the three modes — the frequency differs.
A one-time audit gives a static snapshot, continuous access forms a stream that accumulates into a data mart, and a closed perimeter allows external labels to be linked with your own transaction data without letting them out.
The choice should be made by the task horizon. Monitoring without an alert triage policy turns into a stream of notifications that nobody reads — so continuous access mode only makes sense together with escalation rules.
Figure out how this is closed for your scenario — describe the task, and we will come back with an estimate and a plan.
Nansen setup: work stages from audit to handover
Observing blockchain activity starts not with opening a dashboard, but with inventorying what needs to be monitored.
We go over the task with the client’s team, fix the list of addresses and criteria for a significant event — otherwise observation turns into a stream of notifications that quickly stops being read.
After that, the implementation order is the same for any project — we configure it in Nansen, where labels and rules are tied to addresses and updated with them.
- Task review and address inventory. We collect contracts, treasury, operational and exchange wallets, and clarify which flows matter: inflow and outflow, large holder movement, protocol interactions.
- Label schema. We create a unified dictionary “address — owner — role — type,” so the same wallet reads consistently across all reports and does not have to be decoded again.
- Monitoring setup. We set alerts for above-threshold movements, changes in holder structure and activity spikes. We calculate thresholds from the address’s historical volatility, not “by eye.”
- Backtesting on historical data. We run the rules over past periods: we calculate the false positive rate and events the system missed. We adjust thresholds before handover, not after the first incident.
- Access separation. We assign roles on the least-privilege principle: full access, view-only, notifications-only. Dashboard actions are logged, and access is revoked when the team changes.
- Monitoring policy. We define who responds to an alert and how: notification channel, response window, escalation order and label reconciliation frequency.
- Handover. We provide documentation, label schemas and team training, and stay in touch until the policy runs independently.
At the output, monitoring is reproducible: a change of analyst does not reset the settings, and response to fund movement is measured in minutes, not days.
Access policies, address labels and documentation
After Nansen setup, the client retains not a set of one-off reports, but a working system: labeled workspaces for different teams, an address label directory and the rules by which people are granted access to them. Below is the list of what we hand over along with the configuration and ownership on your side.
- Workspaces for tasks: separate workspaces for treasury, product and risk control — data flows do not mix, and access is granted on the least-privilege principle.
- Address label directory: exchanges, custodians, own wallets, contracts and treasury addresses — with the label owner and last verification date; new addresses are entered using a unified template.
- User roles and permission matrix: analyst, observer, read-only mode — with separation for changing labels, exporting data and managing alerts.
- Access policies: procedure for granting and revoking rights when an employee leaves, sign-in via single sign-on and two-factor authentication, action log for incident investigation.
- Response policy: trigger thresholds, responsible on-call person, escalation order and response times for anomalous fund withdrawals.
- Team instructions: short guides — how to add an address to the directory, build a report, update an alert after a contract change.
- Settings handover: workspace schemas, label templates and triage protocols remain in your repository — the system runs without our involvement.
Case: address labels detected fund withdrawal within a day
How it was
The project issued a token and kept its treasury on several addresses, but monitored them manually: an analyst reconciled the transfer export once a day.
A large stablecoin withdrawal was noticed only the next day — part of the funds had already passed through intermediate wallets and exchange services, and there was no way to recover them.
What we set up
We labeled the project’s addresses — treasury, team wallets, contracts, exchange addresses — and fixed alert rules in Nansen.
Watch conditions trigger on atypical flow: a transfer above the usual amount for the address, a new counterparty, a chain of intermediate wallets within a short window.
What changed
| Metric | Before | After |
|---|---|---|
| Anomaly detection time | about a day | 15-20 minutes |
| Share of transactions with an identifiable counterparty | less than half | 96% |
| False positives | dozens per week | 2-3 per month |
The rules made themselves known after eleven days: the watch triggered on a withdrawal that exceeded the address’s usual turnover several times over.
Incident triage took forty minutes instead of a day of searching — the chain was labeled, the recipient label was attached to a request to the exchange service, and part of the transfer was stopped in time.
False positives were removed with thresholds tailored to specific addresses’ profiles: an alert arrives when there is something to investigate.
How does a one-time export differ from continuous monitoring?
A one-time export is a snapshot of data at a specific moment: balances, holder distribution, fund movement over a period. The mode is justified when a decision is made once: project evaluation before entry, counterparty check, report preparation. The table after the export is static — it describes state, not behavior.
The limitation of a snapshot is that nothing is visible between two exports. A large withdrawal, a change of contract ownership, an activity spike surface only in the next export — with a delay of days. If the cost of error grows with response time, a snapshot is not enough.
Continuous monitoring is a set of conditions under which Nansen polls the network on a schedule and sends an alert on deviation: volume threshold, new address in the list, change in holder share.
Monitoring mode consumes request limits and requires threshold calibration: broad ones create noise, narrow ones miss events.
In practice, the approaches are combined. A one-time export sets the baseline and the list of addresses for monitoring, then continuous mode with deviation alerts works, and a control snapshot once a week reconciles the picture and updates the baseline. The project sees both the current state and the dynamics, and the alert stream remains readable.
The choice of approach is determined by the decision horizon: the answer is needed once — a snapshot suffices; reaction is needed in the moment — we enable monitoring mode.
We select polling frequency to fit the limits, so growth in the number of addresses does not hit constraints.
Technical doubts we resolve before the start
Some questions repeat in almost every estimate — we answer them before the start, so we do not clarify details already at the rule-building stage.
We already have analytics deployed — won’t we get a second perimeter just for the sake of a second perimeter?
First we do an inventory: which networks and addresses are already covered, which reports who reads, where data diverges. We connect the new layer only where it covers what the current perimeter lacks — for example, cross-network fund movement and address connections. The rest stays as is, and we remove duplication rather than add it.
Can address visibility be limited within the team?
Yes, and this is configured at the start. We split workspaces by business line, grant access to addresses and labels by list, and move sensitive wallets into a separate closed perimeter accessible only to a narrow group. Rights are revoked centrally — when a person leaves, access closes with them.
How complete are the labels and can they be trusted?
There are no complete labels: major services, exchanges and known contracts are labeled, while new addresses appear faster than they can be described.
That is why we maintain our own address dictionaries and labeling rules, and for each label we store the source and date — it is clear where there is fact and where there is assumption. This removes the main problem: decisions are made on data with a clear degree of confidence.
How quickly do alerts arrive?
Speed is determined by network polling frequency and delivery method. For critical addresses we set frequent polling and delivery to several channels; for the rest — less often, so as not to burn through limits or drown the team in noise.
A signal for a significant operation arrives within minutes, not hours; priorities and deduplication rules are configured separately.
What will happen to the settings if we decide to run the perimeter ourselves?
The configuration does not remain inside someone else’s account. Alert rules, label dictionaries and notification templates are exported as files and stored in a version control system — they can be transferred and reproduced on your side.
Owner access remains with you; Nansen settings handover is part of the work, not a separate agreement.
Let’s discuss the task and come back with an estimate and plan
To come back with a plan rather than generalities, we need a minimum of inputs. Put them in one message — that will be enough to review the task and estimate the scope of analytics work without a week of clarifying emails.
- Task statement: what decisions are made based on the data — counterparty checks, monitoring team wallets, controlling fund movement across the portfolio.
- Priority networks and assets: where the project’s main liquidity resides, which networks we cover first and which can be deferred.
- Address sources: wallet lists, counterparty registries, ready labels — in what form you have them and who is responsible for keeping them current.
- Users and output format: who views the data and how — web dashboard, regular exports to your reporting, alerts to corporate messenger.
- Constraints: access level and request limits, security service requirements for keys and export storage.
- Definition of done: which report or signal you consider proof that the task is solved.
From this we assemble a work plan: scope by blocks — access, sources, analysis rules, data output — timeline estimate for each block and project start order. Separately we record what remains with you after delivery: configurations, schemas, team instructions.
Describe the task — we will come back with a plan and a list of results you will receive at the output.