Watchlists
Screener
Monitoring
Projects
Analytics
Research
News
More
Project
© Blockworks 2026
Product
ResearchNewsIntelScreenerRankingsWatchlistsCharts
Company
NewsletterPodcastsEventsBrand Assets
Resources
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
Terms of ServicePrivacy PolicyPrivacy CenterDocumentationPricing
NewsletterPodcastsEventsBrand Assets

Rocket Pool

DeFi · Decentralized Liquid Staking
OverviewChartsMonitoringResearchNewsMarketsAboutRocket Pool
OverviewChartsMonitoringResearchNewsMarketsAboutRocket Pool

Token Transparency Filing

B2 v2.0 · Filed 18 Jun 2026Complete

Project & Team

01

Description of Project

Provide a narrative description of the purpose of the project.

Rocket Pool is a liquid staking protocol that operates on Ethereum Mainnet. It is entirely permissionless and decentralised. Anyone can participate in Ethereum staking via Rocket Pool in two key ways: Node Staking and Liquid Staking. Node Staking requires an individual to provide their own 4 ETH along with the hardware, networking, and technical proficiency required to run an Ethereum validator. The protocol supplies the remaining 32 ETH to the node operator via Liquid Stakers. The Node Operator and the Liquid Staker share in the ETH rewards that are generated by the Node Operator. Governance of the protocol is decentralised and administered by Node Operators. In order to participate in Rocket Pool governance, one must stake the RPL token on their node.

02

Known Project Team

For each existing entity, list key team members with full name, official title, and prior experience. Explicitly mark non-existent entities.

Labs / DevCo

Full Name

Official Title

Prior Experience

David Rugendyke

Founder & CTO

David has over 18 years of commercial experience as a senior developer with a computer science background and started designing Rocket Pool in late 2016. He is currently committed to developing Rocket Pool full-time as the chief technology officer.

Darren Langley

General Manager

Darren brings extensive experience in technical leadership, strategy, product management, and blockchain consulting across the finance, government, and technology sectors. He has held senior engineering, architecture, and product roles delivering large-scale digital transformation projects, working closely with executive stakeholders to define product vision, shape technical strategy, and drive delivery across complex, multi-team programmes. He has also worked as a Senior Blockchain Consultant architecting solutions presented to international bodies including the World Intellectual Property Organisation.

—

Foundation

Full Name

Official Title

Prior Experience

No foundation exists

—

DAO / Onchain Governance

Full Name

Official Title

Prior Experience

The IMC/GMC have a flat hierarchy with no leadership roles; members are voted in on an annual basis via Snapshot votes and the current membership details are available here: https://rpips.RocketPool.net/RPIPs/RPIP-36

—

Ken Smith

IMC & GMC Member with Rocket Pool nodes to strengthen physical security for home-staking setups. As the founder of NextBlock Solutions LLC, he is currently focused on advancing zk proving technology to significantly improve proving speeds.

Ken Smith is the founder of NextBlock Solutions LLC, where he delivers Ethereum blockchain infrastructure, consulting, and training services on Web3 topics. His cryptocurrency journey began in 2014 with the construction of home-built altcoin mining rigs. Ken has published detailed analyses of economic returns in EVM-smoothing pools (including low-ether-bonded minipools) and developed secure procedures for pairing the Aegis Key

03

DAO Structure

