What we did

• As a first step to getting insights into the state of the Swarm staker population, we built our stake transparency dashboard and associated staking API, showing stake vital statistics such as TVL and mapping out the stake that belongs to nodes thought to be active (as measured by participation in the reward sharing mechanism). You can check it out at https://beta.dash.swarm.shtuka.io.

  As well as informing research, a goal of the dashboard is to help infrastructure operators have access to the information they need to make investment decisions. However, we soon found that since stake cannot be withdrawn, node operators aren't that interested in pursuing more sophisticated stake strategies.

• Study staker strategies from risk perspective. After building our stake dashboard and talking with node operators, we found that NOs are very hesitant to deposit stake. From a risk management perspective, this is hardly surprising. Because of the twin risks of:

  • No way to recover the investment other than waiting for a highly uncertain revenue stream to cover the principal;

  • Exposure to hard-to-predict external factors like changes in subsidy programmes and the actions of other stakers in your neighbourhood

  we must acknowledge that in its current form, scaling a Swarm stake investment is not a very attractive opportunity. As it stands, it's likely to be of interest only to larger, more sophisticated entities; except that at the network's current scale, the capacity is too small for them too. So what do we do?

• Develop proposals for managing stake. We engaged with Swarm Research and achieved what looks like strong preliminary support for enabling withdrawals of stake positions in general. According to our assessment of node operator incentives — and supported by the results of a poll of actual node operators — this could lead to an immediate boost in TVL. We have two SWIPs (40 and 41) in the pipeline to unlock this change.

What we said we'd do

The opening paragraphs of our research programme statement promises the following things:

1. Develop a principled, objectives-based approach to protocol and parameter upgrades;

2. Improve transparency by gathering and publishing econometric data;

3. Investigate the construction of novel financial primitives based on the Swarm Network economy.

Our stake transparency dashboard is our answer to (2). As a guide to future development on transparency, and a way of thinking about which metrics to publish, we also shared a research memo that sketches a theory of value for BZZ.

We haven't started on (3) — that's more of a long-term research programme, and we find other priorities are more pressing.

Delivering part (1) is top of the agenda for the next six months: we're going to work towards building a roadmap and linking our recommendations for protocol improvement to that roadmap. See below.

In our original announcement, we also posed some open questions to which we're now, thanks to our research, able to provide partial answers:

How competitive is the Swarm node market?

Prior to the start of this programme, we saw no evidence that any node operators engaged in "strategic" behaviour. Virutally all nodes simply deposited the minimum balance of 10 BZZ and took no further action. But over the course of the past six months, the situation has changed: Swarm staking has shown the first signs of "stake matching" behaviour. According to our stake transparency dashboard, some node operators have increased their stake to 40 BZZ per neighbourhood — well past the minimum — presumably in a bid to increase their market share. Other nodes in the same neighbourhood responded by matching their 40 BZZ, bringing the market shares back to an even split.

Is the Swarm storage market liquid enough to respond to demand spikes? Is the price quoting mechanism responsive enough to signal that more supply is needed in a timely manner?

Although we haven't seen any notable demand spikes over the past half year, a supply trough did occur, leaving all neighbourhoods under-replicated. Despite the price oracle kicking in and rapidly marking up the storage price, the undersupply persisted for over three weeks. By not jumping in to participate, node operators leave fee money on the table, indicating a lack of elasticity in the Swarm storage supply chain.

We've also carried out some regression studies (as yet unpublished) that appear to confirm the same thing: the observable effect of storage price on Swarm node supply is miniscule. We expect that structural factors such as the complexity of staking and general interest in Swarm revenue are far more significant factors in determining supply.

Are BZZ or storage price fluctuations scaring off potential users? What can devs do to further stabilise the pricing UX?

Probably, but there isn't enough data to confirm this empirically. Anecdotally, the storage price fluctuations and the uncertainty surrounding batch expiry causes difficulties for developers building on Swarm. We'll be looking into ways to stabilise pricing over the coming months.

What we'll do next

Over the next few months, our main priority is to develop recommendations for Swarm's economic roadmap for 2026 and beyond. That includes issues like staking, tokenomics, and quoting. We'll also carry on working on shipping SWIPs already in the pipeline.

