# Fundamentals — Just Cryptoeconomics

> This file contains the Fundamentals classification framework followed by comprehensive cryptoeconomic analysis data for all published tokens.
> Last updated: 2026-04-07T10:16:57.635Z
> Source: https://fundamentals.fyi
> Total tokens: 41

---

# PART 1: CLASSIFICATION FRAMEWORK

> The Fundamentals classification framework — definitions used throughout the dashboard.
> Canonical pages: https://fundamentals.fyi/docs

# Overview

**Fundamentals** is an analytics dashboard and product offered by [Just Cryptoeconomics](https://justcryptoeconomics.com). It provides structured, comparable analysis of cryptoeconomic systems and tokens. Underpinning the dashboard is our classification framework, which categorises each system according to the type of product or service it sells, how it operates, where economic value is created and captured, who governs its essential components, and what functional roles, if any, its native token performs.

This document is the public reference guide to that framework. It defines the labels, terms, and concepts used throughout the **Fundamentals** dashboard.

## Units of Analysis

**System:** The economic system being analysed. In practice, it includes on-chain components and, where relevant, off-chain entities and infrastructure.

**Token:** A token is analysed only insofar as it has functional roles that require token ownership. A core principle of the Token Functionality Framework is that only those roles that require token ownership to engage and benefit from a system qualify as functionalities.

Canonical URL: https://fundamentals.fyi/docs/overview

---

# Framework Structure

Fundamentals combines three layers that answer different questions. They should be read together.

| Layer | Questions Answered | What It Clarifies |
|---|---|---|
| Sector Classification | What product or service does the system sell to its buyers? | The buyer-facing job and service line. |
| System Taxonomy | What kind of economic system is this, and how does it operate? Where is value created and captured? How is the system governed? | The structural context around value and control. |
| Token Functionality Framework | What role does the token play? Which utilities or rights does it confer? | The functional roles the token plays within the system. |

**Methodological note:** Classifications in **Fundamentals** are based on documented system and token attributes and are applied using an internal analyst methodology designed to support consistency across profiles.

Canonical URL: https://fundamentals.fyi/docs/framework-structure

---

# Sector Classification

## Purpose

Sector classification describes the buyer-facing product or service. It does not describe internal architecture, value flow structure, or governance. Those questions are handled elsewhere in the framework.

## Scope and Principles

Each system receives one primary sector and may receive up to two secondary sectors. Each assigned sector is then mapped to one or more corresponding subsectors.

- One primary sector per system
- Up to two secondary sectors where an additional service line is materially present today.
- Classification follows the dominant service delivered today.
- Buyer-facing economic signals determine classification — revenue, metered work, assets under service, binding commitments, or sustained usage
- In stacked products, the layer that is actually monetised or committed against is classified.
- Reward flows and token incentives do not override the buyer's job.

Examples in the [sector catalogue](/docs/sector-catalogue) and [subsector catalogue](/docs/subsector-catalogue) are illustrative. A system may appear under more than one category where multiple service lines are material.

Canonical URL: https://fundamentals.fyi/docs/sector-classification

---

# Sector Catalogue

The sector catalogue below is the closed set of buyer-facing service categories used in the dashboard.

| Sector | Description | Illustrative Examples |
|---|---|---|
| Blockspace Production | Systems that sell execution capacity, block building, data availability, or proof generation and verification to chains, rollups, applications, and downstream agents that execute against smart contracts. Buyers are protocol teams, application teams, rollups, and any agent that must purchase compute, inclusion, availability, or proofs for their users and workloads. | Bitcoin, Ethereum |
| Interoperability and Messaging | Systems that relay assets or messages across domains and provide intent settlement or liquidity routing for cross-domain activity. Includes cross-domain liquidity networks and intent routers; token transfers are a dominant use case of messaging. Buyers are applications, wallets, and rollups that need reliable movement of value or calls between environments. | Wormhole, Cosmos |
| Trusted Data and Identity | Systems that sell trusted inputs to other systems: price feeds, randomness, external facts, or compute outputs, and identity credentials or naming resolution. Buyers are protocols and applications that require verifiable data or identity primitives to operate. | Chainlink, Pyth Network |
| Storage and Indexing | Systems that provide persistent storage, retrieval and delivery, or indexing and query of data and state. Buyers are applications and users that pay for durable bytes, bandwidth, and structured access to data. | Filecoin, Arweave |
| Communications and Privacy Infrastructure | Systems that provide messaging, routing, connectivity/access, or confidentiality overlays where communication or privacy is the purchased outcome (for example, private routing, secure messaging, transaction or data confidentiality layers). Buyers are users and applications seeking confidentiality for content, state, or flows. | Helium, Nym |
| Money and Payments | Systems that issue or settle instruments used as money and that process payments for consumers and businesses. Buyers are users, merchants, enterprises, and financial intermediaries that require issuance, redemption, or acceptance rails. | Bitcoin, Dogecoin |
| Trading and Exchange | Systems that match or route orders for spot or derivative trading or that protect order flow. Includes token launchpads and primary distribution venues for tradable tokens. Buyers are traders, treasuries, and wallets paying for execution quality, liquidity access, and risk transfer. | Binance, Uniswap |
| Credit and Asset Management | Systems that originate or manage credit or that offer pooled strategies and staking products. Buyers are borrowers and asset holders seeking liquidity, yield, leverage, or exposure. | Jito, Aave |
| Tokenised Assets | Systems that issue or service real-world assets, securitised products, and on-chain funds. Buyers are issuers and investors paying for issuance, servicing, custody, or fund operations. | Raydium, Ondo Finance |
| Consumer Platforms and Media | Systems that monetise attention, fandom, creative work, or interactive entertainment through digital goods and networks. Buyers are creators, brands, investors, and consumers paying for distribution, monetisation, and marketplace services. | Brave, Chiliz |
| Coordination and Governance | Systems that provide collective decision making, treasury operations, grants, or dispute resolution. Buyers are distinct external communities and ecosystems that pay for programme operation and governance capabilities. | Aragon, Gitcoin |

Canonical URL: https://fundamentals.fyi/docs/sector-catalogue

---

# Subsector Catalogue

Subsectors provide a more precise description within an assigned sector. A system may have more than one subsector within the same sector where more than one distinct buyer job is materially present.

## Blockspace Production

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 1-1 | L1 Blockchain | General-purpose base layers that sell execution and inclusion to applications and users; priced by metered work such as gas or compute. Buyers are application teams and end users. | Bitcoin, Ethereum |
| 1-2 | L2 Blockchain | Layer 2 networks and rollups that sell execution and post transaction data to a base layer blockchain to inherit the security properties of the base layer. Buyers are L2 application teams and end users. | Arbitrum, Optimism |
| 1-3 | Specialised Data Availability Layers | Specialised solutions that sell data posting capacity and availability guarantees to blockchains. Buyers are blockchains, including L1s and L2s. | Celestia, EigenCloud |
| 1-4 | Decentralised Sequencer | Sequencer networks that sell transaction ordering services to blockchains. Buyers are rollups seeking to outsource transaction ordering. | Espresso, Astria |
| 1-5 | Block Builders and Order Flow Auctions | Systems that provide block building and inclusion services to blockchains. Includes order flow auctions and builder markets. Buyers are participants in block production services such as validators, builders and searchers. | Jito, Flashbots |
| 1-6 | Proof Generation and Verification Networks | Providers of proof construction, aggregation or verification as a paid service to blockchains and other systems. Buyers are L2s and apps. | Risc Zero Bonsai, Succinct |
| 1-7 | Shared Security and Slot Markets | Markets where consumer chains buy economic security guarantees. Sold outcome: capacity or security rights leased by a consumer chain. Buyers are consumer chains and protocols leasing security or capacity. | Jito, EigenCloud |
| 1-8 | Validator Middleware and Orchestration | Middleware that sells fault tolerance and distributed validator operations to increase safety and liveness. Buyers are validators and staking operators. | SSV Network, Obol Network |
| 1-9 | Chains-as-a-Service (Rollups & Appchains) | Platforms that sell packaged rollup and/or appchain creation and ongoing operations. Buyers are teams launching their own execution environment. | Arbitrum (Orbit), Optimism (OP Stack) |

## Interoperability and Messaging

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 2-1 | General Messaging Layers | Protocols that relay arbitrary calls or messages between L1s, L2s, app chains, rollups and approved off-chain execution environments. Buyers are applications, wallets and rollups that need reliable cross-domain function calls. | Wormhole, Cosmos |
| 2-2 | Asset Transfer Bridges | Systems that move assets between chains using lock and mint, burn and mint, or native issuance. Buyers are apps and wallets that must deliver assets to a destination domain. | Wormhole, Across |
| 2-3 | Cross-Chain Liquidity Networks | Liquidity pool networks that settle swaps across chains without user-managed bridging. Buyers are apps and end users seeking cross-chain liquidity. | THORChain |
| 2-4 | Intent Routers | Networks that accept intents for value movement or execution and route them to solvers or bridges. Buyers are wallets and applications. | LI.FI |
| 2-5 | Interchain Standards and Stacks | Messaging standards and relayer stacks that sell standardised messaging and secure cross-chain communication adopted by multiple chains with supported relayer infrastructure. Buyers are chains or app chains that implement the standard. | Cosmos (IBC), Polkadot (XCM) |

## Trusted Data and Identity

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 3-1 | External Data Oracles | Networks that sell canonical external data and attestations to protocols and applications. Buyers are protocols, applications, and traders. | Chainlink, Pyth Network |
| 3-2 | Verifiable Randomness and Functions | Services that sell randomness and verifiable compute outputs with proofs. Buyers are apps needing unbiased draws or verifiable results. | Chainlink (VRF), drand |
| 3-3 | Off-Chain Compute | Networks that sell outputs from off-chain compute or data processing (e.g., GPU/video/ML) with verifiability or privacy guarantees where available. Buyers are apps that need trusted outputs. | Livepeer, Render |
| 3-4 | Sensor and Real-World Data Networks | Systems that sell real-world data capture or coverage, including sensor, device, vehicle, camera, or mapping networks. Buyers are apps needing real-world data capture or geographic coverage. | Hivemapper, Jasmy |
| 3-5 | Identity Verification | Providers of identity and entity claims and identifier or profile services. Buyers are apps needing verified claims and portable identity. | Jasmy, Civic |
| 3-6 | Naming and Address Resolution | Systems that sell names and resolution to on-chain addresses and resources. Buyers are users and apps. | Ethereum Name Service, Handshake |
| 3-7 | Data Marketplaces | Protocols that sell datasets or data access rights as a product, rather than canonical live feeds for application execution. Buyers are analysts, apps and models. | Ocean Protocol |

## Storage and Indexing

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 4-1 | Persistent Storage Networks | Systems that sell durable storage of data objects with verifiable persistence. Buyers are applications and users paying for permanent or time-bound storage. | Filecoin, Arweave |
| 4-2 | Retrieval and Content Delivery | Networks that sell bandwidth and retrieval from distributed storage, including caching and delivery guarantees. Buyers are applications paying for availability and latency. | Filecoin (retrieval markets) |
| 4-3 | Indexing and Query | Services that sell structured access to on-chain and off-chain data through indexes, subgraphs, or APIs. Buyers are applications and analysts paying for queries. | The Graph, Covalent |
| 4-4 | Node and RPC Access | Providers that sell reliable read and write access to chain state and transaction broadcast through managed nodes or gateways. Buyers are applications and teams needing throughput, reliability and latency guarantees. | Infura, Alchemy |

## Communications and Privacy Infrastructure

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 5-1 | Secure Messaging Networks | Protocols that sell delivery of messages between users or applications with durable inboxes and verifiable delivery. Buyers are applications and wallets integrating messaging for prompts, alerts, governance communications, and app-to-app messaging. | Session, XMTP |
| 5-2 | Private Routing and Mixnets | Networks that sell metadata privacy for traffic, hiding sender, receiver, and path. Buyers are users and apps seeking network-level privacy. | Nym, HOPR |
| 5-3 | Transaction Privacy Overlays | Systems that sell shielding or obfuscation for transactions or account flows on public chains. Buyers are users and apps that need confidential transfers or state updates. | Railgun, Aztec |
| 5-4 | Access Control and Encryption Services | Protocols that sell key management, threshold encryption, and policy-based access for data and content. Buyers are apps and creators needing controlled access and encryption. | Lit Protocol |
| 5-5 | Connectivity and Access Networks | Networks that sell last-mile connectivity (wireless or local access) and/or bandwidth as the purchased outcome, typically via decentralised operators providing coverage hotspots, radios, or access points. Buyers are device operators, mobile subscribers, IoT fleet operators, and service providers that require connectivity coverage and data transfer. | Helium, World Mobile |

## Money and Payments

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 6-1 | Payment and Settlement Networks | Networks that sell peer-to-peer or business payments and final settlement using a native instrument. Buyers are users, merchants and remittance providers. | Bitcoin, Ripple |
| 6-2 | Stable Value Issuers | Issuers that sell price-stable instruments with issuance, acceptance and redemption rails (on-chain or off-chain). Buyers are users and enterprises that need stable settlement. | Circle, Tether |
| 6-3 | Merchant and Enterprise Payment Processors | Services that sell acceptance, invoicing and settlement rails for businesses using crypto instruments. Buyers are merchants and enterprises. | Coinbase Commerce, BitPay |

## Trading and Exchange

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 7-1 | Decentralised Spot Exchange | AMMs and order book DEXs that sell trade execution and liquidity access for spot assets. Buyers are traders and treasuries. | Hyperliquid, Uniswap |
| 7-2 | Decentralised Financial Derivatives Exchange | Venues that sell leveraged exposure or optionality, including perpetuals and options. Buyers are traders and treasuries. | Hyperliquid, Injective |
| 7-3 | Aggregators and Routers | Services that sell the best trading execution by routing across venues and pools. Buyers are wallets and traders. | CoW Protocol, 1inch |
| 7-4 | Centralised Exchange | Custodial trading venues selling execution, listing and custody as a bundle. Buyers are traders and issuers. | Binance, Bitget |
| 7-5 | Token Launchpads and Primary Distribution | Platforms that sell primary distribution and price discovery for new tradable tokens. Buyers are issuers and traders. | Binance (Launchpad), Kaito (Launchpad) |
| 7-6 | Order Flow Protection and Batch Auctions | Systems that sell protection and improved execution quality through intents, batch auctions or protected mempools. Buyers are wallets and traders. | CoW Protocol, MEV Blocker |

## Credit and Asset Management

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 8-1 | Collateralised & Underwritten Lending | Protocols and platforms that lend against posted collateral, typically over-collateralised at the account level. Buyers are borrowers and treasuries seeking working capital or leverage. | Aave, Morpho |
| 8-2 | Credit-Based Lending | Pools or marketplaces where a manager underwrites borrower risk with covenants or off-chain checks. Buyers are institutions and programmes needing credit. | TrueFi, Goldfinch |
| 8-3 | On-Chain Asset Management Platforms | Platforms that sell vault creation, execution, policy and fee infrastructure to strategy managers, who in turn serve depositors. Buyers are strategy managers and organisations launching and operating vaults and strategies. | Enzyme, Set Protocol |
| 8-4 | Liquid Staking Providers | Services that stake assets and issue liquid receipts that track staking claims. Buyers are token holders seeking staking yield and liquidity. | Jito, Lido |
| 8-5 | Restaking Strategies and LRTs | Managers who take staking receipts and restake them into shared security markets, issuing liquid restaked tokens. Buyers are token holders seeking boosted yield and points. | Renzo, Kelp DAO |
| 8-6 | Yield Aggregation and Vault Strategies | Pooled strategies that automate farming, lending or liquidity provision with a management or performance fee. Buyers are holders seeking passive yield. | Morpho, Yearn |
| 8-7 | Indexes and Structured Baskets | Tokenised baskets and index products offering diversified or thematic exposure with transparent methodology and fees. Buyers are investors seeking packaged exposure. | Index Coop, Phuture |
| 8-8 | Structured Products (Options & Rate Strategies) | Packaged strategies that target defined payoff or rate profiles (e.g., covered-call vaults, fixed-rate via PT/YT splits), managed on behalf of depositors for a fee. Buyers are holders seeking yield with guardrails. | Aevo, Pendle |

## Tokenised Assets

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 9-1 | Fixed Income | Issuers offer tokenised fixed income instruments, including cash management, treasury bill funds, notes, receivables, and asset-backed instruments, with defined risk and on-chain issuance, redemption, transfer, and servicing. Buyers are investors and treasuries seeking on-chain cash-like or credit yield. | Ondo Finance, BlackRock BUIDL |
| 9-2 | Commodities | Issuers of claim redeemable or custodied commodity exposure (for example, gold) on chain. Buyers are investors seeking commodities exposure with on-chain settlement. | Tether (Tether Gold), PAX Gold |
| 9-3 | Equity and Fund Shares | Issuers that bring traditional funds or equity interests on-chain as transferable claims. Buyers are investors seeking regulated fund exposure in token form. | Ondo Finance, Franklin on chain fund tokens |
| 9-4 | Real Estate | Issuers of property-backed tokens that pass through rent or sale proceeds, including fractional property vehicles. Buyers are income investors. | RealT, Tangible |
| 9-5 | Issuance and Servicing Platforms | Platforms that sell the tooling and compliance rails for RWA issuance, transfer agency and investor servicing. Buyers are asset managers and issuers. | Wormhole, Raydium |

## Consumer Platforms and Media

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 10-1 | Advertising | Platforms that sell user attention to advertisers and share value with users or publishers. Buyers are advertisers and brands purchasing targeted reach. | Brave |
| 10-2 | Fan Engagement Platforms | Systems that sell fan membership, rewards or access experiences for sports, music or creators. Buyers are clubs, leagues and creators seeking engagement and monetisation. | Chiliz, FANtium |
| 10-3 | Creator Monetisation and IP Rails | Platforms that sell issuance, licensing or revenue share primitives for creative works and IP. Buyers are creators and studios paying for monetisation, licensing, or revenue share rails. | Paragraph, Zora |
| 10-4 | Social Networks and Social Graphs | Consumer networks that sell distribution and relationship graph services to users and apps. Buyers are users and developers seeking discovery and social connections. | Lens, Farcaster |
| 10-5 | Digital Goods and NFT Marketplaces | Marketplaces that sell listing, discovery and transaction services for consumer digital goods. Buyers are creators and consumers. | OpenSea, Magic Eden |
| 10-6 | Gaming Platforms and Game Worlds | Platforms that sell distribution, asset ownership and economy tooling for games and virtual worlds. Buyers are studios and players. | Immutable, The Sandbox |
| 10-7 | Music and Media Platforms | Consumer platforms that sell distribution and monetisation for audio or video content using tokens or NFTs. Buyers are artists and fans paying for distribution, access, and monetisation. | Audius, Sound |

## Coordination and Governance

| Code | Subsector | Description | Illustrative Examples |
|---|---|---|---|
| 11-1 | DAO Frameworks | Frameworks that sell launch and operations for token or member-governed organisations, including proposal lifecycles and on-chain execution modules. Buyers are organisations launching and operating DAOs, including protocol teams, communities, and foundations. | Aragon, DAOhaus |
| 11-2 | Voting and Delegation Platforms | Front ends and contracts that sell decision throughput, recording and accountability via off-chain or on-chain voting and delegation. Buyers are DAOs and protocol communities that need voting, delegation, and accountability surfaces. | Snapshot, Tally |
| 11-3 | Grants and Public Goods Platforms | Platforms that sell programme operations for grants and retro funding, including application intake, review, matching and disbursement. Buyers are ecosystem sponsors, foundations, and communities running grant or retro funding programmes. | Gitcoin (Grants Stack), Giveth |
| 11-4 | Dispute Resolution and Arbitration | Systems that sell adjudication for on-chain disputes, curation or claims, with enforceable outcomes. Buyers are protocols, DAOs, marketplaces, and communities that need enforceable dispute resolution. | Kleros |
| 11-5 | Treasury and Access Control | Tooling that sells multi-party control of assets and programme spend, including multisigs, policy modules and automation. Buyers are organisations that need shared custody, programmable treasury execution, and policy-controlled access. | Safe |
| 11-6 | Contributor Coordination and Compensation | Platforms that sell contributor discovery, allocation and rewards for organisations. Buyers are organisations and programme operators managing contributor allocation and payments. | Coordinape, Dework |

Canonical URL: https://fundamentals.fyi/docs/subsector-catalogue

---

# System Taxonomy

The System Taxonomy provides the structural context needed to interpret a system and its token. It describes the system boundary, operating model, value creation, value capture and routing, and governance.

## Boundary

The system boundary defines what the profile is describing as the system.

In a profile, the boundary should be expressed through the **System Description**. That description should make clear what is inside the boundary, which components and participants are materially relevant to the delivery and operation of the system, and what sits outside the boundary where that exclusion matters for interpretation.

On-chain components are generally in scope. Off-chain components are included only where they are material to the delivery or access of the core service, value creation, value capture or routing, or binding decision rights over an in-boundary component.

Generic marketing sites, documentation sites, and non-exclusive community interfaces are outside the boundary by default.

Materially relevant transferable tokens other than the profiled token may be listed in **Other Tokens in the System**. This is used to capture tokens that are materially relevant to the operation, structure, or interpretation of the system as described by the boundary.

Non-transferable credits created solely by burning, locking, or converting another token are treated as mechanisms, not independent tokens for classification. Wrappers are treated as representations of the underlying token.

Canonical URL: https://fundamentals.fyi/docs/system-taxonomy

---

# System Attributes

## System Operating Model

The operating model describes how the system delivers its core service on a day-to-day basis.

| Category | Description | Illustrative Examples |
|---|---|---|
| Off-Chain Business | A system that depends on centralised entities for essential operational inputs and does not permit independent suppliers except where explicitly allowed. | Circle, Tether |
| On-Chain Protocol | A system whose economically critical coordination, measurement, and settlement are enforced on-chain, even where some work is performed off-chain by independent operators. | Bitcoin, Ethereum |
| Hybrid | A system that depends on both off-chain entities and on-chain protocol components to deliver the core service. | Binance, Optimism |

## System Value Creation

Value creation identifies where the productive activity that generates the core product or service actually occurs.

| Category | Description | Illustrative Examples |
|---|---|---|
| On-Chain Value Creation | The core product or service is generated entirely by an on-chain protocol or cryptoeconomic system. | Bitcoin, Uniswap |
| Off-Chain Value Creation | The core product or service is generated primarily by off-chain businesses or service providers. On-chain components mainly serve distribution, settlement, or accounting roles. | Nexo |
| Hybrid Value Creation | The product or service depends on a material combination of on-chain and off-chain production. | Binance, Optimism |

## System Value Capture and Routing

Value capture and routing identifies where value ends up after the service has been delivered. A system can create value in one place and capture it somewhere else.

| Category | Description | Illustrative Examples |
|---|---|---|
| On-Chain Value Capture and Routing | Value is captured or routed within the cryptoeconomic system itself or to participants within that system. | Bitcoin, Uniswap |
| Off-Chain Value Capture and Routing | Value is captured or routed to off-chain entities with privileged roles in the system. | Circle |
| Hybrid Value Capture and Routing | Value is captured through both on-chain and off-chain components. | Binance, Nexo |

## System Governance

System governance is analysed on a component basis. A governance category should reflect who holds binding decision rights over material system components.

A component is material where a unilateral change could materially affect delivery or access of the core service, monetary flows or asset balances, security assumptions or privileged actors, or user access for a material share of users.

An entity-run interface is not treated as a governed component by default. It becomes material where it is a privileged distribution channel, for example, because it controls exclusive access, has protocol-granted privilege, applies material interface fees, or can materially gate access.

Systems may exhibit multiple governance types across different components.

| Category | Description | Illustrative Examples |
|---|---|---|
| Token-Based Governance | Binding decision rights derive from ownership of freely transferable tokens. Non-binding polls or signalling do not qualify as system-level token-based governance. | Arbitrum, Aave, Uniswap |
| Participant-Based Governance | Binding decision rights are held by privileged participants who satisfy an additional role or identity condition, such as validators, sequencers, councils, or allowlisted operators. | Bitcoin nodes, Ethereum validators, Optimism Citizens' House |
| Entity-Based Governance | Binding decision rights are held by an identifiable off-chain organisation or a small group of organisations. Typical examples include Development Companies and Foundations. | Circle, Tether, Nexo |

Canonical URL: https://fundamentals.fyi/docs/system-attributes

---

# Token Functionality Framework

The **Token Functionality Framework** classifies the roles that a token plays within cryptoeconomic systems. It distinguishes between seven functionality classes: Service Provision, Governance, Value Distribution, Membership, Payments, Collateral, and Asset Ownership.

The framework operates at two layers. The first layer identifies the functionality class. The second layer identifies the specific subtype.

## Core Principles

> Only those roles that require token ownership to engage with and benefit from a system qualify as token functionalities.

**Subtypes are rights, not mechanisms**
Subtypes are defined as rights over a defined object. Mechanisms such as staking, locking, fee switches, bonding curves, and wrappers describe how a right is activated. They do not define the right itself.

**No enforceable rights, no functionality label**
Where a claimed functionality cannot be expressed as an enforceable right over a defined object, it is not treated as a functionality label.

**Derived credits are usually mechanisms, not independent tokens**
Non-transferable credits or accounting units created solely through burning, locking, or converting another token are treated as mechanisms of the originating token unless they have independent issuance and independent rights.

## Endogenous and Exogenous Functionality

**Endogenous functionality** is built into the native system by design. **Exogenous functionality** arises when a token is used by external systems or in external economic settings.

Endogenous and exogenous tagging applies at both the functionality level and the subtype level.

## Utility and Right

The framework distinguishes between utility and right, both of which fall under the broader concept of functionality. All functionality subtypes are defined in rights language. The distinction does not change that drafting convention. Rather, it indicates the economic character of the functionality: whether token ownership primarily enables use within the system, confers an entitlement or claim, or does both.

## Functionality Classes

| Functionality | Summary | Utility or Right |
|---|---|---|
| Service Provision | Right to perform work or provide resources as a supply-side participant. | Hybrid (Utility and Right) |
| Governance | Right to control or influence system decision-making. | Hybrid (Utility and Right) |
| Value Distribution | Right to receive a share of system value without meaningful ongoing service provision or risk underwriting. | Right |
| Membership | Right to access limited features or benefits by holding or locking the token. | Right |
| Payments | Right to use the token as a medium of exchange or a native fee asset. | Utility |
| Collateral | Right to pledge the token for leverage, reserve backing, underwriting, or performance bonding. | Utility |
| Asset Ownership | Right to a claim on an underlying on-chain or off-chain asset. | Right |

Canonical URL: https://fundamentals.fyi/docs/token-functionality-framework

---

# Subtype Catalogue

Each subtype identifies the specific right or service role exercised through the token.

## Service Provision Subtypes (SV-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| SV-01 | State Transition Execution and Transaction Sequencing | Right to execute deterministic state transitions and decide transaction inclusion/ordering for a block. | Ethereum (validators stake ETH, produce blocks) |
| SV-02 | Data Availability | Right to make transaction data payload available under correctness guarantees, for consumption by external execution domains. | Celestia (validators stake TIA, publish blobs) |
| SV-03 | Generalised Off-Chain Computation | Right to execute verifiable off-chain computations whose outputs are attested on-chain. | Livepeer (orchestrators stake LPT, transcode video) |
| SV-04 | Cryptographic Proof Service | Right to generate or verify cryptographic proofs whose correctness can be deterministically validated on-chain. | Succinct (provers use PROVE, generate proofs) |
| SV-05 | Distributed Oracle Service | Right to emit verifiable statements that dependent contracts treat as canonical truth. | Chainlink (operators stake LINK, report data) |
| SV-06 | Identity Attestation | Right to issue verifiable identity claims that downstream contracts accept as canonical. | No canonical live example at publication |
| SV-07 | Data Processing: Data Indexing | Right to supply on-demand access to already published data, meeting declared bandwidth or latency obligations. | The Graph (indexers stake GRT, serve queries) |
| SV-08 | Data Storage: Persistent Storage | Right to supply long-term storage capacity backed by a cryptoeconomic durability promise. | Filecoin (providers pledge FIL, store data) |
| SV-09 | Data Handling: Interoperability Relay | Right to relay messages or assets between execution domains and earn the associated fees. | Axelar (validators stake AXL, relay messages) |
| SV-10 | Data Handling: Confidentiality Relay | Right to route or transform user data so that confidentiality is preserved end-to-end within defined service level and proof requirements. | Nym (operators stake NYM, relay traffic) |
| SV-11 | Physical World Service: Geospatial Coverage Service | Right to operate verifiable physical infrastructure within a defined geographic area and earn usage/incentive fees upon confirmed on-chain validation of coverage, bandwidth, or sensor data delivery. | WeatherXM (deployers stake WXM, provide coverage) |
| SV-12 | Dispute Resolution/Arbitration | Right to resolve disputes between protocol participants or external parties. | Kleros (jurors stake PNK, resolve disputes) |
| SV-13 | Block/State Attestation | Right to attest to the validity or finality of proposed blocks or state updates by producing signatures or votes that the protocol treats as authoritative. | Stacks (signers lock STX, attest blocks) |

## Governance Subtypes (G-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| G-01 | Economic Design/Parameter Control | Right to set or amend the economic design and parameters that directly determine monetary flows, asset balances, or incentive outcomes within the system. This includes fee rates, fee routing, issuance and burn schedules, reward formulas, slashing and penalty rules, interest rate curves, collateral factors, and similar "valves on the pipes". | Aave (AAVE stakers set interest curves) |
| G-02 | Technical Parameter Control | Right to approve or implement changes to the protocol codebase, execution environment, or core technical architecture where the primary purpose is not to directly change monetary flows. This includes upgrades to consensus rules, virtual machine behaviour, cryptography, performance, security fixes, feature additions, and compatibility changes. | Cosmos Hub (ATOM votes software amendments) |
| G-03 | Process and Meta Parameter Control | Right to modify the rules that govern decision-making procedures. | Uniswap (UNI changes quorum thresholds) |
| G-04 | Treasury Control | Right to direct, invest or burn the assets held in the on-chain treasury. | Arbitrum (ARB allocates treasury grants) |
| G-05 | Actor Set Permissioning | Right to appoint, remove, or re-weight actors that perform privileged protocol roles (for example, validators, sequencers, provers, oracles) or formal governance roles (for example, councils, risk committees). This is control over who can act, not control over what actions are taken. | Optimism (OP appoints Security Council) |
| G-06 | Product/Service Line Decisions | Right to approve, veto, or direct the creation, retirement, or deployment of customer-facing products/markets (e.g., new exchange markets, chain deployments), within a declared scope. | Uniswap (UNI approves chain deployments) |
| G-07 | Whole Entity Disposition Right | Right, exercised collectively through the recognised governance process, to liquidate, transfer, or otherwise dispose of 100% of the system's assets and to receive the proceeds pro rata. | RookDAO (ROOK holders voted to dissolve) |

## Value Distribution Subtypes (VD-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| VD-01 | Direct Entitlement | Right to claim a pro rata distribution of protocol surplus reserves or revenue. | SushiBar (xSUSHI earns swap fees) |
| VD-02 | Burn Entitlement | Right to benefit from increased percentage token ownership as a result of system operations. Tokens are burned via mechanisms that consistently and permanently remove tokens. | Ethereum (base fees burn ETH) |
| VD-03 | Buyback Entitlement | Right to benefit from the redistribution of tokens acquired by the system. The benefit stems from changes in token supply dynamics and utilisation. | Frax (revenue buys back FXS) |
| VD-04 | Inflation Entitlement | Right to receive a pro rata share of newly minted units of the same token according to an issuance schedule, where receipt is not conditional on providing an ongoing service or taking on slashable performance risk. | PancakeSwap (stakers receive emitted CAKE) |
| VD-05 | Third-Party Reward Distribution | Right to receive distributions of third-party tokens or assets through a repeatable rewards programme that is conditional on holding, locking, or depositing the token, where the distributed assets are not sourced from the system's own protocol surplus and are not newly minted units of the same token. | Bitget (BGB deposits earn launchpool rewards) |

Value Distribution covers passive economic benefit. If the benefit is conditional on providing a service or assuming slashable performance risk, it should instead be classified under Service Provision or Collateral.

## Membership Subtypes (M-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| M-01 | Access Privilege | Right to enter a venue, receive a service or access a feature that is available only to token holders. | Binance Launchpad (BNB unlocks sale access) |
| M-02 | Preferential Pricing (Hold-Based) | Right to receive lower fees, rebates or cash back by meeting a token holding/locking threshold; payment currency is unrestricted. | Aave (AAVE lowers GHO borrowing rates) |
| M-03 | Usage Quota Uplift | Right to enjoy a higher usage allowance before throttling or additional payment is required. | Pocket Network (POKT staking raises API quotas) |
| M-04 | Reputation Credential | Right to carry a credential that influences voice weight or social status within the system. | Orange Protocol (reputation NFTs boost vote weight) |

## Payments Subtypes (P-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| P-01 | Native Resource Fee | Right to consume a scarce, system-controlled internal resource where access is obtained by paying a system-enforced fee that is payable in the token. | Ethereum (ETH pays gas fees) |
| P-02 | General Medium of Exchange | Right to discharge a payment obligation to a willing counterparty for goods or services, inside or outside the system. This right exists only with a willing counterparty and is not system-enforced. | Bitcoin (BTC settles merchant payments) |
| P-03 | Prepaid Credit | Right to redeem the token with the named issuer or system for a defined quantity of specified future services within a closed loop. | Internet Computer (burn ICP to mint cycles) |
| P-04 | Token-Settled Discount | Right to a reduced price only when fees are settled in the native token. | Binance (BNB lowers trading fees) |

## Collateral Subtypes (C-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| C-01 | Financial Collateral | Right to pledge the token as collateral to obtain leveraged financial exposure, subject to liquidation on adverse price movement. Loss predicate: liquidation on adverse price movement against the position. | Ethereum (ETH backs Aave loans) |
| C-02 | Stablecoin-Reserve Asset | Right to deposit the token as backing for a pegged or synthetic currency that tracks a reference asset at a fixed ratio. Loss predicate: reserve impairment or collateral price decline that forces redemption below target until recapitalised. | Ethereum (ETH backs Liquity LUSD) |
| C-03 | Risk-Underwriting Stake | Right to absorb protocol or contract risk in exchange for premium income, forfeiting the stake to cover losses if a claim event occurs. Loss predicate: claim event or protocol loss triggers the use of staked capital. | Nexus Mutual (NXM underwrites cover claims) |
| C-04 | Performance-Bond | Surety posted to guarantee honest behaviour of a delegated actor role, forfeited (slashed) on misbehaviour. Loss predicate: slashing on rule-verified misbehaviour. | Chainlink (operators stake LINK as bond) |

Collateral can support leverage, reserve backing, risk underwriting, or performance bonding. For C-01, the weak or strong label applies only to exogenous adoption measurement. Endogenous use is recorded as present without a separate strength label.

## Asset Ownership Subtypes (AO-*)

| Code | Subtype | Formal Definition | Illustrative Examples |
|---|---|---|---|
| AO-01 | On-Chain Asset Title/Pool Share | Right to redeem or exchange a pro rata claim on contract-controlled liquidity or wrapper assets. | Lido (stETH redeems for pooled ETH) |
| AO-02 | Off-Chain Asset Title/Pool Share | Right to transfer legal title or beneficial interest in a specified real-world asset that has been tokenised on-chain. | Paxos Gold (PAXG represents claim on gold) |

Canonical URL: https://fundamentals.fyi/docs/subtype-catalogue

---

# Selected Classification Notes

Service Provision excludes the penalty side of participation. Where a token both grants the right to contribute and imposes slashable performance risk, both Service Provision and Collateral may be present. If holders stake, lock, or deposit tokens only to receive distributions, without providing work or assuming slashable performance risk, the functionality is Value Distribution rather than Service Provision or Collateral.

- **SV-02 Data Availability** — assigned only where the chain or system is used as a data availability layer by other independent execution domains. A base layer does not qualify solely because it publishes its own transaction data for its own execution.
- **G-02 Technical Parameter Control** — does not cover changes whose primary purpose is to alter monetary flows. Those belong under G-01 Economic Design/Parameter Control.
- **G-06 Product/Service Line Decisions** — does not cover tuning existing parameters, risk limits, or asset whitelists for an existing product. Those belong under the relevant parameter or permissioning subtype.
- **P-02 General Medium of Exchange** — requires real counterparty acceptance. It is not inferred from market capitalisation, exchange listings, or trading volume alone.
- **VD-04 Inflation Entitlement** — applies only where newly minted units are received without ongoing service provision or slashable performance risk. Where issuance compensates validators, sequencers, or other service providers, it is classified under Service Provision and/or Collateral instead.

Canonical URL: https://fundamentals.fyi/docs/classification-notes

---

# Token Functionality Strengths

In profile pages, some functionality subtypes are shown with an additional **Strength** label that indicates the degree, quality, or mode of execution of that functionality. Other subtypes do not use a graded strength scale and are simply recorded as present where assigned.

| Applies To | Strength and Description |
|---|---|
| Governance subtypes (G-01 to G-06) | **None** - No live governance right over the relevant decision surface.<br>**Signal** - Token holders can express a preference, but the decision is not binding.<br>**Partial** - Token holders have binding control over part of the relevant decision surface, or execution depends on a constrained third party.<br>**Unilateral** - Token holders have binding control over the relevant decision surface and an execution path not subject to arbitrary refusal. |
| Value Distribution subtypes (VD-*) | **None** - No value distribution mechanism is present.<br>**One-off or Random** - A distribution occurred within the past 12 months, but is isolated or ad hoc, with no repeatable expectation. If no distribution has occurred within the past 12 months, then functionality cannot be assigned.<br>**Discretionary but Regular** - A repeatable programme exists (policy, pattern, or established practice) but can be changed or stopped at discretion.<br>**Algorithmic or Guaranteed** - Distribution is enforced by protocol code or a binding obligation and cannot be unilaterally withheld. |
| P-01 | **None** - Not present.<br>**Weak** - The native token is a non-exclusive way to access the system's resources, or only applies to a subset of the valuable resources a system provides.<br>**Strong** - The native token is the exclusive way to access all of the system's valuable resources. |
| C-01 | Scale applies to exogenous adoption measurement only.<br>**Weak** - Asset has at least $50M in cumulative collateralised TVL.<br>**Strong** - Asset has at least $500M in cumulative collateralised TVL. |
| C-02 | **Weak** - At least $50M worth of the token is underwriting stablecoins.<br>**Strong** - At least $500M worth of the token is underwriting stablecoins. |
| AO-01 | **Weak** - Redemption mechanism exists, but is delayed (> 7 days), capped, and/or depends on secondary markets or permissioned entities.<br>**Strong** - Redemption mechanism is immediate and permissionless, with low or no peg slippage risk. |
| AO-02 | **Weak** - There is some legal claim, but access to redemptions is gated and delayed. Alternatively, there is demonstrable liquidity risk on the issuer's balance sheet, or the issuer does not publicly provide proof of assets.<br>**Strong** - Underlying assets are liquid, claims are accessible with strong legal backing and precedent. |
| P-02 | **Not Have** - Real medium-of-exchange acceptance beyond speculation or non-payment use is not evidenced.<br>**Have** - There is real on-chain or off-chain counterparty acceptance for payments or settlement beyond the native chain. |

Canonical URL: https://fundamentals.fyi/docs/token-functionality-strengths

---

# PART 2: TOKEN DATA

---

## Aave (AAVE)

- **URL**: https://fundamentals.fyi/token/aave
- **System**: Aave
- **Dominant Sector**: Credit and Asset Management
- **Sectors**:
  - Credit and Asset Management (primary): Collateralised & Underwritten Lending
  - Money and Payments (secondary): Stable Value Issuers
- **System Description**: Aave is a decentralised, non-custodial liquidity market that enables overcollateralised lending and borrowing via on-chain liquidity pools, and issues the GHO stablecoin through collateral-backed minting within the same system. Founded in 2017, it operates through EVM smart contracts governed by the Aave DAO. The system boundary includes Aave markets, governance, treasury, safety backstop and GHO-related contracts and DAO processes, while excluding base chains, external oracles, and third-party interfaces.

### System Attributes
- **Operating Model**: Aave is best classified as an on-chain protocol, because the core service (lending/borrowing) is delivered by publicly accessible smart contracts deployed on permissionless blockchains rather than by an operating company. Aave also explicitly states that Aave Labs does not control or operate protocol instances.
- **Value Creation**: Aave’s value creation is on-chain, because users supply liquidity and borrow against collateral through smart-contract-defined market rules and parameters. The Protocol description emphasises overcollateralised borrowing implemented in publicly accessible smart contracts.
- **Value Capture**: Core protocol fee flows are described as accruing to the Aave DAO treasury, but Aave Labs’ interface has swap functionality powered by CoW Protocol with explicit swap fees (15/25 bps), and governance discussion indicates interface-linked fee/surplus routing is not necessarily donated to the DAO under the CoW integration.
- **Governance**: Binding decision rights over Aave markets, DAO treasury, safety backstop, and GHO-related contracts (e.g., facilitator approvals, mint caps) reside with the Aave DAO through AAVE-weighted on-chain governance (proposal → vote → timelock execution, including cross-chain payloads). DAO-mandated multisigs and steward roles (Governance/Protocol Emergency Guardians, GHO/Risk Stewards) hold narrowly defined emergency pause/veto and limited parameter-adjustment powers.

### Token Functionalities

#### Governance
- **Technical Parameter Control** [Partial]: Right to approve protocol code and technical changes via governance vote, subject to a Guardian-held veto power that can cancel approved proposals prior to execution.
- **Process and Meta Parameter Control** [Partial]: Right to modify governance process parameters (e.g., governance strategy / voting delay), but proposals remain subject to Guardian cancellation.
- **Product/Service Line Decisions** [Partial]: Right to approve the deployment and activation of new markets or chain instances within the protocol, via binding governance execution infrastructure, subject to emergency guardian veto safeguards prior to implementation.
- **Actor Set Permissioning** [Partial]: Right to appoint/remove privileged roles (e.g., stewards/guardians/committees), but governance actions remain subject to Guardian cancellation (execution refusal risk).
- **Treasury Control** [Partial]: Right to direct treasury assets via governance, but treasury operations also run through delegated committees/allowances (e.g., buyback execution), so token holders are not the only direct mover within delegated envelopes.
- **Economic Design/Parameter Control** [Partial]: Right to vote on changes to protocol economic parameters (e.g., risk/interest/fee parameters), but some parameter spaces are delegated to stewards within bounds.

#### Collateral
- **Risk-Underwriting Stake**: Right to post AAVE as slashable backstop capital underwriting protocol deficits, bearing governance-defined slashing caps and earning safety incentives, with enforcement through on-chain deficit coverage and slashing mechanics.
- **Financial Collateral**: Right to post AAVE as recognised collateral within the protocol’s lending markets, enabling borrowing subject to governance-set risk parameters and enforced through on-chain liquidation mechanics.

#### Value Distribution
- **Buyback Entitlement** [Discretionary but Regular]: Right to benefit from redistribution of tokens acquired by the system via a repeatable DAO-directed AAVE buyback programme (buybacks can be changed/stopped by governance).

#### Membership
- **Preferential Pricing (Hold-Based)**: Right to obtain reduced GHO borrowing rates by staking AAVE, subject to governance-defined eligibility criteria and rate parameters enforced within the protocol’s interest rate logic.

---

## Arbitrum (ARB)

- **URL**: https://fundamentals.fyi/token/arbitrum
- **System**: Arbitrum
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L2 Blockchain, Chains-as-a-Service (Rollups & Appchains)
- **System Description**: Arbitrum is an Ethereum-based Layer 2 system comprising Arbitrum of One, an Ethereum Layer 2 rollup, and Arbitrum Nova, an optimised high-throughput blockchain, along with Arbitrum Orbit, a framework that enables teams to launch custom blockchains with varying features and integration with the Arbitrum System. Founded in 2018 by Offchain Labs, Arbitrum uses the Nitro rollup framework, and both One and Nova use ETH for transaction fees. The system boundary includes the Arbitrum rollup blockchain contracts on Ethereum, the Arbitrum DAO governance contracts and treasury, the Security Council multisig, the foundation, and Offchain Labs as a supporting off-chain entity, while excluding Ethereum, independent Orbit chains unless directly governed by the DAO.

### System Attributes
- **Operating Model**: Arbitrum's One/Nova services are delivered via Ethereum-secured on-chain rollup contracts that enforce settlement, bridging, and fee accounting, but production of the service currently depends on a centralised off-chain operator; a single sequencer for both Arbitrum One and Nova is operated and maintained by off-chain corporate entities. Rollout of Orbit instances further adds an off-chain, programmatic/licensing layer (AEP, Rollup-as-a-service) to system operations that requires Arbitrum off-chain entities to enable others to deploy blockchain infrastructure, which is intentionally operated externally to the Arbitrum system.
- **Value Creation**: Value is created by selling Ethereum-compatible Layer 2 blockspace to applications and users seeking lower-cost and higher-throughput execution on Arbitrum One, as well as benefiting from other systems that deploy blockchain infrastructure as Arbitrum Orbits. The Arbitrum One blockspace with Ethereum assurances is produced through a combination of on-chain and off-chain components. Rollup contracts on Ethereum enforce state validity, dispute resolution, and final settlement, while transaction ordering, batching, and data coordination are performed off-chain by the sequencer of Arbitrum One and, in the case of Arbitrum Nova, a Data Availability Committee.
- **Value Capture**: Transaction fees are paid in ETH for execution on Arbitrum One and Nova. Fees accrue off-chain and are discretionarily distributed to Arbitrum's on-chain DAO treasury after reimbursing sequencer operator operational expenses and Ethereum posting costs. In addition, under the Arbitrum Expansion Program, certain Orbit chains may route a contractual share of profits to the DAO through an on-chain fee router.
- **Governance**: Governance authority is distributed across: (i) the ARB token DAO, which governs the DAO-owned chains and treasury; (ii) a Security Council (multi-sig) with emergency authority delegated by the constitution of the DAO; and (iii) the Arbitrum Foundation that administers programs (e.g., Orbit/AEP), budgets, and maintains/operates critical infrastructure (e.g., sequencer). Arbitrum has a mixed governance structure the independently handle important system wide decisions that span on-chain and off-chain actors. When the DAO approves economic changes, implementation depends on executor entities operating within predefined mandates and technical constraints.

### Token Functionalities

#### Governance
- **Product/Service Line Decisions** [Partial]: Right to govern product-level decisions (e.g., adopting Timeboost ordering), and can approve new service-line actions via proposals (e.g., deploying additional DAO-governed chain); scope and process of proposals are defined by the Arbitrum Constitution and bylaws.
- **Actor Set Permissioning** [Partial]: Right to appoint/remove privileged actors, primarily the Security Council who hold multisig authority over emergency switches, and governance power over key operator sets like sequencer selection and Nova DAC membership/powers. The Security Council itself can also remove a member by an internal 9-of-12 vote and Arbitrum Foundation gates who can enter the election by means of compliance requirements.
- **Technical Parameter Control** [Partial]: Right to vote/delegate on-chain to enact changes to DAO‑governed chains (including changes implemented via smart contract upgrades), recognising some actions are off-chain operational tasks.
- **Economic Design/Parameter Control** [Partial]: Right to set or amend economic parameters that directly change monetary flows in DAO‑governed chains (e.g., ARB supply increases within defined limits; protocol fee distribution parameters where changeable by DAO proposals). When the DAO approves economic changes, implementation depends on executor entities operating within predefined mandates and technical constraints.
- **Treasury Control** [Partial]: Right to govern Arbitrum DAO treasury, and able to make decisions on allocations and distributions of assets.

---

## Avalanche (AVAX)

- **URL**: https://fundamentals.fyi/token/avalanche-2
- **System**: Avalanche
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Avalanche is a proof of stake smart contract platform providing decentralised computation and transaction inclusion for application teams and end users deploying and interacting with on-chain applications. Founded in 2020, it operates using Avalanche consensus (Snowman++), the AvalancheGo client, and its Primary Network comprising the P-Chain, C-Chain, and X-Chain. The system boundary includes the Primary Network validator set and the AVAX token, while excluding application-level protocols and independent Avalanche L1s or Subnets.

### System Attributes
- **Operating Model**: Avalanche coordinates a permissionless set of independent validators to provide blockspace, with day-to-day block production and validation carried out by node operators staking AVAX. Validators run AvalancheGo and stake on the P-Chain, which entitles them to participate in consensus across the Primary Network.
- **Value Creation**: Avalanche’s core product is transaction execution and inclusion, delivered through validator participation in consensus and block production across the network’s chains. Validators secure the network by creating new blocks and processing transactions as part of this consensus process.
- **Value Capture**: Avalanche handles economic flows natively at the protocol level, with transaction fees paid in AVAX and burned, directly reducing token supply. Validator compensation is provided through staking rewards, paid to designated reward addresses and, where applicable, shared with delegators at the end of staking terms if protocol conditions are satisfied.
- **Governance**: Protocol upgrades and economic parameter changes operate through participant-based governance, with binding authority resting on validators adopting compatible client releases. Validator voting weight is determined through token-based governance via stake and delegation, while validator admission is participant-based through permissionless operator entry subject to staking requirements. The ACP process describes activation through client releases and validator adoption of updated software.

### Token Functionalities

#### Governance
- **Actor Set Permissioning** [Unilateral]: Right to re-weight validator influence by delegating AVAX stake to a chosen validator, where validator consensus weight explicitly includes delegated stake. This weighting right is protocol-enforced and does not rely on any discretionary executor, allowing token holders to bindingly influence validator power through delegation.
- **Technical Parameter Control** [Partial]: Right, as a Primary Network node operator or validator, staking AVAX, to influence bounded technical parameters and implement protocol-level technical changes, including voting on the target minimum block time enforced by the proposerVM on the C-Chain through configuration settings, and more broadly by adopting technical upgrades through running compatible client software.
- **Economic Design/Parameter Control** [Partial]: Right (as a Primary Network validator, staking AVAX) to approve/implement changes to Avalanche’s economic design parameters (e.g., fee mechanism parameters, issuance/reward rules, staking-parameter rules) by adopting compatible client releases that activate protocol changes.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased percentage token ownership as a result of system operations burning AVAX fees and permanently removing supply.

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to validate the Primary Network as a validator that creates blocks and processes transactions, with transaction ordering on the C-Chain determined first by priority fee and then by timestamp. Compensation is provided via staking rewards in AVAX to validators and, through delegation, to delegators, conditional on meeting responsiveness and uptime requirements; delegation is supported subject to a minimum stake and a validator-set delegation fee rate that takes a portion of delegator rewards.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay for Avalanche Primary Network transaction execution/inclusion via protocol fees denominated in AVAX.
- **General Medium of Exchange** (Exogenous): Right to discharge payment obligations to willing counterparties for goods/services (e.g., NFTs) in external marketplace contexts where listings are denominated in AVAX.

#### Collateral
- **Financial Collateral** [Strong] (Exogenous): AVAX used as collateral on lending protocols (Aave, Benqi)

---

## Basic Attention (BAT)

- **URL**: https://fundamentals.fyi/token/basic-attention-token
- **System**: Brave
- **Dominant Sector**: Consumer Platforms and Media
- **Sectors**:
  - Consumer Platforms and Media (primary): Advertising
- **System Description**: Brave operates a privacy-preserving digital advertising system integrated directly into its web browser, where advertisers run campaigns to opted-in users and users and creators earn rewards for attention. Founded in 2015, it combines Chromium-based browser software with an off-chain advertising and rewards platform and token settlement on Ethereum. The system boundary includes the Brave Browser, Brave Ads, Rewards and Creators programmes, billing infrastructure, and settlement in BAT, USDC, and USDT, while excluding exchanges and DeFi protocols.

### System Attributes
- **Operating Model**: Brave Ads/Rewards are delivered through a centrally operated browser and advertising stack, requiring ongoing operational input (product development, ad sales tooling, billing, programme rules).
- **Value Creation**: The economically valuable “product” is ad attention and campaign delivery, created by off-chain components (browser distribution, ad matching/delivery).
- **Value Capture**: Value is captured via advertiser payments that can occur off-chain (credit card via Stripe) or via on-chain crypto prepay on Ethereum; value is then routed into BAT-based payouts/contributions within Rewards, alongside Brave’s stated fee capture on wallet transactions and creator tips.
- **Governance**: The binding authority over Brave Browser, Brave Ads, and Brave Rewards rules is held by the operating entity; token-holder governance is not evidenced as a binding control layer for these components.

### Token Functionalities

#### Payments
- **General Medium of Exchange**: Right to use BAT as a medium of exchange with willing counterparties inside the Brave Ads/Rewards economy, including paying for Brave Ads inventory via crypto prepay and transferring value to creators via Rewards.

---

## Bitget Token (BGB)

- **URL**: https://fundamentals.fyi/token/bitget-token
- **System**: Bitget
- **Dominant Sector**: Trading and Exchange
- **Sectors**:
  - Trading and Exchange (primary): Centralised Exchange
  - Blockspace Production (secondary): L2 Blockchain
- **System Description**: Bitget provides centralised and on-chain crypto trading, custody, and settlement services, serving retail and institutional users via custodial exchange accounts, a non-custodial wallet, and optional Layer 2 activity through Morph, which uses ETH as the default network currency for transfers and gas. Founded in 2018, it operates centralised exchange infrastructure alongside a wallet services layer and an optimistic zkEVM Ethereum Layer 2 stack; the system boundary includes the Bitget CEX, Bitget Wallet client and services, and the Morph L2 protocol and operator infrastructure, while excluding unrelated third-party chains and decentralised applications accessed via the platform.

### System Attributes
- **Operating Model**: Bitget is best classified as a hybrid system, combining a centrally operated exchange and wallet business with a Bitget-aligned on-chain Layer 2 protocol, Morph. Both the off-chain components, comprising the CEX and wallet services, and the on-chain Morph protocol fall within the system boundary due to explicit corporate ownership and partnership positioning, as well as cryptoeconomic integration. Bitget is the controlling stakeholder of Bitget Wallet’s predecessor, BitKeep, and publicly positions Morph as a core settlement and roadmap component of its platform.
- **Value Creation**: Bitget exhibits hybrid value creation, generating value off-chain through centralised exchange execution, custody, and wallet user experience, and on-chain through access to an EVM-compatible Layer 2 environment. The Morph L2 is positioned as an optimistic zkEVM that is fully EVM compatible, enabling Ethereum-style deployments for payments and consumer finance-oriented applications, and extending Bitget’s product stack beyond pure off-chain services.
- **Value Capture**: Bitget captures value off-chain through its centrally operated custodial platform, where trading fees and other monetisation accrue to the operating entity. Value is routed on-chain to token holders via recurring burns of BGB, which reduce circulating supply through publicly verifiable burn transactions on Ethereum.
- **Governance**: Binding decision rights over system behaviour sit with the operating entity across the CEX, wallet services, and the Bitget-aligned stack. Any BGB-holder “governance” referenced for burn approvals functions as a non-binding signalling process rather than a protocol-enforced control mechanism, so it does not qualify as token-based governance.

### Token Functionalities

#### Value Distribution
- **Third-Party Reward Distribution** [Discretionary but Regular]: Right to receive distributions of third-party tokens through repeatable Launchpool-style programmes by staking BGB as an eligible asset on Bitget. Launchpool documentation describes earning airdropped tokens by staking BGB, alongside other designated tokens, under programme-specific terms.
- **Burn Entitlement** [Discretionary but Regular]: Right to benefit from increased percentage token ownership due to a repeatable BGB burn programme that permanently removes supply.

#### Governance
- **Economic Design/Parameter Control** [Signal]: Right to vote on approving quarterly BGB burn decisions within Morph’s governance process, on a one-BGB-one-vote basis. Approval is described as required, but execution of burns remains with the system or foundation.
- **Product/Service Line Decisions** [Signal]: Right to express directional preferences on exchange product decisions within a declared scope, such as token listings, via BGB-holder voting mechanisms (for example “Vote to List”). These processes use BGB as an input for signalling user preferences to Bitget, but do not constitute binding, protocol-enforced governance.

#### Payments
- **Token-Settled Discount**: Right to a reduced price only when spot (and spot margin) trading fees are settled in BGB (fee deduction feature). This is in addition to the membership-based preferential pricing functionality.
- **General Medium of Exchange**: Right to pay a willing counterparty for services inside the Bitget Wallet using BGB (e.g., gas-fee services via GetGas).

#### Collateral
- **Financial Collateral**: Right to post BGB as recognised collateral within the platform’s unified and cross-asset margin framework, including USDT-M futures, subject to platform-defined collateral parameters and enforced through account-level margining and liquidation mechanics.

#### Membership
- **Usage Quota Uplift**: Right to higher platform usage allowances (e.g., withdrawal limits; copy‑trading capacity access) conditional on meeting BGB holding thresholds.
- **Preferential Pricing (Hold-Based)**: Right to qualify for lower fee tiers / VIP fee schedules based (in part) on BGB holdings (payment currency unrestricted).
- **Access Privilege**: Right to participate in Launchpad IEO access mechanics (lottery tickets / participation eligibility) conditional on holding BGB.

---

## BNB (BNB)

- **URL**: https://fundamentals.fyi/token/binancecoin
- **System**: Binance
- **Dominant Sector**: Trading and Exchange
- **Sectors**:
  - Trading and Exchange (primary): Centralised Exchange, Token Launchpads and Primary Distribution
  - Blockspace Production (secondary): L1 Blockchain
- **System Description**: Binance provides a hybrid cryptoasset trading and execution system, combining a centralised exchange with an EVM-compatible L1 blockchain, enabling users, issuers, and application teams to trade assets, access custodial services, and execute smart contracts. Founded in 2017, it operates through a centralised exchange stack and the BNB Smart Chain, which uses Proof of Staked Authority (PoSA) consensus, an account-based EVM environment, and native BNB-denominated fees with protocol-level burn mechanisms, with BNB integrated across fees, access, incentives, and coordination. The system boundary includes the Binance Exchange’s custodial trading and matching infrastructure, the BNB token and Binance equity, and the BNB Chain validator set, staking, governance, and fee economics; it excludes independently issued third-party tokens and dApps that merely deploy on BNB Chain, reflecting a tightly coupled and analytically complex system rather than a cleanly separable protocol.

### System Attributes
- **Operating Model**: Binance.com, the centralized exchange, represents the economically dominant product surface area (spot/derivatives trading, custody, listings, distribution, compliance operations) is operated by an off-chain firm, while a meaningful second pillar (BNB Chain) is an on-chain protocol with open developer access and a delegated validator set. This hybrid structure matters because key decisions that move the “Binance” product (market listings, product bundling, incentives, jurisdictional strategy) remain corporate/centralised, while BNB Chain’s execution environment (transactions, smart contracts, on-chain fees) is protocolized and measurable on-chain, but highly reliant on the efforts of the off-chain organisation.
- **Value Creation**: Value is created off-chain through Binance’s operation of a centralised marketplace that concentrates liquidity, price discovery, and distribution across spot and derivatives markets, packaging this liquidity into a broad product suite including trading, margin, earn programmes, launch platforms, and custody and payment rails. On-chain, value is created through BNB Chain’s provision of blockspace to users and developers, where a staked validator set and protocol-level fee metering convert compute, storage, and throughput into a commoditised execution service; the surrounding ecosystem of tooling, dApps, bridges, and scaling or storage components expands functionality and drives activity, reinforcing network effects as increased usage attracts more developers, applications, and demand for the network’s native rails.
- **Value Capture**: Value is captured off-chain primarily as platform revenue generated by Binance’s trading and related services, with fee streams routed internally by the operating entity; at the same time, BNB-linked fee incentives (such as paying fees in BNB for discounts) redirect a portion of economic benefit to token users through reduced costs while preserving the company’s core revenue base. On-chain, value is captured through BNB-denominated transaction fees on BNB Chain, which are distributed to validators for block production, with a portion of gas fees burned in real time under BEP-95 and additional supply reductions executed through the formula-based, auditable BNB Auto-Burn mechanism; net effect, on-chain activity routes value to validators and delegators as operators and to a burn sink that increases token scarcity rather than distributing explicit cashflows to holders.
- **Governance**: Exchange product rules, listings, and BNB-linked programme parameters are entity-governed by Binance, with binding decisions controlled by the operating company across its exchange stack and commercial products. In parallel, BNB Smart Chain incorporates token-based governance, where staking credit holders can propose, vote on, and execute defined on-chain actions through a Governor and Timelock framework, including parameter adjustments and certain system contract changes. At the infrastructure layer, block production and software upgrade coordination remain participant-based, as validators operate the network, adopt client updates, and enforce consensus rules in practice. The result is a layered governance structure that combines entity control over business operations, token-based governance over specified protocol parameters, and validator-based coordination for network execution and upgrades.

### Token Functionalities

#### Governance
- **Economic Design/Parameter Control** [Partial]: Right to set or amend protocol economic “valves” that determine monetary flows (e.g., fee routing/burn ratios) via the BNB Chain governance process, but only across the subset of economic parameters exposed to and enforceable by on-chain governance; broader economic design changes that require validator software upgrades are outside unilateral token control.
- **Technical Parameter Control** [Partial]: Right to approve and execute limited technical parameter changes (within the scope of system contracts/governed modules) via on-chain governance; protocol upgrades that depend on validators upgrading software remain only partially controlled by token governance.
- **Actor Set Permissioning** [Partial]: Right to re-weight which validators enter and remain in the active validator set by staking/delegating BNB (stake-weighted selection), with binding effect only within protocol-defined constraints (e.g., active-set caps and any safety/blacklisting controls), rather than a free-form right to appoint/remove any arbitrary actor.
- **Process and Meta Parameter Control** [Partial]: Right to modify governance process parameters (e.g., thresholds/timelock/quorum within the governance module) where such parameters are themselves configurable by governance.

#### Collateral
- **Financial Collateral**: Right to use BNB as margin on Binance exchange for derivatives trading.
- **Financial Collateral** [Strong] (Exogenous): Right to use BNB as collateral on lending applications on BNB chain.
- **Performance-Bond**: Right to provide BNB as collateral to secure BNB chain. Validators that participate in block production are required to expose staked BNB as slashable collateral to prevent validator misconduct.

#### Value Distribution
- **Burn Entitlement** [Discretionary but Regular]: Right to benefit pro rata from a reduction in circulating BNB supply as the protocol automatically burns a defined portion of transaction fees per block under BEP-95, increasing each remaining holder’s proportional share over time.


Right to benefit pro rata from reductions in circulating BNB supply when the corporate entity conducts quarterly, discretionary buyback-and-burn events funded from profits, increasing each holder’s proportional share of total supply.

#### Membership
- **Access Privilege**: Right to access VIP benefits on Binance Exchange, which have historically included access to exclusive token sales and eligibility for airdrops from projects that on Binance launchpad.
- **Preferential Pricing (Hold-Based)**: Right to discounted trading fees on the Binance exchange for holding BNB, determined by ownership tiers. This membership benefit is distinct from fee discounts obtained by spending BNB to pay trading fees.

#### Payments
- **General Medium of Exchange** (Exogenous): Right to trade on BNB Chain-based decentralized exchanges with BNB where BNB is the quote asset in the trading pair.
- **Token-Settled Discount**: Right to pay reduced trading fees for traders on the Binance exchange when fees are settled in BNB. (e.g., up to 25% for spot and 10% for futures).
- **Native Resource Fee** [Strong]: Right to pay transaction processing fees on BNB blockchain exclusively in BNB. All users and applications that access execution and settlements have to submit transactions to network of validators.

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to stake BNB to contribute in block production service, with a maximum of 21/45 active validator set determined by the largest stake; stake delegation enabled.

---

## BTC (BTC)

- **URL**: https://fundamentals.fyi/token/bitcoin
- **System**: Bitcoin
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Payment and Settlement Networks
  - Blockspace Production (secondary): L1 Blockchain
- **System Description**: Bitcoin provides a permissionless peer-to-peer payment and final settlement network, enabling users and merchants to settle payments and transfers using on-chain BTC transactions. Founded in 2009, it uses Proof-of-Work (SHA-256) consensus with Nakamoto consensus, a UTXO-based ledger, and a peer-to-peer networking model, probabilistic finality, and a fixed-supply BTC issuance schedule with quadrennial halvings. The system boundary includes Bitcoin mainnet consensus rules, nodes, miners, and Bitcoin Core client software, and excludes Lightning Network, and other L2, extensions and third-party wrapped BTC tokens.

### System Attributes
- **Operating Model**: Bitcoin is a system where core rules are executed and enforced on-chain by consensus, where users submit transactions directly to a public mempool and the protocol’s hardware operators (miners and full nodes) validate, order, and finalize state transitions. Access is permissionless; the scarce resource is blockspace, paid for with the native token (BTC) via protocol-defined fees. State is replicated across nodes and settlement is achieved through the chain’s consensus (probabilistic finality under PoW). Upgrades occur via client software releases adopted by independent node operators; there is no centralized operator providing the core service.
- **Value Creation**: The Bitcoin blockchain exclusively creates value on-chain by providing censorship-resistant settlement and a native bearer asset (BTC) transferable via transactions recorded on the Bitcoin blockchain.
- **Value Capture**: Value is captured through block rewards (issuance) and transaction fees, and routed primarily to miners/mining pools who successfully mine blocks and include transactions.
- **Governance**: Governance is primarily participant-based: changes to consensus rules are effectuated through software adoption by network participants (not by BTC-holder voting).

### Token Functionalities

#### Collateral
- **Financial Collateral** [Strong] (Exogenous): Right to use BTC in DeFi applications in external systems as financial collateral. There is an extensive usage of wrapped BTC in other L1 or L2 systems.
- **Performance-Bond** (Exogenous): Right to stake BTC in certain restaking protocols built as L2 systems on Bitcoin. For example right to lock BTC in a Babylon-recognised staking script and delegate it to a Babylon Finality Provider, with the stake subject to protocol-defined slashing (burn) if the delegated Finality Provider double-signs.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay BTC-denominated transaction fees to consume Bitcoin blockspace.
- **General Medium of Exchange** (Exogenous): Right to discharge a payment obligation to a willing counterparty for goods or services outside the system. This right exists only with a willing counterparty and is not system-enforced or regulatory-enforced. Right to trade on centralised exchanges with BTC where BTC is the quote asset in the trading pair.

#### Service Provision
- **State Transition Execution and Transaction Sequencing** (Exogenous): Stacks’ consensus design lets participants use BTC as the work input to perform an external network role (block-production competition). In practice, a participant commits/spends BTC per Stacks’ rules in order to compete for block selection and earn Stacks-native rewards.

---

## Cardano (ADA)

- **URL**: https://fundamentals.fyi/token/cardano
- **System**: Cardano
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Cardano provides a permissionless layer-1 blockchain for transaction settlement and smart-contract execution, enabling users and developers to transfer value and deploy decentralised applications via on-chain transactions priced in ADA. Founded in 2017, it uses Proof-of-Stake (Ouroboros) with an extended-UTXO ledger, epoch-based block production by independent stake pools, and protocol-defined fees and issuance. The system boundary includes the Cardano mainnet protocol and ledger, stake pools and delegators, ADA as the native asset, on-chain fees, rewards, treasury and governance framework, and open-source node software; it excludes application-layer protocols, L2s, sidechains, bridges, and wrapped representations of ADA as separate systems.

### System Attributes
- **Operating Model**: Cardano operates as an on-chain protocol that coordinates a decentralised set of independent stake pool operators to produce blocks, validate transactions, and maintain the Cardano blockchain. Participation in block production is permissionless and governed by protocol rules rather than a central operating entity.
- **Value Creation**: The productive activity that generates Cardano’s core service is block production, transaction sequencing, and ledger state transitions and occurs entirely within the decentralised node network. Independent stake pool operators execute these functions on-chain under cryptoeconomic incentives defined by the protocol.
- **Value Capture**: Value captured through transaction fees and protocol-defined monetary issuance is algorithmically routed to validators (SPOs) and their delegators (ADA holders) as compensation for their operational and security services. Additionally, 20% of rewards are routed to the on-chain treasury to fund future ecosystem growth.
- **Governance**: Cardano’s governance combines token-based and participant-based structures, with ADA holders participating directly or via delegated representatives (DReps) in voting on governance actions. Governance decisions also involve defined participant roles, including stake pool operators and a constitutional committee, depending on the scope of the action

### Token Functionalities

#### Governance
- **Process and Meta Parameter Control** [Partial]: Right to modify governance process rules through constitutional or proposal policy updates, ratified by a majority of DReps and the Constitutional Committee and recorded on-chain, making the outcome binding but not unilateral for ADA-weighted governance due to the required co-approval.
- **Treasury Control** [Partial]: Right to participate in Project Catalyst as a voter or proposer.
- **Technical Parameter Control** [Partial]: Right to approve or reject protocol upgrades and hard forks through Hard-Fork Initiation governance actions, which trigger non-backwards compatible upgrades and require prior software updates. Ratification requires majority approval from all three governance bodies, namely SPOs, DReps and the Constitutional Committee, with execution ultimately dependent on SPOs upgrading node software.
- **Actor Set Permissioning** [Partial]: Right to appoint or re-weight a Delegated Representative to vote on behalf of a stake credential through a vote delegation certificate, thereby granting that representative authority to exercise voting power on the holder’s behalf. Partial since token holders don't have full authority over SPO roles or Constitutional Committee memberships.   
- **Economic Design/Parameter Control** [Partial]: Right to approve or reject changes to economic protocol parameters through Protocol Parameter Change actions, requiring majority approval from DReps and the Constitutional Committee, and, for security-sensitive parameters, Stake Pool Operator approval. The DRep role is permissionless but role-gated, and most such actions require two of the three governance bodies to ratify.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay gas fees for transaction inclusion in the Cardano blockchain. 

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to execute deterministic state transitions and decide transaction inclusion by operating a stake pool, conditional on controlling delegated ADA stake.

---

## Celestia (TIA)

- **URL**: https://fundamentals.fyi/token/celestia
- **System**: Celestia
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): Specialised Data Availability Layers
- **System Description**: Celestia provides a permissionless, specialised data availability blockchain that orders and publishes blob data for external execution environments, with rollups and app-chains purchasing blobspace via on-chain transactions paid in TIA, which also secures the network through staking. Founded in 2019, it is built with the Cosmos SDK and CometBFT, and the system boundary includes the Celestia mainnet, PayForBlob transactions, staking and slashing mechanisms, governance and community pool, the open-source celestia-node software, and the Celestia Foundation, while excluding downstream rollups, application teams, and third-party bridges or wrapped representations of TIA.