Describe DAO governance, powers, economic rights, and control surfaces. If no DAO exists, state so and still address current tokenholder governance rights and economic arrangements.

  • (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, governance-executor authorities, and the method of authority for each.
  • (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) Current tokenholder governance rights and economic arrangements — If any, describe current governance rights of tokenholders and presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
  • (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism.

(a) IP ownership & control

All repos are public and open source. The Rocket Pool brand/trademark is owned by the Dev Team. The DAO is not currently a legal entity.

(b) Contract/admin powers

The Oracle DAO (oDAO) holds upgrade role with a 14 day delay & can update some protocol parameters with a 7 day delay - they require a majority onchain vote (6 of 10 oDAO members). The pDAO has a three-week onchain governance voting process with 15% quorum and can change protocol parameters & manage the security council & treasury. The security council can emergency-pause deposits & veto upgrades, but cannot pause withdrawals.

(c) Locked-token rights (conditional)

RPL staking by Node Operators on their nodes is required to participate in Rocket Pool governance. Node Operators who stake RPL have voting power to allocate RPL inflation and approve protocol changes. A Node Operator may delegate their voting rights to another Node Operator. Staked RPL earns a share of protocol revenue paid in ETH. Staked holders can adjust protocol settings and execute onchain actions, as well as signal intentions via Snapshot vote.

(d) Current tokenholder governance rights and economic arrangements

RPL staking Node Operators have governance voting power to allocate RPL inflation. Governance is on-chain; only Node Operators who stake the RPL token are qualified to vote for protocol changes (voting rights may be delegated to another Node Operator). The DAO receives a share of RPL inflation, from which it votes to fund ongoing development (approximately 50,000 RPL per year is paid to the Dev Team, approved annually by protocol DAO vote — see RPIP-37 and RPIP-10). Node Operators also receive rETH commission and a share of RPL inflation.

(e) Control surface reliance

There are no admin keys and the protocol is under DAO control. Operationally, it is anticipated that there will be further incremental reductions of the responsibilities of the oDAO over time.

(f) Dissolution authority

No dissolution mechanism exists.

04

Primary Foundation

Describe the Primary Foundation, including entity details, IP ownership, governance or token powers, contract/admin powers, and economic arrangements. If it does not exist, state so explicitly.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe current powers over DAO governance, treasury actions, protocol-controlled resources, 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 Developer Company.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each.
  • (f) Current economic arrangements and distribution policies — Describe current governance-approved, contractual, or programmatic mechanisms by which protocol-controlled resources may be directed to this entity, its equityholders, contributors, or other participants. If none exist, state that explicitly.

(f) Current economic arrangements and distribution policies

Blockworks note: No foundation exists

05

Primary Developer Company

Describe the Primary Developer Company, including entity details, IP ownership, governance or token powers, contract/admin powers, and economic arrangements. If it does not exist, state so explicitly.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe current powers over DAO governance, treasury actions, protocol-controlled resources, token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the Developer Company 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.
  • (f) Current economic arrangements and distribution policies — Describe current governance-approved, contractual, or programmatic mechanisms by which protocol-controlled resources may be directed to this entity, its equityholders, contributors, or other participants. If none exist, state that explicitly.

(a) Entity

type and jurisdiction: The legal entity type is an Australian Proprietary (Pty Ltd - private) Corporation.

(b) IP ownership & control

All owned by Dev Team. The Rocket Pool brand/trademark is owned by the Dev Team.

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

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

The development entity holds RPL tokens on its balance sheet and has the same rights and proportional voting power as any other Node Operator in the protocol. Node Operators (including the Dev Team if operating nodes) are the only entities with ultimate control over the governance treasury via on-chain voting. The Dev Team does not have separate unilateral powers over the DAO, treasury, protocol-controlled resources, or token administration outside of its proportional Node Operator voting rights.

(d) Powers over Foundation

No foundation exists.

(e) Contract/admin powers

The Team has two seats on the oDAO (out of 10) & the oDAO has upgrade/settings authority. Essentially this means that the Team does not have unilateral control over upgrades. The oDAO does not have authority to upgrade without pDAO approval. The Team currently holds the sole seat on the Security Council which gives them the ability to pause deposits into the protocol under emergency conditions. The Dev Team operates a 2 of 3 multisig to ensure responsiveness. The Dev Team remain on the Security Council at the behest of the pDAO who can replace them at any time via onchain vote.

(f) Current economic arrangements and distribution policies

The Dev Team is paid by the protocol DAO as a software development partner. Payment occurs once per year, approved by protocol DAO vote, in RPL tokens. The total varies slightly but has been approximately 50,000 RPL per year for ongoing development work. The details of this payment structure are defined in RPIP-37 (https://rpips.Rocket Pool.net/RPIPs/RPIP-37), and historical payments are detailed in RPIP-10 (https://rpips.Rocket Pool.net/RPIPs/RPIP-10#direct-expenses). Most of the Dev Team's costs are paid from the Dev Wallet that was set aside at the creation of the protocol. The Rocket Pool core team is not a non-profit per se, however they do not make a profit from the protocol. There is no plan to return any funds to the Dev Team unless the protocol DAO initiates and approves this by vote.

Blockworks note: The Rocket Pool core team ("Dev Team") is the development entity for the protocol.

06

Affiliated Protocol Contributor

Identify affiliated protocol contributors and explain their control, funding, or operational relationship to the project. If none exist, state so explicitly.

  • (a) Identity & role — Legal name, entity type, jurisdiction, and role.
  • (b) Parameter control & scope — If any, what major protocol parameters the APC controls; include the method of authority. If none, say so.
  • (c) Contract/admin powers — If any, provide pause/upgrade powers, governance-executor authorities and limitations; include the method/threshold for each. If none, say so.
  • (d) Compensation and material economic arrangements — If any protocol-generated resources or economic value is dynamically routed to the APC, describe the arrangement. If none, state that explicitly.

(a) Identity & role

APC one: The IMC is a decentralised committee that does not have a legal name, type, or jurisdiction.

APC two: The GMC is a decentralised committee that does not have a legal name, type, or jurisdiction

(b) Parameter control & scope

APC one: The IMC receives a share of RPL token inflation and uses it to incentivise liquidity for rETHand RPL via a 4 of 7 multisig. Their charter is available here: https://rpips.RocketPool.net/RPIPs/RPIP-20

APC two: The GMC receives a share of RPL token inflation and uses it to fund ecosystem

development (marketing, dev work, tech support etc) via a 4 of 7 multisig. Their charter isavailable here: https://rpips.Rocket Pool.net/RPIPs/RPIP-40.

(c) Contract/admin powers

APC one: The IMC receives a share of RPL token inflation and uses it to incentivise liquidity for rETH

and RPL via a 4 of 7 multisig.

APC two: The GMC receives a share of RPL token inflation and uses it to fund ecosystem

development (marketing, dev work, tech support etc) via a 4 of 7 multisig.

(d) Compensation and material economic arrangements

APC one: The IMC members receive a small nominal stipend based on hours worked

https://rpips.Rocket Pool.net/RPIPs/RPIP-41

APC two: The GMC members receive a small nominal stipend based on hours worked

https://rpips.Rocket Pool.net/RPIPs/RPIP-41

Token Supply

07

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, and 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 — The expected initial price per token.
  • (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

Total of 18,000,000 RPL issued at launch. All tokens fully vested / unlocked at launch (no tokens locked at launch).

(b) Recipient categories & use of funds

  • Investor presale: 8,220,000 RPL (45%) — sold to early investors via presale.
  • Public Crowdsale: 7,080,000 RPL (40%) — sold to the general public during the public token sale.
  • Team Reserve: 2,700,000 RPL (15%) — allocated to the Rocket Pool core team and used to develop the Rocket Pool protocol over a period of 8+ years, including but not limited to:
  • Team member salaries to facilitate core smart contract development, and other staff supporting day-to-day protocol operations across management, ecosystem, & more.
  • Payments to contractors contributing across marketing, design, devops, & more.
  • Payments for professional services eg accounting and legal.
  • 16 security audits from industry-leading companies prior to mainnet launch and every protocol upgrade including Redstone, Atlas, & Saturn.
  • Funding of Immunefi bug bounty with rewards up to $150,000; multiple payouts made across lower tiers.
  • Marketing and advertising covering educational content and awareness campaigns around major protocol upgrades.
  • Team travel to industry events e.g. participation at ETHGlobal events, and attendance at multiple Devcons and Devconnects for technical collaboration, panel and speaking engagements, and leading technical workshops.
  • Sponsorship of booths, branding placement, and other event-related activities.
  • Ecosystem development, including co-funding Ethereum Foundation initiatives.
  • Community activation, including social/collaborative and educational events.

(c) Initial price per token

Whitelist price: 0.00071582 ETH. Crowdsale price: 0.000833333 ETH

(d) Ticker / market symbol

RPL

(e) Total supply & supply regime

Supply is not fixed. RPL is inflationary at 5% annually. Any changes to the inflation rate must be voted on and approved by the DAO and occur fully transparently on-chain.

(f) Initial vesting / release schedules

All initial allocations (Investor presale, Public Crowdsale, Team Reserve) were fully vested at the time of initial allocation. There was no vesting period for any launch category.

08

Vesting Insider Tokens

If there are not post-TGE token compensation plans state explicitly they do not exist. If there are then state the:

  • A) Post-TGE employee lock as % of circulation. State the current total amount of tokens locked or unvested attributable to post-TGE employees, expressed as a percentage of current circulating supply. If circulation isn't used, an explicitly labeled equivalent (e.g., "% of total supply" or "% of FDV") is acceptable. Must include an "as of" timestamp.
  • B) Typical post-TGE vesting schedule. Describe the standard vesting terms used for post-TGE grants, including: cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration. If variants exist (e.g., performance grants), note the typical range.

There are no locked or unvested post-TGE employee tokens.

09

Disclosure of Token Advisory Billings

Disclose token-based compensation for external advisors and service providers (e.g., legal, marketing, technical, growth) funded from the on-chain treasury or token reserves held by the Foundation, Labs/DevCo, or similar entities. You do not need to disclose individual names, roles, salaries, or any advisors receiving fiat-only compensation. Provide:

  • (a) Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).
  • (b) The total token allocation across all advisory services (tokens paid and/or reserved in aggregate).
  • (c) The payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).
  • (d) A brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory").
  • Existence: There are no advisory or similar token payments to the core team. The Rocket Pool core team is paid a set amount for ongoing development of the protocol from RPL inflation, based on the DAO's continued satisfaction with roadmap execution.

  • Total token allocation: No payments

  • Payer entity: N/A

  • Description of advisory/services: Description of services

    N/A

