What a Cryptoeconomic System Actually Is

Once you know what a system sells, and therefore which sector it belongs in, a harder question follows. What kind of system delivers that service?

This is where crypto analysis often becomes undisciplined. Once a project has been placed in a familiar category, discussion often jumps straight to the token. People ask whether the token has utility, whether governance is decentralised, or whether growing usage will accrue to holders. But those are not the first questions. Before any of them can be answered properly, the system itself has to be defined.

A token is not the system. A token may sit at the centre of the story while the economically important activity happens somewhere else. A system may generate real demand, real revenue, and real strategic importance while its token governs only a narrow component and sits outside the main path of value capture. System significance does not automatically imply token significance.

That is why Fundamentals places the System Taxonomy between Sector Classification and the Token Functionality Framework. Sector tells you what the system sells. The system layer tells you what kind of economic arrangement produces that service. Only then does it make sense to ask what role token ownership really plays.

System Taxonomy is the second of three analytical questions in understanding systems and tokens.

Open a Fundamentals profile and this layer appears in compact form. There is a short System Description, followed by four structural fields: System Operating Model, System Value Creation, System Value Capture and Routing, and System Governance. Those fields are not a formatting choice. They are the minimum structure needed to stop token analysis floating free of the underlying system.

The System as the Unit of Analysis

In Fundamentals, the system is the economic system being analysed. In practice, that means the economically relevant arrangement of on-chain components and, where material, off-chain entities and infrastructure that together deliver the service identified at the sector layer.

That definition matters. A system is not merely a token contract. It is not merely a set of protocol components. It is not merely a company. It is the arrangement of components that actually delivers the product or service to buyers or users.

This is also why broad labels such as decentralised and centralised are usually too blunt to do serious work on their own. They compress several questions into one. Where does the productive activity occur. Where does value get captured. Who controls the material components. Can users reach the service without a privileged intermediary. Those questions do not always move together. A system can create value on-chain while capturing much of it off-chain. It can expose some components to token voting while keeping others under entity control. It can look decentralised at the surface and remain structurally dependent elsewhere.

The system layer exists to make those differences visible.

Boundary Before Judgement

Before you can analyse a system, you need to know what sits inside the boundary.

This sounds obvious, but it is one of the places where crypto analysis most often goes wrong. People talk about value capture, decentralisation, and token relevance before they have decided what the relevant unit of analysis even is. Without a clear boundary, later conclusions become unstable because they are all boundary-dependent.

In Fundamentals, on-chain components are generally in scope because they form part of the native cryptoeconomic arrangement through which the service is produced, coordinated, or enforced. Off-chain components are included only where they are materially relevant to one of four things: delivering or accessing the core service, creating value, capturing or routing value, or holding binding decision rights over an in-boundary component. That materiality test is what keeps the system boundary economically coherent.

The importance of that rule becomes obvious once off-chain components enter the picture. In some systems, legal entities, compliance controls, reserve assets, banking relationships, distribution agreements, or operational infrastructure are indispensable to the service itself. In others, those surrounding institutions matter commercially or socially but are not operationally necessary to deliver the product. Treating every visible off-chain entity as part of the system would overstate centralisation in some cases and understate it in others.

Front ends are a good example. An entity-run interface is not automatically part of the system boundary. It becomes material only where it is a privileged distribution channel, for example, because it controls exclusive access, receives protocol-granted privilege, applies material interface fees, or can materially gate access where there is no practical substitute. This prevents the analysis from treating every official website as evidence that the entity governs the system.

That is also why the boundary is expressed through a concise System Description. The description states the service being provided, identifies the materially relevant components inside the boundary, and notes important exclusions where they affect interpretation. It should not smuggle in later conclusions about value capture or governance. Those belong in their own fields. A system that cannot be described clearly usually has not yet been bounded clearly. Where another transferable token is materially relevant to the operation, structure, or interpretation of the system, Fundamentals may also list it as “Other Tokens in the System”.

