From genesis block to global ecosystem, learn about the evolutions, authority, and roles common among Web3 foundations – as well as the data rails that support them.
Major protocols have historically moved through cycles: they start as a whitepaper and launch, move into a period of early excitement and rapid growth, settle into a long middle phase where the chain feels like “boring infrastructure,” and eventually hit moments of major upgrades, new narratives, and sometimes complete reinvention.
What driver does the protocol trust to help manage change, narrative, and community? Among most Web3 projects, it’s common to design a foundation to oversee the technology, capital, and other matters of an open source technology.
Foundations serve through community turmoil, price peaks and valleys, and from no usage to institutional adoption – usually representing the interest of token buyers, technical contributors, and protocol users. They’re there before the hype, still working after it fades, and they quietly absorb a lot of the accountability when things go wrong. They’re the human side to open source technology.
In this piece, we’ll walk through the life of a blockchain ecosystem in four phases and look at what a foundation actually does in each one. Along the way, we’ll reference real foundations like Ethereum, NEAR, Arbitrum, the Web3 Foundation, and Pocket Network’s own foundation-to-foundation model for wholesale data, and then examine where infrastructure decisions, especially those related to data and RPC, actually reside.
If you work in a foundation or around one, you should be able to answer a fundamental question—“are we contributing enough?”—with something more concrete than “we gave out some grants.”
What is a blockchain foundation?
Before examining their roles in different phases, you need to understand the institution.
At a high level, a blockchain foundation is a non-profit organization set up to support, govern, and grow a specific protocol or family of protocols. It gives the project a long-lived, legally recognized home.
It’s the entity that looks after the project’s shared resources over the long term, helps direct support to the work the ecosystem needs most, and provides the protocol with a stable point of coordination and representation in the wider world.
The typical triangle of a protocol: company, DAO, foundation
Most mature ecosystems end up with a similar three-part structure:
- Core dev company (or several) – builds clients, wallets, and core tooling
- DAO / token holders – approve big decisions and budgets, often via on-chain governance
- Foundation – a legal entity that executes long-term work: hiring, grants, contracts, and public-good infrastructure
The typical triangle of a protocol
Who actually sits inside a foundation?
Foundations come in different legal structures (Swiss Stiftung, Cayman, Singapore, and so on), but they share common features internally.
At a high level, you usually see:
- A board or council: sets high-level strategy and signs off on budgets
- An executive team: a director/CEO and an operations lead, sometimes a CTO-type role.
- Program leads: for grants, ecosystem, governance, infrastructure, and communications.
- Legal, finance, and operations: the people who keep the entity compliant and functioning
Organizational Structure of a Foundation
You can see this pattern in lots of places: Ethereum Foundation, Solana Foundation, NEAR, and others all combine a board or council with an executive team and program leads rather than a single, monolithic ‘core dev’ shop.
With that basic picture in mind about what a foundation is and who’s inside it, we can look at how its responsibilities change over the life of a protocol.
Phase 1 – Launch: from whitepaper to mainnet
In most cases, by the time most people see a “mainnet is live” announcement, the foundation has already been working for months. This first phase is where all the abstract roles you just saw, like treasury steward, governance coordinator, and infrastructure backer, become very concrete work.
The institution now has a simple mandate: take the protocol from whitepaper and testnet to something developers can rely on in production, without boxing the ecosystem into short-sighted decisions.
For example, the NEAR Foundation was set up in 2019 as a Switzerland-based non-profit to “promote the development of the NEAR ecosystem and protocol,” and it spent the pre-mainnet period raising and deploying funds into core development, security, and ecosystem support before NEAR’s mainnet went live in April 2020
In practice, that translates into a handful of specific responsibilities in the launch phase:.
a) Early-phase jobs
In the launch phase, a foundation is usually responsible for:
- Legal and structure
- Incorporating the entity and setting up the board
- Handling token issuance and any early sales under local law
- Protocol bootstrapping
- Funding client development, security reviews, and audits
- Coordinating testnets and mainnet launch readiness
- Minimum viable infrastructure
- A basic block explorer
- Documentation and developer resources
- Initial RPC endpoints so wallets and dApps can actually connect.
Think of it as taking a protocol from ‘idea and repo’ to something developers can realistically deploy on.
b) Early data infrastructure decisions
Data infrastructure decisions start surprisingly early. Even at launch, someone has to decide:
- Will we run our own nodes and expose a public RPC?
- Will we rely on a centralized gateway?
- Will we integrate with a decentralized infra network from day one?
Many chains initially run a small set of in-house nodes, sometimes alongside a partner RPC vendor. That works while traffic is low. It becomes a liability when the first major dApp goes into production.
This is where models like Pocket Network’s Foundation Partner Program fits. From launch, a foundation can:
- List its chain in Pocket’s network
- Get a no-key public endpoint backed by a decentralized cluster
- Pay at protocol cost (later via POKT burns priced in compute units) instead of ad hoc SaaS fees.
It’s still early-phase work, but with a downstream impact: if you set up neutral, public-good data rails from the start, your ecosystem growth later on is less painful.
Phase 2 – Early growth: usage and expectations spike
If the launch goes well, we can anticipate a swift rise in usage, and the ecosystem will start to look more like an actual economy than a test lab. The foundation’s job changes from “get this thing live” to “help it scale without breaking.”
a) Growth-phase contributions
In this phase, foundations typically:
- Scale grants and ecosystem programs
- Create themed tracks (DeFi, gaming, infra, education)
- Run open calls with clear eligibility and milestones
- Formalize governance and transparency
- Publish roadmaps and priorities
- Share regular reports on where funds are going
- Stabilize data infrastructure
- Move from “one or two endpoints” to a reliable, multi-region setup
- Introduce rate limiting, abuse controls, and better monitoring
The Arbitrum Foundation’s 2024 Transparency Report is a snapshot of what this looks like in practice. It shows funding for 276 projects across DeFi, gaming, infrastructure, and more, plus new initiatives such as AI-focused programs after its formation in March 2023 and mainnet launch in August 2021.
Arbitrums’ grants approved, by category, in its 2024 report. Source Arbitrum
b) Data infra under stress
From late July 2016 (around 1 year post-mainnet) to the end of 2021, Ethereum’s daily transactions rose from about 42k to 1.2M — a 29x jump (2,800% growth). On a protocol (dApp) level, we can see a similar pattern in Axie Infinity, which went from about 850k monthly active players in Jan 2021 to 2.78M twelve months later, representing over 227% growth in a single year.
.
Ethereum daily transaction chart 2016 – 2021. Source: Etherscan
Early growth is exactly when Phase 1 infrastructure decisions get tested. dApps suddenly drive 10–100× more RPC reads, and public endpoints that handled the quiet launch years now strain under 24/7 polling for balances, prices, events, and archive data.
This is where a foundation has to step in, funding more robust public RPC, archive access, and multi-region deployments, rather than letting under-provisioned infrastructure silently cap the ecosystem.
If RPC is under-provisioned, that shows up as:
- Wallets timing out
- Indexers falling behind
- Devs quietly building on other chains
c) Foundation-to-foundation data partnerships
One pattern we’re starting to see is foundations treating data as a wholesale public good, rather than a series of per-team contracts.
The Solana Foundation and Solana Labs, for instance, maintain shared public RPC endpoints for the network, which are free, rate-limited URLs that any wallet or dApp can access without negotiating its own RPC contract.
Pocket Network’s Foundation Partnerships and F-Chains program is another explicit model here, where:
- Chain foundations sponsor protocol burn at a wholesale rate of $1 per 1 billion compute units (CUs).
- Payments are made via POKT app stakes, and each request burns a small amount of POKT according to the Shannon pricing model.
- The Pocket Network Foundation operates a decentralized load balancer, while node runners stake to serve traffic and earn rewards.
For ecosystem teams, this is demonstrated by a documented public endpoint with generous throughput and daily caps, offering the option of dedicated, unlimited endpoints when stronger guarantees are needed.
The foundation no longer has to negotiate 20 different RPC contracts. It can underwrite one neutral data rail and let specialized vendors compete on top for extra features.
Phase 3 – Maturity: governance, risk, and resilience
At some point, an ecosystem stops feeling “new.” The token might be in the top 20 by market cap. Institutional players are involved. The protocol is embedded in other systems.
Now, the foundation’s job is less about growth at any cost and more about risk management and resilience.
a) Big treasuries, higher expectations
Mature ecosystems often sit on large treasuries, mostly in their native token. That brings new responsibilities.
In June 2025, the Ethereum Foundation published a formal treasury policy that included several changes, such as:
- Annual operating expenses are capped at 15% of total treasury assets.
- EF commits to maintaining a 2.5-year operating buffer.
- The long-term goal is to reduce spending further, toward a 5% target, with regular reporting on token sales and fiat purchases.
In plain terms: EF is deliberately behaving like a conservative long-term steward, not a fast-spending startup.
Other foundations may not publish such detailed policies, but similar constraints apply. Large treasuries need structure to last through multiple market cycles.
b) Infra becomes systemic risk.
As a chain becomes critical infrastructure, data and RPC outages stop being minor hiccups and become systemic risk.
In DeFi, when the pipes clog, protocols can’t reliably update prices or execute liquidations, bridges lose the ability to verify state across networks, and centralized exchanges may pause deposits and withdrawals altogether. At the same time, they wait for the chain to behave again.
At this stage, foundations start thinking about:
- Diversity of providers – avoiding single points of failure.
- Neutral backstops – decentralized networks that can serve as a safety net.
- Clear SLAs and runbooks – knowing who does what when things fail.
Pocket Network’s Shannon upgrade is a good example of designing your data layer around those risks. Pre-Shannon, Pocket mostly acted as a relay system for blockchain RPC; post-Shannon, it runs as a permissionless Open API Network with usage-based burn, multiple independent gateways and suppliers, and protocol-level quality scoring.
In practice, that means underwriting a neutral, decentralized data layer that foundations and gateways can lean on as a shared backstop, while still leaving room for specialized providers, clear SLAs, and operational runbooks on top.
Phase 4 – Renewal: upgrades, expansion, and new narratives
No successful chain or protocol stays static. Over time, the ecosystem starts reaching for bigger moves: launching new L2s or appchains, reworking its economic model, pushing into new verticals like AI, RWA, or DeSci, and even rebuilding parts of the stack with different trade-offs than it chose the first time around.
These “renewal” phases are high-risk and high-leverage. The foundation is usually at the center, coordinating everyone from core devs to infra providers.
a) Coordinating major upgrades
Major upgrades require:
- Governance work: proposals, votes, parameter changes
- Technical work: client updates, migration scripts, testing
- Infra work: endpoint migrations, indexer upgrades, new monitoring
- Communication work: docs, timelines, user guidance.
One good example is Polygon’s 2.0 transition and the MATIC-to-POL migration. In 2023–24, Polygon Labs and the Polygon Foundation proposed a significant upgrade that replaces MATIC with POL as the core token and reorients the network around a multi-chain architecture (the AggLayer).
Coordinating that shift has meant foundation-led governance votes, token migration contracts, validator and infra updates, and careful communication with exchanges, wallets, and users ahead of the mainnet cut-over.
Foundations undergoing similar shifts need strong internal coordination and clear external messaging to avoid fragmenting their communities.
b) Expanding what the ecosystem can offer
Renewal is also when foundations decide what new services they want their chain to support.
That can mean leaning into AI-adjacent workloads that need fast, multi-chain data; backing indexing-heavy DeFi and RWA protocols that depend on deep, reliable history; or making room for new L2s and sidechains that plug into a shared data layer rather than rebuilding their own stacks from scratch.
Here, a generalized data network like Pocket’s Open API approach is one way to give the ecosystem more options without rebuilding infra every time:
- The same data rails that serve base RPC can also serve other APIs.
- Its foundation-to-foundation deals can evolve from “RPC for this chain” to “APIs for this whole product stack.”
Cross-phase responsibilities that never go away
Even as the ecosystem moves through launch, growth, maturity, and renewal, some foundation responsibilities are constant. You can think of them as three axes that cut across all four phases.
Governance as a continuous function
Governance is a continuous function for foundations, not a one-off setup task.
They have to keep processes clear and documented so people know how decisions are made, explain those decisions in a way the community can actually follow, and stay willing to adjust their own role as the ecosystem decentralizes and more responsibility moves out to DAOs, councils, and independent teams.
NEAR Foundation is explicit about this: NF is “a centralized organization championing decentralization as part of a decentralized ecosystem” and expects its role to shrink as the ecosystem matures.
Capital as a long-term resource
Capital is a long-term resource, not just a number on a dashboard. Treasuries will move with the market. Still, the core job stays the same: preserve enough runway to survive multiple cycles, allocate funds in ways that reinforce the ecosystem’s real strengths, and keep a healthy balance between grants, strategic investments, and public goods like infrastructure.
Data & infra as the quiet backbone
Whether a chain is just launching or well into its third major upgrade, somebody needs to own:
- RPC endpoints and other APIs
- Explorers and indexing
- Monitoring, status pages, and incident playbooks
- Relationships with infra providers and networks.
That’s where foundation-to-foundation data models, like Pocket’s Foundation Partner program described earlier, become attractive: they give you predictable, usage-linked costs and stable, no-key endpoints that can be treated as a public good rather than 20 separate contracts.
The responsibilities of a foundation are outlined across the lifecycle in the table below.
| Phase | Governance focus | Capital focus | Data/infra focus |
| Launch | Set up basic structures | Fund core dev & audits | Stand up explorers + initial RPC |
| Growth | Formalize processes & reporting | Scale grants, track outcomes | Harden RPC, add monitoring, consider wholesale RPC |
| Maturity | Manage risk, refine governance | Adopt a clear treasury policy | Diversify providers, treat infra as systemic |
| Renewal | Coordinate major upgrades & pivots | Re-align spend with new priorities | Extend data rails (Open API, new workloads) |
Takeaways for people working in or with foundations
If you work in or with a foundation, a simple lifecycle lens keeps you grounded. At launch, ask whether you have a clear mission, a legal footing, and enough basic infrastructure (explorer, docs, public RPC) for builders to ship.
In early growth, check whether your grants actually match the projects you want, and whether infra incidents are creeping up as usage increases. At maturity, the focus is on guardrails: a written treasury policy with clear caps and buffers, and on treating data infrastructure as systemic, with fallbacks and neutral providers.
In renewal phases—big upgrades or new verticals like AI and RWA—the key questions are whether infra and data are designed in from the start, and whether you have partners who can support new APIs and workloads without fragmenting your stack.
Where Pocket Network fits into this picture
Pocket Network isn’t the only approach to data infra, but it’s a valuable reference for what a foundation-aligned model can look like:
- A non-profit foundation explicitly committed to not profiting from data access, instead charging foundations and gateways at protocol cost.
- A burn-based, compute-unit pricing model under Shannon that ties rewards and costs to real usage.
- A foundation-to-foundation program (F-Chains) where sponsoring chains can give their ecosystems no-key public RPC and dedicated endpoints at a predictable wholesale rate.
For foundations asking themselves, “how do we contribute to this ecosystem beyond grants and governance,” underwriting robust, neutral data rails is one of the most precise answers.
From launch through renewal, that contribution is the same: making sure developers, users, and downstream systems can trust that when they ask the chain a question—through whatever API they’re using—the answer actually arrives.