A Revenue Layer for CKB Nodes

[psawyerberlin]

What if CKB nodes could become a revenue-generating opportunity?

Update (Oct 2): this idea has evolved in the thread into an optional CKB Service Runner, a separate tool beside the node, not a protocol change. See posts #10, #14 and #18. Corrections below are struck through and kept visible.

The Problem

CKB nodes operate at a cost. Unlike Proof-of-Stake chains, they receive no reward stream. The approximately 576 nodes listed on https://nodes.ckb.dev/ are operated by altruists, foundations, and exchanges. This model is fundamentally unsustainable at scale. As @janx pointed out, operators do get non-monetary returns (trustlessness, privacy), and Bitcoin has run on this model for over fifteen years.

The Core Idea

What if nodes could earn fees by running optional services for applications? No protocol changes required. Applications pay for the services they use. Nodes collect fees for providing them.

Expanding the Vision

Imagine if nodes could also do more than just relay and verify transactions:

• Watch on-chain events and trigger webhooks (applications pay per event)
• Store application data as an IPFS alternative (applications pay per GB per month)
• Run oracles (fetch data, compute, sign results)
• Validate user computations via fraud proofs

Each service is independent. Nodes choose which to operate. Applications choose which nodes to pay.

A Proven Example: CRT Where This Started: CRT (in development)

I am developing CKB Revocable Timelock (CRT), a service where nodes hold encrypted key fragments and earn approximately 150 CKB per year per switch. The economics work: the model is simple, profitable, and focused. CRT needs many independent nodes, which is what triggered this idea.

Why This Solves Decentralization

If each of the ~580 nodes could earn even a few hundred dollars a year from ancillary services, enough to cover its own hosting:

• Node operation becomes economically viable in most regions worldwide
• Decentralization becomes a rational business decision, not an ideological commitment
• The network naturally grows toward thousands of independent operators in low-cost regions
• Security improves as the threshold for consensus scales with more nodes
• More independent full nodes make the network harder to isolate or censor, and make services like CRT harder to corrupt (consensus itself stays secured by PoW)

Competitive Analysis

Note (Oct 2): this comparison was written for the original, broader idea; see the update at the top.

Feature	Drand	Chainlink	Filecoin	CKB Nodes
Decentralized	✗ (federation)	✗ (centralized)	✓	✓
Permissionless	✗	✗	✓	✓
Low entry cost	✗	✗	✓	✓
No protocol fork	—	—	—	✓
Revocable/Cancellable	✗	—	✗	✓

Questions I’m Exploring

• Is this economically feasible?
• Which service would matter most to your work?
• What obstacles do you see?
• Should node services be optional or enabled by default? Settled: always optional, off by default, outside ckb itself.

Next Steps

Sept 21, 2026:
I am posting this across multiple forums to gauge community interest. If the response is positive, I will write this up formally for the GitHub discussions (nervosnetwork/ckb · Discussions · GitHub). I do not intend to implement the full platform myself; the goal is to crowdsource ideas and leave implementation to professional developers if the concept resonates.

Oct 2, 2026:
I will create a new GitHub repository, ckb-service-runner, for this purpose. I will keep collecting ideas and take every criticism seriously. In the end, this idea can only fly if many node operators adopt it.

Looking forward to your feedback.

[janx]

This is an interesting topic (a related discussion). The post starts from this premise:

CKB nodes operate at a cost. Unlike Proof-of-Stake chains, they receive no reward stream.

I’d suggest a slight reframing, because I think it changes which question we should be asking.

The costs of running a full node are obvious: hardware, bandwidth and maintenance, usually borne by the operator alone. The returns are less visible, but they exist, and they come in two kinds. The private (internal) returns are trustlessness (you verify everything yourself) and privacy (you don’t reveal which addresses or transactions you care about to a third-party RPC provider). The public (external) returns are the credibility and resilience of the network as a whole. Neither kind is monetary.

The cost/return structure leads to two groups of Bitcoin/CKB full node operators in general: geeks/businesses who value trustlessness and privacy highly, and altruists willing to pay to provide a public good. In short:

CKB nodes operate at a cost with non-monetary returns, and different people value those returns differently.

Seen this way, the model isn’t obviously unsustainable; Bitcoin has run on it for over fifteen years. The more useful question is: what is the net effect on the network if node operators can also earn money from side services? A few things seem worth working out:

• Does service income actually translate into more full nodes? Storage, oracles and webhooks don’t require a CKB full node, and an operator chasing fees could provide them without one, or through a third-party RPC.
• Will the number of node operators running for non-monetary incentives increase or decrease?
• Which new operators will join because of the added monetary reward?
• Is there a minimum income below which it changes nothing, and is that threshold the same for different operator groups?
• What would happen if a full node operator also run fiber channels, i.e. operate a fiber hub?

[psawyerberlin]