10

KOL Marketing Activities

Disclose ongoing KOL/influencer relationships that partially or fully received tokens for payment. Do not need to disclose KOL/influencers that do not receive tokens for payment. Use lettered sub-items:

  • (a) Existence & scope: State plainly whether KOLs receive tokens for payment, if none say so.
  • (b) Usernames & roles: List usernames/handles (with platforms) for participating KOLs and describe their roles/activities. Legal names are not required.
  • (c) Token allocation & vesting/locks: Say whether tokens were allocated to KOLs. If yes, provide the aggregate token amount across all KOLs and summarize vesting/lock terms (e.g., cliff and vest length, or "no vest/locks").
  • Existence & scope: No payments
  • Usernames & roles: N/A
  • Token allocation & vesting/locks: N/A
11

Labelled Unissued & Operational Token Wallets

Publicly label all wallets that hold Unissued Tokens (e.g., foundation, operations, treasury, investor reserve), keep each category in distinct wallets (a unique address per category), and disclose who controls each wallet (DAO multisig, foundation, labs/devco, operations, or contract controller + admin). Include one verification link per wallet (docs or explorer). Definition: Unissued Supply = tokens authorized by the contract but not yet issued to any party; where they sit (treasury or mint authority) does not change that they are unissued. For instance: if a token has a total supply cap of 1B, and 400M tokens have been issued to investors, the team, and users (whether vested or unlocked), then those 400M count as issued supply. The remaining 600M are authorized but unissued supply, even if they are already minted into a DAO treasury wallet.

