Token TransparencyObol - H2 2025
OBOLInitial · v1.0 · Filed 19 Aug 2025Complete
View token

Project & Team

01

Description of Project

Provide a concise narrative that clearly states:
  • (a) Problem the project solves — the problem the project is solving,
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time
  • (c) High-level project overview — how the project works at a high level,
  • (d) Primary token functions — the primary functions of the token (e.g. gov participation),
  • (e) Control surface reliance — if any, briefly describe the anticipated or possible evolution of the protocol’s governance/control model

(a) Problem the project solves

Traditional Ethereum validators rely on a single node operator, creating single points of failure (slashing, downtime, censorship). Obol solves this by enabling Distributed Validators (DVs) — validator keys split across multiple operators so no single party can compromise validator performance or security. This unlocks stronger fault tolerance, lower slashing risk, and broader operator participation in securing Ethereum and other decentralized infrastructure networks.

(b) Operational priorities

The Obol Association (Swiss) funds ongoing protocol development, grant programs, and ecosystem incentives from (i) its share of the Ecosystem Treasury (38% of supply, 8% unlocked at TGE, 30% linear over 3 years), and (ii) protocol revenue — a percentage of staking rewards earned by licensees of the Charon middleware, which accrues to Obol GMBH (Swiss wholly-owned subsidiary of the Obol Association). DV Labs (Delaware) continues core engineering under its own token allocation (19% allocated of 21% reserved for contractors & advisors) and carries out its own node operations services

(c) High-level project overview

Obol exists to distribute, decentralize, and democratize the digital infrastructure of the future — starting with Ethereum and expanding across Web3. As the foundation for Layer 1 blockchains and decentralized infrastructure networks, the Obol Collective is home to the world's largest decentralized operator ecosystem. This includes dozens of staking protocols, client teams, software tools, community projects, and professional node operators — including Lido, EtherFi, Nethermind, EigenLayer, Bitcoin Suisse, Blockdaemon, Stakewise, Chorus One, DappNode, and many more. Today, over 800 decentralized operators run Obol Distributed Validators (DVs) to secure more than $2B on Ethereum mainnet. Obol DVs deliver stronger performance, lower risk, and better rewards than traditional validators — empowering anyone to run high-performance, slashing-resistant validators. Alongside DVs, the Obol Stack is a modular, plug-and-play framework that makes it easy to deploy and manage Ethereum nodes, AI agents, AVSs, and other decentralized infrastructure. From L1s and L2s to DePIN, AVSs, and beyond — Obol is powering the next generation of decentralized systems.

(d) Primary token functions

The OBOL token does not currently have direct value-accrual mechanisms such as fee-sharing or in-protocol staking rewards. The long-term vision is for OBOL to become the economic backbone of the Distributed Validator ecosystem, with utility that is product-driven, tightly coupled to real usage and demand, and sustainable over the long term. Several initiatives are underway toward this goal, including strategic treasury operations, the Obol Economic Engine and Protocol Owned Liquidity, and deeper integration of the token within the Distributed Validator stack.

(e) Control surface reliance

The OBOL Token is regulated by FINMA (Swiss) which does not allow for binding involvement of token holders into decision making. The Obol Association Board (simple majority quorum) controls all decisions regarding operations and funding. DV Labs Board (simple majority quorum) controls all decisions regarding core development.

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the:
  • (a) full names,
  • (b) official titles,
  • (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo — DV Labs

Full NameOfficial TitlePrior Experience
Collin MyersBoard Member & FounderConsensys, Token Foundry, DySys Capital
Oisin KyneCEO, CTO & Co-FounderConsensys, Accenture, Kyne Software
Anthony BertolinoChief Marketing OfficerPOAP
Nannina SackmannChief People OfficerComposable Finance, IOV Labs

Foundation — Obol Association

Full NameOfficial TitlePrior Experience
Francis HackettPresidentHead of KPMG Legal Ireland
Patrick StorcheneggerBoard MemberBoard of the Ethereum Foundation (current)
Thomas HeremansCFODV Labs co-CEO, Salesforce

DAO / Onchain Governance

Full NameOfficial TitlePrior Experience
N/A
03

DAO Structure

Provide a structured description of the DAO’s governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

There is no active DAO or similar structure holding any IP, tokens or other property. The Obol Collective is a general concept used by marketing to refer to the wider ecosystem of partners and users of Obol-related technologies

(b) Contract/admin powers

Not applicable

(c) Locked-token rights

Not applicable

(d) Value accrual & holder rights

OBOL does not currently have direct value-accrual mechanisms such as fee-sharing or staking rewards embedded in the token design. Subject to legal and regulatory constraints, revenue generated by the Obol Association may be used to buy back tokens or pay a yield to token holders which it has done in the past.

(e) Dissolution authority

Not applicable

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn’t exist.
  • (a) Entity — type and jurisdiction.
  • (b) IP ownership & control — what IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; “3/5 multisig”).
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