You make a fair point about RPC—technically it could work. But I think the real insight is: CKB already has a network.

Why Leverage the Existing CKB Node Network?

Here’s the real advantage: CKB already has 582 independent node operators (ref https://nodes.ckb.dev/).

Instead of building a separate operator network for CRT, event-watching, or any new service, developers just:

1. Write service code (deploy as a cell)
2. Nodes automatically discover and run it
3. Operators earn fees

You don’t need to find, recruit, or convince operators to run your infrastructure. You don’t need to build reputation systems or staking from scratch. The network already exists with built-in incentives for independence.

The Service Runtime design lets developers tap into an existing, proven network of committed infrastructure providers.

Addressing Your Specific Questions

Does service income translate into more full nodes?
Probably yes.

Will non-monetary operators decrease?
Will the number of operators running for non-monetary incentives increase or decrease?
No. Running services is optional. Here’s the key: node operators stay in control with the proposed --enable-service-runtime flag in ckb init. Service runtime is disabled by default.

Minimum income threshold?
Good question/idea. The node operators could set economic filters themselves—minimum fee thresholds, ROI requirements, resource limits. Moreover, the service automatically prioritize based on ROI.

What about Fiber hubs?
This is interesting. Fiber (CKB’s Lightning-like payment channels) is already partially built today. The question: could fiber also run as a Service Runtime service? Could fiber be deployed as WASM in a cell? That would be a question for fiber dev.

---

That’s the idea: reuse the existing network rather than build a new ones. Developers get adoption from day one. Node operators get infrastructure that pays for itself.

[psawyerberlin]

A second thought on the first question above, whether service income actually brings more full nodes. My “probably yes” was too quick; it’s the real crux.

Storage or webhooks can run on any server using someone else’s RPC. So a revenue layer only strengthens CKB if it pays for services where a locally verifying full node is the product, where trusting a third-party RPC would break the service. One example is signing attestations about CKB state, such as “this cell exists at block N,” for a bridge or another chain. A signature is only worth something if the signer verified it on its own node.

So, a challenge for the community: what other service can only be trusted if it runs on a full node?

And to node operators: what would it take for you to enable a service on your node?

[joshyates1980]

I have ran two full nodes out of love for Nervos over the past five years but always wondered about the importance from a different perspective just “how important it is for us to run our 24/7 full nodes.”

I primarily run the full nodes as a way to support Nervos, to have the entire library of blocks downloaded just seems to be overall beneficially for Nervos Network.

Personally, even 1 ckb a day would be a cool reward for running a full node. This could be a type of “signature of acknowledgment” for all the full nodes.

[psawyerberlin]

@joshyates1980 Same here: I’ve been running two miners plus a mainnet and a testnet node for years to support the project. That’s what “RUN CKB” is about.

Your “signature of acknowledgment” touches the hard part: proving it comes from a live, synced full node, not a script reading someone else’s RPC.

A thought: every node already ships CKB-VM, and CKB already stores code in cells. What if an opted-in node could also run service code from a cell, off-chain, in the same VM, cycle-limited like any script? Then “RUN CKB” gets a second meaning: your node doesn’t just keep the chain, it runs CKB code that does useful work. Your acknowledgment signature could be the first such service.

Node operators: would you let your node run code from a cell, if it’s opt-in and cycle-limited?

[psawyerberlin]

For those who prefer video: RyptoCrypto made a short summary of this idea on X
https://x.com/RyptoCrypto/status/2103525842986864653?s=20

Thanks to him for spreading it. One clarification: nothing is built yet. This thread is still the place where the idea is being shaped.

[LusoCryptoLabs]

My two cents, one service that needs the node itself is serving light clients. It runs over the node’s own p2p protocol, so it cannot be served from someone else’s RPC, and CKB nodes already do it for free, since light client support is on by default. Wallets that embed a light client depend on it. A fee there would go to the node itself, not to a server next to it, and it looks like a natural fit for Jan’s idea in the related thread of paying per data served over Fiber.

[psawyerberlin]

Thanks, a good example of a service that only a real, synced full node can provide, and every node already runs it. But I’d be careful: light clients depend on it, so the basic service should stay free, or wallets break. A fee could only work as an optional extra on top, e.g. priority or higher limits for wallet providers, maybe paid per data via Fiber as @janx suggested.

It brings me back to the core idea: full nodes offering side services for a fee, paid in CKB or via Fiber. Applications and their users pay for a service they need, and nodes earn by doing the work. A win-win.

Some services depend on a full node by nature (light clients, attestations about chain state). Others, like storage or event watching, could technically run on any server. My proposal is to make a full node a requirement for every service anyway. An app would then know its service runs on a synced node that verifies the chain itself, not on a script reading someone else’s RPC. That raises trust for all services, and it gives people a reason to run more full nodes.

The hard part is proving it: how does an app know the service really runs on a full node? Ideas welcome.

[psawyerberlin]

Where this thread has led me: trust before money

Thanks to everyone who contributed. A few points changed my thinking:

• @janx: node operators already get non-monetary returns (trustlessness, privacy), and service income only helps CKB if it actually brings more full nodes.
• @joshyates1980: many of us run nodes simply to support Nervos, and some recognition would already mean a lot.
• @LusoCryptoLabs: light-client serving is a service only a real full node can provide, and it has to stay free.

So my conclusion: any service layer must stay outside the node, as a separate, optional tool, never part of ckb itself. And trust has to come before money.

What I’m sketching now, working title CKB Node Runner:

1. A dashboard for node runners. Node health, sync, peers and alerts, plus a live view that makes CKB’s cell model visible (cells consumed → cells created). Useful on its own, no payments involved.
2. An optional, public node ranking. Availability, sync lag, version, age and network diversity, keyed by node ID (never IP), with a verifiable summary published on-chain. It rewards long-term reliable operators with reputation, the “signature of acknowledgment” idea in a first form.
3. Only after ~12 months of ranking data: an optional service runtime, where ranked full nodes can take paid jobs. By then there’s a track record to choose nodes from, and time for applications to be built on it.

Would you install such a dashboard on your node? And what would you want it to show?

[LusoCryptoLabs]

Thanks for pulling this together. A few things that may help.

Your first step is the same one Jan proposed as CKB Node Ninjas in the related thread post #2, a daemon beside the node and an ethstats-style site, funded by the Community DAO, which would pick rewards among the reporting nodes. That may be a path to funding the dashboard. His sybil point carries over too, node IDs are free to create, so availability and age would do most of the work.

“Network diversity” and “never IP” pull against each other. Publishing each node’s network operator (ASN) and region, without the address, keeps both. ckbadger’s crawler already records discovery, sessions and dial results, and its README says what that does not prove.

What we would want it to show: which nodes serve light clients (LightClient and Filter in their protocols), and which offer a public RPC. In the related thread, phroi counted two public RPC nodes he could query from a web app.

On proving a service runs on a full node: our resolver can read from any public node, and that is fine, because every answer carries a proof a client can check. Where an answer can be checked, where it runs stops mattering.

[psawyerberlin]

Thanks, very helpful. I hadn’t connected this to @janx’s CKB Node Ninjas proposal, but it’s essentially the same idea: a reporter beside the node and a public stats site.
CKBadger’s crawler looks like a natural data source. What’s missing is the reporting side and a shared public ranking. @janx, would you still like to see CNN built, and as an add-on to CKBadger or a separate project?
Agreed on ASN and region instead of IP, and on showing light-client and public-RPC support.
On proofs: agreed, a proven answer doesn’t depend on which node served it. I’d still require a full node, to reward nodes that make the network stronger and enhance trust: each paid service should come with another running full node.

[joshyates1980]

This idea could also be supported by developers and not just the Foundation, for example @Ayoub_Lesfer wants to develop a CrowdCell application which the business flow might not completely line up with what we are talking about with a revenue layer for CKB nodes, but for the community to support full nodes can also be considered. $ckb is so affordable that the community could step in and share a donation.

[psawyerberlin]

Thanks @joshyates1980, I like that direction. A group of developers and node runners could build a CKB Service Runner together: an optional tool that runs beside the full node, provides a health dashboard and executes jobs for applications. A group that supports the project would also speed up adoption.

The revenue layer for nodes is a by-product, not the goal. The real goal is to make CKB the best place to build truly decentralised apps that don’t depend on anyone. Many dApps today still depend on a server of their own: a bot that triggers transactions, an indexer, a keeper. CrowdCell’s finalization bot is one example. With a Service Runner, those jobs would run on many independent full nodes instead, so no single operator can switch the app off.

• Users get apps that keep working, whoever built them.
• Developers get decentralised infrastructure without running servers themselves.
• Full-node operators get a new reason to run a node, and a fee for the work.
• CKB gets more full nodes and truly decentralised applications.

A clear win-win for all stakeholders.

[janx]

I believe it should be a separate project. Collecting and ranking full nodes (possibly with daemons running alongside the CKB node), and linking these to rewards is beyond CKBadger’s scope.

[Ayoub_Lesfer]

Cheers for the mention @joshyates1980. @psawyerberlin yeah the finalization bot is a good example of what you mean. Release and refund are permissionless on CrowdCell, the lock script checks where the money goes so it doesn’t matter who submits the tx. Right now the bot runs next to the indexer on a free Render instance, which works but it’s still one operator. One detail that might help the design, the fee for release and refund already comes out of the pledge cell, so a runner doesn’t need to hold CKB for those, but there’s also nothing in it for them yet. A keeper tip would have to be built into the lock script, which is doable. If the Service Runner gets to a testnet version I’d be happy to try moving the bot onto it.

[NightLantern]

My concerns are as follows

1. Why fix what isn’t broken. Bitcoin which is the golden standard. Has full nodes that don’t get paid and the network still works. CKB already handled the part that actually gets expensive with state rent, so a normal node stays cheap to run. Unpaid verification is the model, not a problem that needs a revenue layer.

2. This just raises the cost for apps. If they have to pay nodes for webhooks, storage, oracles, or key holding, that cost lands on the people building on the chain. CKB’s is a lean L1 with computation pushed off-chain. Adding a standing fee market for “node services” raises the cost of building on the chain

3. What are we actually incentivizing. A miner running 10 machines raises hashrate. Someone running 10 nodes doesn’t. Consensus here is work, not node count. If payouts are per node, one person can spin up a bunch and collect several times. That’s gaming it, not decentralizing it. More nodes also don’t raise the consensus threshold on a PoW chain.

4. None of this incentivizes mining. Miners already get issuance and fees. Paying some node operators for side services doesn’t add hashpower and doesn’t fund security. It’s a separate business. Fine if someone wants to sell it, but it isn’t a fix for how the chain is secured.

If a person cares about their investment, it’s wise they support the network that their investment exists on, and such support appreciates their asset. But if a person wishes to earn, they should expend the electricity and mine. This is PoW, not PoS.

[psawyerberlin]

Thanks all. Answering the last three together. I’m also updating the first post to reflect where this thread has taken the idea. Corrected parts are struck through, not deleted, so the history stays visible.

Where this came from. The trigger was a concrete need: CRT needs many independent nodes to hold key shares and release them when the conditions are met. Rather than recruit a separate network just for CRT, I asked whether CKB node operators could run it. The idea is generic: the same runner could host CRT, CrowdCell’s finalization bot, and any app that today depends on one server of its own.

@janx Agreed, a separate project. A tool that runs beside the node, never inside ckb. CKBadger can stay what it is; at most, its data could be read, not extended.

@Ayoub_Lesfer That’s exactly the use case, thanks. Permissionless release/refund plus a fee already paid from the pledge cell means a runner needs no funds and no trust. A small keeper tip in the lock script is all that’s missing, paid to whoever submits the transaction first. When there’s a testnet version, CrowdCell and CRT would be the two pilots. What tip would feel reasonable to your users?

@NightLantern Fair points, and I agree with several of them:

1. Not broken: agreed. Unpaid verification works, and this doesn’t try to fix it. The revenue is a by-product (see #14); the goal is apps that don’t depend on a single server.
2. Cost for apps: it adds no cost to apps that don’t use it. Apps that do run a bot or keeper already pay for it today (a server, an operator, a single point of failure). The runner replaces that cost; it doesn’t add one. In CrowdCell’s case the tip would come from the pledge cell, just as the fee already does.
3. What’s incentivized: on PoW, consensus is hashpower, not node count, so “consensus threshold” was the wrong word in my first post. But I still think more independent nodes make things safer. For a service like CRT, more nodes holding shares means more operators would have to collude to break it. For the network, more full nodes mean more independent verification and a network that’s harder to isolate or censor. The key word is independent, which is why pay is per job done, not per node (ten idle nodes earn nothing), and why node choice would rely on reputation and diversity, not node count.
4. Mining: agreed. It doesn’t add hashpower or fund security. It’s a separate business beside the node, which is exactly what it should be.

So in one line: an optional side application next to a full node, which earns only once many apps use it as their decentralised backend.

[psawyerberlin]

The project is now CKB Service Runner: a separate application you install next to your full node. It needs no change to ckb and no consensus change, and nothing runs unless the operator opts in.

GitHub - psawyerberlin/ckb-service-runner: Side application for CKB full nodes: dashboard,...

The plan, in two phases (testnet first):

• Phase 1: dashboard and node ranking. A web dashboard for your node (based on a CKB fork of mempool) and a public ranking of runner nodes by availability, sync, age and network diversity, summarised weekly in a stat cell. Operators get something useful from day one, before any paying service exists.
• Phase 2: service runtime. Once the network has run for 12 months with at least 60 diverse nodes, services published as cells run in a CKB-VM sandbox. CRT (revocable timelock) would be the first.

[Ayoub_Lesfer]

@psawyerberlin sounds good, happy to be one of the two pilots. On the tip: the pledge lock already caps what can leave a pledge cell at 1 CKB on release or refund, and the minimum pledge is 100 CKB, so I’d keep the tip inside that cap. Flat per pledge cell, not a percentage, since the work is the same whatever the pledge size. That’s under 1% on the smallest pledge and the real tx fee is a tiny part of it. On a refund it comes out of the backer’s own money, so I’d rather keep it small there. Does a flat amount per job work for the runner or do you need it to scale with something?