Title

Primary Function

Chain

Address

Control Mechanism

Explorer Link

Rocket Pool protocol DAO vault

Protocol DAO treasury / governance-controlled funds

Ethereum Mainnet

0x3bdc69c4e5e13e52a65f5583c23efb9636b469d6

DAO (on-chain governance by RPL-staking Node Operators)

https://etherscan.io/address/0x3bdc69c4e5e13e52a65f5583c23efb9636b469d6

Dev Wallet

Funds set aside at protocol creation to cover Dev Team costs

Ethereum Mainnet

0xd2A4848a6644749e652c1D9398B5AA317f57395B

Dev Team control — specify 2 of 3 multisig

https://etherscan.io/address/0xd2A4848a6644749e652c1D9398B5AA317f57395B

IMC / liquidity incentives wallet(s)

Wallets used by the Incentive Management Committee to disburse liquidity incentives for rETH and RPL

Ethereum Mainnet (confirm) Yes

0xb867EA3bBC909954d737019FEf5AB25dFDb38CB9

Multisig — specify threshold 4 of 7

https://etherscan.io/address/0xb867EA3bBC909954d737019FEf5AB25dFDb38CB9

GMC

Operational

Ethereum Mainnet

0x6efD08303F42EDb68F2D6464BCdCA0824e1C813a