### System Attributes
- **Operating Model**: Celestia provides a specialised data availability blockchain that orders and publishes blobs for external execution domains. Rollups and other execution domains purchase blobspace to publish transaction data to Celestia to access Celestia's trust guarantees. Founded in 2019, it is built with the Cosmos SDK and CometBFT and uses data availability sampling. The system boundary includes the Celestia blockchain, TIA for fees, staking and governance, the celestia-node software, the Celestia Foundation, and Celestia Labs, while excluding downstream rollups and third-party bridges.
- **Value Creation**: The system’s core economic output, ordering transactions and guaranteeing the availability of posted blob data, is produced directly by the on-chain protocol and its open validator set operating the Celestia blockchain software. Validators stake TIA, produce blocks, and ensure that blob data is correctly ordered and made available for external execution domains such as rollups and blockchains.
- **Value Capture**: Users pay transaction/blob fees denominated in TIA, received by validators; inflationary block rewards are paid to validators/delegators and a defined share is routed to the community pool.
- **Governance**: Protocol upgrades and hard forks are determined by validators through software adoption, making validator participation the decisive authority for core changes. In parallel, token-based on-chain governance allows staked and delegated TIA holders to modify a defined subset of economic, technical, and governance process parameters and to authorise spending from the on-chain community pool. Validator membership is participant-based, while validator voting power is continuously reweighted through token staking and delegation.

