In December, Aragon announced the Ownership Token Index: an attempt to formalise what it actually means to "own" a crypto token.
That announcement focused on why the index exists. This article follows up with how we evaluated the initial set of projects and how we think about verifying ownership in practice.
Our team reviews governance systems and EVM contracts as part of our day-to-day work. We routinely analyse upgrade paths, access control, admin roles, and value routing across protocols. The motivation behind the index was to compress that analysis into something legible, comparable, and grounded in verifiable facts for investors and teams.
When we talk about "ownership" in this context, we are referring to four distinct control surfaces:
- Token control: whether the token itself can be upgraded, censored, seized, or otherwise modified, and who controls those capabilities.
- Protocol control: which protocol contracts tokenholders actually control, versus those controlled by other actors through privileged roles.
- Value accrual and control: whether value flows to tokenholders or to assets they control, and whether that flow can be modified or revoked.
- Offchain control: ownership of IP and control of distribution, which can override onchain guarantees through coordination power.
The aim of the index is not to point fingers. We understand that teams in our space have faced the reality of raising capital in uncertain regulatory environments and in markets that often did not demand meaningful ownership from tokens.
The goal here is to help drive change through transparency, awareness and, ultimately, demand. Our hope is that investors gravitate toward tokens that grant clearer, more durable ownership claims, while providing teams with a concrete roadmap for how those claims can be strengthened over time.
For the initial set of projects, we did the following:
- reviewed the public repositories for each protocol
- identified the governance model used in practice
- evaluated each of the 4 ownership vectors:
- Token, Protocol, Value Accrual, Offchain
- performed spot checks against deployed contracts vs the source
- reviewed onchain data that needs verification i.e. contract addresses
We did not attempt to exhaustively analyse everything a protocol can do. The scope was narrower: identify the durable ownership and value claims a tokenholder can point to today.
When reviewing any codebase, the first step is understanding the governance model, if it exists. This determines whether permissioned functions and elevated privileges are ultimately controlled by tokenholders.
There are 3 broad options for governance
No upgrades, no admin functions, no privileged roles. Governance is not required because there is nothing to govern.
Many designs exist here. The most common and relevant are token-based governance systems. The key question here is whether tokenholders have ultimate control over key functions in the protocol or token that can affect ownerhsip or value accrual.¹
Multisigs, EOAs, server-run automation, or any setup where a defined group or individual can act unilaterally. This can be desireable or even necessary for operational efficiency but of course it's important to know if tokenholders can be sidelined due to elevated access being granted to a 3rd party.
The above hierarchy applies per function. A protocol can be permissionless in one area and trusted in another. A single contract can contain multiple privileged roles with different owners and different risk profiles.
Our analysis follows a simple sequence:
- identify privileged roles and workflows
- determine who ultimately controls themThe goal is not completeness. It is to
Most ownership and value disputes reduce to this.
- Checklist w. Example
Before assessing the vectors, identify the underlying control mechanism.
- On-chain Workflow Control: Does an on-chain workflow exist that gives holders ultimate voting power? (e.g., Timelocks or DAOs).
- Access Control managed by Holders: Are all significant privileged roles (those impacting value/ownership) gated by the holder workflow and revocable?
⚠️ Note: It's important to note that in the case of every vector other than the token, there may be differences per-product/protocol version that the token claims ownership of. In such a case it may be helpful to segment analysis into separate sub groups for each product line.
Token ownership and protocol ownership are separate questions and must be analysed independently.
The core question here is straightforward: can a third party meaningfully interfere with ownership of the token?
For ERC-20 tokens on EVM chains, we focus on whether the token:
- can be upgraded, and how upgrade authority is controlled
- Example: ERC20 behind UUPS Proxy, controlled via
auth(UPGRADER_ROLE)
- Example: ERC20 behind UUPS Proxy, controlled via
- has mutable supply, and if so, who controls
mintfunction - includes blacklist or forced transfer mechanics
- Checklist
- Upgrade Sovereignty: Do holders control the upgrade logic via governance, or is the contract immutable?
- Supply Sovereignty: Is the supply fixed/programmatic, or do holders control the minting process? (No third-party "Minter" roles).
- Censorship Immunity: Are there no "Guardian" or "Admin" roles capable of freezing, blacklisting, or seizing tokens?
- Tokenholder Concentration: does any one group control a majority share of the token supply?
Protocols can be complex in the ways that matter for ownership:
- multiple contracts
- multiple versions
- multiple repositories
- different control models per component
Rather than analysing everything, we focus on what directly affects ownership and value.
We look for two things:
- which contracts are in scope for tokenholder control
- which privileged roles sit outside tokenholder control
This requires understanding the access-control patterns used in each contract, including proxies and upgrade mechanisms.
Concretely, we identify roles that can, for example:
- upgradensorship Immunitye implementation logic via proxies
- change economic or risk parameters
- redirect protocol fees or assets
- restrict or block user interactions
Those roles are then mapped to the governance hierarchy defined earlier.
⚠️ Note: This may be repeated on a per-product basis within the protocol
- Upgrade Sovereignty: Do holders control the implementation logic of the specific "Engine" or product?
- Privileged Access controlled by holders: Are significant ownership restrictions or protocol parameters (risk/economic) gated specifically by holders?
Value accrual matters alongside token and protocol control. Without it, ownership claims rely almost entirely on expectation rather than mechanism.
We ask:
- does value route to tokenholders, either directly or via assets tokenholders control?
- if it does, can that routing be modified or revoked?
- if not today, does a mechanism exist that could be activated, and who controls that activation?
We track:
- whether fees or revenues are generated onchain
- whether those flows route to the token directly, to a tokenholder-controlled treasury, or to a set of distribution contracts
- whether distributions are built into the protocol or rely on trusted, discretionary executors²
- whether tokenholders control the direction of value
- whether latent value accrual mechanisms exist and what it would take to activate them
Value can accrue indirectly through assets held by treasuries or contracts. Note that this is only accretive, strictly speaking, if tokenholders control those assets or the IP they fund.
⚠️ Note: This may be repeated on a per-product basis within the protocol
- Accrual Defined: Is a mechanism (even if latent/inactive) defined in the codebase or legal IP?
- Accrual Active: Are value flows currently active and governed by holders (non-discretionary)?
- Treasury Ownership: Is the protocol treasury programmatically controlled by the token-governance workflow?
- Accrual Mechanism Control: Can holders modify accrual parameters (e.g., changing fee splits or rates)?
Onchain ownership is only one half the story, in many cases.
We collect publicly disclosed and verifiable information relating to:
- ownership or licensing of core IP
- control of distribution channels such as domains, websites, and social accounts
- the ability of key individuals or entities to redirect users to alternative deployments
Distribution controls coordination. Even with immutable contracts, the ability to shift users to a fork or new deployment can break the link between existing tokenholders and future activity.
This is also where ambiguity belongs. Private agreements, informal influence, and undisclosed structures cannot be fully captured. The goal is to make visible control surfaces explicit, not to claim completeness.
⚠️ Verification Rule: Mark as YES/NO only if there is a specific legal disclosure, whitepaper clause, or public filing confirming/denying the token holders' (or DAO's) legal rights to the below. If nothing public exists we assume TBD.
- IP Ownership (Brand): Is there evidence of DAO/holder ownership of trademarks, logos, and brand names?
- IP Ownership (NPD): Do holders have legal rights to new product development (patents, trade secrets, proprietary codebase)?
- Distribution (Website): Does the DAO/token entity own the primary domain (rather than an individual)?
- Distribution (Socials): Does the DAO have administrative control over primary channels (X, Discord, Telegram)
The initial release focuses on EVM systems.
Key roadmap items include:
- stronger source-to-bytecode verification
- better handling of multi-repo and multi-version protocols
- expansion to other ecosystems, including Solana, once comparable analysis is feasible
When reviewing any codebase, the first step is understanding the governance model, if it exists. This determines whether permissioned functions and elevated privileges are ultimately controlled by tokenholders.
- On-chain Workflow Control: Does an on-chain workflow exist that gives holders ultimate voting power? (e.g., Timelocks or DAOs).
- Access Control managed by Holders: Are all significant privileged roles (those impacting value/ownership) gated by the holder workflow and revocable?
- Governance Concentration: does any one group control a majority share of the voting supply?
Token ownership and protocol ownership are separate questions and must be analysed independently.
The core question here is straightforward: can a third party meaningfully interfere with ownership of the token?
- Upgrade Sovereignty: Do holders control the upgrade logic via governance, or is the contract immutable?
- Supply Sovereignty: Is the supply fixed/programmatic, or do holders control the minting process? (No third-party "Minter" roles).
- Censorship Immunity: Are there no "Guardian" or "Admin" roles capable of freezing, blacklisting, or seizing tokens?
Rather than analysing everything, we focus on what directly affects ownership and value.
We look for two things:
- which contracts are in scope for tokenholder control
- which privileged roles sit outside tokenholder control
This requires understanding the access-control patterns used in each contract, including proxies and upgrade mechanisms.
⚠️ Note: Analysis must be performed on a per-product basis within the protocol (e.g., different versions or distinct engines).
- Upgrade Sovereignty: Do holders control the implementation logic of the specific "Engine" or product?
- Privileged Access controlled by holders: Are significant ownership restrictions or protocol parameters (risk/economic) gated specifically by holders?
Value accrual matters alongside token and protocol control. Without it, ownership claims rely almost entirely on expectation rather than mechanism.
Value can accrue indirectly through assets held by treasuries or contracts. Note that this is only accretive, strictly speaking, if tokenholders control those assets or the IP they fund.
⚠️ Note: Analysis may need to be segmented into sub-groups for each product line.
- Accrual Defined: Is a mechanism (even if latent/inactive) defined in the codebase or legal IP?
- Accrual Active & Owned: Are value flows currently active and governed by holders (non-discretionary)?
- Treasury Ownership: Is the protocol treasury programmatically controlled by the token-governance workflow?
- Accrual Mechanism Control: Can holders modify accrual parameters (e.g., changing fee splits or rates)?
Onchain ownership is only one half the story, in many cases.
Distribution controls coordination. Even with immutable contracts, the ability to shift users to a fork or new deployment can break the link between existing tokenholders and future activity.
⚠️ Verification Rule: Mark as YES/NO only if there is a specific legal disclosure or public filing. If no public evidence exists, mark as TBD.
- IP Ownership (Brand): Is there evidence of DAO/holder ownership of trademarks, logos, and brand names?
- IP Ownership (NPD): Do holders have legal rights to new product development (patents, trade secrets, proprietary codebase)?
- Distribution (Website): Does the DAO/token entity own the primary domain (rather than an individual)?
- Distribution (Socials): Does the DAO have administrative control over primary channels (X, Discord, Telegram)