(a) Entity

Obol Association Obol Association — Swiss entity (Verein) in Zug.

(b) IP ownership & control

The Obol Association owns Obol GMBH, a wholly-owned Swiss subsidiary. The Charon IP (and its related repositories, under BSL) is owned by DV Labs and licensed to the Obol Association for sub-licensing to Obol GMBH and ultimately to end-users. The Obol GMBH receives a percentage of the staking rewards of Charon licensees, deducted automatically via smart contracts. The Pluto IP (second implementation of the DV Protocol, developed by Nethermind) is owned by the Obol Association. The Obol Association owns the IP with the trademark and brand associated with Obol.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

The Obol Association holds all control over its treasury The Obol Association controls the following on-chain wallets:

  • Ecosystem Treasury 1: 0x42D201CC4d9C1e31c032397F54caCE2f48C1FA72
  • Ecosystem Treasury 2: 0xAEfd0B68212ddca96D9cF69128C6f47351feF5FB
  • OBOL Incentives Reserve: 0xdc8A309111aB0574CA51cA9C7Dd0152738e4c374
  • Protocol Revenue: 0xDe5aE4De36c966747Ea7DF13BD9589642e2B1D0d
  • Grant Program: 0xa59f60A7684A69E63c07bEC087cEC3D0607cd5cE Association board resolution and signing threshold on the above wallets are required for any significant transaction.

(d) Powers over DevCo

The Obol Association does not hold any equity, board seat, contractual, or other influence over DV Labs' decision-making. Revenue generated by the Obol Association will not be returned to equity holders in DV Labs The Association contracts with DV Labs for certain services on arm's-length terms paid in USD/USDC.

(e) Contract/admin powers

Not applicable in the absence of a DAO. The Obol Association holds no pause/upgrade/admin controls over smart contracts deployed by users of Charon.

(f) Current economic arrangements and distribution policies

Core team members and the Board of the Obol Association are compensated through a combination of salary and token allocation from the Obol Association. No core team member is compensated with tokens allocated to the Obol Association outside of the Obol Association team members who are known and compensated by the Obol Association. The Obol Association's primary source of revenue is a percentage of the staking rewards received by licensees of the Charon middleware, deducted automatically via smart contracts and flowing to Obol GMBH (the Swiss wholly-owned subsidiary of the Association). Revenue generated by the Obol Association will not be returned to equity holders in DV Labs via dividends on DV Labs equity or by share repurchases of DV Labs. Subject to legal and regulatory constraints, revenue may be used to buy back OBOL tokens. This is not a legal right of token holders. No programmatic distribution mechanism to token holders currently exists.

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn’t exist.
  • (a) Entity — type and jurisdiction.
  • (b) IP ownership & control — what IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; “3/5 multisig”).
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

(a) Entity

DV Labs Obol Labs Inc. dba DV Labs — Delaware corporation Inc.

(b) IP ownership & control

The Charon IP (and its related repositories, under BSL) is owned by DV Labs and licensed to the Obol Association for sub-licensing to Obol GMBH and ultimately to end-users. The Obol Stack IP.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

DV Labs controls the following on-chain treasury wallets:

  • DV Labs Treasury 1: 0xC62188bDB24d2685AEd8fa491E33eFBa47Db63C2 (2 of 3 multisig)
  • DV Labs Treasury 2: 0x6BeFB6484AA10187947Dda81fC01e495f7168dB4 (2 of 3 multisig)
  • DV Labs Treasury 3: 0x0e401B6e6e0BE96E785aF0243f9af61b387AD28e (1 of 2 multisig)
  • DV Labs Treasury 4: 0x198632b2f6B53e03E349be805EabFe03FBf5D227 (2 of 5 multisig) DV Labs held its portion of the token supply prior to the establishment of the Obol Association and has allocated 19% of the total supply to its contractors and advisers out of a 21% reserve (leaving 2% for future contributor incentivisation). DV Labs does not have direct power over protocol-controlled resources (e.g., Charon fee parameters), or reward-parameter changes.