• Ship withdrawals. It's pretty clear by now that whatever else ends up on the Swarm economy roadmap, enabling stake withdrawals will be near the top of the list. We'll finish tweaking the parameters, evaluate whether it ought to be bundled with other upgrades or shipped as a standalone, and hit send.

• Scale staking. We'll research designs that mitigate or eliminate stake fragmentation and scale what a node operator can do with one node and one wallet. Begin research into separating the roles of operations from capital: that is, give BZZ investors a way to hand their tokens to a professional operator in exchange as part of a loan or profit sharing arrangement.

• Reevaluate price quoting. There is currently little evidence that the price adjustment mechanism has its intended effect of stabilising supply. At the same time, it worsens UX for users by making prices and batch expiry uncertain, and can leave prices at a very high point, presumably scaring off potential customers. We want to find an easy-to-implement, practical way to make Swarm price quoting UX easier to understand and more stable for storage customers, and ship it fast.

• Explore protocol upgrade UX. The current UX surrounding protocol changes and migrations for protocol developers, client teams, and users alike presents serious challenges. We'll explore ways to make the experience more reliable and frictionless for users without sacrificing ownership or security.

We're still in the process of aligning with Swarm Research on how best to collaborate over the coming six months. We want to ensure that our recommendations are as relevant as possible to Swarm core team strategy and have opportunities to impact the official roadmap. Watch this space.

Background

In the Swarm Protocol today, storage node operators must pay a BZZ-denominated deposit into a Stake Registry smart contract in order to participate in revenue sharing. Prior to SWIP-20, introduced last year, this deposit could not be withdrawn except under special governance-driven circumstances such as a contract migration.

SWIP-20 introduced a rule that allows operators to partially withdraw their deposit under certain market conditions — roughly speaking, that the price of storage is lower than when they made the deposit. The stated intention of this rule is to allow node operators (NOs) to realise some gains on staked BZZ when a BZZ price increase precipitates a fall in the BZZ-denominated storage price. More abstractly, it introduces optionality that gives NOs more tools for risk management.

However, tracking the conditions that dictate whether and how much deposit can be withdrawn necessitates introducing a unique three-term stake model in which the stake registry must track "committed" and "potential" stake and compute "effective" stake for the purposes of redistribution. Because the approach is new and unfamiliar, it is not likely to be widely understood. We are concerned that it may be causing confusion for node operators and protocol developers alike.

As an illustration of how the added complexity is already causing issues in protocol development, consider the recent regression in the storage incentives repo in which an unforseen interaction with SWIP-21 allowed NOs to withdraw all of their stake at any time by manipulating the height parameter of their position. Since the response of the developers was to change the contract rules to prevent committed stake from decreasing, it is clear that this interaction was not intended. However, since this new rule is not specified in any SWIP, the change represents a drift in the protocol from what can be gleaned from publicly accessible documentation.

Addendum. Viktor Trón has informed me that the research team is working on a new draft SWIP that will replace the SWIP-20 system with one with a fixed amount of stake per node, all of which will be withdrawable. I believe the considerations raised in this memo remain relevant to the design of the new SWIP, so I am publishing it as is.

Enabling withdrawals

Rather than attempting to clarify or "fix" SWIP-20, this memo will make the argument that these types of issues are an inevitable consequence of the complexity inherent in tracking market conditions to govern withdrawals. We advocate for a return to a standard single term stake model where the amount deposited is used as a weight for revenue sharing and leader election.

On the other hand, giving NOs more tools to manage the risk of their operations is clearly in the interests of building a robust, scalable Swarm Network.

We will introduce some arguments in favour of unconditional withdrawals and of throttling withdrawals by introducing a delay, and quantify and compare risks faced by NOs in the no-withdrawals versus the withdrawable stake models.

Unconditional withdrawals

Next to never allowing withdrawals, the simplest policy with respect to withdrawals it to always allow them. Clearly, this policy does not require introducing additional fields to the stake registry. As compared with the no-withdrawals model, several advantages immediately suggest themselves:

1. By making the system more similar to other staking systems, engineers are more likely to be able to reuse intuition when designing or implementing protocol upgrades. They are therefore less likely to introduce unintended behaviour.

2. By making the system more similar to other staking systems, it becomes much easier to evaluate risks and rewards and compare them with those of other opportunities on an even footing. It will be easier to onboard NOs, and easier for those NOs to manage their operations reliably after onboarding.

