Pay By The Second, Watched By The Second: The Problem Hiding Inside Micropayments

abel · August 16, 2026, 7:25pm

A few weeks ago I came across a post from CKBA on LinkedIn about micropayments. The argument was that subscriptions exist mostly because charging tiny amounts continuously has never been practical, and that once you fix that, you can sell things that were previously commercially unviable. Fourteen seconds of GPU time. A single token of AI output. Only the bandwidth you actually used.

It stuck with me. I started reading into Fiber to understand how the mechanism actually worked, and the deeper I went the more I noticed something the pricing argument leaves out. If you bill someone by the second, you also create a record of them by the second. Whether that becomes a problem depends entirely on where those records are settled, and that turns out to be the more interesting half of the story.

So I wrote it up. I am new to this ecosystem and still learning it, so corrections are welcome, particularly from anyone working on Fiber directly.

The arithmetic of granularity

We begin by looking at what changes when billing reaches a fine level of detail.

With a monthly subscription, twelve billing events occur per year. This simply tells the service that you are a customer and, at most, which service tier you use. Your actual usage remains a private matter between you and the service provider.

Now consider per-second billing. Moving from monthly to per-second billing generates approximately 2.6 million additional billing events in a continuous-use scenario. Listening to a podcast for an afternoon can generate thousands of payment records, showing the amount paid and the exact moment of each payment.

The significance of this depends entirely on where those records end up.

When all settlements take place on a public blockchain, the payment flow and the record of behaviour become one and the same. There is no need to hack a database to find out what you listened to, when you started, when you paused playback, or when you stopped listening twenty minutes later. That information is already public.

That also applies to the use cases people are excited about. With token-based AI billing, payment records could reveal the queries you made and the length of the responses. For electric vehicle charging billed by the kilowatt-hour, they could reveal where your car was located and how long it stayed there. Data streams billed per request could reveal real-time market activity and the urgency with which you needed to monitor it.

These three examples turn an implicit usage pattern into an explicit payment record. That behaviour might already exist in a provider’s server logs, but there is a crucial difference between keeping that data behind corporate doors, subject to contracts and regulations, and permanently recording it on a ledger open to indexing by anyone.

The more granular the billing, the higher the resolution of the payment record. That part is arithmetic. What is not predetermined is whether that resolution becomes public. That decision is architectural.

Privacy is not the same thing as hiding something

In a November 2025 status update, the Fiber team, who are developing CKB’s payment channel network, addressed this issue directly. Their approach is worth adopting because it cuts through the usual defensiveness: privacy is not anonymity, and seeking privacy does not imply acting suspiciously.

They give two examples, neither of which involves anyone doing anything wrong.

A company pays its employees in stablecoins. On a transparent ledger, all the organisation’s salaries become public. Not just to regulators, but to everyone, including the employees themselves and any competitor trying to hire them.

Then there is the case of a milk tea shop that accepts stablecoins. Competitors can literally read its daily revenue on-chain. Not estimate it. Read it.

There is no wrongdoing on either side. It is ordinary business activity, yet total transparency makes maintaining that activity difficult. MEV, or Maximal Extractable Value, as the Fiber team notes in that same post, is a manifestation of the same fundamental problem: if everyone can see what you are about to do, someone can get ahead of you.

Now multiply that problem by the volume of events involved in micropayments. The practical viability of a payment system with enough granularity to be truly useful depends largely on whether that granularity is made public by default.

Why channels change the equation

This is where payment channel networks start to become much more than just a scalability solution.

Typically, on a public blockchain, transactions are broadcast across the network so that nodes can validate them and reach a consensus on a shared state. This is what makes transaction activity visible to the rest of the world, while also making the chain a reliable source of shared information.

A payment channel network works differently. The channel is created on-chain, but routine payment updates between two parties occur off-chain through a sequence of signed states exchanged between them. On-chain transactions are primarily needed when a channel is opened or closed, or when it requires some form of intervention, such as during a dispute or forced closure.

It is worth understanding the mechanism that keeps this honest because it explains why privacy here does not necessarily require a tradeoff. Each new update replaces the previous one and includes a method for the counterparty to penalize anyone trying to settle using an outdated state. If your counterparty closes the channel using a previous balance that was advantageous to them, you can claim their funds as a penalty. Mere observation does not prevent cheating. The design makes cheating unprofitable.