(d) Powers over Foundation

DV Labs or its principals does not hold board seats, contractual rights, or any other direct or indirect influence over the Obol Association. There is no overlap between the Obol Association board and DV Labs’. Note that some members of the Obol Association leadership (e.g., Thomas Heremans and Francis Hackett) served in DV Labs roles in the past prior to moving to the Association full time.

(e) Contract/admin powers

DV Labs holds no pause/upgrade/admin controls over smart contracts deployed by users of Charon.

(f) Current economic arrangements and distribution policies

Core team members in DV Labs are compensated by a mix of salary and token allocation from DV Labs, utilizing a supply owned wholly by DV Labs prior to the establishment of the Obol Association. The total number of tokens allocated to current or future Labs contractors and advisers is 21% of the total supply; DV Labs has currently allocated 19% of the total supply to its contractors and advisers, leaving 2% in DV Labs for incentivisation of current and future contractors. Revenue generated by the Obol Association will not be returned to equity holders in DV Labs via dividends on the equity in DV Labs or by share repurchases of DV Labs. Where the Obol Association contracts with DV Labs for certain services, any such contracts are the product of arm's-length negotiation and payment in USD or USDC. DV Labs has a standalone revenue source from node operations.

Token Supply & Allocations

06

Initial Allocation

Disclose launch and initial supply details in a single initial allocation schedule covering the token’s launch. Include:
  • (a) Launch supply totals — the total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch;
  • (b) Recipient categories & use of funds — the recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket;
  • (c) Initial price per token (if applicable) — the initial price per token at TGE.. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
  • (d) Ticker / market symbol — the ticker/market symbol;
  • (e) Total supply & supply regime — the total supply and whether the supply is fixed (if not explain inflation rate or deflation rate);
  • (f) Initial vesting / release schedules — the initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic);

(a) Launch supply totals

The OBOL Token was launched (TGE) on 7 May 2025 at 11:00am UTC. Total tokens issued at launch: 500,000,000 OBOL. Based on the per-category initial unlocks below, approximately 19.14% of supply (~95.7M OBOL) was unlocked at TGE, with the remainder (~404.3M OBOL, ~80.86%) subject to vesting or scheduled release.

(b) Recipient categories & use of funds

Category% of SupplyUnlocked at TGEUse of Funds
Private Investors23.5%0%Consideration for prior fundraising rounds (see Section 10).
Public Sale (Coinlist)3.6%1.8%Consideration for community-round participants.
Airdrop7.5%7.5%Distributed to eligible community participants (see Section 7).
Community Incentives7.5%0.24%Community incentive programs, released weekly over 3 years.
Ecosystem Treasury38%8%Ecosystem grants, liquidity, operational funding of protocol.
Advisors & Team19%1.6%Compensation for DV Labs contractors, advisers, and team (see Section 1.D of prior filing).

(c) Initial price per token

The token started trading on May 7th 2025 11:00am UTC on multiple centralised and decentralised exchanges around $0.2

(d) Ticker / market symbol

OBOL.

(e) Total supply & supply regime

Total supply is capped at 500,000,000 OBOL. Supply is fixed — there are no additional issuance plans other than the scheduled vesting/unlock described below. Any future token issuance (e.g., minting or emissions outside scheduled vesting) will be disclosed before or at issuance with full details (amount, reason, recipient, context) in an official, permanent public channel.

(f) Initial vesting / release schedules