### Token Functionalities

#### Payments
- **Native Resource Fee** [Strong]: Right to consume Celestia blockspace and blobspace by paying compulsory transaction fees denominated in TIA, including PayForBlob transactions. Current fee levels are low and primarily function as spam resistance rather than revenue generation.
- **Native Resource Fee** [Weak] (Exogenous): Right to pay transaction processing fees on certain execution systems (e.g. external blockchains) that use Celestia's data availability services, examples include Forma and Flame who both use TIA as their native gas token by which transaction fees are paid for.

#### Governance
- **Actor Set Permissioning** [Unilateral]: Right to re-weight Celestia consensus validators’ voting power (and therefore influence active validator set composition within the set limit) by delegating or undelegating staked TIA.
- **Process and Meta Parameter Control** [Partial]: Right to modify on-chain governance process parameters (e.g., quorum/threshold) via governance; however, key process surfaces (e.g., upgrade path) are described as off-chain/social, limiting scope.
- **Technical Parameter Control** [Partial]: Right to approve changes to a defined subset of protocol technical parameters, while major protocol upgrades require validator software adoption through off-chain social consensus.
- **Treasury Control** [Unilateral]: Right to direct spending of the on-chain community pool (treasury) via governance proposals voted by TIA stakers. (Note: Community pool does not include foundation treasury.)
- **Economic Design/Parameter Control** [Partial]: Right to approve changes to a defined subset of economic parameters that determine monetary flows and incentive design, including staking and slashing parameters, through on-chain governance by TIA stakers, while other core economic surfaces such as certain mint parameters remain hardcoded and outside governance control.