The token profile page displays the System Description, Structural Fields, and Other Tokens in the System.

How the Service Is Delivered

Once the boundary is clear, the next question is how the system delivers its core service on a day-to-day basis. Fundamentals records this as the System Operating Model.

At a high level, systems fall into three broad forms.

Some are Off-Chain Businesses. These rely on centralised entities, whether for-profit or non-profit, for essential operational inputs. Critical user interactions such as custody, issuance and redemption, account control, managed distribution, or matching occur through infrastructure controlled by the entity. A token may still matter economically, but it extends the business model rather than constituting the operating core.

Some are On-Chain Protocols. Here, the core service is produced through open or credibly open participation, and the economically critical coordination, measurement, rewards, penalties, and settlement needed to deliver that service are enforced on-chain. Off-chain work may still exist, but the product does not depend on a privileged operator in the same way. This is the structure many people have in mind when they talk about crypto-native systems, but it should not be assumed. It has to be demonstrated.

And some are Hybrid Systems. These combine economically material off-chain business inputs with economically material on-chain protocol inputs. This hybrid form is common. It is also one reason why slogans about decentralisation so often fail. A system may use on-chain coordination for one essential function while still relying on a company, foundation, or operator for another essential function. The right question is not whether the project sounds decentralised. The right question is which operational inputs are essential, who supplies them, and under what governance conditions.

Where the Value Is Actually Created

The next question is where the productive activity that generates the core product or service actually occurs. Fundamentals records this as System Value Creation.

This is not the same question as operating model. Operating model asks how the service is organised and delivered, through an off-chain business, an on-chain protocol, or a hybrid structure. Value creation asks where the productive activity that makes the service valuable actually occurs. A stable value issuer, for example, can have on-chain token contracts and interoperability infrastructure while still creating much of its value through off-chain issuance, redemption, and reserve management.

The distinction is simple in wording and easy to get wrong in practice.

On-chain value creation means the productive activity that delivers the buyer-facing service occurs within the cryptoeconomic system itself. Bitcoin creates value on-chain by providing censorship-resistant settlement and a native bearer asset transferable through the Bitcoin blockchain. Uniswap’s core exchange protocol creates value on-chain through liquidity pools and execution logic embedded in smart contracts. In these cases, the productive core is not merely settled on-chain. It is produced on-chain.

Off-chain value creation is different. Here, the core service is primarily produced by an off-chain business or service provider. On-chain components may still matter for distribution, accounting, or representation, but they are not where the service is principally produced. A system that depends on reserve management, legal and banking relationships, managed issuance, or off-chain underwriting is creating value differently from a system whose productive core lives inside contracts and on-chain participant coordination.

Hybrid value creation captures cases where economically relevant production spans both domains. This is not a hedge. It is a substantive claim about where the productive core really sits. A system may combine on-chain execution infrastructure with off-chain operational control, coordination, or service delivery. That is why a stable value issuer can have on-chain token contracts and interoperability infrastructure while still relying heavily on off-chain issuance, redemption, and reserve operations. It is also why a rollup can offer on-chain blockspace while depending on centrally operated sequencing or off-chain ecosystem coordination.

Getting this right matters because crypto rhetoric often treats value creation as though it sits wherever the token is most visible. That is false. Tokens may sit close to the product, far from the product, or somewhere in between. The value-creation field forces the analysis to identify where the economically valuable work is actually happening.

Where the Value Actually Goes

After the service is delivered, the next question is where value ends up. Fundamentals treats this as a separate field because a system can create value in one place and capture or route it somewhere else. That separation is central to serious analysis.

It is not enough to say that a system is valuable. You need to know who or what captures the economic surplus.