3. Withdrawals allow resources to be reallocated to more efficient operators, i.e. ones with lower operating costs per unit of storage. For details, see Theorem 1.1 of our January report.

4. Making stake positions less risky will likely substantially increase demand for BZZ to hold for the purpose of staking. Indeed, as the calculations below will show, a withdrawable stake model supports a total investment of up to $$Y/r$$ where $$Y$$ is network revenue and $$r$$ is a risk-free yield, while non-withdrawable stake supports investment of only $$Y/(1+r)$$. For common values of $$r$$ these bounds differ by orders of magnitude.

5. Without withdrawals, stake positions are likely to be dominated by owners who can afford to wait longer for their capital investment to pay itself off. This creates a barrier to entry primarily affecting smaller operators. With withdrawals allowed, commitment time doesn't matter very much. We expand on this point below.

What are the potential disadvantages of a system with withdrawable stake? The only one we could think of is a little perverse: since, following point (4) above, the non-withdrawable model attracts a much lower level of total investment for the same total cash flow, the yield on that investment is correspondingly much higher than it would be in the withdrawable model. That is, each investment in the is correspondingly much more capital efficient than its counterpart in the withdrawals-enabled model.

On the other hand, because the investor is not guaranteed to ever recover the amount of his initial investment, the no-withdrawals investment is much more risky than its withdrawable counterpart. This reflects the same type of tradeoff that one sees in tradfi between debt and venture capital investments. We will quantify this difference mathematically below.

In the case of Swarm infrastructure, failure to recover principal could occur if, for example, the revenue that the investor could earn from his node permanently falls below the variable costs at which he is able to operate.

Throttled withdrawals

There's a continuous family of models interpolating between the instant withdrawals and non-withdrawable models where stakers face a withdrawal delay $$T$$ during which they may still continue to provide the service and earn rewards. Obviously, the limit $$T=0$$ represents instant withdrawals, while a very large $$T\gg0$$ — longer than the investment horizon of any NO — is strategically equivalent to disallowing withdrawals completely.

Although introducing this new parameter adds complexity, which we began this memo by arguing we want to reduce, it is within the bounds of standard practice in protocol design and can be defended in terms of the additional leverage it gives the protocol over NOs. Specifically, NOs have an incentive to continue operations for $$T$$ epochs after broadcasting their intention to withdraw from the network, giving other NOs time to spin up additional nodes or deposit more stake and hence support an orderly handover of responsibilities.

As well as a delay, one could also look into introducing a withdrawal queue as in Ethereum staking. Since Swarm storage is quite sensitive to churn among nodes with similar addresses, this might be worth considering.

Battle-tested models like modest withdrawal delays and queues are not compatible with the SWIP-20 system, so simplification is needed first before we can make any improvements in this direction.

Risk calculations

Assumptions

We will make a sequence of simplifying assumptions that allow us to reduce the question of policy choice in the instant withdrawals model to a deterministic decision problem.

• For simplicity, we assume that at the start of the round the network revenue for that round $$Y$$ is known with certainty. Since the bulk of this revenue will be coming from quotas that are already outstanding at the start of the epoch, and the storage price is known up to a factor close to $$1$$, this assumption is not far from the truth.

• We also assume that nodes receive a proportional payout every round instead of participating in a lottery. This assumption is not satisfied in the current Swarm Protocol, but rather simulates what it would be like to participate in a stake pool. We also pretend that nodes may adjust stake and receive rewards in the same epoch, i.e. there is no cool-off period. If the decision cycle is long compared to the 2 round cool-off period, then this is a fair approximation.

• Finally, we assume that the strategy of our competitors is known in advance. For example, we can assume that competitors make no move to top up or remove stake after an initial period. This is quite a good approximation of what Swarm staking competition looks like at the moment.

Under this model, nodes face no risk over what happens in the following epoch.

Withdrawable case

If stakes are instantly withdrawable, a node operator therefore has a family of risk-free strategies: in each round, he should adjust his stake balance to a value $$X_i$$ so that the net weighted yield $$w(X_i)\cdot Y - O_i$$ for the next epoch exceeds $$rX_i$$, where $$r$$ is a single epoch risk-free rate.

If we simplify by assuming $$O_i$$ is negligible, he should top up stake so that the total stake $$X$$ in the neighbourhood satisfies $$ Xr \leq Y.$$ Hence the amount of stake in the neighbourhood will generally be bounded above by $$Y/r$$.