CategoryUnlock Schedule
Private Investors (23.5%)1/3 unlocks 1 year post-TGE; remainder unlocks quarterly over 2 years. EDIT: DV Labs has waived the lockup for private investors leading to the full 23.5% being unlocked on May 7th 2026 with the intention of reducing supply overhang and increasing float.
Public Sale (Coinlist) (3.6%)1/2 unlocks at TGE; remainder unlocks monthly over 12 months.
Airdrop (7.5%)Fully unlocked at TGE.
Community Incentives (7.5%)Unlocks weekly over 3 years; start date 1 April 2025.
Ecosystem Treasury (38%)8% unlocked at TGE; 30% unlocks linearly over 3 years post-TGE.
Advisors & Team (19%)1.6% unlocked at TGE; 17.4% unlocks linearly over 3 years post-TGE. Pre-TGE early team & advisors: 1/3 vests 1 year from Network Launch (1 April 2024), 1/6 every 6 months thereafter. Pre-TGE later team & post-TGE team: 1/3 vests 1 year from Token Launch (7 May 2025), 1/6 every 6 months thereafter. Unlock schedule mirrors vesting schedule; restrictions set out in token purchase agreements.
07

Airdrop Process

If the project has planned but not yet airdropped, it must:
  • (a) commit to publish, in a public channel and provide to Blockworks quarterly a recipient wallet list until the initial TGE airdrop is fully completed,
  • (b) Generally state the possible target user segments (e.g., “stakers of X,” “Aave users”) and the allocation method (e.g., proportional to ve-balance or net position). If the project has already airdropped, it must:
  • (a) For executed airdrops, point to an per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone don’t count.
  • (b) Clearly state covered user segments (e.g., “stakers of X,” “Aave users”) and the allocation method (e.g., proportional to ve-balance or net position). If the project does not plan to do an airdrop for TGE, it must:
  • (a)If no airdrop has ever been conducted, say so plainly (“We have never conducted an airdrop to date and do not plan to execute one”).

