# Metanode: early thinking on consolidating node services **URL:** \ **Category:** Tech Talk\ **Created:** [September 18, 2026, 1:53pm UTC](https://forum.polkadot.network/t/metanode-early-thinking-on-consolidating-node-services/18689 "2026-09-18T13:53:58Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![acatangiu](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/acatangiu/32/540_2.png) [@acatangiu](https://forum.polkadot.network/u/acatangiu)\ **Post date:** [September 18, 2026, 1:53pm UTC](https://forum.polkadot.network/t/metanode-early-thinking-on-consolidating-node-services/18689/1 "2026-09-18T13:53:58Z")
# Metanode: early thinking on consolidating node services Most of the Polkadot Products Platform is going live now or very soon. Products and users will be coming with it (e.g. the Polkadot App), and the Polkadot decentralized nodes fleet needs to be ready to absorb that demand. This post is meant to start a conversation on how best to do that. We would like to build the shape of this with our existing operators and community. ## The demand that is coming The Polkadot Products Platform will require full nodes to serve the clients (triangle hosts). Each user session will run light clients to interact with the different chains. Thus, we expect to require many more full nodes to meet their requests. Three chains carry most of that load: - **Asset Hub (AH)** - contracts, assets, and most of what products touch on-chain. - **People Chain (PC)** - identity, and the messaging that sits on top of it. - **Bulletin Chain (BC)** - static apps, app assets, user media. These will be heavily used by each client in the Triangle (Mobile App, Desktop, Web) regardless of which product/dapp is used on top. All products will use assets or SCs, identity/personhood is a core part of our Humanity-focused, privacy-focused stack, and all dapps are loaded from BC (plus their potential dapp-specific user storage). Today the full nodes for all of the above are provided by a mix of RPC providers, collators and bootnodes, each funded separately. That has worked so far (with varying degrees of success or ease), but it is definitely not sized for the demand that is about to arrive, and it is hard to adapt. ## Current shape is hard to scale The current model of several separate bounties for RPCs, collators, bootnodes, doesn’t scale. Each has its own funding, its own renewal cycle, and its own set of providers. That means: - Nobody is accountable for whether the whole thing works end to end. Each part is funded on its own terms. - Quality is administered through OpenGov rather than measured by the protocol. Governance can fund or defund a bounty, but it cannot tune how well a service runs. - Scaling any one part or shifting resources from one to another means separately going back through its own process. We have a stronger model already in use: Polkadot Consensus. Polkadot validators are measured on era points, paid on that measurement, and penalised when they fail. The mechanism has proven to work and provide high-quality consensus as the Polkadot base-layer offering. **The new services of the stack powering the Polkadot Products Platform need something equivalent.** ## What we are thinking about The short version: **have validator operators run more of the stack.** Validators are already a large, well-distributed, well-run fleet with identity, stake and an election mechanism. Rather than building new fleets for each service, we would rather reuse the one that exists. Concretely for this year, that means asking validator operators to also run collation for Asset Hub, and likely People Chain. For Bulletin Chain, where storage hw costs are non-negligible at scale, we can have validators opt-in progressively as we get more data on the demand. For anyone following Ethereum, the closest analogy is **based rollups** : the L1 validator sequences the rollup instead of a separate sequencer set. Same move here: validators collate instead of a separate collator set. Longer term the same approach extends to the rest of the service layer, and the services provided can be metered as part of the protocol and paid accordingly. We will come back to that in later posts. **This post is about the near-term step.** ## What this means for operators **Extra hardware required will be compensated.** We are not asking anyone to absorb the cost of running more. Providing more services, and serving more components of the stack, will in effect open more streams of income for validators. We do not have final hardware numbers yet, and we would rather publish them once they are measured than guess now. Early testing suggests that adding Asset Hub collation to an existing validator is a modest addition rather than a second machine’s worth of work, partly because the collator can reuse the validator’s relay chain connection. We will share the numbers when we have them. Nothing here is mandatory yet, and nothing changes without notice. ## What we would like to hear 1. **What does your current setup look like?** One machine or several, bare metal or cloud, containers or systemd? 2. **If you were asked to run an extra node alongside your validator, what would break first?** Hardware, bandwidth, monitoring, on-call, something else. 3. **How much notice would you need** to add hardware, given your own purchase and contract cycles? 4. **What would make this worth doing for you** , beyond covering the cost? 5. **Is there anything totally wrong here?** We will post more as the design firms up, including hardware guidance and how compensation would work. ---
**Author:** ![ultracoconut](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ultracoconut/32/5932_2.png) [@ultracoconut](https://forum.polkadot.network/u/ultracoconut)\ **Post date:** [September 19, 2026, 9:15am UTC](https://forum.polkadot.network/t/metanode-early-thinking-on-consolidating-node-services/18689/2 "2026-09-19T09:15:19Z")
I think moving everything to the validators would be too much of an overload for them, don’t you think? I’m proposing this; perhaps we could add RPC to the collators, but I’m not sure. > [@Proposal: Unified Collator Pool for System Chains (64 Slots)](https://forum.polkadot.network/t/proposal-unified-collator-pool-for-system-chains-64-slots/18453): > > Short Description I propose unifying the collator infrastructure of Polkadot’s System Chains — Polkadot Hub, Bridge Hub, People, Collectives, etc. — into a single shared pool of 64 active operators. Instead of maintaining separate collator sets for each System Chain, all operators would be capable of supporting the entire System Chain ecosystem. The protocol could then dynamically assign block production responsibilities across the pool. The goal is to reduce infrastructure fragmentation, impr… ---
**Author:** ![ross](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/ross/32/11267_2.png) [@ross](https://forum.polkadot.network/u/ross)\ **Post date:** [September 19, 2026, 12:40pm UTC](https://forum.polkadot.network/t/metanode-early-thinking-on-consolidating-node-services/18689/3 "2026-09-19T12:40:11Z")
This makes sense in principle but I’d withhold final assessment until the hardware and resource requirements are made public. In my view it is absolutely worth doing with the current public incentive structure given that the requirement is a modest addition and not a separate dedicated machine. I would say a month notice is fair; scaling hardware is not a problem. Integrating the additional setup into existing playbook processes will probably be a more critical task than upscaling hardware. Looking forward to see how this develops. Happy to discuss actual current setups and how they’d be effected off the forum.