# BZZ as an investable instrument
**Date.** 2025-11-01.
**Disclaimer.** This memo describes a vision for the value proposition for BZZ and goals for BZZ tokenomics developed by [Shtuka Research](https://shtuka.io), a partner of the Swarm Foundation. It is **not** the official position of the Swarm Foundation or part of any official roadmap.
It is intended as a living document and community feedback, through commenting here on HackMD or by reaching out on Discord (@awma or @aata.eth), is invited.
[toc]
## Executive summary
* The most promising value accrual mechanisms for the BZZ token are based on distributing shares of the Swarm Network revenue to BZZ stakers. TVL — the dollar value of the BZZ locked in staking — is a direct measure of the realised investor demand for this revenue stream.
* The key factor limiting TVL growth today is market sentiment about the future of Swarm revenue. The most impactful way to unlock higher TVL will be to grow demand for Swarm's services.
* A secondary limiting factor is stake fragmentation inherent in the design of the redistribution system, which splits the staker market into thousands of tiny sub-markets. Fragmentation amplifies the effect of pvp competition and substantially complicates position management.
* BZZ lending or equity markets could improve investor access to Swarm revenue by separating the roles of capital and operations. In order to record debt priority or shared ownership onchain, Swarm's staking system would benefit from modifications that allow staked assets to be controlled by smart accounts (not just EOAs).
* Due to the small amount of total stake in play today, present node operator demand for external financing is probably very low, so the potential for a BZZ-based debt or equity market to gain traction in the near future is correspondingly limited.
## BZZ value accrual
Why might anyone buy the BZZ token? In terms of the core protocol incentives, there are basically two reasons:
1. To pay for Swarm services, i.e. storage and bandwidth.
2. To access a portion of Swarm revenue by running a node and staking.
It is [often claimed](https://x.com/ethswarm/status/1659195057940094979) that the BZZ token is intended to be a "utility" token, meaning that its primary function is to facilitate transactions between buyers and sellers of storage services. One might naturally assume, therefore, that use case (1) will be the primary driver of market capitalisation (MC). In this note, I will argue that it is in fact (2) that provides BZZ with its "buyers of last resort" that fundamentally drive valuation; any price action driven by monetary activity as in (1) will generally be marginal and ephemeral.
### Who is the buyer?
A key distinction between these two sources of demand and their propensity to drive value to the token is the role of the holder in the ecosystem and their level of intrinsic buy-in to the future of the Network. In (1), the buyer is a Swarm user, while in (2) it is a service provider.
Although Swarm users do, by choosing to host part of their infrastructure on Swarm, have some implicit commitment to the future of the service, I claim that the service provider class has considerably more. A service provider who has made the investment to deploy and maintain node fleets needs the Network to succeed in order to continue its business. It needs the value of its stake positions to grow. It is natural to expect that service providers will be the ones to buy and hold BZZ tokens over longer periods.
Meanwhile, low buy-in users can get away with only acquiring BZZ tokens shortly before they wish to pay for the service. In the context of the new Swarm app which provides instant cross-chain liquidity for buying quotas, the holding time for most users is a matter of seconds. Users only need the Swarm Network to persist for as long as they use the service. It is cheaper to switch to a new storage service than to pivot a service provider operation.
From the perspective of an investor, (2) furnishes BZZ with a cash flow and hence a reason to own the token. The price at which the investor is prepared to buy the token depends on the size of the cashflow, confidence in the future sustainability of the cashflow, and the dividends or yields available elsewhere in the market.
Somewhat less convincingly, an investor might also consider speculatively buying the token in the hopes of later selling it to a price-insensitive Swarm user wishing to use it for a payment. The prices at which this resale could happen depend heavily on complex secondary market dynamics, e.g. liquidity depth and velocity of money. Without cash flows to anchor the valuation, it is much harder to link these prices to the value of the storage service itself.
### TVL and "liquid" MC
The Total Value Locked metric counts the dollar value (marked to market) of the total BZZ balance locked in the Stake Registry contract. It is a measure of the amount of investor interest in Swarm cashflows: a TVL of $X$ means that investors collectively invested $X$ in order to get a piece of Swarm profits.
For the sake of analysing the relationship between TVL and MC, introduce a new term *Liquid Market Cap* (LMC) for the portion of BZZ supply which is "liquid", i.e. not locked in stake positions. Today, all liquid BZZ can be thought of as being ready to trade.
The main reasons to hold liquid BZZ are:
* Facilitating BZZ trading
* Short term speculation on BZZ price
Both of these motives are non-fundamental — they only generate returns if there is *already* someone in the market willing to buy the BZZ token. That someone is the fundamentals investor who stakes BZZ in order to earn its cash flows.
When the total value of assets standing ready to buy into Swarm revenue is larger, the market for trading should also be larger. I therefore argue LMC is an increasing function of TVL (though there are of course other factors). If it is a goal of the Swarm Community to grow the market cap of the BZZ token, then TVL is the pivotal component to optimise on.
### Transaction currency
A complication to our revenue-driven value model for BZZ is that Swarm revenue is itself denominated in BZZ. Generally speaking, the opportunity to earn more of the same token is not in and of itself a reason to buy the token — you still need someone to buy it off you. Concretely, in order to realise a profit, NOs must sell their revenue for cash (e.g. USD). But to whom will they sell it and for how much?
In order to untether the valuation of this revenue stream from the BZZ price, we will need to abstract away the transaction token. We will argue that its cash value is driven by the real-world value of the storage service and not token prices, so that in this case it *does* provide a fundamental driver of MC.
Consider the following idealised model for Swarm payments:
* Users continuously pay for storage in cash as they use it.
* All storage providers receive a stake-weighted share of the revenue stream immediately, again in cash.
This would need to be facilitated by middleware services handling:
* Conversion of cash to BZZ at time of purchase;
* Conversion of paid-up-front storage quotas in fixed sizes to elastic, on-demand storage;
* Revenue redistribution liquidity;
* Conversion of BZZ rewards to cash at time of payout.[^middleware]
[^middleware]: At both buyer and seller end, these abstractions incorporate a maturity transformation that entails some price risk (both for storage price and BZZ exchange rate). MMs on both ends must hold some BZZ on their books. So these services most likely incur a fee, possibly increasing with volatility.
Posit a world in which nearly all Swarm users and NOs transact through these middleware services. (If such services exist, I think the likely outcome is that most participants will use them.) Now suppose the following happens:
* A repricing of BZZ occurs, resulting in a temporary volatility spike and a persistent new price.
* The price oracle recalibrates the storage price back to its previous cash value, assumed to be in equilibrium.
What happens to the cash value of the revenue stream? If the repricing happened for some reason unrelated to confidence in the future of Swarm — say, a change in token supply implied by the Foundation announcing it will burn a million BZZ — then it remains the same. The same people are still out there pouring the same amount of cash into buying Swarm services.
The repricing does change the liquidation value of BZZ-denominated stake. If the main motivation to put BZZ in stake is to get access to the cashflow, then the result is likely to be that stakers adjust their balances to restore the cash value of the position to where it was before the BZZ repricing.
## Accessing BZZ cash flows
In order for a cash flow to drive value to the BZZ token, there needs to be a way for investors to access it. Unfortunately, the Swarm network's design and current state has a few peculiarities that may reduce this accessibility.
The main pain point is stake fragmentation, which complicates operations and competition. The increased cost of these factors further cuts into the already slim capacity of the opportunity presented by Swarm revenue today. Improving tooling and finding ways to aggregate stake into larger pools will improve accessibility for all investors, not just those with access to devops gurus.
### Operations
In order to access a share of BZZ revenue, would-be investors must run nodes. In order to scale the position, investors can use a combination of adding more stake to each node and increasing the number of nodes (i.e. individual bee processes) they run. Since [SWIP-21](https://github.com/ethersphere/SWIPs/blob/master/SWIPs/swip-21.md), it has also become possible to increase the area of responsibility (AoR), and hence network share, of a single node. This has been tested successfully up to a reserve size of 256GiB, or 16 times the size of a basic node.
Managing hundreds of node processes, their Gnosis chain accounts, and their stake positions is a complex devops operation. While standard devops tooling is available (and familiar to professionals) for managing the bee processes themselves, tooling for secure management of large numbers of keys, sweeping revenue from accounts, and adjusting stake positions in response to signals is much less standard. To effectively stake even $1K worth of BZZ probably requires bespoke automation solutions.
### Competition
While the overall level of competition among Swarm NOs is low, the fragmented structure of the reward sharing system means that even a little competition can be sharply felt. Each stake deposit competes in the tiny pool of stake attached to the same neighbourhood — less than $20 in most cases. Even a pocket's change worth of additional deposit sharply impacts the ROI of other investors in the same pool. To avoid triggering a top-up war of attrition, investors must carefully split any deposit they wish to make across numerous neighbourhoods. Again, managing these transactions is costly and there is a lack of off-the-shelf solutions.
### Capacity
The Swarm network currently doesn't have much revenue, so the capacity of the staking opportunity today is correspondingly small.
The largest possible "honest" node operation runs a node in every neighbourhood, which currently amounts to 1024 nodes.[^honest] To access a share of revenue roughly proportional to the node count, the operator must stake 40 BZZ per neighbourhood, or ~40000 BZZ. At time of writing, that's about $4500. It's not an enormous sum, but still, a purely income-motivated node operator may be put off by the level of long exposure entailed by owning those funds.
[^honest]: Since a node operator may increase his share of the revenue to a neighbourhood by simply topping up stake, there is no "honest" reason to run multiple nodes in a neighbourhood. The only motivation I know of to run multiple nodes replicating the same data is to misrepresent the resilience of Swarm storage or manipulate prices.
The capacity of the trade is then 1/4 of Swarm's revenue of $5K/month. Running a 1000+ node fleet may entail substantial management overhead. For how many investors is the $1250/mo less costs up for grabs worth the labour effort of managing such a fleet?
Staking and revenue data drawn from beta.dash.swarm.shtuka.io.
## Passive BZZ investing
What if an investor doesn't want to run infrastructure? What if a node operator doesn't want to or can't afford to amass enough BZZ to run a competitive node operation? Traditional capital markets provide several ways to separate the roles of capital allocation (investment) and business management (operations). Unsurprisingly, these methods have their analogues and generalisation in the DePIN context that have found some success, for example, [in the Filecoin ecosystem](https://www.glif.io/en/pool/infinity). If sufficient demand exists, they could be used to provide opportunities for passive BZZ investors to access Swarm revenue and for income-focussed operators to limit their capital exposure.
### Lending markets
A node operator who does not own enough BZZ capital to run a competitive node operation, or who wants to limit their long exposure to the price of the BZZ token, might wish to take out a BZZ loan to cover the staking requirement of the operation. The interest rate on this loan cannot be more than the BZZ-denominated ROI the NO expects to make (after deducting costs).
We don't have access to very robust data on NO profit margins, but based on anecdotal evidence we imagine that the current ROI of Swarm node operations could support lending rates exceeding 50% per annum.
Since the amounts of BZZ required to participate effectively in BZZ staking are currently miniscule, it's doubtful that there's any real latent demand for BZZ loans that could support a lending market. If Swarm TVL were to increase by a factor of ten, there might be enough demand to drive a few small private loans for larger scale operators.
Conversely, a passive investor who does not wish to involve himself in the technical matter of operating infrastructure can earn a yield by contributing his BZZ capital to the network in the form of a loan to a node operator. For this to be attractive, the rate has to be high enough to offset the twin risks of operator default and being long BZZ. Since slashing is not currently enabled in the Swarm Protocol, the risk of operator default is probably fairly easy to manage, and could be further mitigated by implementing onchain controls such as restrictions on operator-initiated withdrawals and tiered liquidation mechanisms triggered by changes in network conditions. However, this would require either trust assumptions around key management or a more flexible protocol design with respect to node ownership — currently, only EOA-owned stake positions can participate in revenue sharing.
We don't have any data on lending markets for tokens with market cap as small as that of BZZ. However, a quick look at the supply APYs of non-stablecoin assets on [Aave](https://app.aave.com/?ampDeviceId=55d3b487-8f32-4dbd-9ec0-086dd694e71f&marketName=proto_mainnet_v3) indicates that bullish long investors may be prepared to accept quite low rates for lending.
### Node equity and liquid staking
An alternative approach to capitalising node operations is by selling *equity*, which in the Swarm case is most likely to be realised as a sale of a share of future revenue, which is recorded onchain. Financially speaking, the equity approach allows the node operator to pass income risk on to the investor, allowing the investor to capture additional upside.
As with the case of lending, investor confidence in a Swarm node equity investment could be enhanced by representing the shared ownership over the income stream by a smart contract account.
Liquid staking tokens (LSTs), long a hot topic in the Ethereum ecosystem, can provide greater liquidity and utility to stake positions by pooling and mobilising them, making them available for trading and lending. Ethereum and Solana LSTs each make up a little over 10% of their respective ecosystem's market cap (Source: [DefiLlama](https://defillama.com/protocols/liquid-staking/ethereum)).
To be useful, an LST must actually be liquid, i.e. have market makers ready to trade it on exchanges. Common leverage strategies based on LSTs also require them to be accepted as collateral for loans. In the case of a smaller ecosystem like Swarm in which even the underlying token has shallow liquidity and no lending activity, there's little reason to believe that an LST would find PMF.