#### Collateral
- **Performance-Bond**: Right to stake TIA as a slashable performance bond to secure the Celestia network by participating directly as a validator or by delegating stake to a validator, with staked TIA subject to protocol-enforced slashing or jailing in the event of defined misbehaviour such as double-signing or extended downtime, thereby underwriting the network’s security and liveness.

#### Value Distribution
- **Third-Party Reward Distribution** [One-off or Random] (Exogenous): External execution systems and ecosystem projects that use Celestia for data availability have, at times, distributed tokens to cohorts defined by TIA holding or staking. These distributions are not guaranteed, are not recurring by default, and are not enforced by the Celestia protocol.

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to execute Celestia state transitions and decide transaction inclusion/ordering as a validator by staking TIA.
- **Data Availability**: Right to make transaction data payload available under correctness guarantees for consumption by external execution domains, by operating a validator secured by staked TIA.

---

## Chainlink (LINK)

- **URL**: https://fundamentals.fyi/token/chainlink
- **System**: Chainlink
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Verifiable Randomness and Functions, External Data Oracles, Off-Chain Compute
  - Interoperability and Messaging (secondary): General Messaging Layers
- **System Description**: Chainlink is an oracle and cross-chain messaging middleware that supplies external data, randomness, and automated execution to smart contracts. Founded in 2017, smart-contract teams consume Chainlink services such as price feeds, VRF, automation, and CCIP via on-chain oracle, billing, and staking contracts coordinated with off-chain reporting nodes operated by independent providers. The system boundary includes the LINK token, oracle feeds, VRF, automation, CCIP, staking and rewards mechanisms, and node software, while excluding client applications and external data sources.

### System Attributes
- **Operating Model**: Chainlink’s services rely on on-chain contracts and off-chain DON execution by node operators, while privileged operational input also exists off-chain (e.g., multisig signer administration selected from node operators and Chainlink Labs).
- **Value Creation**: The economically valuable outputs (price updates, randomness/functions, cross-domain delivery) are produced by off-chain node execution and reporting, then finalised/consumed via on-chain contracts.
- **Value Capture**: Oracle providers (node operators) capture value directly as paid service providers (fees paid to node operators), while Chainlink also describes off-chain enterprise revenue and on-chain service usage being converted into LINK and accumulated in an on-chain Reserve.
- **Governance**: Chainlink documentation describes key contract ownership/admin as a multisig Safe, and Chainlink states multisig signers are selected from node operators (participants by role/identity) and Chainlink Labs (corporate entity), meaning authority is grounded in operator/corporate identity rather than LINK holdings; signer identities are not publicly disclosed.

### Token Functionalities

#### Collateral
- **Financial Collateral** [Weak] (Exogenous): LINK used as collateral on lending protocols (Aave, Compound, Venus)
- **Performance-Bond**: Right to post LINK as a performance bond (for node-operator staking) that can be slashed under defined conditions tied to oracle performance/security.

#### Service Provision
- **Distributed Oracle Service**: Right to provide distributed oracle services (as a node operator) that deliver verifiable statements to on-chain consumers is gated by, where node-operator participation can be tied to oracle services secured by staking LINK.

#### Value Distribution
- **Buyback Entitlement** [Discretionary but Regular]: Right to benefit from systematic acquisition and sequestering of LINK by the Chainlink Reserve, funded by on-chain and off-chain service revenue converted into LINK via Payment Abstraction.

#### Payments
- **Native Resource Fee** [Weak]: Right to pay for Chainlink services by paying in LINK (or via mechanisms that settle service payments into LINK), where LINK payment is not strictly exclusive across all services.

---

## Chiliz (CHZ)

- **URL**: https://fundamentals.fyi/token/chiliz
- **System**: Chiliz
- **Dominant Sector**: Consumer Platforms and Media
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
  - Consumer Platforms and Media (primary): Fan Engagement Platforms
- **System Description**: Chiliz operates a sports-fan engagement platform that enables clubs to issue Fan Tokens and supporters to participate in tokenised memberships, voting, and reward experiences, primarily via the Socios app. Founded in 2018, the system combines an EVM-compatible Layer 1, Chiliz Chain, where CHZ is used for execution and gas, with off-chain application and wallet infrastructure. The system boundary includes Chiliz Chain execution, validator onboarding, and Socios app operations, while excluding external exchanges and non-controlled third-party dApps.

### System Attributes
- **Operating Model**: Chiliz operates as an off-chain business tightly coupled to an on-chain protocol. Day-to-day service delivery depends on the Socios consumer app and commercial partnerships, while transaction execution and settlement occur on Chiliz Chain using CHZ for gas. Validator participation is subject to verification and staking requirements administered by Chiliz Labs, reinforcing the role of off-chain operational control.
- **Value Creation**: Core user value in the Chiliz system is created through off-chain fan engagement experiences and branded utility, with on-chain infrastructure used to create, hold, and transfer tokenised assets. The consumer experience is primarily delivered via the Socios app, while Chiliz Chain provides the execution and settlement layer that underpins Fan Token ownership and transactions.
- **Value Capture**: On-chain, value is captured and routed via CHZ-denominated gas and issuance mechanics, including an EIP-1559-style base fee burn, validator and delegator rewards, and predefined allocations to network reinvestment buckets such as community incentives and ecosystem and operational funds. Off-chain, additional value is captured at the platform layer, where the Socios operator levies fees and penalties under its terms, creating a separate capture surface that is distinct from protocol-level gas fees and third-party DEX activity.
- **Governance**: Protocol upgrades and economic parameters are governed by active validators, making these components participant-based despite stake-weighting. Validator admission is subject to off-chain verification by Chiliz Labs, introducing an entity-governed control surface. Validator power weighting is deterministically shaped by CHZ holder delegation, giving token holders binding authority over actor-set weighting and qualifying as token-based governance for that component. Off-chain platform components remain entity-governed.

### Token Functionalities

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased percentage token ownership as CHZ is consistently and permanently removed via protocol fee-burning.

#### Governance
- **Actor Set Permissioning** [Partial]: Right, as validator owners with voting power weighted by delegated CHZ, to vote on validator-set changes, including adding validators or adjusting the maximum number of active validators and related thresholds. Delegation provides a token-based mechanism to re-weight validator influence, while execution involves identifiable operator action to implement approved changes. In practice, validator-set expansions have been approved through stake-weighted voting and subsequently applied by operators, indicating that outcomes depend on both validator votes and coordinated implementation rather than automatic enforcement.
- **Economic Design/Parameter Control** [Partial]: Right, as a validator owner with voting power proportional to CHZ delegated to the validator, to vote on binding governance proposals that modify key economic parameters such as staking and unjail timing or broader cryptoeconomic variables, subject to a two-thirds quorum and validator coordination for execution. Governance operates through a stake-weighted system in which validator owners cast votes based on total delegated CHZ, and approved proposals have been implemented in practice, including changes to unstake cooldowns, unjail periods and broader cryptoeconomic updates.
- **Technical Parameter Control** [Partial]: Right, as a validator owner with voting power weighted by delegated CHZ, to approve and implement protocol and system-contract technical changes that are gated by governance access control, while core upgrades may additionally require validator software adoption. Governance can directly authorise modifications to core system contracts through restricted governance functions, but hard forks and major client upgrades depend on validators choosing to run updated software, meaning execution ultimately relies on validator coordination rather than automatic enforcement.

#### Collateral
- **Performance-Bond**: Right to post CHZ as surety for a validator or delegator role, with that stake subject to slashing or penalties in cases of misbehaviour.

#### Payments
- **Native Resource Fee** [Strong]: Right to execute on-chain transactions on Chiliz Chain by paying gas fees in CHZ, enforced at the protocol level.
- **General Medium of Exchange**: Right to use CHZ as a payment and exchange medium to acquire other assets, such as Fan Tokens, via on-chain transactions executed through the Socios wallet or interface, subject to market availability and counterparty participation.

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right (as an active validator operator, backed by self-staked and delegated CHZ) to produce blocks and determine transaction inclusion/ordering on Chiliz Chain, earning validator rewards that are then shared with delegators per validator commission rules; delegation is the mechanism by which CHZ holders increase a validator’s stake-weight and thus its chance of block production and governance weight.

---

## Dogecoin (DOGE)

- **URL**: https://fundamentals.fyi/token/dogecoin
- **System**: Dogecoin
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Payment and Settlement Networks
- **System Description**: Dogecoin is a peer-to-peer payment and settlement network designed for transferring DOGE between users and merchants who use it to send and receive payments. Founded in 2013, it runs on a Scrypt proof-of-work blockchain implemented through Dogecoin Core with merged mining support, and its system boundary includes the Dogecoin mainnet, the DOGE token, miners and nodes, ongoing Dogecoin Core development processes, and the Dogecoin Foundation’s stewardship of intellectual property, while excluding custodial service providers and third-party payment processors or merchants.

### System Attributes
- **Operating Model**: Dogecoin operates as a permissionless blockchain protocol where anyone can run a validating/relaying node (Dogecoin Core) and miners add blocks via proof-of-work. Users submit to a public mempool; independent full nodes and PoW miners (Scrypt-based, merge-mined with Litecoin and other Scrypt-based PoW blockchains) validate, order, and commit state. Operating rules change only via Dogecoin Core releases that nodes and miners choose to adopt.
- **Value Creation**: The Dogecoin system exclusively creates on-chain value by providing censorship-resistant settlement and a native bearer asset (DOGE) transferable via transactions recorded on the Dogecoin blockchain.
- **Value Capture**: Value created on-chain is capture at the protocol-level by validators (PoW miners) via block rewards and DOGE-denominated transaction fees, which are routed through block production.
- **Governance**: Off-chain, participant-based governance in which independent hardware operators (full nodes and miners) exercise decision-making authority by selecting and running Dogecoin Core client software and rules; authority does not flow from transferable tokens. Changes are proposed/reviewed in the open-source repo and shipped as Dogecoin Core releases; they only take effect if software updates are adopted.

### Token Functionalities

#### Payments
- **Native Resource Fee** [Strong]: Right to access Dogecoin blockspace/transaction inclusion by paying compulsory DOGE-denominated network fees.

---

## EigenCloud (prev. EigenLayer) (EIGEN)

