CPS-0022? | Lost Stake

[Cerkoryn]

Completed some research put together this CPS to formally define a problem that we (the Cardano Incentives Working Group) have identified.

It is unfortunately difficult to measure with quantifiable numbers, but this should be explained well in the CPS.

---

(rendered)

[Ryun1]

Cross referencing with past similar CPS-???? | Ada token supply exhaustion

[rphair]

Thanks again @Cerkoryn for another research-informed submission. It's already been tagged for Triage at next week's CIP meeting (https://hackmd.io/@cip-editors/117) & you and other authors (@EarnCoinPool, @CarlosLopezDeLara, ?) are welcome to talk about it there & observe initial responses especially if not already posted here.

My understanding is, as @Ryun1 points out in #1060 (comment), that this is a "horizon" problem and I would not want to make the mistake every generation makes about social, economic, political and human conditions always continuing on the same trajectory of "progress". For instance, the assumption of a generally available 3% compounded interest continuing until year 2070 and beyond seems to ignore many disruptive scenarios that are likely to occur (and compound) long before then.

Still I would rather see this CPS on the books and see if what kind of bids we get in the next few years for CIPs that might provide a better outlook. I think most in our community would agree that long-term responsibility leads to short-term equity, and therefore would like to see this CPS in place.

[Cerkoryn]

@rphair

My understanding is, as @Ryun1 points out in #1060 (comment), that this is a "horizon" problem and I would not want to make the mistake every generation makes about social, economic, political and human conditions always continuing on the same trajectory of "progress". For instance, the assumption of a generally available 3% compounded interest continuing until year 2070 and beyond seems to ignore many disruptive scenarios that are likely to occur (and compound) long before then.

This is very true and part of the problem in doing research to determining the true depth of this problem. It's extremely difficult (arguably impossible) to determine which addresses are actually permanently unreachable using on-chain data, so even our best, educated guesses end up being wild estimates.

However, there are some important things to note for why we ended up on the 3% number. Historically, Cardano's rewards APY has been as high as 8%. If ADA was lost during this time, that 8% would be compounding much faster than our 3% number. As far as the future is concerned, it is true that disruptive scenarios are almost certain to occur. We'd roughly anticipated that things like partner chains or other future changes will prop up the rewards rate at some point. Otherwise the trend shows it going below 1% APY by 2030, which is already on the edge of sustainability.

Another point worth mentioning is that we tried to calculate just how much ADA is being sent into the void CURRENTLY based on our estimates for Lost ADA. If you reference this chart:

Notice that the red line appears to be roughly crossing the 5B ADA mark around the current year 2025 (Note that this is also using the flat 3% compound instead of the historically higher APY numbers!).

• If ~50% of that ADA is still staked, then that represents 2.5B Lost ADA that is still earning rewards.
• Currently there is roughly ~21B ADA staked.
• The rewards pot (after treasury cut, unmet pledge, pool performance, and the unstaked proportion is taken out) is around 7.5M ADA distributed each epoch
• 2.5B out of 21B is about 12%.

Based on this very rough napkin math, that would mean 12% of the rewards pot is ALREADY being wasted each epoch. This represents 900k ADA each epoch, or 65.7M ADA each year. It's important to empathize that this is only an estimate, but it's also using conservative numbers. The actual amount could be better or worse. We wanted to include this in the CIP, but felt it might be too alarming or sensationalist and without enough hard support to justify mentioning directly. So instead we used the language...

Cardano already distributes a significant amount of ADA every epoch in staking rewards to addresses that are permanently inaccessible

In my opinion, even if we accept more conservative estimates, it's very likely that this is a already a problem TODAY that is hurting our fee efficiency and staking rewards. Not just a long term horizon problem.

[rphair]

@Cerkoryn if you can put the essence of #1060 (comment) into the Problem section of the CPS — under a heading where it can be easily spotted by readers who will by default consider this a far-term problem — I will call attention to it at our next meeting and suggest to fellow reviewers that it should be considered near-term if not already in effect & ready to address with tangible solutions.

p.s. even if this economic vulnerability is in fact already significant, I would much rather see it documented by Cardano's advocates than its adversaries.

[TerminadaPool]

A couple of ideas for consideration:

Quantifying lost or inactive stake

We are going to gain insight into the scale of the problem after the Midnight glacier drop concludes. The Night token will be independently valuable and thus it could be reasonably assumed that any Cardano users not claiming their Night tokens either aren't paying attention, don't care, or can't use their keys. Even though we may not be able to identify which individual addresses represent lost or inactive keys, we will get an idea of that proportion of Ada.

Education problem: Staking rewards are not interest but rather reward for active participation

I think it would be good if this CPS attempted to address the education problem regarding why Cardano even has staking. IE: What is the purpose of staking in the protocol and why do stakers earn rewards for "staking"?

Many users think they are entitled to staking rewards just like receiving interest on a bank account. A kind of set and forget thing where they just need to do this initial extra step of selecting a stake pool, and now also a DRep, in order to receiving staking rewards. However, if rewards were supposed to be like interest on a bank account then there would be no need for the selection of a stake pool and the "interest" could simply accumulate automatically. The code could be simpler too because there would be no need for all this staking stuff.

We need to educate people that staking is voluntary, and those that choose to participate in staking are agreeing to be involved in an active process. Staking is how the protocol decides which pools get to make blocks, and that underpins the security of the ledger. Stakers are effectively performing a contract whereby they agree to monitor Cardano network health, and the performance of their chosen pool, in return for receiving a portion of the block production rewards. Stakers are actually voting for a pool operator using a form of liquid democracy to determine block production and they are expected to change that vote should network conditions change through malicious behaviour or poor performance. Users that are unable to actually change their chosen pool, should the need arise, are not fulfilling their side of the contract and therefore should not be entitled to rewards.

Lost or inactive stake is not actually contributing to securing Cardano and it would be better if it was somehow "unstaked" for two reasons:

1. It would be better for security since inactive stake provides some older pools with extra control over block production that they shouldn't be entitled to forever. When eventually one of the OG multi-pool operators sells his pool keys to Blackrock then maybe people might understand the security threat from "sticky stake" better.
2. The limited pot of rewards could be directed to the real, active, participants so they receive more instead of throwing rewards away at undeserving wallets.

Ways to mitigate the problem

One possible mitigation strategy could be to automatically deem stake no-longer active after say 1yr, thus requiring re-staking or at least confirmation of current stake pool selection. A kind of proof-of-life that the user is capable of signing with his keys. This would at least place a limit on pools continuing to accumulate "sticky" or inactive stake.

[rphair]

FYI @Cerkoryn the CIP meeting # 117 referred to above — where this is on the agenda for Triage — has been postponed 2 weeks (due to Rare Evo).

[Cerkoryn]

@TerminadaPool Agree on all points.

The NIGHT airdrop may be a helpful way to gauge/estimate alive addresses. I was toying with the idea of looking at ADA in reward account (non-UTxO) balances for addresses that have been inactive for a long time as well.

Education problem: Staking rewards are not interest but rather reward for active participation

For this and for your suggested solution, I plan to address both issues in the CIP that I am currently writing to address this CPS.

[Cerkoryn]

@rphair I made some changes based on the comments you left here for your review.

[rdlrt]

The NIGHT airdrop may be a helpful way to gauge/estimate alive addresses

Are you sure? Some of us dont really care about that token or believe in the management of it and wouldnt want to touch cold storage for it. It's value is very much opinionated and IMO - shouldnt count for much for representing 'activity'

[rphair]

thanks @Cerkoryn - the writing looks really well organised now and I doubt there would be dispute that at least the problem statement is rational. So I feel sure it will be accepted as a candidate at the CIP meeting tomorrow (https://hackmd.io/@cip-editors/117) though you might be interested in coming anyway since I think all editors would be curious to hear more about the CIP you have developing from this.

[Cerkoryn]

Are you sure? Some of us dont really care about that token or believe in the management of it and wouldnt want to touch cold storage for it. It's value is very much opinionated and IMO - shouldnt count for much for representing 'activity'

@rdlrt TBH I am not sure that it will help all that much. It is just another partial piece of information that may help us get a better idea for the open question of how to reliably identify lost stake keys.

[perturbing]

What is the reason to change this? As I always understood it, the failure to produce blocks means the rewards for that missed slot cannot be claimed by anyone, so they are put into the treasury.

That is, the motivation of the CIP does not warrant this change?

[Cerkoryn]

Currently, any rewards that are allocated during the rewards calculation but not distributed, are returned to the reserve, not the treasury.

The intent of CIP-163 is to make staking more dynamic by rewarding activity accordingly and curtailing rewards for inactive accounts. The section you quoted works synergistically with the first section, 1) Reward-account inactivity expiry (proof-of-life). The reasons for how it fulfills the motivation for the CIP are listed under the rationale section.

[perturbing]

The sizes of these circles are a bit misleading (I know that you cannot say exactly how big they are relative to each other).

[rphair]

@Cerkoryn as observed at the CIP meeting today we are leaving this in Last Check to allow all other editors enough time for further review and follow-up on existing review points. We might merge this earlier than the next meeting (https://hackmd.io/@cip-editors/120) if we have consensus earlier here on GitHub.

[rphair]

@Cerkoryn as you observed at the CIP meeting today (# 120) we had to postpone our Last Checks until next meeting (https://hackmd.io/@cip-editors/121) due to not having editor quorum at meeting (only 1 editor present) and the massive turn-out for emergency Leios review.

@Ryun1 @Crypto2099 @perturbing for these 2 proposals I'd offer to merge this in the in-between period if you can provide approval and if there are now objections... otherwise it's on to Last Check as planned in 2 weeks' time.

[Ryun1]

really well articulated problem statement
appreciate the efforts @Cerkoryn 🙏

[Ryun1]

is this file intended to be included within this pull request?
I think it may be a mistake

[rphair]

@Cerkoryn just noting for the community & editors, based on today's CIP meeting consensus, that these two submissions are practically ready to merge as soon as we have a universally acceptable justification that doesn't rely on the "red line" graph of geometrically increasing opportunity cost:

• #1060
• #1077

and that both proposals can stay in Last Check until merged at next meeting https://hackmd.io/@cip-editors/122 or perhaps earlier by online consensus.

[Cerkoryn]

@Ryun1 @rphair @Crypto2099

I removed the chart with the projections and any references to the speculative estimates throughout the document. There were a couple of places where I re-phrased the wording to be clearer without relying on any of those numbers. I think that it reads well now, so I didn't feel the need to add another graphic to replace the one that was there. However, if any of you think that something needs to be added I'm happy to try and incorporate that to communicate the problem statement more clearly.

I also squashed the commits that had accidentally included CIP-0163 as well. The git history should be clean now.

Please let me know what you think or if you require any further changes.

[rphair]

thanks @Cerkoryn - the updates certainly seem to me to support a more general & inclusive view of the problem. I am now in favour of merging this without reservation & will check to see if further confirmation can be expedited so we don't have to wait another 2 weeks to merge this.

edit, p.s. before we do that, I assume the "offending" file CPS-0022/fig2.jpg was also intended for removal along with all the references to it. If your intention was to leave it in then please indicate what purpose it serves: otherwise we'll wait for that file to be git rm'd in your fork before merging.

p.p.s.

I also squashed the commits that had accidentally included CIP-0163 as well.

FYI we have the repository set up so that commits are squashed when PRs enter the repo... so committing the unmodified file into your branch will achieve the same effect, sometimes more simply (as long as the round trip didn't include any otherwise inapplicable co-authorship). 🤓

[Cerkoryn]

My apologies, I had overlooked the image file. That is now removed as well.