Adaptive Inflation

Deprecated - see version 1.1

by Sophia Gold and Nicolas Ochem - Oxhead Alpha

This is a functional specification of Adaptive Inflation, based on Arthur Breitman's original post on Agora. It attempts to formally introduce the notion of cobaking based on the follow-up discussion on the Blockchain Evolved show. It introduces an accounting model that allows cobakers to have arbitrarily small balances in a scalable way. It also introduces a mechanism for in-protocol collection of cobaking fees.

The specification is accompanied by design notes in this format.

Cobaking

There are two types of delegators under Adaptive Inflation:

Regular delegators, as they currently exist in Tezos
Cobakers, who contribute to the security deposit.

Delegation with slashable security deposit exists in other protocols, e.g. Cosmos and Polkadot. Since adaptive inflation targets a higher percentage of supply held in security deposit, the ability of delegators to contribute to their bakers' deposit is useful for smaller bakers to remain competitive and therefore to preserve the decentralization of the network.

Cobakers trust bakers to not equivocate, otherwise they may lose their deposit.

A new operation cobake is introduced. Any manager account can call this operation. It takes a strictly positive amount value in mutez as a parameter.

Contracts can cobake using a new COBAKE Michelson instruction, taking a strictly positive amount value in mutez as a parameter.

Whenever the cobake operation is called on a manager account, or the COBAKE instruction is called within a contract, the following happens:

if amount is larger than the account's free balance, the operation is rejected,
if the account is not delegating, the operation is rejected,
otherwise, amount goes into a cobaking staging area and is no longer part of the account's free balance: it is frozen,
if as a result the free balance becomes zero, the account is not reaped and it is not necessary to pay a storage burn to transfer new tez to it.

Note that the above also applies when the manager account is the baker itself, e.g. the baker can contribute to their own security deposit with the cobake operation.

The only way to contribute to the security deposit is by cobaking. The protocol no longer takes it automatically from the free balance.

The purpose of amount parameter is to prevent the entire balance from being frozen. This would remove the ability to pay fees, preventing for example a subsequent uncobake operation.
It is still possible for an account to freeze its entire balance by setting amount to exactly the free balance minus fee. Then an inbound transfer of tez is required prior to any further operation.

Baking rights for every cycle C are based on a stake snapshot taken during at cycle C - PRESERVED_CYCLES - 1. If this snapshot contains delegators with a non-zero balance in their cobaking staging area, this amount is considered as part of the deposit of the delegator's baker for the purposes of rights calculation. Then, when cycle C starts, this amount is converted into an actual security deposit for the delegator's baker and starts earning rewards and being susceptible to slashing.

Whoever succesfully runs this operation is then known as a cobaker for the baker they are delegating to (unless they are the baker themselves).

Wallets and Octez CLI can further simplify cobaking by batching the delegation operation with the cobake operation, and set good defaults for the user (for example, cobake the entire balance minus one tez).

The purpose of the staging area is to prevent opportunistic cobaking to a baker that has been lucky with block and endorsement rights in the next 5 cycles. As a consequence, cobaking, just like baking and delegation, becomes effective 6 cycles after the operation is submitted.

Existing contracts on Tezos today can not cobake. New contracts will be written that will have cobaking ability using the COBAKE instruction.
For example, it will be possible to write a multisig cobaking contract.

Baking Rights

Octez documentation refers to a baker as a "delegate". In this document we used "baker".

Baking and endorsing rights for any active baker

b

are distributed using a discrete probablilty distribution weighed on the value of

b a k i n g R i g h t s (b)

given by the formula below.

We define:

$d e p o s i t (b, c)$ as the security deposit of any cobaker
$c$ of baker
$b$
- this includes the baker's own security deposit
  $d e p o s i t (b, b)$
$d e p o s i t (b)$ as
$b$ 's total security deposit:
$d e p o s i t (b) = \sum_{c} d e p o s i t (b, c)$
$d e l e g a t i o n (b)$ as the balance of
$b$ and all delegators of
$b$ , free and frozen.