- **URL**: https://fundamentals.fyi/token/eigenlayer
- **System**: EigenCloud
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): Shared Security and Slot Markets, Specialised Data Availability Layers
- **System Description**: EigenCloud is a verifiability and shared-security platform built on EigenLayer, letting AVSs and application developers secure and verify off-chain data, events, and computation by tapping into a pooled operator network backed by restaked collateral. Founded in 2021, it combines Ethereum smart contracts (restaking, delegation, rewards and slashing) with off-chain operator software, and can use restaked ETH and staked EIGEN to back AVS-specific penalties. The system boundary includes EigenLayer/EIGEN staking contracts, operators and delegators, and Eigen Labs/Eigen Foundation governance and primary interfaces; it excludes Ethereum L1 itself, independent third-party AVSs and downstream apps, and third-party bridges or wrapped representations of ETH/EIGEN.

### System Attributes
- **Operating Model**: EigenLayer’s core restaking coordination is implemented as an on-chain protocol that coordinates restakers, operators, AVSs, rewards, and slashing, while EigenCloud services are operated under EigenLabs terms, including EigenAI and EigenCompute.
- **Value Creation**: Value is produced by on-chain restaking coordination (delegation, rewards/slashing logic) plus off-chain operator work/EigenLabs services (e.g., EigenAI/EigenCompute).
- **Value Capture**: EigenLayer routes on-chain rewards to AVS operators and restakers, while Eigen Labs captures off-chain subscription and usage fees from EigenCloud services.
- **Governance**: Eigen Labs, Inc. maintains authority over most of the off-chain product lines, the Protocol Council holds the sole power to execute approved changes to core contracts, whilst token holders exert their say through intersubjective governance.

### Token Functionalities

#### Service Provision
- **Data Availability**: Right to provide data availability services by making transaction data available under correctness guarantees for external execution domains (EigenDA).

#### Collateral
- **Performance-Bond**: Right to post EIGEN as stake backing AVS and operator commitments, functioning as a performance bond. Restaked or delegated stake is slashable, with slashed value either burned or redistributed, subject to current constraints on which assets are eligible for redistribution.

---

## Ethereum (ETH)

- **URL**: https://fundamentals.fyi/token/ethereum
- **System**: Ethereum
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Ethereum provides a permissionless general-purpose execution, settlement, and data availability network, enabling users, applications, and external systems to execute smart contracts, settle transfers, and publish transaction data via Ethereum transactions. Founded in 2015, it uses a Proof-of-Stake consensus mechanism with an account-based execution model (EVM) that prioritises a large decentralised validator set. The system boundary includes the Ethereum state, validators and nodes, ETH the native asset, staking and slashing mechanisms, the on-chain fee market, open-source client software, the Ethereum foundation and the protocol software development process, and excludes applications on Ethereum, external L2 rollups, bridges, and other EVM-based blockchains.

### System Attributes
- **Operating Model**: Ethereum delivers credible-neutral blockspace by coordinating independent providers (validators) with open entry; the service work is metered and settled on-chain, and the operations necessary to create value live on-chain. In other words, Ethereum’s day-to-day provision of blockspace does not require off-chain corporate operations as an input: only the on-chain protocol elements are operationally necessary.
- **Value Creation**: The Ethereum blockchain creates value by producing scarce execution/inclusion capacity (blockspace) and, post-EIP-4844/Dencun, time-limited blob data availability used by rollups for publishing transaction data.
- **Value Capture**: Users pay gas fees; the protocol burns the base fee (reducing supply) and routes priority fees to validators, while validators also receive ETH rewards for securing the chain.
- **Governance**: Governance rights in Ethereum is tied to participants that fill operational roles (e.g., validators and node operators) and are implemented through mechanisms such as client software adoption and network upgrades. The Ethereum Foundation plays a significant coordinating and funding role in research, roadmap development, and client ecosystem support, but does not possess unilateral authority to enforce protocol changes; upgrades require adoption by independent validators and node operators.

### Token Functionalities

#### Collateral
- **Performance-Bond**: Right to provide ETH as collateral to secure the system. Validators that participant in block production are required to expose staked ETH as slashable collateral to prevent validator misconduct.
- **Financial Collateral** [Strong] (Exogenous): Right to use ETH as financial collateral in Ethereum DeFi application ecosystem, as well as ecosystems of L2 systems that are integrated with Ethereum blockchain.
- **Performance-Bond** (Exogenous): Right to restake ETH to contribute to other decentralized network services. For example EigenLayer restaking allows Ethereum validators and stakers to earn additional rewards by securing Actively Validated Services using their already-staked ETH or Liquid Staking Tokens (LST).

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased percentage token ownership due to protocol-level burning of fees (supply reduction). 100% of base transaction fee is burned and priority fee is earned by Ethereum validators.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay transaction processing fees on Ethereum blockchain exclusively in ETH. All users, applications and L2 systems that access execution, settlement, and data-availablity services have to submit transactions to network of validators.
- **Native Resource Fee** [Weak] (Exogenous): Right to use ETH to pay for fees of on several L2 blockchains that use Ethereum for trust gurantees and data availability (gas token). Arbitrum, Base, Optimism and many other rollups use ETH as their primary or exclusive asset in which fees can be paid to access services.
- **General Medium of Exchange** (Exogenous): Right to discharge a payment obligation to a willing counterparty for goods or services, inside or outside the system. This right exists only with a willing counterparty and is not system-enforced.

#### Service Provision
- **Data Availability**: Right to make transaction data available under correctness guarantees for consumption by external execution domains (e.g., rollups posting blobs).
- **State Transition Execution and Transaction Sequencing**: Right to stake ETH to contribute in block production service as a validator.

---

## Ethereum Name Service (ENS)

- **URL**: https://fundamentals.fyi/token/ethereum-name-service
- **System**: Ethereum Name Service
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Naming and Address Resolution
- **System Description**: Ethereum Name Service is an on-chain naming and address-resolution system that provides human-readable names (e.g., alice.eth) which map to Ethereum addresses and other resources, enabling simpler identity and routing for users and applications. Founded in 2017, ENS runs on Ethereum smart contracts; the system boundary includes the ENS registry and resolver contracts, the ETH Registrar (which charges a registration fee in ETH), the ENS DAO and treasury, and primary management interfaces, while excluding third-party wallets and applications that simply consume ENS resolution.

### System Attributes
- **Operating Model**: Ethereum Name Service operates primarily as an on-chain protocol that coordinates ownership and resolution of a single application: decentralized naming on Ethereum. The economically valuable service registering names and resolving them to addresses or records is supplied through open-entry smart contracts, while off-chain entities (such as ENS Labs, the ENS Foundation, and front-end interfaces) support usability and ecosystem development but are not required for the protocol to function at a base level.
- **Value Creation**: Ethereum Name Service exhibits on-chain value creation because the product users value verifiable ownership of names and deterministic name resolution is produced directly by smart contracts. The registry, registrars, and resolvers define and enforce name ownership, expiry, and resolution logic without reliance on custodial databases or discretionary off-chain execution. Off-chain components such as documentation, interfaces, and integrations enhance distribution and usability but do not create the core service itself, which is generated and enforced entirely within the on-chain component of the system.
- **Value Capture**: Value capture and routing in Ethereum Name Service occurs on-chain, following the creation of value through name registration and renewal. Fees paid in ETH by users for registering and renewing ENS names accrue to a treasury controlled by the ENS DAO. While supporting entities exist off-chain, they do not automatically extract protocol revenues by default; instead, value is first captured within the system and only routed onward when governance explicitly authorizes spending or transfers.
- **Governance**: Ethereum Name Service operates under a hybrid governance model combining Token-based and Participant-based governance. Primary authority rests with ENS token holders, who exercise binding, on-chain rights through the ENS DAO to approve technical upgrades, modify economic parameters, allocate treasury assets, and appoint or remove designated protocol actors via executable proposals. Alongside this, a DAO-appointed Security Council holds limited participant-based authority, including the ability to cancel approved proposals prior to execution under predefined conditions, functioning as a procedural safeguard within the same decision space.

### Token Functionalities

#### Governance
- **Technical Parameter Control** [Partial]: Right to approve and execute changes to the protocol’s live technical architecture, including upgrades to registrars, resolvers, and other core contracts, using an on-chain Governor and Timelock mechanism. These decisions are binding within the technical decision space and do not rely on discretionary implementation by off-chain actors. However, execution authority is shared: the Security Council can cancel passed proposals that modify technical components before they are enacted.
- **Economic Design/Parameter Control** [Partial]: Right to modify live economic parameters of the system, including fee structures, treasury allocation policies, and token issuance constraints, through executable DAO proposals. These decisions operate within a clearly defined economic decision space and are enforced via smart contracts rather than discretionary off-chain actors. However, this authority is not exclusive: a non-token-holder Security Council retains the enforceable right to cancel approved proposals affecting economic parameters prior to execution.
- **Actor Set Permissioning** [Partial]: Right to appoint, remove, or reassign privileged protocol roles, including Security Council members and other governance-designated actors, through binding on-chain governance votes. These permissions apply to a real and active actor-selection decision space and are enforceable through protocol mechanisms rather than informal coordination. However, actor-related proposals are subject to cancellation by the Security Council prior to execution.
- **Treasury Control** [Partial]: Right to direct, allocate, transfer, or burn assets held in the ENS DAO treasury through executable on-chain proposals. Treasury decisions are made entirely within an active, well-defined decision space and can be enforced directly by smart contracts without reliance on off-chain custodians, subject to Security Council approval.
- **Process and Meta Parameter Control** [Signal]: Right to make changes to governance process. ENS governance process defines “Constitutional Amendment” as a proposal type with a higher approval threshold (2/3) and off-chain signalling via Snapshot; this is governance at token level but non-binding on-chain.

---

## Hedera (HBAR)

- **URL**: https://fundamentals.fyi/token/hedera-hashgraph
- **System**: Hedera
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Hedera is a public ledger that sells metered consensus ordering and execution for transactions and smart contract calls, enabling developers and end users to record state changes via Hedera network services. Founded in 2018, it uses hashgraph consensus (Hiero) alongside EVM smart contracts. The system boundary includes the mainnet ledger, consensus and mirror nodes, fee and staking accounts, and the Hedera Council and Hiero governance, while excluding third-party dApps and exchanges.

### System Attributes
- **Operating Model**: Hedera operates as an on-chain protocol for users (transactions are metered and settled on-chain), but the supply-side operators (consensus nodes) are permissioned and run by Hedera Council members (a corporate entity), and key operational decisions (pricing, upgrades, treasury actions) are made via an identifiable off-chain governance body.
- **Value Creation**: The economically valuable service (ordering/execution into a consensus state) is produced by the mainnet’s consensus nodes, which receive transactions, charge fees, and contribute to consensus.
- **Value Capture**: Hedera’s primary cashflows are transaction fees in HBAR that are captured and routed via on-chain accounts: fees are split between a network account and the node that submitted the transaction, and current mirror-node stake parameters show explicit fee fractions to staking reward and node reward pools.
- **Governance**: Hedera’s system governance is primarily off-chain and entity-governed, with binding authority over protocol upgrades, economic parameters, and treasury management exercised by the Hedera Council through equal-weight council voting. Consensus node operation is participant-based but permissioned, as mainnet nodes are operated by Council member organisations rather than open participants. Token-based governance exists only in a narrow, scoped form, where HBAR holders can bindingly re-weight consensus influence by staking to admitted nodes, without authority over admission or protocol parameters.

### Token Functionalities

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to have one’s HBAR balance counted as such that it contributes to stake‑weighted consensus (consensus weight) and to earn staking rewards for that contribution, subject to protocol parameters (minimum staking period; node min/max stake thresholds; reward-rate parameters).

#### Governance
- **Actor Set Permissioning** [Partial]: Right to re-weight the effective consensus influence (stake weight) of admitted consensus nodes by choosing which node one’s HBAR is staked to (proxy staking). Partial because token delegation impacts weight within a permissioned node set but cannot appoint/remove consensus nodes (permissioned Council operator set).

#### Payments
- **Native Resource Fee** [Strong]: Right to consume Hedera network processing resources (submit transactions that nodes process into consensus) by paying transaction fees in HBAR.

---

## Hivemapper (HONEY)

- **URL**: https://fundamentals.fyi/token/hivemapper
- **System**: Hivemapper
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Sensor and Real-World Data Networks
- **System Description**: Hivemapper is a decentralised mapping data network that delivers street-level imagery and map features to data customers. Founded in 2015, customers consume Hivemapper data products using Map Credits, with coordination handled via Solana programmes alongside off-chain data capture, processing, and delivery infrastructure. The system boundary includes the HONEY token contracts and associated off-chain infrastructure, while excluding Solana base-layer governance and third-party trading venues.

### System Attributes
- **Operating Model**: Day-to-day service delivery depends on off-chain activities such as hardware distribution, data capture and processing, and product delivery, while token accounting and mint and burn flows for HONEY are executed and enforced on-chain.
- **Value Creation**: Value creation in the Hivemapper system is primarily off-chain. The core outputs, including mapping imagery and derived map features, are produced through data capture and subsequent off-chain processing and packaging into products, with consumption mediated via Map Credits rather than on-chain computation.
- **Value Capture**: Value is captured off-chain when customers purchase Map Credits via fiat from the Hivemapper Foundation (including a transaction/processing fee), and then routed on-chain as the Foundation buys HONEY and burns it to generate Map Credits; the burn-and-mint design then routes a defined share of value back into the cryptoeconomic system via re-minted rewards to contributors while permanently burning the remainder, linking customer demand to token supply and distribution dynamics.
- **Governance**: Governance changes are driven by an off-chain MIP process coordinated by the Hivemapper Foundation, with current documentation explicitly noting that voting-based governance is a longer-term direction rather than the primary mechanism today.

### Token Functionalities

#### Payments
- **Native Resource Fee** [Strong]: Right to generate non-transferable Map Credits by burning HONEY, where such credits are exclusively required to access core data products, including imagery and map features, thereby linking product consumption directly to token destruction through protocol-defined mint-and-burn mechanics.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased percentage token ownership as a result of system operations that consistently and permanently burn a share of HONEY redeemed for Map Credits

---

## Injective (INJ)

- **URL**: https://fundamentals.fyi/token/injective-protocol
- **System**: Injective
- **Dominant Sector**: Trading and Exchange
- **Sectors**:
  - Trading and Exchange (primary): Decentralized Financial Derivatives Exchange
- **System Description**: Injective is a finance-specific Layer 1 blockchain that provides optimised, high-performance infrastructure for decentralised derivatives and global financial markets for institutional and retail traders. Founded in 2018, it utilises the Cosmos SDK and the native INJ token to achieve sub-second finality through a customised Tendermint consensus engine. The system boundary includes the Injective Chain, native financial modules such as the Frequent Batch Auction exchange, the MultiVM execution environment, and Helix, while excluding other networks such as Cosmos and its app-chains, independent third-party front-ends, and off-chain centralised trading venues.

### System Attributes
- **Operating Model**: Injective is an L1 network, specifically a Cosmos app-chain, that coordinates a set of validators to operate its blockchain. Helix is a dedicated trading application and interface, providing an off-chain experience for users.
- **Value Creation**: Injective creates value by enabling on-chain execution and settlement for decentralised spot and derivatives trading via protocol-native order book and matching modules. This value is created by the Injective validator set that produces and validates the blocks.
- **Value Capture**: Transaction and trading-related fees are captured on-chain and routed to validators and protocol participants, with a portion routed to INJ holders via an endogenous burn-auction mechanism.
- **Governance**: Token-based governance with validator-mediated execution, consistent with Cosmos SDK governance, where INJ holders vote on protocol parameters and upgrades subject to validator enforcement.

### Token Functionalities

#### Governance
- **Economic Design/Parameter Control** [Partial]: Right to vote on trading fees, inflation, and auction parameters. Execution requires majority consensus and validator participation.
- **Product/Service Line Decisions** [Partial]: Right to direct the retirement of customer-facing products/markets via the binding power to change a market's status from "Active" to "Suspended" or "Demolished" via on-chain status change proposals
- **Treasury Control** [Unilateral]: Right to direct treasury spend/allocations.
- **Technical Parameter Control** [Partial]: Right to vote on protocol upgrades and chain-level feature changes. Technical changes and chain-level feature additions are enacted via on-chain governance proposals and executed by validators.
- **Actor Set Permissioning** [Unilateral]: Right to re-weight privileged actors (validators) by delegating/bonding/voting power). Additionally, right to appoint/remove whitelisted contract deployers

#### Payments
- **Native Resource Fee** [Strong]: Right to pay for transaction inclusion on the Injective blockchain

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to order and validate transactions. Validators and delegators stake INJ to participate in block production and consensus.

#### Value Distribution
- **Burn Entitlement** [Discretionary but Regular]: Right to benefit from increased percentage token ownership as a result of system operations. Tokens are burned via mechanisms that consistently and permanently remove tokens.

#### Collateral
- **Performance-Bond**: Right to bond INJ to validators to underwrite good behavior, subject to slashing. Performance bond also provided to submit governance proposals, which are subject to burning if the proposal gets vetoed or doesn't reach the minimum deposit threshold

#### Membership
- **Preferential Pricing (Hold-Based)**: Right to receive fee discounts on Helix exchange (built by Injective Labs) by holding INJ. 

---

## JasmyCoin (JASMY)

- **URL**: https://fundamentals.fyi/token/jasmycoin
- **System**: Jasmy
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Identity Verification, Sensor and Real-World Data Networks
- **System Description**: Jasmy is a decentralized data democracy platform that enables secure information management and monetization for IoT device owners and enterprises. Founded in 2016, it utilizes the Arbitrum Orbit-based JasmyChain and the JASMY ERC-20 token to achieve trustless data exchange, settled on the Ethereum blockchain. The system boundary includes the Personal Data Locker (PDL), SKC/SG authentication protocols, and the Janction AI compute marketplace, while excluding the underlying Ethereum/Arbitrum consensus mechanism and third-party IPFS storage nodes.

### System Attributes
- **Operating Model**: Jasmy relies on a centralized corporate operator delivering identity & data-management services, though also has an on-chain protocol including the JasmyChain, PDL smart contracts, and the SG/SKC authentication logic
- **Value Creation**: On-chain value is produced through the generation of secure blockspace on JasmyChain and the cryptographic verification of data authenticity via the SG protocol. Off-chain value is created through the design and distribution of IoT hardware.
- **Value Capture**: Monetary value is captured within the cryptoeconomic system through transaction fees on JasmyChain, which are paid in JASMY tokens. Jasmy Incorporated likely captures value through traditional service contracts with corporate partners, licensing fees for its proprietary SKC/SG modules, and the sale of IoT hardware.
- **Governance**: The core technical roadmap, the selection of strategic partners, and the management of the Ecosystem fund (48% of the total supply) are currently governed by the Jasmy Foundation and Jasmy Incorporated. JASMY token holders have the right to vote on certain protocol parameters and ecosystem grants.

### Token Functionalities

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from supply reduction due to the EIP-1559 style base transaction fee burn

#### Payments
- **Native Resource Fee** [Weak]: Right to pay for transactions on the jasmychain using JASMY tokens. Whilst JASMY is the only token for chain transactions, it is not required as payment for access to users' Personal Data Lockers (PDL), which is the other and more notable value service provided. 

---

## Kaito (KAITO)

- **URL**: https://fundamentals.fyi/token/kaito
- **System**: Kaito
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Off-Chain Compute
  - Trading and Exchange (secondary): Token Launchpads and Primary Distribution
- **System Description**: Kaito provides a crypto-native information and attention coordination system that delivers AI-driven market intelligence and tokenised attention signals for users, creators, and projects. Its products enable discovery, ranking, and coordination around crypto information flows and token launch participation. Founded in 2022, Kaito operates primarily as an off-chain AI platform with supporting on-chain components on Base, including the KAITO token, staking contracts, launchpad and attention attestations. The system boundary includes Kaito-operated applications and infrastructure and these on-chain components, and excludes external social platforms and third-party protocols.

### System Attributes
- **Operating Model**: Kaito’s primary products (Pro/Yaps/Connect) are platform services that use proprietary search algorithms, semantic LLM capabilities, and analyticsvdelivered as an application-layer product rather than a purely on-chain protocol.
- **Value Creation**: The primary valuable service, transforming unstructured Web3 data into searchable and actionable insights, is produced by off-chain AI components (OpenKaito Digital Ltd).
- **Value Capture**: Subscription revenue from the Kaito Pro terminal, which serves over 600 crypto teams, is captured by the corporate entity to fund ongoing development. Conversely, protocol fees generated by the Yapper Launchpad and other on-chain services are routed back to the community through a programmatic buyback program and staking rewards.
- **Governance**: Corporate governance is evidenced by the company-operated platform and legal terms.  Separately, KAITO is explicitly positioned to enable community governance (propose/vote on key protocol and algorithm changes) and tokenomics references governance voting for allocation decisions, but the publicly available docs do not specify whether votes are binding/automatically executed (so “hard power” strength is uncertain).

### Token Functionalities