Example. If we take current annual revenue at around 300,000 BZZ and a risk-free rate of 5%, this bound allows a total network-wide risk-free stake of 6 million BZZ, or around 10% of supply. Conversely, significantly less than 1% of the BZZ supply is staked today.

Non-withdrawable case

If stakes are not withdrawable, then our NO faces risk over the future cash flows of the position. Following (Artzner, 1998), we will quantify this risk in terms of acceptance sets among a set of policy choices. To this end, we introduce two representative scenarios for network revenue:

1. Flat continuation. The revenue each epoch continues at a constant rate equal to what it was last epoch.

2. Worst case. New demand instantly drops to zero, and only cash already stored in the PostageStamp contract is ever paid out.

At time of writing, the pessimistic scenario has future cashflows of about $7000 while the flat continuation has about $1 per epoch. If the investment horizon is 6 months, this corresponds to a total of about $20400 in the flat case.

We parametrise NO risk tolerance in terms of how much "weight" the NO places on the worst case outcome versus the flat outcome when making policy choices. That is, an operator with lower risk tolerance is one that places more weight on the worst case scenario. Formally, introduce a family of risk measures given by convex combinations of point masses at these two scenarios, parametrised by $$\alpha\in[0,1]$$, the weight given to the flat outcome. We call $$\alpha$$ the risk tolerance of the operator.

We posit an NO $$ \mathcal{P}$$ who invests according to returns over a fixed period $$T$$, counted in epochs; he discounts to zero any expected returns arriving after the end of the period. Hypothesise that $$\mathcal{P}$$ finds a policy admissible from a risk perspective if the $$\alpha$$-weighted position value at the end of the investment period under the two scenarios is not worth less than the original outlay plus a non-compounding risk-free yield $$r$$. We also assume he

The acceptance thresholds in the two extreme cases are:

• $$(\alpha=0) \qquad X(1+Tr)\leq w(X)\cdot 7000$$

• $$(\alpha=1) \qquad X(1+Tr)\leq w(X)\cdot T\cdot 1$$.

So the acceptance decision depends substantially on the investment horizon and risk tolerance of the investor. (For simplicity we omit operating costs from these formulas; they wouldn't substantially change the conclusion.)

Note. Recall that under the withdrawable stake régime, one can construct policies that have zero drawdowns with probability $$1$$, regardless of the outcome scenario. These policies would be in the admissible set for any $$\alpha$$, and they dominate any strategies that do accept drawdowns. So $$\alpha$$ isn't important for NO decision-making in that model.

Take-homes

In the withdrawable stake model, the set of viable strategies doesn't depend very much on individual risk preferences. In fact, under reasonable conditions, the optimal strategies are quite close to being risk free. On the other hand, when stake is not withdrawable the viability threshold is quite sensitive to the risk tolerance and investment horizon of the operator. We therefore expect a market that’s more accessible to smaller operators and hence more competitive once withdrawals are enabled.

With origins that trace back to the very beginning of Ethereum, the Swarm Protocol is a permissionless storage pool protocol in which users can buy storage quotas over a pool of thousands of nodes, by sending tokens to a smart contract, at prices comparable to traditional cloud storage. In fact, to the best of our knowledge, it is the only decentralised storage platform with these characteristics.

This new partnership comes at a time when the Swarm Community is shifting priorities from research to onboarding real users, and the core team and Swarm Foundation are in a process of transformation to a more transparent operating model. More than ever, Swarm needs a robust node population ready to meet the demand brought by these new users, and easily accessible insights into its economic activity to inform sound governance decisions.

We'll be working with the Swarm Foundation research team to answer market structure and econometric questions like:

• How competitive is the Swarm node market?

• Is the Swarm storage market liquid enough to respond to demand spikes?

• Is the price quoting mechanism responsive enough to signal that more supply is needed in a timely manner?

• Are BZZ or storage price fluctuations scaring off potential users?

• Will prices converge to stable equilibrium, or diverge or oscillate wildly?

• What can devs do to further stabilise the pricing UX?

Using a combination of econometric studies, control theory, and financial engineering, Shtuka Research will help the Swarm research community ensure that node supply is able to elastically scale to demand, prices strike a balance between stability and competitiveness, and infrastructure operators have access to the information they need to make investment decisions.