Off-chain value capture and routing means value is captured or routed to off-chain entities, typically corporate entities or other privileged organisations. That includes not only cash flows, but also claims on assets, revenue rights, licensing positions, distribution relationships, and other operational assets that support monetisation. A system may be widely used and strategically important while the dominant economic benefit accrues to identified off-chain entities rather than to token holders or on-chain participants.

On-chain value capture and routing means value is either retained within on-chain system-owned or collectively governed destinations, such as treasuries, collectors, or burn paths, or routed to participants within the system. Bitcoin routes value through block rewards and transaction fees to miners and mining pools. Uniswap routes swap fees to liquidity providers, and protocol-directed value can be routed through on-chain collector paths where enabled. Even here, the destination still has to be specified carefully. Routing to validators, liquidity providers, treasuries, burners, or token holders are not interchangeable outcomes.

Hybrid capture and routing is common in systems that combine off-chain businesses with on-chain components. Binance is a good illustration. Value is captured off-chain through exchange revenues, while on-chain value also exists through BNB Chain fee flows and burn mechanics. The point is not simply that both domains matter. It is that they matter in different ways, to different beneficiaries, under different governance structures.

This is also where many token narratives quietly fail. A token can be active, visible, and socially central to a project while still sitting outside the dominant path of value capture. Or it can capture one narrow stream while the main monetary flows accrue elsewhere. Unless value capture and routing are separated from value creation, it becomes too easy to assume that system demand automatically benefits the token. Very often, it does not.

Who Has Binding Control

Governance in Fundamentals is analysed on a component basis. The question is not simply whether a system is decentralised or centralised. The question is who holds binding decision rights over material system components, from assets to access.

Both conditions matter. Decision rights must be binding, and the component must be material. 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.

This component-based approach reflects how governance actually works in crypto. One component may be governed through transferable token ownership. Another may be governed by role-based participants such as validators, sequencers, councils, or allowlisted operators. Another may still be governed by an entity that holds admin keys, bank accounts, intellectual property, or legal authority. Systems often exhibit several governance forms at once, and those forms may sit alongside one another rather than inside one neat hierarchy.

That is why Fundamentals distinguishes among Token-Based Governance, Participant-Based Governance, and Entity-Based Governance. Token-Based Governance sits with tokenholders exercising formal decision rights. Participant-Based Governance sits with role-bearing actors such as validators, sequencers, councils, or allowlisted operators. Entity-Based Governance sits with a company, foundation, multisig, or other legal or operational body that can bind the relevant component. These labels are descriptive, not ideological. They say where authority lives.

This is also why non-binding sentiment is handled carefully. Advisory votes may matter socially, but they do not constitute system governance unless they bind the relevant component. Equally, an entity-run interface should not be treated as evidence of entity governance unless that interface is a privileged distribution channel under the boundary test. The framework is designed to resist two common errors at once. It does not over-credit decentralisation, and it does not over-credit centralisation either.

Why the System Layer Changes Token Analysis

The most important function of the system layer is that it prevents false inferences about tokens.

A token may carry a governance label, but if the material components remain entity-controlled, the economic significance of that governance may be narrow. A token may sit inside visible value-distribution mechanics, but if the dominant surplus is captured off-chain, the token may still sit beside rather than inside the main economic flow. A token may appear essential to usage, but if the core service is produced off-chain and the token mainly shapes access or incentives, its role is very different from that of a token tied directly to on-chain production or binding control.

In other words, the system layer is where token narratives are either properly grounded or shown to be overstated. It clarifies the boundary. It identifies where the service is produced. It identifies where the value goes. It shows who can change the rules. Once those things are visible, token analysis becomes much harder to sustain on narrative alone.

That is why Fundamentals puts the Token Functionality Framework below the System Taxonomy rather than beside it. Before asking what a token does, it is necessary to know what kind of system the token is part of.

For readers who want the full formal system framework, the public Fundamentals documentation sets that out separately.

Only then does the next question become meaningful. What role does token ownership actually confer within that system?

That is the job of the Token Functionality Framework.