#### Payments
- **General Medium of Exchange**: Right to subscribe to Kaito Pro services by paying for annual or bi-annual subscriptions with KAITO token. Using KAITO as payment currency does not offer discounts relative to traditional payment solutions.

#### Governance
- **Product/Service Line Decisions** [Partial]: Right to vote on which projects/programmes are selected for Kaito Connect launchpad/leaderboard launches using Holder Votes derived from staked KAITO (sKAITO)

#### Value Distribution
- **Buyback Entitlement** [Discretionary but Regular]: Right to benefit from open-market buybacks by Foundation using system revenue.

---

## Lido DAO (LDO)

- **URL**: https://fundamentals.fyi/token/lido-dao
- **System**: Lido
- **Dominant Sector**: Credit and Asset Management
- **Sectors**:
  - Credit and Asset Management (primary): Liquid Staking Providers
- **System Description**: Lido provides a permissionless liquid staking system that lets users stake assets, primarily ETH, while receiving liquid staking tokens like stETH that represent claims on the staked assets and rewards, enabling continued liquidity and DeFi use. Founded in 2020, it operates through on-chain smart contracts for staking, validator coordination, and reward accounting, supported by off-chain node operators and DAO processes. The system boundary includes Lido’s staking and accounting contracts, liquid staking tokens, DAO governance, node operators, and core interfaces, while excluding underlying base-layer consensus systems and external DeFi integrations built on top of stETH.

### System Attributes
- **Operating Model**: Lido’s staking, minting/burning of stETH, and reward accounting are handled via Ethereum smart contracts, with protocol state changes settled on-chain. Node operators and oracles are selected/managed through DAO processes and interact with the protocol as coordinated service providers.
- **Value Creation**: The system produces yield by performing consensus duties, which users value because it allows them to earn a return on their ETH without the technical overhead of running a validator or the illiquidity of the native staking process
- **Value Capture**: Captured value is ultimately routed to either stakers (90%), node operators (5%), or the DAO treasury (5%).
- **Governance**: Token-based governance via LDO operates through on-chain voting that can directly execute smart contract upgrades and treasury fund transfers, while stETH holders hold a binding veto and delay right through Dual Governance that allows approved proposals to be blocked for a defined period, with the potential for extended disruption via Rage Quit. Alongside this, participant-based governance applies to emergency pauses and certain routine operational actions through committee-controlled multisigs, with paused components requiring a subsequent on-chain DAO action to resume.

### Token Functionalities

#### Governance
- **Technical Parameter Control** [Partial]: Right to approve/execute smart contract updates through Aragon on-chain governance; execution is subject to governance flow and Dual Governance delay.
- **Actor Set Permissioning** [Partial]: Right to onboard or remove node operators and oracles. While the DAO sets policies, specific modules like the Curated Module rely on a committee for day-to-day vetting.
- **Product/Service Line Decisions** [Partial]: Right to influence major product/module direction by approving and configuring modules and their key settings and it also governs operational motions that shape the protocol’s ongoing service footprint. Examples include sunsetting the Solana/Polygon operations or mandating the launch of ValMart, the Lido Validator Marketplace.
- **Economic Design/Parameter Control** [Partial]: Right to set protocol economic parameters (e.g., protocol fee rate and module fee splits) via DAO governance; execution can be delayed by Dual Governance opposition
- **Treasury Control** [Partial]: Right to approve direct treasury fund transfers through Aragon execution, and also govern spending pathways used for recurring operational disbursements (e.g., grants within predefined budgets routed via Easy Track).
- **Process and Meta Parameter Control** [Partial]: Right to amend binding governance-rule parameters for Lido DAO decision-making, including voting thresholds/quorum/support requirements (e.g., the 5% of total LDO supply requirement) and Dual Governance configuration thresholds (e.g., FirstSealRageQuitSupport = 1% and SecondSealRageQuitSupport = 10%, plus associated timelock parameters).

---

## Lido Staked Ether (STETH)

- **URL**: https://fundamentals.fyi/token/staked-ether
- **System**: Lido
- **Dominant Sector**: Credit and Asset Management
- **Sectors**:
  - Credit and Asset Management (primary): Liquid Staking Providers
- **System Description**: Lido provides a permissionless liquid staking system that lets users stake assets, primarily ETH, while receiving liquid staking tokens like stETH that represent claims on the staked assets and rewards, enabling continued liquidity and DeFi use. Founded in 2020, it operates through on-chain smart contracts for staking, validator coordination, and reward accounting, supported by off-chain node operators and DAO processes. The system boundary includes Lido’s staking and accounting contracts, liquid staking tokens, DAO governance, node operators, and core interfaces, while excluding underlying base-layer consensus systems and external DeFi integrations built on top of stETH.

### System Attributes
- **Operating Model**: Lido’s staking, minting/burning of stETH, and reward accounting are handled via Ethereum smart contracts, with protocol state changes settled on-chain. Node operators and oracles are selected/managed through DAO processes and interact with the protocol as coordinated service providers.
- **Value Creation**: The system produces yield by performing consensus duties, which users value because it allows them to earn a return on their ETH without the technical overhead of running a validator or the illiquidity of the native staking process
- **Value Capture**: Captured value is ultimately routed to either stakers (90%), node operators (5%), or the DAO treasury (5%).
- **Governance**: Token-based governance via LDO operates through on-chain voting that can directly execute smart contract upgrades and treasury fund transfers, while stETH holders hold a binding veto and delay right through Dual Governance that allows approved proposals to be blocked for a defined period, with the potential for extended disruption via Rage Quit. Alongside this, participant-based governance applies to emergency pauses and certain routine operational actions through committee-controlled multisigs, with paused components requiring a subsequent on-chain DAO action to resume.

### Token Functionalities

#### Collateral
- **Financial Collateral** [Strong] (Exogenous): Right to pledge stETH as collateral in Ethereum (and Ethereum L2 systems) applications that range from lending to restaking.
- **Stablecoin-Reserve Asset** [Weak] (Exogenous): Right to use as stETH as collateral to mint USDS on Sky.

#### Asset Ownership
- **On-Chain Asset Title/Pool Share** [Strong]: Right to redeem a pro-rata claim on pooled staked ETH by burning stETH to withdraw ETH, with redemption permissionless but not immediate (queue/throughput constrained), and with the claim’s value reflecting net staking outcomes.

#### Governance
- **Process and Meta Parameter Control** [Partial]: Right to escrow stETH into Lido's Dual Governance to delay/block Lido DAO motion execution via Veto Signalling (1% threshold; blocks motions 5–45 days) and to keep execution blocked during Rage Quit until escrowed tokens exit.

---

## Litecoin (LTC)

- **URL**: https://fundamentals.fyi/token/litecoin
- **System**: Litecoin
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Payment and Settlement Networks
- **System Description**: Litecoin is a peer-to-peer payment and settlement network providing on-chain value transfer via a proof-of-work public blockchain. Founded in 2011, it enables users and merchants to send and settle LTC transactions directly on the network. The system boundary includes the consensus rules, on-chain ledger, and peer-to-peer node and mining infrastructure, while excluding centralised exchanges and payment processors that integrate LTC.

### System Attributes
- **Operating Model**: Litecoin is operated day to day by open-entry network participants, with block production performed by miners and transaction verification and propagation handled by distributed nodes, rather than by any single off-chain operator.
- **Value Creation**: Litecoin creates value on-chain by providing final settlement on its ledger, produced through transaction inclusion in blocks and subsequent network confirmations. The network’s core service is the processing and confirmation of transactions directly on the blockchain.
- **Value Capture**: Litecoin captures and routes value entirely on-chain, with protocol value accruing to miners through block rewards and transaction fees. Miners receive newly issued LTC via issuance and may also receive transaction fees paid in LTC for including transactions in blocks.
- **Governance**: Binding changes to the protocol’s rules in Litecoin occur through participant adoption, with nodes and miners choosing whether to upgrade and run modified software, rather than through token-holder voting rights. As an open-source system, protocol changes only take effect if a sufficient share of network participants voluntarily adopt the updated rules.

### Token Functionalities

#### Payments
- **General Medium of Exchange** (Exogenous): Used as a medium of exchange for payments outside the base protocol (e.g., payment processors/merchant rails), supported by third-party research citing payment usage.
- **Native Resource Fee** [Strong]: Right to consume a scarce, system-controlled internal resource where payment in LTC is compulsory and enforced by the system.

---

## Livepeer (LPT)

- **URL**: https://fundamentals.fyi/token/livepeer
- **System**: Livepeer
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Off-Chain Compute
- **System Description**: Livepeer provides off-chain video and AI compute, including transcoding and inference, coordinated by the Livepeer protocol and was founded in 2017. Developers and media applications purchase compute via Livepeer Studio APIs and protocol gateways, with services settled in ETH, which broadcasters pay and orchestrators receive, while coordination and accounting are handled by smart contracts on Arbitrum One and a distributed orchestrator network. The system boundary includes protocol contracts, orchestrators, gateways and broadcasters, Livepeer Studio SaaS, ETH-denominated compute payments, and on-chain treasury and governance contracts, while excluding base-chain governance and third-party customer applications.

### System Attributes
- **Operating Model**: Livepeer has a deployed on-chain protocol on Arbitrum that coordinates staking, roles, and protocol components, while Livepeer Studio is a hosted SaaS/API and enterprise support layer that routes workloads to the network on a day-to-day basis.
- **Value Creation**: The productive activity includes (i) off-chain compute work (orchestrators executing computation) and (ii) on-chain protocol components that attest outputs on-chain.
- **Value Capture**: Fees and incentives are routed to service providers and protocol/treasury mechanisms on-chain, while Livepeer Studio captures off-chain revenue from enterprise-facing productisation (support, SLAs) even when compute is performed by the network. Treasury-directed flows (e.g., treasury reward cut parameters) create an additional on-chain value routing channel.
- **Governance**: Livepeer’s governance combines on-chain token-based treasury governance, participant-based control for safety-critical actions, and off-chain corporate and foundation governance for non-protocol components. Treasury decisions are executed via governor contracts, while privileged roles such as a protocol security committee can carry out on-chain proposals and act as a first line of defence. In parallel, Livepeer Studio’s fees and commercial terms are set by Livepeer Inc., and ecosystem coordination is handled by the separately constituted Livepeer Foundation.

### Token Functionalities

#### Governance
- **Technical Parameter Control** [Signal]: Right to signal preference over protocol upgrades and core architectural changes via token-weighted governance voting, without automatic execution effect, as authority to stage and execute changes is vested in a privileged Governor executor contract rather than directly triggered by the vote itself.
- **Process and Meta Parameter Control** [Partial]: Right to modify specified governance process parameters for treasury decision-making, including voting delay, voting period, proposal thresholds, and quorum settings exposed via the Governor contract, subject to a superior controller owner authority that retains unilateral power to alter core contract mappings and upgrade targets, including governance modules.
- **Treasury Control** [Partial]: Right to direct allocation and transfer of on-chain treasury assets via Governor proposals covering budgets, grants, and other treasury disbursements, executed through a timelocked governance framework, subject to a superior controller Safe that retains unilateral authority to modify core contract registrations and governance wiring, thereby limiting token-holder control to a subordinate layer.
- **Economic Design/Parameter Control** [Signal]: Right to signal preference over core economic parameters, including inflation and issuance dynamics, via token-weighted governance voting, without direct execution authority, as implementation of parameter changes remains gated to a privileged controller role in protocol code.

#### Service Provision
- **Generalised Off-Chain Computation**: Right to perform verifiable off-chain video compute (transcoding/AI video jobs) as an Orchestrator secured by bonded LPT; earn fees via probabilistic micropayments and protocol rewards.

---

## Morpho (MORPHO)

- **URL**: https://fundamentals.fyi/token/morpho
- **System**: Morpho
- **Dominant Sector**: Credit and Asset Management
- **Sectors**:
  - Credit and Asset Management (primary): Collateralised & Underwritten Lending, Yield Aggregation and Vault Strategies
- **System Description**: Morpho is an on-chain credit protocol that enables permissionless, overcollateralised lending and borrowing, alongside curated vault strategies for passive capital allocation. Its core primitive, Morpho Blue, is a minimal, immutable lending framework where markets are defined by collateral, loan asset, oracle, and interest rate model, while MetaMorpho adds a vault layer that aggregates deposits and manages lending strategies across Morpho markets. Founded in 2021, the system comprises of Morpho Blue and MetaMorpho smart contracts, the MORPHO governance token and governance multisigs, vault curators, and the Morpho Association, a French non-profit association responsible for operating the primary user interfaces, documentation, and other off-chain governance and coordination surfaces; it excludes the underlying blockchains, external assets, and third-party oracle providers on which the protocol relies.

### System Attributes
- **Operating Model**: Morpho operates primarily as an on-chain protocol. The core economic activity of overcollateralised lending and borrowing is executed entirely through permissionless smart contracts, with open market creation and access that do not depend on a central operator. MetaMorpho vaults likewise execute on-chain and allow independent curators to deploy and manage strategies without protocol-level permission. While off-chain components—such as the Morpho Association–operated front end and documentation—support user access and coordination, they are not operationally required for the protocol to function, nor do they intermediate lending activity. As a result, the system’s day-to-day provision of credit is coordinated by on-chain contracts rather than by an off-chain business.
- **Value Creation**: Morpho’s value is created on-chain through the provision of capital-efficient credit markets. Lenders supply assets to earn interest, borrowers post collateral to access liquidity, and liquidators enforce solvency, all via deterministic smart contract execution. MetaMorpho vaults further create value by packaging exposure to these markets into curated, rule-based strategies, but the productive activity remains the same: allocating capital within on-chain lending markets. No material value is created through off-chain services such as custody, underwriting, or discretionary credit decisions.
- **Value Capture**: Value within the Morpho system is routed on-chain between participants rather than captured by a central operator. Borrower interest and liquidation penalties flow directly to lenders and other on-chain participants according to protocol rules. At present, the protocol itself does not extract a protocol-level surplus in the form of recurring fees routed to a treasury or off-chain entity. Although governance retains the ability to activate or adjust certain fee mechanisms, observed value flows today primarily route between users within the on-chain system. There is no material off-chain revenue capture by the Morpho Association or any other corporate entity tied to protocol usage. In June 2025, Morpho Labs became a wholly-owned subsidiary of the Morpho Association (a French nonprofit entity that supports the project) to eliminate any perceived conflicts with equity value.
- **Governance**: Binding changes to Morpho’s protocol parameters and treasury are made via MORPHO token governance with timelocked execution. A role-gated multisig (e.g., an invalidator/guardian role) retains bounded administrative or veto powers during the timelock window, so system governance is token-based plus participant-based.

### Token Functionalities

#### Governance
- **Treasury Control** [Partial]: Right to vote on the allocation, transfer, or use of assets held in the on-chain governance treasury.
- **Product/Service Line Decisions** [Partial]: Right to vote on defined product/service decisions (e.g., code licensing or deployments within scope). 
- **Technical Parameter Control** [Partial]: Right to vote on technical changes to protocol-level components (e.g., upgrades to the MORPHO token contract and other explicitly governed contracts). Execution of proposals are implemented by a 5/9 governance Multisig elected by token holders.
- **Actor Set Permissioning** [Partial]: Right to determine the composition of privileged governance executors, specifically the membership of protocol governance multisigs. Token holders can vote to appoint or replace signers, establishing formal influence over who executes governance decisions.
- **Process and Meta Parameter Control** [Partial]: Right to govern governance process itself, including how proposals are interpreted, prioritised, or operationally executed by governance actors. Governance execution is mediated by multisig executors elected by token holders, governance can express views on process-level matters such as voting norms, execution expectations, or governance coordination practices.
- **Economic Design/Parameter Control** [Partial]: Right to vote on economic parameters that influence monetary flows and risk configuration within the Morpho system (e.g., fee switch/routing, LLTV and interest-rate model allowlists). Execution of proposals are implemented by a 5/9 governance Multisig elected by token holders.

---

## Ondo native token (ONDO)

- **URL**: https://fundamentals.fyi/token/ondo-finance
- **System**: Ondo Finance
- **Dominant Sector**: Tokenised Assets
- **Sectors**:
  - Tokenised Assets (primary): Fixed Income, Equity and Fund Shares
- **System Description**: Ondo Finance provides tokenised asset issuance and servicing for yield-bearing treasury instruments and tokenised public securities, with USDY and OUSG offering on-chain exposure to fixed-income products and USDon acting as the settlement and redemption rail for its tokenised markets. Founded in 2021, it uses token contracts across EVM chains and Solana alongside off-chain KYC, custody, and SPV infrastructure, with the system boundary including the USDY, OUSG and USDon token contracts, Flux Finance, ONDO governance, and issuer-side operations, while excluding the underlying asset issuers.

### System Attributes
- **Operating Model**: Ondo Finance’s tokenised products depend on identifiable off-chain operators for onboarding, KYC, custody, and ongoing portfolio and asset operations. By contrast, Flux Finance is an on-chain lending protocol coordinated through smart contracts and on-chain governance, with its core operations and rule execution occurring on-chain.
- **Value Creation**: Value is created off-chain through custody, brokerage, and asset-sourcing activities that support the issuance and redemption of USDY, OUSG, and USDon, with yield generated from interest on bank deposits and US Treasuries at system-defined rates. On-chain, value is created by enabling lending and borrowing execution within Flux, where lending markets are configured and administered through protocol controls.
- **Value Capture**: Ondo Finance captures value primarily off-chain through product-level economics, including a yield spread and redemption fee on USDY and a management fee on OUSG. In parallel, Flux Finance routes value on-chain by passing borrower interest payments through smart contracts to suppliers, with launch parameters indicating minimal or no diversion to a protocol reserve.
- **Governance**: Flux protocol changes are governed by ONDO token holder voting with on-chain execution, alongside participant-based privileged roles such as guardians, committees, and multisigs that retain control over specific risk and safety parameters including pausing, caps, and whitelisting. In parallel, the off-chain tokenised-asset products operated by Ondo Finance rely on operator-controlled custody, accounts, and operational processes rather than protocol-enforced execution.

### Token Functionalities

#### Governance
- **Actor Set Permissioning** [Partial]: Right to appoint/remove privileged roles (e.g., pause guardian, borrow cap guardian, whitelist guardian) that can take specific actions without full token-holder votes at action time.
- **Product/Service Line Decisions** [Partial]: Right to approve new markets/service scope within Flux (e.g., supporting new lending markets), though the system also has off-chain product lines outside token-holder control.
- **Economic Design/Parameter Control** [Partial]: Right to change economic parameters of Flux markets (e.g., collateral factors, close factor, liquidation incentive, reserve factors), but some risk controls can also be executed by privileged guardians.
- **Process and Meta Parameter Control** [Partial]: Right to modify governance process parameters (e.g., voting delay/period, proposal threshold, quorum, timelock delay), but with privileged guardian/whitelist roles present.
- **Technical Parameter Control** [Partial]: Right to approve technical changes to the on-chain protocol (e.g., upgrading or altering core contract behaviour through admin-controlled upgrade surfaces and governance execution).

---

## Optimism (OP)

- **URL**: https://fundamentals.fyi/token/optimism
- **System**: Optimism
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L2 Blockchain, Chains-as-a-Service (Rollups & Appchains)
- **System Description**: Optimism is an Ethereum-based L2 system that provides rollup blockspace through OP Mainnet and rollup deployment infrastructure through the OP Stack for developers, applications, and chain teams. Founded in 2019, Optimism uses the OP Stack optimistic rollup stack, and the system boundary includes OP Mainnet rollup contracts and fee vaults, governance contracts and treasuries, OP Stack software, sequencer operations, and the material off-chain entities Optimism Foundation and OP Labs, while excluding the independent stacks and governance systems of third-party chains built with the OP Stack.

### System Attributes
- **Operating Model**: Optimism combines on-chain rollup infrastructure with material off-chain operational inputs, because OP Mainnet block production is still managed by a single sequencer and the Optimism Foundation currently runs the only block producer on OP Mainnet, while OP Labs and external contributors determine the feature roadmap for the OP Stack.
- **Value Creation**: Value is created by providing Ethereum-secured L2 blockspace via OP Mainnet and other OP Stack based chains, combining on-chain rollup contracts for execution and settlement with critical off-chain operations, most notably a centrally operated sequencer. Additional value is created through the OP Stack and Superchain, where off-chain software development, standards coordination, and ecosystem support enable third parties to deploy OP-based chains. Execution and settlement are on-chain, while platform rollout and coordination are off-chain, resulting in a hybrid value creation model
- **Value Capture**: Transaction fees paid by users for L2 execution are accrued within on-chain fee vault contracts that deterministically account for sequencer fees, L1 data costs, and protocol revenue. These fees are settled on Ethereum and are withdrawable via predefined on-chain flows to designated recipient addresses. Where OP Stack chains participate in shared economic frameworks, value is routed on-chain via transfers to Collective-aligned treasury addresses, rather than through off-chain billing, licensing, or contractual payment rails. No material value is captured through proprietary off-chain revenue streams, enterprise licensing, or corporate balance sheets.
- **Governance**: Optimism’s system governance is organised as a multi-layered structure combining token-based, participant-based, and foundation-governed authority across different system components. OP token holders exercise binding governance over economic parameters, treasury allocation, and protocol direction through the Token House, while the Citizens’ House provides participant-based governance over defined public-goods funding decisions. Protocol safety, upgrades, and emergency actions are managed by a role-based Security Council whose members are elected through governance processes but exercise privileged authority as participants. Off-chain execution, legal custody, and operational implementation of governance decisions are carried out by the Optimism Foundation within mandates set by governance. Because authority is distributed across on-chain token holders, role-based participants, and an off-chain foundation rather than concentrated in a single mechanism. Upgrade authority for OP Mainnet is held by a 2-of-2 multisig between the Optimism Foundation and an elected Security Council.

