Corresponding author: Andrew Macpherson

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.

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.

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.

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.

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.

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.

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.

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.

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.

Corresponding author: Andrew Macpherson

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.

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.

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.

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.

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.

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.

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.

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.

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.