A baker can potentially bake without contributing to the security deposit themselves, instead relying only on cobakers to get rights. This is fine: cobaking is a trust relationship. What matters is that someone's funds are at stake.

We then define:

X (b) = {\begin{cases} d e p o s i t (b) & if d e p o s i t (b) > m i n i m a l S t a k e \\ 0 & otherwise. \end{cases}

t o t a l D e p o s i t = \sum_{b} X (b)

$m i n i m a l S t a k e$ is 6,000 on mainnet. This means, a baker must have over 6k of security deposit to bake, either provided by the baker, a cobaker, or a combination of both. Otherwise, they don't get any rights at all.

Y (b) = m i n (10 * X (b), d e l e g a t i o n (b))

t o t a l D e l e g a t i o n = \sum_{b} Y (b)

As is the case today, the "free space" of a baker for delegation is at most 10 times the amount of security deposit. These is to prevent the baker from accumulating too many rights while having little at stake.

b a k i n g R i g h t s (b) = \frac{2}{3} * \frac{X (b)}{t o t a l D e p o s i t} + \frac{1}{3} * \frac{Y (b)}{t o t a l D e l e g a t i o n}

This has the property that the total deposit grants twice as many rights as the total delegation.

It holds that:

\sum_{b} b a k i n g R i g h t s (b) = 1

The mechanism that maps the distribution of baking rights into discrete rights per block is unchanged.

For a given cycle

n

, the calculations above are considering the balances as of a randomly chosen stake snapshot during the cycle n-PRESERVED_CYCLES - 1. This is also unchanged.

The governance voting power is proportional to the baking rights at the beginning of the governance period.

Protocol Rewards

t o t a l S u p p l y

is the total amount of tez in circulation.

The value of
$t o t a l S u p p l y$ can be accessed from within the protocol since Ithaca.

Under adaptive inflation, the global inflation rate is set at

2 * (1 / (100 x))^{2}

where

x

\frac{t o t a l D e p o s i t}{t o t a l S u p p l y}

Every new cycle, the global inflation rate is computed based on the value of

x

as of the chosen stake snapshot. We then use the constants blocks_per_cycle and minimal_block_delay to convert the desired yearly inflation into an amount of inflation by cycle.

This amount is then further split between baking and endorsing rewards following the rules that already exist.

As a result, every block baked during a cycle receives a similar block reward (and bonus, assuming all endorsers are active). Endorsement reward is distributed based on the baking rights distribution. This does not change.

What changes is the total amount of rewards given for baking and endorsing. Currently it is 80 tez per minute. Under Mumbai with 15 second blocks, each block grants up to 10 tez baking rewards and up to 10 tez endorsing rewards. Under adaptive inflation, this amount is reevaluated at every cycle based on the percentage of tez in security deposits globally.

Today, the frozen supply is at 7.7% and the total supply is 950M tez. Assuming this is the case when Adaptive Inflation kicks in, the global inflation rate will be
$2 * (1 / 7.7)^{2} = 0.034$ , or about 61 tez per minute.
People are incentivized to switch their delegation to cobaking to earn more rewards. As they do, the total amount of security deposits increase and the inflation rate goes down further.

Adaptive inflation only affects block and endorsement rewards. Other type of rewards (revelation, block fees, denunciations, VDF revelation…) remain unchanged.

Internal Security Deposit Accounting

Within this section, "account" refers to an container account within the account generalization introduced in Ithaca.

For every cobaker

c

, we store a pseudo-token balance

t o k B a l (b, c)

. The baker itself also has a pseudo-balance

t o k B a l (b, b)

A baker is associated with 2 convenience accounts (as is the case today) and one pseudo-token balance:

('Contract b) stores the free balance
('Frozen_deposits b) stores the security deposit
$d e p o s i t (b)$ associated with the baker
$t o k B a l (b, b)$ stores the portion of the deposit contributed by the baker

This is an internal representation not exposed to the user.

A delegator account (manager or contract) is also associated with 2 convenience accounts and one pseudo-token balance:

('Contract c) stores the delegator free balance (subject to free delegation)
('Pending_cobaking c) stores the amount in the cobaking staging area
$t o k B a l (b, c)$ stores the cobaker's portion of
$d e p o s i t (b)$

The purpose of this design is to lazily limit the number of storage updates. A reward does not require any update of any of the cobaker's three values described above. Only upon uncobaking are these values updated.

We define

t o k B a l (b)

as the sum of pseudo-tokens belonging to the baker and any associated cobaker:

t o k B a l (b) = \sum_{c} t o k B a l (b, c)

The cobake operation or COBAKE Michelson instruction causes an Token.transfer from ('Contract c) to ('Pending_cobaking c).

When the stake snapshot being considered for rights calculation contains delegators with a balance in ('Pending_cobaking c), the protocol performs a Token.transfer to move these amount to ('Frozen_deposits b) for their respective baker.

The first contribution to ('Frozen_deposits b) grants the contributor

c

an amount

t o k B a l (b, c)

of pseudo-tokens equal to the amount contributed in mutez.

Then, when a baker or cobaker

c

makes a contribution of

k

mutez to the security deposit, they receive

K

pseudo-tokens according the formula:

K = k * \frac{t o k B a l (b)}{d e p o s i t (b)}

At any time, the frozen deposit in tez of a baker or cobaker

c

can be calculated by:

d e p o s i t (b, c) = t o k B a l (b, c) * \frac{d e p o s i t (b)}{t o k B a l (b)}

The pseudo-token balances are units of internal accounting that are never exposed to the user by CLI, and should not be exposed by wallets or block explorers. They can not be transfered between accounts.

Instead, wallets and CLI should expose the current frozen balance in tez by computing it on-the fly with the formula above (plus any amounts in the staging area).

Reward Distribution

When rewards are earned during a given cycle, the protocol splits them according to the baking rights formula in the section above:

the portion
$\frac{\frac{1}{3} * \frac{Y (b)}{t o t a l D e l e g a t i o n}}{b a k i n g R i g h t s (b)}$ corresponding to delegation is credited to the baker's free balance ('Contract b)
the remaining amount
$\frac{\frac{2}{3} * \frac{X (b)}{t o t a l D e p o s i t}}{b a k i n g R i g h t s (b)}$ goes to ('Frozen_deposits b).

The portion of the rewards that come from cobaking is split between all cobakers in proportion of their contribution.

This happens in-protocol: no payout is required. Until they withdraw, they can monitor their gains by querying their RPC balance, which computes it based on the pseudo-token balance of the cobaker and the deposit amount in tez. And when they withdraw, both rewards and principal are credited to their free balance after unfreezing.

On the other hand, rewards from delegation are credited to the baker as free balance, and the baker is expected to pay them out with a payout engine (TRD, breadcrumbs, TAPS, tezpay…), as was the case before.

Every reward (baking, endorsing, fees, revelation, denunciation) is split in the same way.

Over time, we expect cobaking to become dominant compared to existing delegation, and therefore most rewards will be accrued in-protocol without explicit payout transactions.

This is desirable since it removes the regulatory ambiguity regarding payouts.

Rewards from cobaking are automatically added as part of the security deposit. If the cobaker wants to cash them out, they have to uncobake them and wait for them to unfreeze.

Cobaking Fee

A new operation set_cobaking_fee is introduced, taking a numerical value

f

as parameter. Any baker active or inactive can submit this operation. The default value is 0 and the acceptable values are numbers between 0 and 1, with a maximum precision of 4 digits.

The user-facing representation of the fee should be displayed as a percentage. For example
$f = 0.1000$ is a 10% fee.

The fee is stored in the context, in the table that was introduced to store the consensus key. Bakers can update this value at will. The fee effective at the end of the cycle when the stake snapshot was taken is taken into account for any reward accrued during the cycle.

This means any change of fee takes 21 days to be effective on mainnet.

When the baker earns a reward of

r

tez, the baker's fee is credited in the form of additional pseudo-tokens

K_{f e e}

based on the formula:

K_{f e e} = t o k B a l (b) * (\frac{d e p o s i t (b) + r}{d e p o s i t (b) + r * (1 - f)} - 1)

This design scales well. Indeed, only the pseudo-token balance of the baker is updated. The pseudo-token balance of all cobakers does not change. This is equivalent to the cobakers being slightly "diluted" at each reward.

By default, when the fee is zero,

K_{f e e}

is equal to zero and no token is credited to the baker when a reward is accrued.

See the appendix below for a detailed explanation of this formula.

Slashing

Slashing denunciation events lower the tez balance of

d e p o s i t (b)

if
$d e p o s i t (b)$ is positive after slashing, there is no effect on the pseudo-token balance
if
$d e p o s i t (b)$ is zero after slashing, all token balances of all cobakers are zeroed out and erased.

Slashing does not alter the ownership of the deposit. Everyone is slashed in proportion of their contribution.

The Tenderbake slashing rules remain unchanged under Adaptive Inflation: double baking slashes 640 tez from the security deposit, double endorsing slashes 50% of the initial security deposit for the cycle. Two double endorsing events result in the security deposit being entirely slashed. When the security deposit is zero, blocks and endorsements for this baker become invalid for the remainder of the cycle.

If a cobaker contributes to the security deposit after the offence but before the denunciation, then they get slashed like everyone else: the timing of the denunciation, not the offence, is relevant.

Uncobaking

Another new operation uncobake is introduced. It takes a strictly positive amount value in mutez as a parameter.

For contracts, a new Michelson instruction UNCOBAKE is introduced, which takes a strictly positive amount value in mutez as a parameter.

When uncobake is called, the following happens:

if amount is greater than the security deposit of the cobaker that is not currently unfreezing, the operation fails,
if the baker is inactive (a.k.a. passive delegate), amount is immediately transfered to the free balance of the cobaker,
otherwise, these pseudo-tokens go into an unfreezing period for MAX_SLASHING_PERIOD + PRESERVED_CYCLES cycles. During this time, they are still subject to slashing and still earning rewards.

These unfreezing pseudo-tokens are tracked by tagging them, along with the cycle number when the unfreezing will be complete. When amount is strictly lower than

d e p o s i t (b, c)

, the tokens are split in two entries, between the unfreezing tokens (tagged as such) and the remainder.

There may be several concurrent unfreezings completing in several future cycles.

At the beginning of every cycle, the protocol traverses the pseudo-tokens of every cobaker, and credits the newly unfrozen deposits to the cobakers' free balance.

Whenever any amount is credited to the cobaker's free balance, it decreases

d e p o s i t (b)

accordingly and zeroes out the corresponding pseudo-token entry.

If the baker is active, the amount you get is higher than the amount you request. In includes the rewards accrued during the unfreezing period.

When a cobaker withdraws their delegation or switches their delegation to another baker, their entire security deposit is uncobaked.

A cobaker can delegate or cobake free tez with another baker as soon as they withdraw. But they can not cobake unfreezing funds. They have to wait for unfreezing to be complete before cobaking them again.

Consequently, it is possible for a cobaker to have frozen balance with several bakers. In this case, several pseudo-token balances

t o k b a l (b, c)

and

t o k b a l (b^{'}, c)

are tracked in the cobaker's account.

Set Deposits Limit Deprecation and Orderly Shutdown

The set_deposits_limit operation is deprecated.

set_deposits_limit is made redundant by the cobake operation: the baker and their cobakers are now fully in control of their security deposit, and therefore the notion of deposits limit no longer applies.

The baker can perform an orderly shutdown of their operations by withdrawing their self-delegation. When this happens, the baker's and every cobaker's security deposit is uncobaked and unfreezes according to the schedule. The withdrawn baker is no longer considered for baking and endorsing right distribution.

This is to replace another common usage of set_deposits_limit which is to perform an orderly shutdown of baking operations by setting the limit to zero.

Drain Delegate Deprecation

The drain_delegate operation is deprecated.

drain_delegate transfers the free balance of the baker to its consensus key. The purpose is to act as a deterrent against careless handling of the consensus key. With adaptive inflation, bakers no longer have an incentive to maintain a free balance to attract delegations. Instead, they are expected to actively freeze all of their balance in order to maximize their income (except perhaps a few tez to pay fees). Therefore drain_delegate no longer is an effective deterrent and can be removed.

Switchover to Adaptive Inflation

Adaptive inflation is activated by a toggle signal in block headers, similar to the liquidity baking toggle. The signal may be "on", "off" and "pass" where "on" means "I want Adaptive Inflation to be on". The context maintains an exponential moving average of that toggle. The EMA is initiated at 100% "off".

Adaptive inflation permanently kicks in at the end of the first cycle

C

when an EMA of 50% of blocks has signaled "on" or "off", and 80% of those have signaled "on" for 5 cycles.

Then, baker's accounts are immediately considered as security deposits according to the following rule:

for any baker without deposit limit set, their entire balance becomes
$d e p o s i t (b)$ ,
for bakers with deposit limit set, the minimum between 10% of their deposit limit or their entire balance becomes
$d e p o s i t (b)$ ,

The rights for the cycle C + 1 + PRESERVED_CYCLES + 1 are then calculated based on the Adaptive Inflation calculation of Baking Rights above, and so on for all future cycles.

Bakers will see all of their balance frozen unless they take action before activation to set their deposit limit.

The rights distribution in the first cycle of Adaptive Inflation Baking Rights will look very different than the cycles before. The dominant factor in rights distribution will be the baker's own balance.

RPC & CLI & Encodings & Gas

To be completed.

Appendix: explanation of the Fee Formula

Let's suppose the baker

b

has a cobaker

c

The cobaker owns

t o k B a l (b, c)

in pseudo-tokens. Shall they withdraw, they would be entitled to

t e z B a l (b, c)

The following holds:

t e z B a l (b, c) = t o k B a l (b, c) * \frac{d e p o s i t (b)}{t o k B a l (b)}

A reward

r

is accrued. Now the cobaker owns

t o k B a l^{'} (b, c)

in pseudo-tokens. Shall they withdraw, they would be entitled to

d e p o s i t^{'} (b, c)

The following holds:

d e p o s i t^{'} (b, c) = t o k B a l^{'} (b, c) * \frac{d e p o s i t^{'} (b)}{t o k B a l^{'} (b)}

where:

d e p o s i t^{'} (b) = d e p o s i t (b) + r

We do not want to update the cobaker's pseudo-token balance each time there is a reward. Therefore:

t o k B a l^{'} (b, c) = t o k B a l (b, c)

Only the baker's pseudo-token balance changes and is increased by

K_{f e e}

, therefore:

t o k B a l^{'} (b) = t o k B a l (b) + K_{f e e}

Consequently we have the result A:

d e p o s i t^{'} (b, c) = t o k B a l (b, c) * \frac{d e p o s i t (b) + r}{t o k B a l (b) + K_{f e e}}

The balance of cobaker

c

in tez has increased by the proportion of the reward

r

based on their current share of

d e p o s i t (b)

, minus the fee:

d e p o s i t^{'} (b, c) = d e p o s i t (b, c) + r * \frac{d e p o s i t (b, c)}{d e p o s i t (b)} * (1 - f)

or more simply we have the result B:

d e p o s i t^{'} (b, c) = d e p o s i t (b, c) * (1 + \frac{r * (1 - f)}{d e p o s i t (b)})

Taking A and B together:

d e p o s i t (b, c) * (1 + \frac{r * (1 - f)}{d e p o s i t (b)}) = t o k B a l (b, c) * \frac{d e p o s i t (b) + r}{t o k B a l (b) + K_{f e e}}

Hence:

t o k B a l (b) + K_{f e e} = \frac{t o k B a l (b, c)}{d e p o s i t (b, c)} * \frac{d e p o s i t (b) + r}{1 + \frac{r * (1 - f)}{d e p o s i t (b)}}

Which simplifies to:

t o k B a l (b) + K_{f e e} = \frac{t o k B a l (b)}{d e p o s i t (b)} * \frac{d e p o s i t (b) + r}{1 + \frac{r * (1 - f)}{d e p o s i t (b)}}

t o k B a l (b) + K_{f e e} = \frac{t o k B a l (b) * (d e p o s i t (b) + r)}{d e p o s i t (b) + r * (1 - f)}

Finally:

K_{f e e} = t o k B a l (b) * (\frac{d e p o s i t (b) + r}{d e p o s i t (b) + r * (1 - f)} - 1)

Let's verify with 2 common scenarios:

if
$f = 0$ then
$K_{f e e} = 0$ . Indeed, the baker does not take a cobaking fee and the rewards are distributed equally between baker and cobakers. The baker's balance in pseudo-tokens needs not change.
if
$f = 1$ (100% fee) then
$K_{f e e} = r * \frac{t o k B a l (b)}{d e p o s i t (b)}$ , indeed, the baker receives newly minted pseudo-tokens whose value in tez is equal to r: the baker pockets the entire reward r regardless how much they actually contribute to the deposit.

Why bother with minting new pseudo-tokens when the fee is 100%? The baker may have cobakers anyway, and these cobakers are entitled to withdraw their contribution to the deposit, though it will be equal to what they did put in.
Also, perhaps the fee has not always been 100%, and the cobaker earned a reward before that.

Maxime REYNOUARD

2023/03/02 12:33:03

Rights

I believe there are errors in the definitions / formulae of this section ? for example, if nothing is delegated then 1/3 of baking rights are not distributed In the current definition of delegation(b) we take into account the stake of b + the rest of his balance + the costake entrusted to him + the rest of the balance of its delegators. This means we always have delegation(b) > deposit (b), because delegation(b) = deposit(b) + rest of balance of b and its delegators (Edited)

2023/03/02 12:33:11

Either we keep this definition wich is not really intuitive (delegation seems to point to only what is delegated + possibly the baker's own free balance) but then I propose bakingRights(b) = (X(b) + Y(b)) / (totalDeposit + totalDelegation). This way, the double counting of a frozen deposit happens because X(b) is already included in Y(b)

2023/03/02 12:33:23

An alternative: delegation(b) = rest of balance of b and its delegators Y(b) = min(9*X(b), delegation(b)) bakingRights(b) = (2*X(b)+Y(b)) / (totalDeposit + totalDelegation)

Nicolas Ochem

2023/03/02 17:28:23

Thanks for commenting! > if nothing is delegated then 1/3 of baking rights are not distributed Under the current definition of delegation(b), it includes the deposit. So if nothing is delegated then only deposit is taken into account, therefore the distribution of the 1/3 is equal to the distribution of the 2/3. so where is the problem? (Edited)

2023/03/07 09:23:24

My bad, by wanting to simplify my example too much I made it wrong. Let's look at this example then b1 has a stake of 2, b2 has a stake of 1, and a delegation of 2. They should have the same baking power, however: deposit(b1) , deposit(b2) = 2, 1 delegation(b1), delegation(b2) = 0, 2 X(b1), X(b2)= 2, 1 Y(b1), Y(b2)= 2, 3 totalDeposit = 3 totalDelegation = 5 bakingRights(b1) = 2/3 * 2/3 + 1/3 * 2/5 = 26/45 bakingRights(b2) = 2/3 * 1/3 + 1/3 * 3/5 = 19/45 (Edited)

2023/03/07 09:23:50

They should have the same powers but they don't. The separated normalisation is the issue here, it doesn't accomplish giving twice the rights for stakes. General solution for stakes giving lambda times more rights, for "twice", lambda = 2: bakingRights = ((lambda-1) X + Y ) / ((lambda-1) totalDeposit + totalDelegation)

rafoo

2023/03/08 10:02:22

Existing contracts on Tezos today can not cobake. New contracts will be written that will have cobaking ability using the `COBAKE` instruction.

The simplest to implement is actually to let current smart contracts cobake. Is there a good reason to exclude current smart contracts from cobaking? (Edited)

2023/03/09 05:20:03

Thanks for commenting. I meant to say, since the COBAKE instruction is new, you need to write new contracts in order to use it. Any contract deployed today does not have it and therefore cannot cobake. Is my phrasing problematic or am I missing something?

2023/03/08 10:04:39

The pseudo-token balances are units of internal accounting that are never exposed to the user by CLI, and should not be exposed by wallets or block explorers.

Could you please give a rationale for this design point? It goes against the idea of Demurrage recently rediscussed in https://forum.tezosagora.org/t/demurrage-for-tezos/5165. (Edited)

2023/03/09 05:18:45

Thanks! your formula is indeed better, and accounting for delegation separate from security deposit makes things clearer. next version of this spec will replace my version with yours. (Edited)

2023/03/09 05:25:36

Sure. The issue is, the pseudo-token balances are drifting from the actual Tezos value you get at redeeming. Imagine you are baking with 6,000 tez as security deposit, your pseudo-token balance is forever 6,000,000,000 until you withdraw. When you withdraw, assuming you didn't get slashed, your balance is much higher than 6,000 tez. If you get partially slashed, it could be less. but the pseudo-balance is never updated. (Edited)

2023/03/09 05:35:22

Demurrage as described flips everything on its head: the "pseudo-balance" becomes the actual balance. In the absence of slashing, you take out exactly what you put in. Every account that's not cobaking has a "pseudo-balance" and they commonly share a dwindling pot of tez. When they withdraw, they get their share of the pot. (Edited)

2023/03/09 05:40:27

it actually sounds.... possible with minimum changes compared to the current spec? The thing is, on a scale of craziness, Adaptive inflation + cobaking is 1, but demurrage is 4. So I don't know if people would ever vote for this. (Edited)

2023/03/10 15:40:58

formula

Those formulaes need to be adapted (see my comment on the "Baking Rights" chapter (Edited)

2023/03/10 15:55:56

To me, adaptive inflation doesn't in itself goes against demurrage. Correct me if I'm wrong but aren't: - Demurrage: burning a part of non-participants' balance - Inflation: combination of demurrage and currency issuance, so demurrage only means deflation, issuance only means inflation, both means it depends - Adaptive inflation: Inflation is a function of the frozen deposit. This can be achieved by having demurrage as a function of the frozen deposit, or issuance, or both (Edited)

2023/03/10 15:57:58

Everyone is slashed in proportion of their contribution

I feel like this point could be discussed, Couldn't the responsibility of the baker still be engaged at a higher level ? (Edited)

2023/03/10 16:04:49

One could imagine that after the slashing, the pseudo-token balance of the baker is lowered (multiplied by lambda<1 for example). This would reinforce the impact of the slash for the baker's deposit, and soften it for the co-bakers.

2023/03/10 16:08:09

This might not be a good idea thought, as it could encourage the baker to mostly place his deposit as a sibyl co-baking with his main account. But all the implications are hard to forsee. As bakers having a low deposit(b,b)/deposit(b) would be seen as riskier and therefore less likely to attract co-bakers.