This naturally raises an obvious issue: you need to be watching.

If your counterparty attempts to cheat while you are offline, the action could go unnoticed. This is where watchtower services come into play. A watchtower monitors the state of a channel on your behalf and can generate and submit the appropriate revocation transaction when it detects that an old commitment has been published. You delegate the monitoring responsibility without giving up custody of your funds.

When multi-hop routing is added, where payments travel along a path of connected channels from one node to another, the privacy feature follows. Onion encryption ensures that an intermediary node only needs to see the information relevant to its own hop rather than the entire payment path. Generally speaking, only the nodes involved in a payment’s path need to observe that payment at the network level.

Therefore, it is incorrect to say that micropayments automatically create surveillance systems. High-frequency payments settled individually on a public blockchain would create that problem, but channel architectures exist precisely to separate these two things. Payment channels separate payment frequency from public settlement frequency. It is clear, then, that whether micropayments are compatible with privacy depends on their architecture, not simply on transaction costs.

Fiber makes this concrete at the level of a configuration flag. Its documentation describes a unidirectional channel, opened with the flag one_way: true, where funds can only move from the initiator to the acceptor. Its first listed use case is streaming payments, where a subscriber pays a content provider on an ongoing basis, for example per second of video watched or per API call made. This is followed by machine-to-machine payments, where a device drips payments as it consumes compute, data, or bandwidth.

The key detail lies in the characteristics associated with this type of channel. Unidirectional channels are always private and do not allow for the routing of third-party payments. According to the documentation, any attempt to configure a channel to be both public and unidirectional is rejected. These channels also remain invisible on the network graph.

Therefore, the channel type Fiber proposes for streaming payments is designed to be publicly invisible. Privacy is not an optional choice for the user. It is an intrinsic feature of the tool created for this specific purpose.

The cost figures are also relevant. The Fiber repository indicates that it supports payments as small as 0.0001 cent, with a fee of 0.00000001 cent. It is within this range that per-second billing stops being a metaphor and becomes a reality.

What Fiber brings to the Lightning model

The general concept behind these ideas is not new. Bitcoin’s Lightning Network pioneered this method, and Fiber’s documentation makes it clear that it follows in those footsteps.

What Fiber contributes to the Lightning model is enabled by the underlying CKB network.

Fiber is built on CKB, a network that allows for programmable on-chain states using the Cell model, alongside scripts that define how that state is validated. This equips Fiber with native multi-asset functionality that goes beyond the single-asset Lightning model found in Bitcoin. The repository mentions compatibility with stablecoins, RGB++ assets issued on the Bitcoin ledger, and UDT assets issued on CKB.

This means that a payment and an exchange can be combined into a single operation. If a channel route exists, Fiber enables immediate exchanges between asset pairs. Its roadmap documentation also identifies streaming swaps, or continuous exchanges, between USDI, CKB, and BTC across multiple routes as a target use case.

At the payment network layer, Fiber was designed with interoperability in mind, and the repository includes cross-network payment and exchange capabilities, specifically between Fiber and Lightning. According to a Q2 2025 Messari report, the network launched with multi-hop routed payment functionality, multi-asset channels, and a watchtower service.

This layered structure is intentional, at least according to the team behind the project. In a November 2025 update, Fiber’s developer relations team stated that the technical trajectory of Nervos was built on a combination of Proof of Work, UTXO, and Layer 2 channels. They also cited the CKB whitepaper to argue that channel networks were part of the original design rather than an afterthought.

This is further along than the pitch decks suggest

A common weakness in this type of analysis is that use cases often remain purely hypothetical. Multimedia streaming, machine-to-machine payments, and autonomous agent economies are plausible scenarios, yet none have been demonstrated in practice.

Fiber features a showcase page that helps address this objection. It currently hosts dozens of open-source projects, a significant number of which correspond exactly to the scenarios outlined in the initial conceptual proposal.

