There is a recurring conversation inside crypto companies where two people want the same thing and cannot agree on what it is. One side asks for visibility into on-chain user activity. The other side asks for a monitoring and reporting capability. They are describing the same data, the same wallets and frequently the same afternoon of work, but the vocabulary is so different that each concludes the other is solving a different problem.
This is a translation guide, because the gap is expensive. Teams buy analytics tooling that cannot produce evidence, or compliance tooling that nobody in the product org will open.
Same data, two questions
The distinction is not technical. It is about what the answer has to survive.
A product or growth question ends when you have a number you believe. How many wallets came back this month, which protocols they touched, where the volume concentrated. The bar is that it is directionally right and that you can rerun it next month.
A compliance question ends when someone outside the company accepts the answer. A supervisor, an auditor, a bank's onboarding team, occasionally a court. The bar is that the claim is reconstructible: which addresses, on what basis they were grouped, what the state of the chain was when you looked, and who decided.
That is the whole difference. Not the data, the durability.
The four phrases and what they turn into
"Full visibility into on-chain behaviour." In practice this means one question: for a given actor, can you see everything they did, across the chains they used, without stitching exports by hand? The compliance version adds a clause. Everything they did, and you can show why you believe those addresses are the same actor. Clustering that is good enough for a dashboard is not automatically good enough for a file, because a dashboard never has to defend a false positive.
"Analyse web3 transactions." Product teams mean aggregate: flows, cohorts, protocol mix. Compliance means the opposite direction, one transaction expanded outward until the counterparties are known. Most tools are built for one of these two directions and are awkward in the other. Worth knowing which one you bought.
"On-chain user insights." The honest translation is attribution. An insight about a user presupposes you know which addresses are that user. Everything downstream inherits the quality of that step, which is why attribution methodology is the thing to interrogate in a demo, not the dashboard.
"Ecosystem monitoring." For a protocol team this usually means health: TVL, active addresses, unusual outflows. For compliance it means exposure: which of the addresses touching your contracts are sanctioned, which came through a mixer, which belong to a counterparty you are supposed to have offboarded. Same watchlist, completely different alert.
Where the two genuinely converge
Three cases force both teams into the same room, and they are the ones worth designing for.
Market manipulation. A product team notices wash trading because it corrupts the metrics. A compliance team has to detect it because MiCA Title VI requires it. Under Commission Delegated Regulation (EU) 2025/885, a firm professionally arranging or executing crypto transactions has to analyse orders that were placed, modified, cancelled or rejected, on or off a trading platform and on the ledger. That is a surveillance obligation, but the underlying signal is the same anomaly the analytics team was already annoyed about.
Incident response. When funds leave, everyone needs the same trace, immediately. The difference is that the compliance version has to still make sense in three months, with the reasoning attached, because that is when the insurer or the regulator asks.
Counterparty screening. Before an integration, a listing or a partnership, someone has to ask what the other side's addresses have touched. That is due diligence whether or not anyone calls it that.
What to ask a provider, in either vocabulary
The useful questions are the ones that expose the durability gap:
- How do you decide two addresses belong to the same entity, and can I see the basis for a specific grouping?
- Do you keep chain state as of the time of the query, or only as of now? Answers that silently change are unusable in a file.
- Can I export the reasoning behind a conclusion, or only the conclusion?
- Does coverage extend across bridges, or does the trail stop at the chain boundary?
- Are cancelled and modified orders retained, if you also cover venue activity?
None of these are exotic. They are just the questions that separate a tool that answers a question from a tool that answers it again later, to someone who is not inclined to believe you.
The practical advice
If you are a web3 team with a compliance obligation arriving, do not buy twice. The analytics stack you already run and the monitoring capability the regulation expects overlap by most of their surface. What is usually missing is not more data, it is three things: attribution you can defend, history you can query as of a past moment, and a path from an alert to an exportable record.
If you are a compliance team talking to engineers, stop leading with the regulation. Lead with the wallet. Everyone in the building already agrees that knowing who is on the other side of a transaction is worth doing, and that agreement is where the budget comes from.
Seqlense Monitoring exists at that intersection, watching both the order book and the chain in one view (what separates the two records), but the framing matters more than the tool. Two teams buying separately for the same problem is the failure mode, and it is easy to avoid once someone notices it is happening.
Sources
- Commission Delegated Regulation (EU) 2025/885 of 29 April 2025, RTS on market abuse under MiCA
- ESMA, Markets in Crypto-Assets Regulation (MiCA)