4 of 7 multisig

https://etherscan.io/address/0x6efD08303F42EDb68F2D6464BCdCA0824e1C813a

Market Structure

12

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 Name: None — no active market makers
    • Token Allocation Committed: N/A — 0%
    • Term Duration: N/A
    • Structure Name: N/A

Blockworks note: Rocket Pool has no active market maker agreements or deals. No native tokens have been loaned or allocated to any market maker.

13

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. If no native-token listing fees were paid, state that explicitly; cash/fiat fee amounts are not required for this item.

Blockworks note: Rocket Pool has no centralized exchange deals or agreements. No native RPL tokens have been paid as listing fees to any CEX. On the DEX side, the DAO's Incentive Management Committee (IMC) provides liquidity incentives for rETH and, to a lesser degree, RPL. Specific DEX pool/pair details, allocation percentages, and term durations for each incentivised pool are provided below in Q14.

14

Liquidity Deals and Market Activity

If a category does not exist or is not applicable, make that clear in plain language (no specific wording required).

  • (a) Buybacks & re-release (bought-back tokens only): source of funds (e.g., % of revenue), treatment (burn/treasury/POL), controller/approvals (DAO, multisig, or contract), and whether bought-back tokens can ever be re-released; if "never," give the mechanism (burn or irrevocable timelock); otherwise state the re-release policy.
  • (b) Protocol-owned liquidity (POL): where deployed, total token or dollar size across all deployments, controller, and unwind/exit policy.
  • (c) Liquidity deals / purchased TVL: the total size across all deals, and where the capital participates - no counterparty names needed.
  • (d) Token-secured loans/lines (incl. against unissued tokens): principal, gross position size, collateral, counterparties, and unwind/exit policy.
  • Token repurchases or secondary-market accumulations (if any): None
  • Protocol-owned liquidity (POL): + $26k full range WETH/RPL dedicated to oracle safety+ $23k full range rETH/WETH for similar stability+ Up to $35k intended as concentrated rETH/RPL liquidity; about $12k is currently deployed on univ3 POL is controlled by the IMC via 4 of 7 multisig, and unwind policy is at the decision of the IMC
  • Liquidity deals / purchased TVL: No purchased TVL
  • Token-secured loans/lines (incl. against unissued tokens): None

Resources

15

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 / Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
  • (b) Date of sale (at least month & year).
  • (c) Number of tokens sold (or % of total supply)
  • (d) Vesting schedule

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.")

  • Series Name: Simple presale (https://medium.com/rocket-pool/rocket-pool-token-presale-9d0 832477894)
    • Date Of Sale: Sept ‘17
    • Number of tokens sold: 8,220,000 RPL (45% of initial supply)
    • Vesting Schedule: Fully vested at allocation — no vesting period
  • Series Name: Public Crowdsale
    • Date Of Sale: Nov ‘17
    • Number of tokens sold: 7,080,000 RPL (40% of initial supply)
    • Vesting Schedule: Fully vested at allocation — no vesting period

Blockworks note: Unable to disclose specific details but only outright sales (no vesting schedule).

16

Operational Funding, Economic Flows, and Resource Provisioning

Provide a narrative description of the Project's material funding sources, economic flows, and operational provisioning, broken out by entity: Foundation, Lab/DevCo, and DAO. If an entity does not exist, state that explicitly. If an entity exists but does not pursue revenue-generating activity, state how it funds or provisions its operations.

  • (a) Entity existence — Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.
  • (b) Material sources of funding or economic inflows — For each existing entity, describe its primary sources of operational funding or economic inflows, if any (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts). If none, state "none."
  • (c) Operational use of resources — Briefly describe how those resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).
  • (d) Onchain Resource Usage — Provide links to public dashboards and token holder relations reports that help explain on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources. Make certain to explain what each link is for.