There is a self-hosted audio and podcast player that charges for every second of listening time, as well as an electric vehicle charging simulation based on pay-per-use micropayments. There is also a blog demo featuring paid content that uses an L402-style access control system as a paywall, along with retro games that settle micropayments during gameplay and an escrow system built using hold invoices.

A much denser ecosystem has formed around autonomous agents. Agent Pay is a decentralised payment protocol for agent economies, native to Bitcoin. Fiber402 is an autonomous wallet agent that pays for on-chain information using x402. Omniflow manages agent workflows, including channel administration and invoice payments. Fiber Pilot is an agent that manages a node’s own liquidity and routing. There is even an AI agent for token analysis that accepts micropayments via Fiber in exchange for its responses.

It is best to view these projects as community-developed examples rather than definitive proof of widespread adoption in production environments. Nevertheless, they answer the question of whether it is truly possible to create such solutions. The answer appears to be yes.

Where the protocol actually stands

Anything beyond this is pure marketing. The development updates released by the Fiber team are notable for their candor, and the following shows how the story around the most difficult parts has evolved, according to the team itself, over the past twelve months.

Two of the main challenges highlighted in the November 2025 status update were technical complexity and the lack of an ecosystem or a killer app. A security audit revealed issues that took over a month to resolve, while large-scale stress tests uncovered performance problems that had not surfaced during standard development. The team was also refining contract logic and watchtower systems to handle extreme edge cases.

They also made some blunt points about routing. A node has only partial information about the network as a whole, finding optimal routes is complex, and, to their knowledge, no best practice has yet been widely adopted.

By January 2026, the focus had shifted. Describing Fiber as “protocol-complete” and “network-tested” on this forum, core developer quake outlined progress on both the protocol and engineering sides. The protocol specifies the full lifecycle of channels, including opening, updating, closing, and dispute resolution. It also supports multi-hop payments and defines state commitment, forwarding rules, and failure handling.

From an engineering standpoint, a functional core written in Rust is in place, alongside implemented channel state machines and routing logic, as well as on-chain contracts and scripts for settlement, state verification, and dispute management.

A year of testing with multi-node networks revealed edge cases involving fund safety, performance bottlenecks under load, and the need for greater stability and resilience among individual nodes in the network. Much of the work in recent weeks has focused on resolving these issues.

This self-assessment is more valuable than any outside analysis could be. The team approaches the matter with Lightning’s own history in mind, placing Fiber in an early stage of network development. It has moved past basic channel functionality validation and into validating network behaviour under more realistic conditions, but there is still a long way to go before widespread wallet adoption and ecosystem maturity.

Their outlook for 2026 shifts the focus from the immediate engineering challenges of 2025 toward considerations such as protocol complexity, liquidity, wallet integration, and ecosystem maturity. Regarding complexity, they note that features like routing, multi-asset support, and watchtowers introduce a high level of complexity and should only be tackled once the core is stable. They also warn against the temptation to simply impose Bitcoin and Lightning assumptions onto a Turing-complete base layer that does not necessarily require them.

Liquidity remains the primary constraint. Acting as a useful routing node requires opening channels with multiple peers, which ties up capital and demands constant management. This is one of Lightning’s fundamental challenges, and Fiber’s stated plan is to adapt proven concepts, such as liquidity pools and rebalancing, to its own design.

Other priorities for the year focus on wallet integration, specifically mentioning JoyID, as well as creating documentation and demonstrations for developers and partners rather than marketing activities.

This is what genuine infrastructure work looks like. These status updates are valuable because the cycle of narrative rewards moves much faster than the actual work itself.

The point

The argument for micropayments is usually framed in terms of pricing. The result is more precise billing and, with it, the ability to sell products and services that a subscription model could never support.

That argument is valid, but it represents the less significant part of the story.

The most significant part is that per-second billing generates per-second records. Whether those records leave a public trail of behaviour depends on where the transactions are settled.

Payment channels are generally described as a mechanism to make blockchain transactions faster and cheaper. Another fundamental characteristic is that they move high-frequency settlement activity off the public ledger. Privacy therefore emerges as a design choice rather than an afterthought.

And, incidentally, if streaming payments do become the foundation for AI services, machine-to-machine commerce, and the media sector, that privacy will not merely be another positive feature. It could, in fact, be the factor that makes all of this possible at scale.