Cowrie Research

nansen

4 min read

Nansen

  • Name: Nansen
  • URL: https://nansen.ai/
  • Category: onchain-intelligence operator / labeled-wallet analytics company / API-and-agent workflow company
  • Tags: ethereum-ecosystem solana-ecosystem bitcoin-ecosystem
  • Summary: Nansen belongs in companies/ because the durable dependency is not just a dashboard with wallet labels. The useful question is which named operator owns the labeled-address corpus, decides entity classifications and Smart Money heuristics, gates account and API access, controls credits and restricted endpoints, sets redistribution policy, and now packages agent, MCP, and execution workflow on top of that data. The practical leverage sits with Nansen’s company-run analytics, access, and workflow shell rather than with any neutral protocol primitive.
  • What it does:
    • Operates a multi-chain onchain-intelligence platform centered on proprietary wallet and entity labels, Smart Money analytics, portfolio and profiler surfaces, and token-screening views
    • Packages authenticated API access for Smart Money, Profiler, Portfolio, Token Screener, Hyperliquid, Prediction Markets, and adjacent datasets under one company-managed credit and rate-limit shell
    • Exposes AI-facing access through a hosted research-agent API and a hosted MCP server, both tied back to Nansen account and API-key workflow
    • Sells a combined research-and-execution product where users can move from wallet intelligence and narrative detection into spot or perp trading inside the same branded app experience
    • Controls the legal, contractual, and technical perimeter around restricted endpoints, data redistribution, attribution, competitor access, and feature retirement
  • Key claims:
    • The homepage frames Nansen as The first truly agentic onchain app and says users can research, analyze, and execute, all in one loop, which is analytically stronger as a company-run workflow shell than as a neutral analytics primitive
    • The same site says Nansen is powered by 500M+ labeled addresses and treats those labels as the core reason users can see where Smart Money, whales, public figures, and funds are moving
    • The docs intro says Nansen applies unique, human-readable labels to hundreds of millions of blockchain addresses and presents proprietary labeling plus Smart Money analytics as the API’s core value boundary
    • The agent docs show access starts with a Nansen account sign-in and setup flow rather than an open protocol handshake, reinforcing that machine access is company-mediated
    • The MCP docs say the hosted Nansen MCP server requires the same API key and credit balance as the regular API, which makes AI-facing workflow packaging part of the same operator boundary
    • Nansen’s API terms say MCP is governed as an API access method, that Nansen’s labeled blockchain data and classification methodologies are proprietary intellectual property, that restricted endpoints are approval-gated at Nansen’s sole discretion, and that competitor access can be restricted or prohibited
    • The API terms also say labels, entity classifications, and analytics methodologies are licensed, not sold, while the terms of service say Nansen may modify or discontinue service features at its discretion, which is exactly the kind of control-surface reality the company layer should preserve
  • Whitepaper: No classic Nansen company whitepaper is the important artifact here. The clearest current primary materials are the homepage, docs intro, agent and MCP docs, API terms, and terms of service captured in ../whitepapers/nansen-company-primary-sources-2026-08-08.md.
  • Sources:

Internal linkages

  • Alias / prior project-layer entry: nansen.
  • Useful adjacent company reads for operator-authored analytics and workflow truth: dune, kaiko, allium, and zerion.
  • Useful contrast where the interesting question stays closer to a reusable open protocol or lower-layer primitive: walletconnect and open-payments.

Product / company boundary

  • Keep Nansen in companies/ because the current branded stack is one company-run shell: proprietary labels, Smart Money classification, API access, agent and MCP access, redistribution terms, and execution packaging all travel together.
  • For now there is no separate project-layer note because the useful analytical question is not what neutral protocol does Nansen add? but who owns the labels, gates the interfaces, prices the credits, restricts the endpoints, and decides what downstream users or agents can do with the resulting intelligence?
  • If a later pass finds a reusable lower-layer primitive or a distinct product branch that stands cleanly apart from the company shell, that can be split back out. This pass does not support that yet.

Control surface

  • Practical leverage sits in label curation, entity classification, Smart Money heuristics, supported-chain and dataset coverage, API-key admission, credit and rate-limit policy, restricted-endpoint approvals, redistribution permissions, attribution requirements, and the hosted MCP / research-agent access path.

  • The legal docs make the operator boundary unusually legible: Nansen treats labels and methodologies as proprietary IP, can restrict competitor access, can withdraw endpoint approvals, and can change or discontinue service features.

  • The sticky dependency is not only data quality. It is the company-run workflow graph tying dashboard truth, API output, agent/MCP access, and trade-adjacent execution into one branded decision surface.

  • Treat Nansen as an operator boundary first: a named company controlling labeled-wallet intelligence, machine access, and execution-adjacent workflow rather than a neutral onchain protocol.

  • Last reviewed: 2026-08-08 UTC

Graph View

Backlinks