Status: Airdrop executed. A total of 7.5% of the 500M OBOL supply (37.5M OBOL) was distributed to the community. Snapshot date: 13 January 2025. Claim window: 90 days from 24 January 2025. Tokens were initially locked and issued as ERC-721 NFTs (enabling governance participation) before becoming transferable following a governance vote. Eligibility checker: claim.obol.org. Covered user segments and allocation method:

  • Obol Core Community (40% of airdrop) — holders of Techne credentials (any tier), testnet participants (Alpha, Beta, Athena, Bia), and DappNode owners.
  • Obol Contributions Holders (26.7% of airdrop) — based on the amount of ETH staked into Obol Distributed Validators. Linear allocation model with quadratic scaling for large contributors; 100-token minimum threshold to avoid dusting.
  • Solo Stakers & Rocketpool Node Operators (33.3% of airdrop) — based on on-chain data, including StakeCat's List B and Rocketpool operator lists. Per-address recipient source: The prior filing states: "The full recipient list can be found and downloaded here: https://github.com/ObolCollective/airdrop Transactions & Market Structures

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
  • (a) Market maker’s name — the market maker’s name;
  • (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
  • (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
  • (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker NameToken Allocation CommittedTerm DurationStructure Name
Amber0.8% of max supply1 yearLoan
Auros0.6% of max supply1 yearLoan
Arrakis0% (liquidity wholly owned by the Obol Association)Terminable on 1 month's noticeSelf-owned liquidity provision arrangement
09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
  • (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
  • (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
  • (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
  • (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange NameToken Allocation CommittedTerm DurationNative Token Listing Fees
Binance Alpha & Perps3% of max supply1% airdrop to alpha users, 1% for immediate marketing, 1% for marketing 6 months post TGE.None
Bybit1.5% of max supplyAirdrop to users in the first week of TGE and for marketing purposes. Unlocked at TGE.None
Gate0.5% of max supplyAirdrop to users in the first week of TGE and for marketing purposes. Unlocked at TGE.None
Bitget0.4% of max supplyAirdrop to users in the first week of TGE and for marketing purposes. Unlocked at TGE.None

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
  • (a) Series Name
  • (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
  • (c) Date of sale (at least month & year).
  • (d) Number of tokens sold (or % of total supply)
  • (e) Vesting schedule
  • If no prior sales occurred, state that explicitly (e.g., “No prior fundraising, OTC, or discounted MM sales have occurred.”)
Series NameInvestment VehicleDate of SaleNumber of Tokens Sold (or % of total supply)Vesting Schedule
Seed Round(Lead: Ethereal Ventures; $6M raised at $50M FDV)SAFE/Token Purchase Agreement~September 20218.3% of Total SupplyCovered under "Private Investors" 23.5% bucket: 1/3 unlocks 1 year post-TGE; remainder quarterly over 2 years.
Series A1(Leads: Pantera, Archetype, Placeholder; $12.5M at $125M FDV)SAFE/Token Purchase Agreement15 December 202214.7% of Total SupplyCovered under "Private Investors" 23.5% bucket.
Strategic Round(Investors: Hashkey, Infstones; $1M at $180M FDV)SAFE/Token Purchase Agreement~November 20230.6% of Total SupplyCovered under "Private Investors" 23.5% bucket.
Community Round (Coinlist)($3M at $125M FDV)Token Purchase Agreement~February 20253.6% of Total Supply1/2 unlocks at TGE; remainder unlocks monthly over 12 months.
11

Previous Exploits Affecting The Project

If any, list prior exploits/incidents that affected protocol funds. For each incident, provide:
  • (a) Date & component affected — date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected;
  • (b) Exploit vector summary — plain-language summary of the exploit vector (what the hack was);
  • (c) Quantified impact — quantified impact (assets/tokens affected or a clear “no loss of funds” statement);
  • (d) Remediation/response taken — remediation/response taken (patches, upgrades, governance actions, compensation);
  • (e) Current status — current status (resolved, in litigation, under investigation, refunded, etc.);
  • (f) References (optional) — references (optional): link(s) to post-mortem/advisory/PR.
  • If no prior incidents, state this explicitly (e.g., “No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD”).

No exploits affecting tokenholders or protocol funds as of 2026-04-24

12

Material Risk Factors (Regulation, Technology, Token Economics)

A. Regulatory, Legal & Tax Risks

Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:

  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?

Impact of Regulatory Change on TGE and Listings: The OBOL token was issued by the Obol Association, a Swiss entity. Evolving or conflicting regulatory frameworks across jurisdictions could affect the ability to maintain exchange listings or deliver tokens. In particular, jurisdictions that classify utility or governance tokens as securities could force delistings or restrict secondary trading. Exchange listing agreements (e.g., Bybit, Gate, Bitget) explicitly reserve the right to delist if the token is deemed a security or financial instrument in any jurisdiction. Entity-Level Regulatory Impact: The Obol ecosystem operates through multiple entities — the Obol Association (Swiss), Obol GMBH (Swiss subsidiary), and DV Labs (Delaware). Changes in Swiss foundation law, U.S. securities regulations, or cross-border enforcement actions could force structural changes to how the entities interact, how protocol revenue is collected, or how token allocations are administered. Licensing requirements for middleware software or staking infrastructure in new jurisdictions could create additional compliance burdens. Tokenholder Tax Treatment: The tax treatment of OBOL tokens varies by jurisdiction and is not settled in most regions. Tokenholders should be aware that acquiring, holding, or disposing of OBOL tokens may create taxable events. Tokenholders are solely responsible for understanding and complying with their own tax obligations. The Obol Association does not provide tax advice. Jurisdictional & User Access Restrictions: The OBOL token is not offered or available to U.S. persons, and exchange listing agreements restrict promotional activities in the United States, the People's Republic of China, and EEA jurisdictions (for certain exchanges such as Bybit). Sanctioned countries are excluded. Users who circumvent geographic restrictions do so at their own risk and may face loss of access to exchange services or token functionality.

B. Protocol, Technology & Security Risks

Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:

  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?

Bugs and Design Flaws: Obol's core technology stack includes the Charon distributed validator middleware (written in Go), the Obol Splits smart contracts (Solidity), and supporting infrastructure including the DV Launchpad and relay network. Potential risks include bugs or design flaws in Charon's BFT consensus implementation, its BLS threshold signature scheme, or its distributed key generation (DKG) process. Smart contract vulnerabilities in Obol Splits could lead to misallocation of staking rewards. The protocol also depends on Ethereum's beacon chain, validator clients, and third-party infrastructure (relays, beacon nodes), any of which could introduce bugs or failures outside Obol's control. Key threat vectors identified in Obol's published threat model include: exfiltration of operator identity (ENR) keys enabling impersonation; collusion of a threshold number of rogue operators to reconstruct validator private keys and produce slashable messages; malicious beacon nodes serving illegitimate data that could disrupt BFT consensus; compromised relay infrastructure enabling topology discovery and DDoS attacks; and social engineering attacks to get operators to run modified lock files with verification disabled. Centralization risks are also documented: Obol hosting relay infrastructure creates a single point of failure (mitigated by third-party relay operators such as DSRV, Infstones, Hashquark, and Node Guardians); Obol's ability to push Charon code updates could introduce vulnerabilities (mitigated by operators pinning specific docker image versions); the DV Launchpad is hosted centrally (mitigated by CLI-based alternatives); and Obol's custodying of pre-signed exit messages could enable unwanted validator exits (mitigated by EIP-7002 withdrawal-address-initiated exits post-Pectra). Security Measures & Their Limitations: Obol has undertaken the following security measures: Audits: Six completed audit engagements — a security assessment of Charon by Sigma Prime (resulting in v0.16.0); a second Charon assessment by Quantstamp (resulting in v0.19.1); a Solidity audit of Obol Splits by Zach Obront; a penetration test of the DV Launchpad by Sayfer; and second and third Solidity audits of Obol Splits V2 and V3 by Nethermind Security. A review of development processes was also conducted by Ethereal Ventures. All audit reports are published at github.com/ObolNetwork/obol-security. Bug Bounty: Obol operates a bug bounty program with rewards up to $100,000 for critical vulnerabilities (e.g., BLS private key exfiltration, arbitrary BLS signature production, malicious cluster invite subversion). Rewards scale down to $500 for low-severity issues. The scope covers Charon, the DV Launchpad and Public API, Obol Splits contracts, and Obol-hosted relay infrastructure. Reports can be submitted to [email protected]. Limitations: Audits and bug bounties cannot guarantee the absence of undiscovered vulnerabilities. Charon's BFT consensus can tolerate misbehaving nodes up to the configured fault tolerance threshold, but if more than two-thirds of nodes in a cluster are malicious, safety guarantees are lost. Novel vulnerabilities in underlying cryptographic libraries (BLS12-381, SECP256K1+ECDSA) or zero-day exploits in shared infrastructure could affect multiple clusters simultaneously. The relay-based peer discovery model, while mitigated by third-party relays, remains a potential disruption vector.

C. Token Economics, Unlocks & Incentive Risks

Describe how the token’s economic design and supply schedule could affect holders by answering, at a minimum, questions like:

  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

Critical Economic Assumptions: OBOL is a governance token without direct value-accrual mechanisms such as fee-sharing or protocol staking rewards. Staking (stOBOL) is no longer actively promoted and carries no new incentives or emissions. The token's long-term value depends on the assumption that DVT adoption grows, that Charon licensing revenue sustains the protocol, and that future product-driven utility creates organic demand. If DVT adoption stalls, competing implementations gain share, or Ethereum staking economics deteriorate materially, the economic rationale for holding OBOL may weaken. The fixed 500M supply cap removes inflation risk but also means the protocol has a finite incentive budget — if ecosystem treasury and community incentive allocations are exhausted before self-sustaining demand materializes, the project's ability to fund growth and attract operators could be constrained. Governance Control over Monetary Policy & Rewards: The OBOL token is regulated by FINMA (Swiss), which does not permit binding involvement of token holders in decision-making. The Obol Association Board holds all execution authority over treasury operations, fee parameters, and any future distribution mechanisms. Token holders have no enforceable right to direct monetary policy, revenue distribution, or reward allocations. The Association could, at its discretion, deploy treasury funds, initiate token buybacks, or redirect protocol revenue in ways that may not align with all token holders' interests. Any future changes to supply mechanics (e.g., burns, new emissions) would be disclosed publicly but are not subject to binding token holder approval. Disclaimer: This Token Transparency Filing is prepared by [PROTOCOL_NAME] and is provided for general informational purposes only. Blockworks makes no representations or warranties, express or implied, regarding the accuracy, completeness, or timeliness of the information provided (including any external links to third-party content), and Blockworks is not liable for any errors or omissions in the content or for any actions taken in reliance on this content.

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Obol is solely responsible for the content, accuracy, and legality of its disclosures.

Newsletter

The Breakdown

Decoding crypto and the markets. Daily, with Byron Gilliam.

Blockworks Research

Unlock crypto's most powerful research platform.

Our research packs a punch and gives you actionable takeaways for each topic.

SubscribeGet in touch

Blockworks Inc.

133 W 19th St., New York, NY 10011

Blockworks Network

NewsPodcastsNewslettersEventsRoundtablesAnalytics