### Token Functionalities

#### Governance
- **Treasury Control** [Partial]: Right to direct, allocate, or approve the deployment of assets held in Collective-controlled on-chain treasuries, including funding for ecosystem development, incentives, and public goods. This right is Partial because while governance determines allocation decisions, treasury custody and transaction execution are handled by the Optimism Foundation or other designated executors operating under governance mandates. OP governance controls direction, but not direct unilateral custody or execution.
- **Technical Parameter Control** [Partial]: Right to approve changes to the protocol codebase, execution environment, and core technical architecture of OP Mainnet and Superchain-aligned systems. Partial because execution depends on privileged roles such as the Security Council and upgrade multisigs and is subject to safety constraints and staged decentralisation plans. OP holders can direct technical evolution, but cannot independently deploy upgrades without these additional execution layers.
- **Economic Design/Parameter Control** [Partial]: Right to set or amend economic parameters and frameworks that determine monetary flows and incentive structures within the Optimism system, including treasury allocation policies and defined economic programmes. Partial because not all economic levers are directly or automatically executable by token governance. 
- **Actor Set Permissioning** [Partial]: Right to appoint, remove, or rotate members of formally designated governance and security roles within the Optimism system. This functionality is intentionally narrow: OP holders cannot broadly appoint or remove operational actors such as sequencers, chain operators, or Superchain participants at will. As a result, actor-set permissioning exists, but is tightly scoped to governance and safety roles rather than economic operators, and therefore remains Partial.
- **Process and Meta Parameter Control** [Partial]: Right to modify the rules governing governance procedures, including proposal requirements, voting mechanics, delegation frameworks, and structural interactions between governance bodies. The classification remains partial because changes to governance processes must operate within constitutional constraints and often require coordinated execution by governance-appointed actors rather than self-executing contract logic.

---

## Polkadot (DOT)

- **URL**: https://fundamentals.fyi/token/polkadot
- **System**: Polkadot
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): Shared Security and Slot Markets, L1 Blockchain
  - Interoperability and Messaging (secondary): Interchain Standards and Stacks
- **System Description**: Polkadot is a sharded, permissionless protocol providing shared security and interoperable blockspace to a network of sovereign, purpose-built blockchains. Utilizing the Substrate SDK and a Nominated Proof-of-Stake mechanism, it coordinates a decentralized validator set through OpenGov. The system boundary encompasses the Relay Chain, System Parachains, and the coretime allocation market, which manages execution capacity. It excludes external oracle networks and the independent economic runtimes of application-specific parachains, which remain sovereign while consuming the Relay Chain’s underlying security and finality.

### System Attributes
- **Operating Model**: Polkadot is an L1 network that coordinates validators that secure both the Polkadot asset hub and parachains.
- **Value Creation**: Secure, interoperable blockspace is generated by the collective activity of the on-chain validator set.
- **Value Capture**: Revenue from coretime sales and a portion of fees are algorithmically burned or routed to the on-chain Treasury.
- **Governance**: Polkadot is token-governed for upgrades/parameters/treasury through OpenGov referenda with protocol execution, while validator set composition and weighting is participant-governed through stake-based election and nomination mechanics.

### Token Functionalities

#### Governance
- **Process and Meta Parameter Control** [Unilateral]: Right to participate in Opengov Governance v2, which defines tracks, origins, voting curves, and enactment rules
- **Technical Parameter Control** [Unilateral]: Right to approve code upgrades. Runtime upgrades are approved on-chain and autonomously enacted after referendum. Changes use a forkless update path where the blockchain's state transition function is stored on-chain as a Wasm blob.
- **Actor Set Permissioning** [Unilateral]: Right to appoint/remove, or even reweight validator sets or privileged governance actors. Governance can add/remove members of technical collectives or modify validator set parameters.
- **Economic Design/Parameter Control** [Unilateral]: Right to set or amend the economic design and parameters, including Refereundum 1710 and RFC014. Changes don't depend on node operators to update software as changes happen within the runtime rather than the host
- **Treasury Control** [Unilateral]: Right to direct treasury assets. A treasury proposal will pass as long as it meets the required governance thresholds, via the referendum process.

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to produce relay chain blocks. Validators elected via NPoS order transactions and execute state transitions for the Relay Chain, right is exercised via staking DOT
- **Block/State Attestation**: Right to attest parachain state. Validators verify information in assigned parachain blocks, built by collators, to ensure network-wide validity.

#### Collateral
- **Performance-Bond**: Right to put up stake subject to slashing, which is included in Polkadot's NPoS consensus system for validators and nominators.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to have the DOT denominated revenue from Coretime sales burned and removed from supply. Additionally, right to have a portion of unspent treasury balances burnt at regular intervals

#### Payments
- **Native Resource Fee** [Weak]: Right to pay for transaction included in the Polkadot Asset Hub. Asset Hub upgrade notes "Fee flexibility: ability to pay transaction fees in any supported asset.", but DOT remains the canonical fee and pricing unit

---

## Pyth Network (PYTH)

- **URL**: https://fundamentals.fyi/token/pyth-network
- **System**: Pyth Network
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): External Data Oracles
- **System Description**: Pyth Network is a decentralised first-party oracle protocol that delivers high-fidelity, real-time financial market data to smart contract applications across over 100 blockchains. Utilising a "pull-based" architecture on its SVM-based Pythnet app-chain, it aggregates data directly from institutional publishers to achieve sub-second latency. The system boundary includes the PYTH token, Oracle Integrity Staking (OIS) contracts, the Pyth DAO, and the treasury, while excluding external data venues (e.g., Cboe), the Wormhole messaging layer used for cross-chain delivery, and the recipient blockchains' consensus.

### System Attributes
- **Operating Model**: The protocol operates as a hybrid system combining an on-chain blockchain environment (Pythnet) with off-chain data provision by authorised publishers and oracle participants. Publishers supply price data off-chain, which is aggregated and validated within the Pythnet environment before being made available for on-chain consumption. Oracles and relayers then broadcast these verified price feeds to external blockchains, enabling downstream protocols to access and use the data permissionlessly.
- **Value Creation**: Value is created through a hybrid process, where high-quality real-time market data is produced by data providers and transformed into standardised, verifiable price feeds. Off-chain publisher activity generates the underlying informational value, while on-chain aggregation, validation, and availability mechanisms ensure the integrity, timeliness, and composability of that data within blockchain environments.
- **Value Capture**: Value is captured from both on-chain and off-chain sources. On-chain, users and integrators pay update fees to pull fresh price data onto supported blockchains, with these fees routed through protocol-controlled mechanisms. Off-chain, institutional users may subscribe to premium data services (e.g. Pyth Pro), generating additional revenue streams. A portion of both on-chain fees and off-chain revenues is routed to the Pyth Reserve, which functions as a system-level treasury for funding ecosystem development, incentives, and operational sustainability.
- **Governance**: The Pythian council is the dominant governing body, though there is also token based governance through the Pyth DAO on certain parameters

### Token Functionalities

#### Governance
- **Technical Parameter Control** [Partial]: Right to approve code changes. Implementation is partial as the Pythian Council retains limited discretion to delay/veto upgrades for safety.
- **Actor Set Permissioning** [Unilateral]: Right to appoint or remove council members. Token holders possess the exclusive authority to elect and remove members of the Pythian and Price Feed Councils.
- **Economic Design/Parameter Control** [Unilateral]: Right to set or amend economic design parameters (oracle fees, reward structures). Unilateral since councils can only execute actions that have been explicitly delegated by governance as per the legal framework of the Pyth DAO LLC.
- **Treasury Control** [Unilateral]: Right to direct treasury assets. The DAO has binding executive authority over the allocation and expenditure of the Pyth network treasury.

#### Collateral
- **Performance-Bond**: Right to post collateral to data providers that would get slashed for misbehaviour. The process of slashing is at the discretion of the Pyth council.

#### Service Provision
- **Distributed Oracle Service**: Right for permissioned publishers to publish feeds and qualify for rewards by staking PYTH, and accept stake from PYTH holders.

---

## Render (RENDER)

- **URL**: https://fundamentals.fyi/token/render-token
- **System**: Render
- **Dominant Sector**: Trusted Data and Identity
- **Sectors**:
  - Trusted Data and Identity (primary): Off-Chain Compute
- **System Description**: Render is a decentralised GPU rendering and compute marketplace where creators and studios purchase Render Credits to run rendering and compute jobs on a distributed network of node operators. Founded in 2017, it combines Solana-based RENDER token settlement with off-chain rendering orchestration and node software, with the system boundary covering token contracts, burn and emissions mechanisms, governance voting, and the node operator stack, while excluding base-layer consensus and external trading venues.

### System Attributes
- **Operating Model**: Render is best classified as a hybrid system combining an off-chain business with an on-chain protocol. Core off-chain operations are run by OTOY and the Render Network Foundation and Render Network Team, covering rendering software and IP, governance administration, operational coordination, and implementation of approved changes, while on-chain components handle settlement and accounting for the RENDER SPL token, including burn and mint conversion into Render Credits and emissions and incentive flows. Node participation is not permissionless, but application-based through a foundation-managed onboarding process.
- **Value Creation**: Value in Render is created primarily off-chain, because the core productive activity is GPU compute and rendering performed by node operators that output rendered frames. Public network statistics reporting tens of millions of frames rendered and thousands of nodes since inception evidence ongoing off-chain production at scale.
- **Value Capture**: Job payments are routed to node operators as direct compensation for rendering work, while the protocol also applies an explicit network fee (e.g., 5%) intended to fund operational costs and therefore creates an additional off-chain value capture surface financed by system flows.
- **Governance**: Render operates a hybrid system governance model combining token-based governance with off-chain, foundation-governed control. Binding decisions over protocol direction within the defined RNP scope are exercised by RENDER token holders via formal, token-weighted votes, while governance process administration, implementation of approved changes, and compute node onboarding remain controlled off-chain by the Foundation and core contributors. As a result, the system is not purely entity-governed, but execution and participation controls are materially centralised despite live, on-chain token governance.

### Token Functionalities

#### Governance
- **Economic Design/Parameter Control** [Partial]: Right to approve adjustments to economic parameters and token economics through the governance process. Foundation directors can reject approved proposals during a cooldown period and can adjust economic parameters in emergency conditions.
- **Product/Service Line Decisions** [Partial]: Right to approve the introduction of new features or services (material product/service line decisions) through the RNP process. Approved proposals remain subject to Foundation director approval and off-chain execution.
- **Actor Set Permissioning** [Unilateral]: Right to elect and remove Foundation directors and the Foundation supervisor (formal governance actors), within the constraint that the Foundation cannot be left without a director and/or supervisor.
- **Treasury Control** [Partial]: Right to approve Foundation multisig spending, including grants, commercial agreements, and employee contracts, subject to legal and compliance constraints. Execution is still mediated and proposals/spend can be blocked through the director approval stage.
- **Technical Parameter Control** [Partial]: Right to approve protocol-level technical changes, including modifications to rendering algorithms or network infrastructure, via RNP governance votes. Foundation directors can reject approved proposals during a cooldown period.
- **Process and Meta Parameter Control** [Partial]: Right to modify governance rules, including changing DAO quorum requirements and consenting to bylaw / article changes that amend or remove tokenholder rights. Directors retain amendment authority in certain cases and can operate under emergency procedures.

#### Payments
- **Prepaid Credit**: Right to redeem RENDER with the system for Render Credits (a closed-loop, non-transferable “coupon token” used to submit work).

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from supply reduction via systematic burning of RENDER as part of network operations under the burn and mint equilibrium mechanism.

---

## Ripple (XRP)

- **URL**: https://fundamentals.fyi/token/ripple
- **System**: Ripple
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Payment and Settlement Networks, Stable Value Issuers
  - Blockspace Production (secondary): L1 Blockchain
- **System Description**: Ripple provides cross-border payments and settlement rails that use digital assets to move value between counterparties, primarily serving banks, fintechs, and payment providers. Founded in 2012, it combines the XRP Ledger and XRP with Ripple-operated payment software and RLUSD issuance and reserve infrastructure across XRPL and Ethereum. The system boundary includes Ripple Payments, XRP, and RLUSD issuance and management, while excluding third-party wallets, exchanges, and unrelated tokens issued on XRPL.

### System Attributes
- **Operating Model**: Ripple’s buyer-facing payments and stablecoin operations rely on identifiable off-chain operations, while settlement and core token-enforced constraints (fees/reserves) are provided by the XRPL on-chain protocol.
- **Value Creation**: The user-valued payments and settlement service is delivered through a hybrid model that combines off-chain payment rails and integrations with on-chain settlement finality on the XRP Ledger. Ripple describes its payments offering as leveraging digital assets and XRPL transactions to complete and finalise cross-border value transfers.
- **Value Capture**: System value capture and routing in the Ripple system is hybrid. On-chain, the XRP Ledger routes value through protocol-enforced burning of transaction costs, reducing XRP supply rather than distributing fees to operators. Off-chain, Ripple captures value via Ripple Payments service fees, collected through quoting, deduction, or invoicing, and through net returns on RLUSD reserves that are withdrawable by Ripple under the RLUSD terms.
- **Governance**: Governance in the Ripple system combines on-chain participant-based governance with off-chain entity governance. On-chain, XRPL protocol changes are activated through validator signalling thresholds, with authority tied to the validator role rather than token holding. Off-chain, Ripple’s RLUSD issuance and operational terms are governed by an identifiable corporate entity.

### Token Functionalities

#### Collateral
- **Financial Collateral** [Weak] (Exogenous): XRP used as collateral on lending protocols (Venus, Kinetic)

#### Payments
- **Native Resource Fee** [Strong]: Right to consume XRPL resources (transaction processing and ledger object/state access) by paying transaction costs and meeting protocol-enforced reserve requirements in XRP.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from supply reduction via transaction costs that are irrevocably destroyed (burned) on XRPL.

---

## Solana (SOL)

- **URL**: https://fundamentals.fyi/token/solana
- **System**: Solana
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Solana provides a permissionless, high-throughput, low-latency execution and settlement network designed for real-time applications, enabling users and developers to execute programs and settle transfers via on-chain transactions priced in SOL. Founded in 2017, it uses Proof of Stake combined with Proof of History for cryptographic time-ordering, a BFT-style consensus protocol (Tower BFT), and a parallel runtime for concurrent execution and fast confirmation. The system boundary includes the Solana mainnet protocol (execution and consensus), validators and nodes, SOL as the native asset, staking and inflation mechanisms, the on-chain fee market (including fee burning and validator rewards), open-source client software, and Solana Foundation support, and excludes application-layer protocols, external L2s and other blockchains, bridges, and third-party wrapped SOL as separate systems.

### System Attributes
- **Operating Model**: Solana's blockchain operates as a fully on-chain protocol, where permissionless validators run protocol client software to produce blockspace (ordering/executing transactions and voting on blocks) rather than a single off-chain operator controlling execution. Validators require specialised hardware and the validator set consists of roughly 800 validators.
- **Value Creation**: The Solana blockchain creates value by producing general-purpose blockspace, enabling developers and users to execute on-chain programmes. Network usage generates SOL-denominated fees.
- **Value Capture**: Solana participants capture value through transaction fees paid in SOL and inflationary issuance, routing revenues primarily to validators and delegators (staking rewards), while burning a portion of base fees which accrues to SOL holders via supply reduction.
- **Governance**: Solana’s governance is layered and predominantly participant-based. Consensus protocol upgrades and economic changes ultimately take effect through validators choosing which client software to run, often following stake-weighted validator voting that is advisory rather than binding, with influence re-weighted by delegated SOL stake. Validator admission is permissionless for anyone operating the required infrastructure, while validator influence is token-weighted through SOL delegation. Certain feature-gate scheduling and activation operations, however, are controlled by restricted authority accounts that have historically been associated with Solana Labs and Foundation-aligned operators, introducing a limited entity-governed coordination layer within the broader participant-driven upgrade model.

### Token Functionalities

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to execute state transitions and sequence transactions by operating a validator with sufficient stake weight to be scheduled as leader under Solana’s Proof-of-Stake mechanism. When selected as leader, the validator has the protocol-enforced right to include transactions, determine ordering, and produce blocks in accordance with consensus rules.

#### Collateral
- **Financial Collateral** [Strong] (Exogenous): Right to use SOL as financial collateral in Solana DeFi application ecosystem, especially lending applications.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from protocol-enforced supply reduction through the automatic burning of a portion of transaction fees, which reduces total SOL supply and proportionally increases each holder’s percentage ownership of the network.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay transaction processing fees on Solana blockchain exclusively in SOL. All users and applications that access execution and settlements have to submit transactions to network of validators.
- **General Medium of Exchange** (Exogenous): Right to access primary token sales on the Solana blockchain that are quoted in SOL, this includes memcoin creation sales. Right to trade on Solana-based decentralized exchanges with SOL where SOL is the quote asset in the trading pair.

#### Governance
- **Actor Set Permissioning** [Unilateral]: Right for SOL holders to re-weight validators by delegating stake, thereby directly altering stake-weighted voting power and leader selection frequency through on-chain delegation mechanics. This right is endogenous and unilateral within the re-weighting surface, as redelegations are permissionless and automatically enforced by the protocol, while validator admission remains permissionless and outside token-holder appointment or removal control.

---

## Stacks (STX)

- **URL**: https://fundamentals.fyi/token/blockstack
- **System**: Stacks
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L2 Blockchain
- **System Description**: Stacks is a Bitcoin-anchored smart contract blockchain that provides execution and transaction inclusion for application developers and end users, and supports native Bitcoin liquidity via sBTC. Founded in 2021, it uses the Stacks chain, Clarity smart contracts, and Proof-of-Transfer with Nakamoto signers to anchor state, security, and Bitcoin-backed assets to Bitcoin. The system boundary includes the Stacks blockchain, PoX mining and stacking, sBTC minting and redemption flows, and Bitcoin anchoring and reward transfers, while excluding Bitcoin governance and application-layer dApps.

### System Attributes
- **Operating Model**: Stacks’ day-to-day operation is supplied by permissionless protocol participants: miners compete by committing BTC and signers/stackers lock STX and sign blocks under protocol rules, without a single operator required to run the chain.
- **Value Creation**: The system’s core product is blockspace: smart contract execution and transaction inclusion on the Stacks chain, positioned as a Bitcoin layer for smart contracts.
- **Value Capture**: Value is captured and routed primarily to protocol participants: users pay transaction fees in STX; miners receive STX fees and block rewards; and PoX routes BTC commitments from miners to STX stackers/signers as Bitcoin rewards.
- **Governance**: The SIP process establishes formal off-chain roles and coordination structures, with foundation-governed elements plausibly present around programme management and committee formation within the system boundary. STX-holder votes via SIPs function as the recognised gating condition for changes to economic parameters such as emissions and supply, introducing a token-based governance component for that decision surface. However, protocol upgrades and hard forks remain participant-based in practice, as binding effect depends on node operators, miners, and signers adopting upgraded software, leaving the most-privileged condition for execution with system participants rather than token holders.

### Token Functionalities

#### Service Provision
- **Block/State Attestation**: Right to attest to Stacks blocks by acting as a signer (requires locking STX; signers validate and sign blocks, and rewards are contingent on performing signer duties).

#### Governance
- **Economic Design/Parameter Control** [Partial]: Right for STX holders to approve or reject changes to economic design parameters (e.g., supply/emissions) via SIP voting; passed proposals are implemented via protocol hard fork.
- **Technical Parameter Control** [Partial]: Right to vote on consensus‑breaking protocol changes via network-wide public voting as an STX holder.

#### Payments
- **Native Resource Fee** [Strong]: Right to pay protocol transaction fees in STX (microSTX) to have transactions and smart contract calls processed on Stacks.

---

## Stellar (XLM)

- **URL**: https://fundamentals.fyi/token/stellar
- **System**: Stellar
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Payment and Settlement Networks
  - Blockspace Production (secondary): L1 Blockchain
- **System Description**: Stellar is a public blockchain network for payment settlement and the issuance of tokenised assets, with built-in asset conversion and the Soroban smart contract platform. Founded in 2014, it operates using Stellar Core and the Stellar Consensus Protocol alongside Soroban. The system boundary includes the Stellar ledger, validators, the native XLM asset, the protocol-level DEX and liquidity pools, and the Stellar Development Foundation, while excluding third-party anchors, wallets, and exchanges.

