OBIS-0002: Shared Taxonomies for Blockchain Intelligence#
Abstract#
This document specifies shared taxonomies for blockchain intelligence: controlled vocabularies that downstream OBIS specifications reference when labelling addresses, services, and events. v1-draft surveys the prior work in the area, defines a small number of top-level concepts in each of two vocabularies (Actor Type and Abuse Type), and organises specific sub-terms hierarchically beneath them. Mappings to the INTERPOL DW-VA-Taxonomy and the DefiLlama protocol categories are given as separate sections.
1. Introduction#
Most work in blockchain intelligence requires labelling addresses, services, and events with categorical information. What kind of service is this (e.g., centralised exchange, mixer, DEX, sanctioned actor)? What kind of abuse has been observed (e.g., ransomware, scam, sextortion)? Which protocol category does a DeFi smart contract belong to (e.g., DEX, lending, liquid staking)? Different communities have produced different vocabularies in response to similar questions, and tools that interoperate across communities have to map between them.
OBIS-0002 commits to a set of shared vocabularies, owned and maintained openly, that downstream OBIS specifications can reference. The initial release covers actor type and abuse type, in each case via a small number of top-level concepts under which more specific terms are organised. A protocol-category vocabulary is deferred to a future revision once cross-area consensus is in reach.
2. Scope#
The taxonomies relevant to OBIS work fall into three layers. This document specifies the first two and defers the third:
- Actor type. What kind of real-world participant or on-chain construct an address represents (§6).
- Abuse type. What kind of harmful activity has been observed (§7).
- Protocol category. For programmable on-chain logic, the role of the protocol within the DeFi ecosystem. Out of scope for v1.
A fourth layer, transaction type (e.g., transfer, swap, mint, contract call), is handled adequately by chain-native semantics today and is treated as out of scope until an interoperability gap is identified.
3. Terminology#
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.
- Term. A single labelled concept in an OBIS taxonomy, carrying an identifier and a definition.
- Top-level concept. One of the small number of concepts that anchor a vocabulary (§6.1 for actors, §7.1 for abuse).
- Sub-term. A concept refining a top-level concept, named with the dot-separated form
<top-level>.<specific>. - Vocabulary. A coherent set of top-level concepts and their sub-terms covering one layer (e.g., the OBIS Actor Type Vocabulary).
- Source taxonomy. A pre-existing taxonomy that OBIS terms map to (e.g., INTERPOL Entity Taxonomy).
4. Related work#
4.1 INTERPOL Darkweb and Virtual Assets Taxonomy#
The INTERPOL Innovation Centre, via its Darknet and Cryptocurrencies Working Group, publishes two coordinated taxonomies:
- Entity Taxonomy (v0.3): real-world actors and services in dark-web and cryptoasset ecosystems.
- Abuse Taxonomy (v0.1): forms of improper service deployment or abuse.
Both are published in human-readable form alongside machine-readable downloads (CSV), are developed on a public Git repository, and explicitly “build on existing definitions and do not claim to replace them.” They are maintained by an INTERPOL working group composed of law-enforcement and academic contributors; latest revision 2022. The INTERPOL taxonomies are the de facto base used by open-source investigations tooling and the most direct prior art for OBIS-0002. The OBIS-to-INTERPOL mapping is given in §8.
4.2 GraphSense conventions#
GraphSense TagPacks (the basis of OBIS-0003) reuse the INTERPOL Entity and Abuse taxonomies as their category and abuse fields rather than maintaining a separate vocabulary. The choice is significant: an investigations-focused open-source tooling ecosystem treats the INTERPOL taxonomy as the operational base.
4.3 DefiLlama categories#
DefiLlama maintains a community-curated classification of DeFi protocols (e.g., DEX, Lending, Yield, Bridge, CDP, Derivatives, Liquid Staking, Insurance). The taxonomy is centred on protocol role rather than actor type, spans multiple blockchains, and is maintained openly via the DefiLlama GitHub repository. It is the most widely cited classification for protocol-category work in research and journalism. The OBIS-to-DefiLlama mapping is given in §8.
4.4 Closed commercial classifications#
The major commercial blockchain analytics vendors (e.g., Chainalysis, TRM Labs, Elliptic) each maintain proprietary actor and abuse taxonomies. These are not publicly redistributable and frequently differ in granularity and terminology, both from one another and from INTERPOL. They are noted because tooling that interoperates with these vendors must in practice map to and from them; they cannot serve as the basis for an open standard.
5. Design principles#
OBIS-0002 commits to the following principles, derived from the dimensions on which existing efforts vary (§4):
- Small top-level vocabulary, expandable in depth. Each vocabulary defines a handful of top-level concepts; specificity is added by sub-terms rather than by widening the top level.
- Hierarchical identifiers. Sub-terms are named
<top-level>.<specific>(e.g.,service.exchange,extortion.ransomware). Implementations MAY use the top-level identifier alone when the sub-term is unknown or unnecessary. - Stable identifiers. Identifiers do not change with rewording; human-readable labels and definitions may evolve, but the identifier is permanent.
- Open extension. Implementations MAY introduce extension sub-terms with the
x-prefix on the specific segment (e.g.,service.x-bespoke); OBIS reserves all non-x-sub-terms. - Explicit mapping to source taxonomies. Mappings to INTERPOL, DefiLlama, and other sources are given in their own section (§8) rather than embedded as columns in the vocabulary tables. This keeps the vocabularies self-contained and makes the maps replaceable as source taxonomies evolve.
- Conservative additions. The initial vocabularies are small and cover the cases most frequently exchanged in practice. Coverage grows by versioned revision, not by ad hoc per-implementation additions.
6. OBIS Actor Type Vocabulary#
6.1 Top-level concepts#
The Actor Type Vocabulary is anchored by three top-level concepts. Every actor-type tag SHOULD carry either a top-level identifier or a <top-level>.<sub-term> identifier from §6.2.
| Identifier | Meaning |
|---|---|
service | An automated or operated function in the cryptoasset ecosystem that exchanges value, holds custody, processes payment, or provides infrastructure. Services may be centralised (a corporate exchange), decentralised (a smart-contract-based DEX), or hybrid. |
party | A real-world participant in the ecosystem in a non-service capacity: a natural person, an organisation, or an actor designated by a regulator or sanctioning authority. |
program | On-chain programmable logic that holds or moves value as a thing in itself (a token contract, a DAO treasury) rather than as a service. Where the program’s user-facing role is operationally a service (e.g., a DEX pool), service.* takes precedence. |
6.2 Sub-terms#
| Identifier | Definition |
|---|---|
service.exchange | Centralised virtual-asset exchange or trading service. |
service.dex | Decentralised exchange or automated market maker. |
service.mixer | Mixing or anonymising service. |
service.bridge | Cross-chain bridge or wrapping service. |
service.lending | DeFi lending or borrowing market. |
service.liquid-staking | Liquid-staking service. |
service.payment-processor | Merchant or remittance payment processor. |
service.gambling | Betting, casino, or prediction-market service. |
service.miner | Block producer (PoW miner, PoS validator, or mining pool). |
service.darknet-market | Marketplace operating predominantly on a darknet. |
service.unknown | Service of undetermined sub-type. |
party.individual | Natural person. |
party.organisation | Non-exchange organisation (foundation, NGO, corporation). |
party.sanctioned | Actor designated by a competent sanctioning authority; usually accompanies a more specific sub-term where one applies. |
program.smart-contract | Generic on-chain programmable logic. |
program.token-contract | Token-issuing contract (e.g., ERC-20, ERC-721). |
program.dao-treasury | DAO treasury contract. |
Implementations using these terms in OBIS-0003 records (or any other OBIS context) MUST use the OBIS identifier on exchange. They MAY retain alternative internal representations.
7. OBIS Abuse Type Vocabulary#
7.1 Top-level concepts#
The Abuse Type Vocabulary is anchored by four top-level concepts. Every abuse-type tag SHOULD carry either a top-level identifier or a <top-level>.<sub-term> identifier from §7.2.
| Identifier | Meaning |
|---|---|
extortion | Payment extracted under threat or coercion. |
fraud | Payment extracted by deception. |
prohibited | Activity prohibited by law regardless of victim consent — sanctions evasion, financing of designated activity, marketplaces for unlawful goods, child sexual abuse material. |
theft | Value taken without authorisation. |
7.2 Sub-terms#
| Identifier | Definition |
|---|---|
extortion.ransomware | Address used by a ransomware operator to receive ransom payments. |
extortion.sextortion | Sextortion campaign demanding payment under threat of disclosure. |
extortion.other | Extortion of payment under other forms of duress. |
fraud.phishing | Phishing site, wallet drainer, or fake interface deployed to steal credentials or funds. |
fraud.rugpull | Rug-pull operation: an apparent legitimate project withdraws liquidity or absconds with funds. |
fraud.investment | Investment fraud, including pig-butchering and Ponzi schemes. |
prohibited.sanctions-evasion | Activity designed to evade sanctions designations. |
prohibited.terror-financing | Address used to finance designated terrorist activity. |
prohibited.csam | Address used in connection with child sexual abuse material. |
prohibited.illicit-market | Marketplace trading goods or services that are illegal in the jurisdiction of operation. |
theft.cybercrime | Theft of cryptoassets via exploit, hack, or unauthorised access. |
Use of the prohibited.csam and prohibited.terror-financing terms in exchanged records carries elevated handling obligations; see OBIS-0003 §11 (privacy and security).
8. Mappings to source taxonomies#
Source taxonomies do not necessarily share OBIS’s structure. The maps below give the OBIS identifier most closely corresponding to each source term. Equivalence is = (exact correspondence), ~ (close, with minor scope differences), or → (the OBIS term is broader or narrower; consult the definition).
8.1 INTERPOL Entity Taxonomy (v0.3) → OBIS Actor Type#
| INTERPOL term | Relation | OBIS identifier |
|---|---|---|
| Exchange | = | service.exchange |
| Mixer | = | service.mixer |
| Mining | = | service.miner |
| Gambling | = | service.gambling |
| Darknet Market | = | service.darknet-market |
| Payment Processor | ~ | service.payment-processor |
| Unknown | ~ | service.unknown |
Terms in the INTERPOL Entity Taxonomy without a current OBIS mapping are listed in §9 (Mapping completeness).
8.2 INTERPOL Abuse Taxonomy (v0.1) → OBIS Abuse Type#
| INTERPOL term | Relation | OBIS identifier |
|---|---|---|
| Ransomware | = | extortion.ransomware |
| Sextortion | = | extortion.sextortion |
| Extortion | → | extortion (use a sub-term if known) |
| Scam | → | fraud (use a sub-term: fraud.phishing, fraud.rugpull, or fraud.investment) |
| Theft | ~ | theft.cybercrime |
| Terrorism Financing | = | prohibited.terror-financing |
| CSAM | = | prohibited.csam |
| Darknet Market (as abuse) | = | prohibited.illicit-market |
8.3 DefiLlama categories → OBIS Actor Type#
| DefiLlama category | Relation | OBIS identifier |
|---|---|---|
| DEX | = | service.dex |
| Lending | = | service.lending |
| Bridge | = | service.bridge |
| Liquid Staking | = | service.liquid-staking |
| CDP | ~ | service.lending |
| Derivatives | → | service (no current sub-term; reserved for future revision) |
| Insurance | → | service (no current sub-term; reserved for future revision) |
| Yield | → | service (no current sub-term; reserved for future revision) |
DefiLlama categories not listed map to service at the top level pending future revision.
9. Extension mechanism#
Implementations MAY introduce extension sub-terms beyond those defined in §6 and §7, subject to the following rules:
- Extension sub-terms MUST carry the
x-prefix on the specific segment (e.g.,service.x-bespoke,fraud.x-trade-finance). - Extension terms MUST be defined locally in any TagPack header or external schema document that uses them.
- Recipients of records containing extension terms MUST treat unknown extensions as opaque labels under their declared top-level concept, rather than ignoring the tag entirely.
- Extension terms with broad utility SHOULD be proposed for promotion to a non-prefixed OBIS sub-term in a future revision of this document.
10. Open issues#
- Protocol-category vocabulary. Deferred to a future revision. DefiLlama categories are the expected starting base.
- Mapping completeness. INTERPOL Entity Taxonomy v0.3 and Abuse Taxonomy v0.1 contain terms not yet mapped here (e.g., specific service subtypes). Coverage will grow in v2 as implementation feedback identifies gaps.
- Stable URIs. Each OBIS term is expected to receive a stable resolvable URI of the form
https://obistandards.org/taxonomy/actor/<id>andhttps://obistandards.org/taxonomy/abuse/<id>; the publishing mechanism is deferred. - Multi-classification. Whether a single address may carry more than one sub-term at the same hierarchical level (e.g., both
service.exchangeandservice.payment-processor) is left to the data format (OBIS-0003) and is not constrained by this vocabulary.
References#
- IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels.
- INTERPOL Innovation Centre, Darkweb and Virtual Assets Taxonomy. Entity Taxonomy v0.3, Abuse Taxonomy v0.1.
- DefiLlama, Protocol Categories.
- GraphSense, TagPacks Wiki.
- OBIS-0001, OBIS Document Lifecycle.
- OBIS-0003, Attribution Tag Data Model and Exchange Format.