(a) Entity existence

  • Foundation — Based on the prior filing, no traditional Foundation entity appears to exist. The Rocket Pool core team (Dev Team) is the development entity, paid by the DAO.
  • Nil foundation
  • Lab/DevCo — Exists. Referred to in the prior filing as the "Rocket Pool core team" or "Dev Team." Legal entity type and jurisdiction not disclosed (see Section 5).
  • DAO — Exists. On-chain governance administered by Node Operators who stake RPL tokens.

(b) Material sources of funding or economic inflows

  • DAO: Receives a share of RPL inflation (5% annual). Protocol revenue flows include rETH commission (shared between Node Operators and Liquid Stakers) and the DAO's share of RPL inflation.
  • Dev Team / DevCo: Paid by the DAO as a software development partner in RPL tokens (~50,000 RPL/year, approved annually by protocol DAO vote per RPIP-37). Additional costs are paid from the Dev Wallet set aside at protocol creation. The Dev Team also holds RPL tokens on its balance sheet (15% Team Reserve at launch).
  • Node Operators: Receive rETH commission and a share of RPL inflation based on their staked RPL.
  • Nil foundation

(c) Operational use of resources

Primary uses: ongoing protocol development (funded from DAO-approved RPL payments to the Dev Team), liquidity support (IMC-administered incentives for rETH and RPL pools), and protocol operations.

The Dev Team also uses funding to perform multiple security audits of each upgrade, and to pay for marketing/ecosystem expenses such as travel to industry events/conferences. Grants are covered by the GMC.

(d) Onchain Resource Usage

public dashboards and links:

  • Protocol DAO vault (holds DAO-controlled RPL): https://etherscan.io/address/0x3bdc69c4e5e13e52a65f5583c23efb9636b469d6#readContract
  • RPL Inflation events (on-chain minting of RPL inflation): https://etherscan.io/token/0xd33526068d116ce69f19a9ee46f0bd304f21a51f?a=0x0000000000000000000000000000000000000000
  • pDAO summary report (Google Sheet): https://docs.google.com/spreadsheets/d/1Zo9iFJ2YZNAkgNo53yJGSCnz8XAYuLJ7SeiwJx6oF0A/edit?gid=524613045#gid=524613045
  • DAO transaction dashboard (Dune): https://dune.com/queries/1264376
  • Quarterly roadmap updates / token holder relations: https://dao.RocketPool.net/tag/roadmap_update
  • Bi-weekly team updates: https://medium.com/rocket-poo l
  • RPIP-37 (Dev Team payment structure): https://rpips.RocketPool.net/RPIPs/RPIP-37
  • RPIP-10 (historical direct expenses): https://rpips.RocketPool.net/RPIPs/RPIP-10#direct-expenses
  • Governance docs: https://RocketPool.net/governance/protocol-dao and https://medium.com/rocket-pool/rocket-pool-protocol-dao-governance-a3c3e92904e0
17

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (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) — Link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits affecting tokenholders or protocol funds have occurred as of 13 May 2026.

(b) Exploit vector summary

N/A

(c) Quantified impact

N/A

(d) Remediation/response taken

N/A

(e) Current status

N/A

(f) References (optional)

N/A

18

[Optional] Offchain Foundation Or DevCo Income Statement

Provide a single income statement, expense summary, or comparable operating statement for the primary Foundation or Developer Company. A consolidated or entity-level presentation is acceptable. Balance Sheet and Statement of Cash Flows may be included but are not required. This item is intended to provide transparency into offchain operating resources and expenditures only.

Line Item

Amount

Blockworks note: N/A

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. Rocket Pool is solely responsible for the content, accuracy, and legality of its disclosures.

Project
OverviewChartsMonitoringToken DisclosuresResearchNewsMarketsAbout
Fundraising
Rocket Pool
Curious what full access looks like?
Access premium insights on ETH and BTC pages for free.
BTCETH