### System Attributes
- **Operating Model**: Stellar is best classified as an on-chain protocol, coordinating a distributed set of validators to deliver payment settlement and core protocol operations without reliance on a central service operator. The Stellar Consensus Protocol enables an open, distributed validator set, and the network does not depend on explicit on-chain incentive payments to node operators.
- **Value Creation**: Value is created on-chain through protocol-level execution of settlement and financial primitives, including asset issuance and trustlines, path payments routed via the built-in DEX and liquidity pools, and Soroban smart contract execution. Path payments explicitly traverse the Stellar DEX and liquidity pools, and application logic executes directly on the Soroban mainnet, demonstrating that the service is produced at the protocol level.
- **Value Capture**: Value capture and routing in Stellar is on-chain. Protocol fees are paid in XLM and routed into a locked fee pool rather than being distributed to validators or other participants, and Soroban fees follow the same locked-pool design.
- **Governance**: Governance in Stellar combines participant-based and off-chain entity governance. Protocol upgrades and key network parameters are controlled through validator participation, where authority depends on operating a validator rather than holding XLM. In parallel, the Stellar Development Foundation acts as an identifiable off-chain entity that coordinates protocol development and broader ecosystem direction.

### Token Functionalities

#### Payments
- **Native Resource Fee** [Strong]: Right to submit transactions and pay Stellar protocol network fees in XLM.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit pro-rata from protocol-enforced supply reduction through the accumulation of transaction fees in an inaccessible, non-circulating fee pool, which mechanically increases each holder’s relative share of the circulating supply without requiring discretionary distribution.

---

## Sui (SUI)

- **URL**: https://fundamentals.fyi/token/sui
- **System**: Sui
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: Sui is a layer-1 smart contract blockchain that provides transaction execution, finality, and on-chain state storage, allowing application teams and end users to purchase blockspace to run smart contracts and transfer digital assets. Founded in 2021, it uses the Move programming language and a delegated proof-of-stake consensus design. The system boundary includes the Sui mainnet protocol, covering validators, full nodes, system Move modules, staking, and gas and storage fund mechanics, as well as the protocol upgrade mechanism, while excluding application-layer dApps, bridges, wallets, and centralised exchanges.

### System Attributes
- **Operating Model**: Sui operates as an on-chain protocol in which validator nodes participate in delegated proof-of-stake consensus to execute and validate transaction blocks, while full nodes validate state and serve history and query requests. Validator responsibilities also include protocol-level tasks such as staking operations, gas price reference updates, and execution of system transactions.
- **Value Creation**: Value in Sui is created on-chain through the sale of metered execution and storage resources to users and application teams. Transactions directly represent on-chain operations, including asset transfers, object creation, and smart contract interactions, with gas paid in SUI to consume protocol resources.
- **Value Capture**: Value in Sui is captured and routed on-chain via gas fees paid in SUI for computation and storage. Computation fees and stake reward subsidies are pooled each epoch and distributed to validators and their stakers, while storage fees accrue to a dedicated storage fund whose rewards are routed to validators to offset storage costs, with partial rebates issued when stored data is deleted.
- **Governance**: Binding protocol upgrades are participant-based, requiring validator votes meeting a supermajority threshold to adopt new protocol versions. By contrast, the validator actor set is token-mediated in its weighting, as any SUI holder can stake or delegate to deterministically re-weight validator voting power, with validator admission mechanics reflecting a mixed surface where stake-based weighting is token-driven but operational entry actions remain participant-gated.

### Token Functionalities

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to execute deterministic state transitions and decide transaction inclusion/ordering as a validator, which requires staking SUI; validators are rewarded via protocol-defined fees/rewards, and SUI holders can delegate stake to validators (supporting validator selection/weighting).

#### Governance
- **Actor Set Permissioning** [Unilateral]: Right to appoint/remove/re-weight validators by staking/delegating or withdrawing staked SUI, which deterministically changes validator voting power used in consensus/governance (token holding is sufficient; no extra privileged role required).
- **Economic Design/Parameter Control** [Partial]: Right to influence/approve changes to protocol-level economic parameters (e.g., storage fee) through the network’s governance process, executed via validator decision-making at epoch boundaries.
- **Technical Parameter Control** [Partial]: Right to participate in protocol upgrade decisions (protocol version/framework upgrades) through validator voting and epoch activation.

#### Payments
- **Native Resource Fee** [Strong]: Right to consume the system’s valuable resources (execution and storage) where payment is enforced in the native token as gas fees.

#### Collateral
- **Financial Collateral** [Weak] (Exogenous): SUI is used as collateral on the Suilend and NAVI Lending lending markets.

---

## Tether (USDT)

- **URL**: https://fundamentals.fyi/token/tether
- **System**: Tether
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Stable Value Issuers
  - Tokenised Assets (secondary): Commodities
- **System Description**: Tether is a centralised stable-value issuer that provides USD₮, a digital asset designed to maintain parity with the U.S. dollar, and also issues XAU₮, a gold-backed token. Founded in 2014, it operates as a for-profit financial service across multiple public blockchains; the system boundary includes Tether’s corporate entities, reserve-management infrastructure, and official token contracts, and excludes the underlying blockchain consensus layers, external DeFi protocols, and third-party exchanges. USD₮ remains the system’s primary settlement rail for digital liquidity.

### System Attributes
- **Operating Model**: Tether relies on centralised corporate entities to run issuance, redemption, reserve management, compliance, and privileged token administration. The core service is not supplied by open, independent providers; public blockchains act as external distribution rails rather than the operating core.
- **Value Creation**: The core product is created through off-chain issuer operations: taking in fiat or commodity backing, managing reserves or custody, and issuing or redeeming tokens against those assets. The token contracts primarily distribute these issuer-managed claims across third-party blockchains.
- **Value Capture**: Monetary value is captured primarily by the issuer entities through reserve income, fees, and related financial operations. Token holders receive transferability and redemption rights, but do not receive the reserve upside as an automatic token-holder entitlement.
- **Governance**: The Tether Board unilaterally controls all economic parameters, reserve management, and technical upgrades.

### Token Functionalities

#### Collateral
- **Financial Collateral** [Strong] (Exogenous): Used to underwrite overcollateralized loans. USDT is a primary collateral asset in major DeFi lending markets (Aave, Compound) and CEX margin trading.
- **Stablecoin-Reserve Asset** [Strong] (Exogenous): Used to anchor synthetic assets. USDT is used as a core backing component for USDe (Ethena) and other derivative stablecoins.

#### Payments
- **General Medium of Exchange** (Exogenous): Used to settle payments and debts. USDT is the widely accepted for global on-chain trade, CEX settlement, and retail remittances.

#### Asset Ownership
- **Off-Chain Asset Title/Pool Share** [Strong]: Right to redeem 1:1 for USD from Tether's off-chain reserve.

---

## Toncoin (TON)

- **URL**: https://fundamentals.fyi/token/the-open-network
- **System**: TON
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L1 Blockchain
- **System Description**: The Open Network (TON) is a proof of stake, general-purpose Layer-1 blockchain that provides blockspace through transaction execution and ordering using a sharded multi-chain architecture. Founded in 2018 as Telegram’s original TON initiative and later continued by independent developers with ecosystem support from a Swiss-based non-profit foundation, TON is the exclusive blockchain infrastructure for Telegram Mini Apps that integrate on-chain functionality. The system boundary includes the TON protocol and system contracts, validator operations, TON Connect integration surfaces, and Stars-to-Toncoin withdrawal flows, while excluding Telegram’s non-Web3 messaging features and unrelated third-party applications.

### System Attributes
- **Operating Model**: TON operates as an on-chain protocol for blockspace production (validators coordinate block production and set fee levels via protocol voting), while simultaneously relying on an off-chain business component because Telegram centrally controls key distribution and integration surfaces for Telegram Mini Apps.
- **Value Creation**: Value is created on-chain through transaction execution, inclusion, and settlement provided by validators, and off-chain through Telegram Mini Apps and Stars monetisation features that drive usage and route activity into TON. Telegram Stars balances can be withdrawn as Toncoin, reinforcing TON’s role as the exclusive blockchain infrastructure for Mini Apps that integrate on-chain functionality.
- **Value Capture**: On-chain, value is captured and routed through transaction fees, with fee levels governed by validator voting. Off-chain, value is routed when Telegram platform activity, including Stars balances and certain Telegram service payments, converts into Toncoin flows used for developer and creator payouts.
- **Governance**: Participant-based authority applies to protocol parameters, which are governed through validator voting and enforced by system contracts, while token-based authority exists over actor set weighting via staking and delegation that re-weights validator stake. Separately, entity-governed authority applies to Telegram Mini Apps blockchain integration rules, where Telegram is the most privileged decision-maker, mandating TON and TonConnect usage under its official guidelines.

### Token Functionalities

#### Governance
- **Actor Set Permissioning** [Unilateral]: Right to move/re-weight privileged actors (validators) by (i) applying as a validator with stake and (ii) re-weighting validator stake via delegation mechanisms, which deterministically affects validator election outcomes (opt-in holder / role-gated).
- **Process and Meta Parameter Control** [Partial]: Right to modify governance process parameters (e.g., proposal acceptance rules such as min_wins, vote thresholds, and critical-parameter handling) encoded as configuration parameters in the Config contract (role-gated validator right)
- **Technical Parameter Control** [Partial]: Right to execute changes to core technical parameters (e.g., network version, consensus/catchain/VM-related configuration stored in config) via validator-governed Config updates (role-gated validator right).
- **Economic Design/Parameter Control** [Partial]: Right to approve and execute changes to monetary parameters (fees/gas prices, block rewards, slashing/fines) via Config proposals voted by the active validator set (role-gated validator right; stake-weighted approvals).

#### Service Provision
- **State Transition Execution and Transaction Sequencing**: Right to execute deterministic state transitions and decide transaction inclusion and ordering for a block by operating as a validator with TON stake. Validators perform block production and protocol execution under proof of stake rules defined by the TON protocol.

#### Payments
- **General Medium of Exchange**: Right to use TON as a medium of exchange with willing counterparties within Telegram’s platform surfaces, where TON is the supported cryptocurrency for eligible payments and transfers. This right is conditional on acceptance and enablement by Telegram under its platform rules.
- **Native Resource Fee** [Strong]: Right to access the system’s core resource of transaction execution and inclusion by paying protocol fees in TON. Fees are deducted and settled in TON, with fee levels governed by validator voting, and no alternative fee currencies implemented at the protocol level.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased proportional token ownership through protocol-enforced fee burning tied to system operations. A portion of transaction fees is burned at the protocol level, reducing effective supply and increasing remaining holders’ relative ownership.

#### Collateral
- **Performance-Bond**: Right to post slashable surety in the form of TON stake to guarantee honest behaviour when acting in the delegated validator role. Validator stake is subject to protocol-defined penalties, including slashing or fines, enforced through system contracts and configuration in cases of misbehaviour.

---

## Uniswap (UNI)

- **URL**: https://fundamentals.fyi/token/uniswap
- **System**: Uniswap
- **Dominant Sector**: Trading and Exchange
- **Sectors**:
  - Trading and Exchange (primary): Decentralized Spot Exchange
- **System Description**: Uniswap is a decentralised spot exchange protocol that enables traders to swap ERC-20 tokens directly from self-custody wallets using automated market maker liquidity pools and router smart contracts. Launched in 2018, it operates on EVM-compatible blockchains, with governance and fee mechanisms coordinated via Ethereum-based contracts and the UNI token. The system boundary covers the Uniswap protocol deployments, governance and protocol-fee infrastructure, and Uniswap Labs interfaces, while excluding the underlying L1 or L2 consensus layers and third-party front ends.

### System Attributes
- **Operating Model**: Uniswap’s core service (spot trade execution via pooled liquidity) is provided by on-chain smart contracts that admit open participation (anyone can trade; anyone can supply liquidity). Off-chain interfaces exist but are not required to access the protocol directly.
- **Value Creation**: The productive activity that creates value, providing liquidity and executing swaps, occurs on-chain in the pool contracts, with pricing and settlement enforced by smart contracts.
- **Value Capture**: Value is captured primarily as swap fees: LP fees are routed to liquidity providers, while protocol fees (where enabled) route into an on-chain collector pipeline that is configured to burn UNI under the 'UNIfication' change.
- **Governance**: UNI holders (often via delegation) submit and vote on binding on-chain proposals executed through Uniswap's Timelock and Governor contracts (e.g., economic parameters, treasury actions, fee-switch activation). Uniswap Labs' operation of uniswap.org does not constitute off-chain entity governance, as the interface charges no fees (as of 27th December 2025), and the protocol remains independently accessible via alternative interfaces or direct contract interactions.

### Token Functionalities

#### Governance
- **Process and Meta Parameter Control** [Unilateral]: Right to modify governance-process rules (decision procedure parameters), including voting delay/period and proposal threshold (admin-only setters exist in the on-chain governance implementation).
- **Actor Set Permissioning** [Unilateral]: Right to constitute, scope, and revoke formally permissioned DAO roles and committees, including granting or withdrawing their on-chain authorities, via governance-defined processes with binding execution.
- **Treasury Control** [Unilateral]: Right to direct and authorise transfers from the DAO treasury, including grant allocations (e.g., foundation funding and ecosystem programmes), via binding on-chain proposal approval and execution.
- **Economic Design/Parameter Control** [Unilateral]: Right to set/amend monetary-flow parameters (e.g., protocol fee activation/routing and other “valves”) via binding on-chain governance execution.
- **Product/Service Line Decisions** [Partial]: Right to approve or veto the official designation of chain deployments, and to mandate their execution by authorised committees, with binding committee implementation rather than automatic smart-contract execution.

#### Value Distribution
- **Burn Entitlement** [Algorithmic or Guaranteed]: Right to benefit from increased percentage token ownership via systematic UNI burning funded/triggered by system operations (protocol fees routed into a burn mechanism).

---

## USDC (USDC)

- **URL**: https://fundamentals.fyi/token/usd-coin
- **System**: Circle
- **Dominant Sector**: Money and Payments
- **Sectors**:
  - Money and Payments (primary): Stable Value Issuers
- **System Description**: Circle is a regulated financial technology firm that issues USDC (a fully-reserved digital dollar) and EURC (a fully-reserved digital euro). Founded in 2013, the system facilitates minting and redemption backed by the Circle Reserve Fund. The system boundary includes Circle’s licensed issuance infrastructure, compliance controls, native token contracts, and the Cross-Chain Transfer Protocol (CCTP) for interoperability. It excludes the underlying consensus mechanisms of host blockchains, third-party DeFi protocols, and secondary market liquidity providers, which operate independently of Circle’s core reserve management and primary issuance systems.

### System Attributes
- **Operating Model**: The system depends on Circle-controlled issuer infrastructure, reserve management, compliance controls, and contract administration to deliver minting, redemption, and cross-chain transfer services. Although the boundary includes on-chain token contracts and CCTP, the critical operational inputs remain centrally controlled rather than supplied by open independent operators.
- **Value Creation**: Value is created through Circle’s off-chain reserve management, regulated issuance and redemption infrastructure, and compliance-controlled minting and redemption processes, together with on-chain token contracts and CCTP-based interoperability that enable native transfer and settlement across supported blockchains. The core service therefore depends on both off-chain issuer operations and in-boundary on-chain infrastructure.
- **Value Capture**: System value is primarily captured through off-chain reserve-related economics and routed to Circle-controlled entities and contractual counterparties. The included on-chain components support distribution, transfer, and interoperability, but do not create a tokenholder claim on system cash flows.
- **Governance**: Circle Internet Group, Inc. is a publically traded corporation

### Token Functionalities

#### Asset Ownership
- **Off-Chain Asset Title/Pool Share** [Strong]: Right to redeem 1:1 for USD from Circle's off-chain reserve. 

#### Collateral
- **Stablecoin-Reserve Asset** [Strong] (Exogenous): Used to anchor synthetic assets. Ethena and other protocols use USDC as a stable backing component to maintain the delta-neutral peg of USDe.
- **Financial Collateral** [Strong] (Exogenous): Used to underwrite overcollateralized loans. USDC is the primary low-volatility asset used to underwrite overcollateralized debt in DeFi protocols like Aave and Compound.

#### Payments
- **General Medium of Exchange** (Exogenous): Used to settle payments and debts. USDC is widely accepted as a final settlement asset by on-chain merchants, payment networks, DAOs, and off-chain vendors.

---

## Wormhole (W)

- **URL**: https://fundamentals.fyi/token/wormhole
- **System**: Wormhole
- **Dominant Sector**: Interoperability and Messaging
- **Sectors**:
  - Interoperability and Messaging (primary): General Messaging Layers, Asset Transfer Bridges
  - Tokenised Assets (secondary): Issuance and Servicing Platforms
- **System Description**: Wormhole provides a cross-chain interoperability and messaging system enabling applications, wallets, and chains to transmit verified messages and assets across heterogeneous blockchain environments. Founded in 2020, it uses a hybrid architecture with on-chain verification contracts across supported chains and an off-chain, permissioned Guardian network that observes events, attests to them, and produces signed messages, supported by relayer infrastructure that submits transactions. The system boundary includes Wormhole Core contracts, messaging and token bridge modules, Guardian nodes, relayers and executors, the Wormhole DAO governance framework, the W token, and the Wormhole Foundation as a coordinating governance entity, and excludes underlying L1 and L2 blockchains, their consensus systems, bridged assets, and third-party applications that merely use Wormhole for cross-chain communication as separate systems.

### System Attributes
- **Operating Model**: Wormhole depends on on-chain contracts for message publication, verification and cross-chain execution, but economically critical attestation comes from a permissioned Guardian set and automatic execution depends on off-chain relay providers.
- **Value Creation**: Core product is a cross-chain message that is verified on a destination network's core contracts, with fees levied by applications built upon it. Verification depends on a signed message from a 13-of-19 Guardian set supermajority, and automated delivery depends on off-chain relay providers and quoters (even though quotes may be verifiable on-chain).
- **Value Capture**: Value from fees on the dedicated front-end "Portal" don't accrue to any known on-chain participant. Whilst contracts may charge a core message fee, Guardian governance can set that fee and transfer accumulated fees, and the Executor can route delivery payments to a payee address, these are not currently active.
- **Governance**: Although there is token governance through Multigov, there is no meaningful decision making being delegated to it, with virtually all decisions being made through the foundation/labs entities.

---

## ZKsync (ZK)

- **URL**: https://fundamentals.fyi/token/zksync
- **System**: zkSync
- **Dominant Sector**: Blockspace Production
- **Sectors**:
  - Blockspace Production (primary): L2 Blockchain, Chains-as-a-Service (Rollups & Appchains)
- **System Description**: zkSync Era is a general-purpose ZK rollup Layer 2 that provides EVM-compatible execution and settlement on Ethereum, enabling users and applications to purchase L2 blockspace to execute smart contracts and transfer assets. Founded in 2019, it uses a zkEVM-style architecture with off-chain sequencing and proving, while relying on ETH for transaction fee payment and for settlement costs when posting data and proofs to Ethereum. The system boundary includes the zkSync Era chain, Ethereum rollup and bridge contracts, governance contracts and ZK token governance machinery, and sequencer and prover infrastructure, while excluding Ethereum base-layer consensus and third-party applications deployed on zkSync Era.

### System Attributes
- **Operating Model**: zkSync Era relies on an on-chain rollup protocol for settlement and governance smart contracts, while operational throughput depends on off-chain sequencing and proving components (sequencer/prover lifecycle).
- **Value Creation**: Value (L2 execution capacity with fast confirmations) is created through off-chain transaction ordering and proof production, paired with on-chain verification/settlement guarantees of a ZK rollup design.
- **Value Capture**: On zkSync Era, L2 transaction fees are collected by an operator-owned FeeCollector, used to pay unavoidable Ethereum L1 costs such as pubdata posting and proof verification, and withdrawn to L1 to fund the ETH operator. Any net surplus remains under operator control rather than being programmatically routed to ZK token holders, with the exact split between costs and retained surplus not fully specified in the available documentation.
- **Governance**: Binding governance over protocol upgrades and governance contract changes is exercised via ZK-token delegated voting through on-chain governor contracts, but is constrained by Guardian veto and Security Council/Guardian approval steps (participant-based checks); operational control of the sequencer is described as centralised, indicating an off-chain entity-governed component.

### Token Functionalities

#### Governance
- **Economic Design/Parameter Control** [Partial]: Right to approve Token Program Proposals that assign minting/burning rights (and caps/mechanics) for ZK token programs governed by the Token Governor (covering the Token Assembly-controlled allocation).
- **Process and Meta Parameter Control** [Partial]: Right to upgrade components of the governance system (Protocol/Token/GovOps governors) via ZIPs, changing governance process parameters through contract upgrades.
- **Actor Set Permissioning** [Partial]: Right to approve ZIPs that upgrade the Security Council and Guardian multisigs (including membership changes), affecting privileged governance actor sets.
- **Technical Parameter Control** [Partial]: Right to vote on ZIPs via the Protocol Governor to upgrade zkSync protocol components (executed via a message from zkSync to Ethereum), subject to the broader multi-body governance process.

---