What NimMap draws
NimMap takes one address and walks its transaction history outward. Every hexagon is an address. Every arrow is a single transaction, pointing from the address that sent to the address that received. Nothing is sampled or precomputed: the map is composed on request from live chain data, which is also why a deep scan takes a few seconds rather than none.
Four things carry meaning, and it is worth knowing all four before you read a map:
- Position. The address you searched is the seed, pinned in the middle. Everything else is there because a transaction connects it back to that seed.
- Hexagon size. How much value has passed through an address, in plus out, on a logarithmic scale. A small wallet and a large one both stay on screen.
- Arrow width. The amount, on the same kind of scale. A signalling transaction carries no value at all, so it draws as the thinnest possible line.
- Arrow colour. What kind of transaction it is. That is the next section.
One more shape worth recognising: a hexagon with a dashed outline is the edge of the scan. It was found as somebody's counterparty, but its own history was never read, so the arrows you see around it are only the ones that reach back into the map.
Searching: start from an address
The box on the map takes a Nimiq address, the NQ form with or without its spaces, and the Scan button starts the walk. If you have nothing to hand, the two example chips under an empty map load our own validator and an ordinary staking wallet.
A transaction hash or a block height goes somewhere else. Our block explorer takes all four kinds of input, a block height, a block hash, a transaction hash or an address, and routes each one to where it can be read: blocks and transactions get their own explorer pages, and an address opens in NimMap seeded on that address. That is the division of labour between the two tools. The explorer answers "what is this", the map answers "where did it go".
Addresses are also linkable directly. A URL of the form /graph/?seed=NQ...
opens the map already scanning that address, which is what the explorer uses internally and
what you can paste into a message or a bookmark.
The edge families
Nimiq puts the interesting part of a transaction in two places a map can read cheaply: the account type at each end, and the first byte of the data attached to it. From those, every arrow lands in one of six families, and the legend in the top right corner names them.
| Family | Colour | What it is |
|---|---|---|
| Basic | Zinc grey | A plain transfer between two ordinary accounts, with nothing attached. |
| Stake | Cyan | Anything going into the staking contract, and the validator deposit coming back out of it. The arrow is named for the exact operation where the chain said it: Stake, Add stake, Update staker, Set active stake, Unstake, or one of the validator operations. |
| Reward | Gold | Value leaving the staking contract to a staker. Retired stake and the rewards that accrued on it are paid out together, and the chain does not separate them, so neither does the label. |
| Message / data | Violet, drawn dashed | A transfer carrying a payload: a message, a cashlink, or whatever the sender chose to attach. When the payload creates a contract the arrow says so instead. |
| HTLC | Pink | One end is a hashed time locked contract, the escrow type used for swaps. |
| Vesting | Teal | One end is a vesting contract, which releases a balance on a schedule. |
The violet family is worth a note, because we renamed it. It used to read "Contract call", which was borrowing an idea from Ethereum that Nimiq does not have: there is nothing on this chain to call. What those transactions actually carry is data, and the family is now named for that: Message / data. The one case where the word contract is literally true, a payload that creates a vesting contract or an HTLC, gets its own label on the arrow.
The legend also has Type and Age chips. Switch to Age and the families disappear, replaced by one ramp from grey to cyan running oldest to newest, which is the view for questions about when rather than what.
Depth: how far out it looks
Depth is the number of hops the scan will open, and it is the control that changes the answer most:
- Depth 1. The seed and everybody it transacted with.
- Depth 2. Those counterparties opened in turn, so their counterparties appear.
- Depth 3. One more ring. This is as far as a free scan goes.
- Depth 4 and 5. Two further rings, for a reader with a pass.
Picking a depth while a map is on screen re-runs that map at the new depth rather than waiting for the next search. Two things are deliberately not expanded at any depth. The staking contract is one, because it trades with tens of thousands of wallets and opening it would fill the map with strangers. The other is whatever sits at the outer ring when the depth runs out, which is what the dashed hexagons and the boundary notice under the map are telling you about: the map has an edge, and it says where it is.
The rest of the controls
- Labels. The toggle in the top right corner hides the address text on every hexagon and brings it back. On a dense map, hiding it is usually how the shape becomes readable.
- Moving around. Drag to pan, scroll or pinch to zoom, drag a hexagon to pull it out of a cluster. The zoom buttons and Reset sit above the map.
- Clicking a hexagon. A panel opens with the balance, the number of transactions on the map, the totals received and sent, and how many hops it is from the seed, plus a link out to nimiq.watch. Badges mark a validator, the staking contract, an address whose history would not load, and the edge of the scan.
- Clicking an arrow. The amount, both addresses, the time, the confirmations and the full transaction hash, which copies with a click.
- The list under the map. The newest transactions in the scan, in order, and clicking a row selects that arrow on the canvas. The CSV export carries every transaction rather than just the visible rows.
- Esc clears a selection. Double clicking a hexagon, or the Scan from here button in its panel, restarts the map from that address, which is how you walk a trail one address at a time instead of widening the whole map. That one needs a pass.
A worked trace: our own validator address
Here is a complete map, read on 14 September 2026. The seed is the ImpactZero validator
address, NQ08 ACT8 T0FE PTG8 P5RL H2S3 QGXH V15R NVXY, which we publish in the
footer of every page on this site. It is a good teaching example for two reasons: the
address belongs to a validator we run, so reading it in public exposes nobody else, and its
history is short enough that a free scan sees all of it. At depth 1 it drew eight
transactions across three counterparties.
Read from the oldest arrow forward, the map tells one continuous story:
| When | What the arrow says | How it reads on the map |
|---|---|---|
| 25 July 2025 | 100,000 NIM in, from an ordinary address | Grey, no label. A plain transfer funding the deposit. |
| 25 July 2025 | 100,000 NIM out, labelled Create validator | Cyan, into the staking contract hexagon. |
| 13 August 2025 | Deactivate validator, then Retire validator | Two hairline cyan arrows. Signalling transactions move no value. |
| 17 August 2025 | 100,000 NIM back, labelled Delete validator | Cyan, out of the contract. The deposit returning at the end of the exit. |
| 17 August 2025 | 100,000 NIM out to an ordinary address | Grey. The deposit parked somewhere else. |
| 11 September 2026 | 100,000 NIM back in from that same address, then Create validator 49 seconds later | Grey in, cyan out. The validator registered again. |
That is the validator lifecycle drawn without anyone narrating it: fund, register, then deactivate, retire and delete to exit, then register again. It is also the difference between the two exit paths in one picture, because deactivate, retire and delete is the validator path. A staker leaving a delegation sends a different set of operations, which is what how to unstake NIM walks through.
Two honest caveats about this trace. It is a reading from one day, and the address will have more transactions on it by the time you scan it. And a map like this one is unusually clean because the address is young; a wallet with years of payments behind it produces something far denser, which is what the labels toggle and the depth control are for. For what this validator is doing right now, including whether it is elected, the live answer is on our validators page rather than in any map.
What is free, and what the pass changes
Plainly, because a paywall described vaguely is a paywall described dishonestly. Transaction history comes from our own API, cached for a minute, and a scan is bounded so that one reader cannot exhaust it for everyone else.
| Free | With a pass | |
|---|---|---|
| Depth | 1 to 3 | 1 to 5 |
| Transactions read per address | 20 | 50 |
| Addresses on one map | 100 | 400 |
| PNG and CSV export | No | Yes |
| Rescan from a clicked address | No | Yes |
The free tier needs no wallet, no sign in and no popup, and most questions are answerable inside it. The pass runs for 30 days and is paid on chain in NIM. It is priced in dollars and charged in NIM, so there is no figure worth printing on this page; the dialog shows the exact amount and the address it goes to before anything is sent. Once you have sent it, the dialog asks the chain whether the payment arrived and keeps asking while it confirms. There is no receipt to upload and nobody to email.
Signing in takes two steps and neither one is a transaction:
- Connect a wallet. On a desktop that is the Nimiq Hub, which opens as a small window and asks which account you want to use. On a phone it is Nimiq Pay, which already knows.
- Sign one short sentence. A signature proves the address is yours. It costs nothing and moves nothing, and the wallet prefixes the message before signing it precisely so that what you signed can never be mistaken for a transaction.
The pass then lives in that browser. Signing in again with the same wallet somewhere else moves it there, so it is attached to an address rather than to a device.
The staker pass
If you delegate to ImpactZero, the full tier is free while that delegation stands. Sign in with the wallet you staked from and the map reads your staker record from the chain and checks which validator your delegation names. If it names ours, the pass unlocks with no payment, and the badge says staker pass rather than counting days down. Any live delegation qualifies; there is no minimum on it today.
The honest version of that offer: the chain is re-read whenever the site asks about your pass, not only at sign in, so it lasts exactly as long as the delegation does and lapses back to the free tier when the stake moves. And we are the people who run the validator it points at. It is a reason to look at our validator comparison with your eyes open, not a reason to skip it. If you are weighing where to delegate at all, the guide for that is how to stake NIM.
What a map cannot tell you
The most useful thing to know about any graph explorer is where it stops being evidence.
- It shows payments, not people. An arrow means one address paid another. It does not mean they know each other, and an address is not an identity.
- It reads recent history, not all of it. Each address contributes its most recent transactions, up to the tier's limit. A busy address is marked as having more than the scan read, and what you see is the newest slice of it.
- Gaps are marked, not hidden. An address whose history would not load is flagged as partial and the scan carries on, so the map is honest about being incomplete rather than quietly wrong.
- The edge is arbitrary. Where a map ends is a function of the depth you chose and the address cap, not of where the money stopped moving.
With those in mind, go and break something: open NimMap, paste an address you already understand, and check whether the picture matches what you know. That is the fastest way to learn to read one. The rest of our guides are on the Learn hub.