CIP-0163? | Time-Bound Delegation with Dynamic Rewards

[Cerkoryn]

This is I think the most ambitious CIP that we (the community SPO Incentives Working Group) are proposing.

I think the expired delegations part is already mostly expected and well-understood. But the changes to the rewards calculation were necessary to include together and that required quite a bit more work. The documentation for how this "residual" ADA is returned from the rewards pot to the reserve was hard to find and difficult to follow. It's also highly likely that my math is off, but we included a link to our open source tool that duplicates the math (in a simpler form) using Typescript.

The references to the relevant sections in the Shelley Delegation spec and Shelley Ledger spec are referenced at the bottom and should help any implementors to understand what we are trying to achieve with this CIP.

(rendered)

[trjate]

This CIP feels very comprehensive and I can't really think of any counter arguments why we wouldn't want to implement something like this. Social contract yada yada yada, but I think encouraging slightly more active participation from delegators is the right way to go. I like the bank analogy. Staking on Cardano is not opening a savings account.

However, I read both the CPS and CIP, but I'm not sure I saw an accounting of the fact that lost stake still theoretically increases the number of blocks a pool produces, and therefore the amount of rewards that all active pool stakers receive.

The CIP drills on the point that lost stake siphons off rewards that otherwise would go to active stakers, but doesn't seem to account for the increase in block rewards it generates, which are shared by other stakers in the pool. Assuming I have this right I'm not saying I don't agree with CIPs solution to this problem, just that it still feels unclear how lost stake negatively impacts other pool stakers.

My understanding on all of this is certainly incomplete though.

[rphair]

@Cerkoryn looking forward to introducing this in Triage at the next CIP meeting (https://hackmd.io/@cip-editors/118) especially since #1060 is also up for Last Check there.

@lehins @WhatisRT since this proposal depends so heavily on the Ledger, I hope you can both give this your early assessment and keep contributing guidance on what would ultimately make it a target for implementation.

Since most of the Implementation Plan is about Ledger interaction we need your help to make sure the language there is (or will eventually be) realistic, complete, and correct. If you think it needs to be broken down more simply (see #1077 (comment)) please say so.

[WhatisRT]

From a Ledger POV this is a pretty clear proposal and it would be relatively easy to implement.

Have the contents of this CIP been discussed with incentives researchers? Incentive designs are quite tricky and non-intuitive, so this should definitely happen in the path to active. I'd also like to see a distribution of active stake that would be removed by this proposal depending on the initial value of stakePoolDelegationLifetime.

Removing a large amount of delegations at once might give an adversary quite a bit of power, so this approach seems quite dangerous to me. Old delegations may or may not be problematic for the network safety, but they add to the "momentum" of the system. If X% of the stake is removed, an attacker would require X% less stake to to the same amount of damage as today. Note also that exchanges (and other big players) are likely not affected by this - they would keep their delegations active. So this removal would likely increase the percentage of stake owned by them.

Requiring periodic review of delegations may also push active delegators away from the ecosystem, or lead to wallets that automate that chore. The former is clearly bad, while in the latter case nothing was gained in the long run.

[Cerkoryn]

@rphair I made the formatting corrections and changed the name of the CIP. The math should render correctly now.

[Cerkoryn]

However, I read both the CPS and CIP, but I'm not sure I saw an accounting of the fact that lost stake still theoretically increases the number of blocks a pool produces, and therefore the amount of rewards that all active pool stakers receive.

The CIP drills on the point that lost stake siphons off rewards that otherwise would go to active stakers, but doesn't seem to account for the increase in block rewards it generates, which are shared by other stakers in the pool. Assuming I have this right I'm not saying I don't agree with CIPs solution to this problem, just that it still feels unclear how lost stake negatively impacts other pool stakers.

@trjate the intent with expiring delegation certificates is that the lost ADA would become effectively unstaked eventually. Which would mean they would not contribute to block production for any pools either.

[Cerkoryn]

@WhatisRT

Have the contents of this CIP been discussed with incentives researchers? Incentive designs are quite tricky and non-intuitive, so this should definitely happen in the path to active. I'd also like to see a distribution of active stake that would be removed by this proposal depending on the initial value of stakePoolDelegationLifetime.

I would love to hear the feedback from more qualified incentives researches like @BTL_Edinburgh.

As for the distribution of active stake that would be removed at various parameter settings, that was intentionally left out of this CIP. The intent is for that research to be presented to the parameter committee and community via governance and/or off-chain vote to determine what the best initial settings should be.

[Cerkoryn]

I think it's worth taking a step back and looking at it from the perspective of an insider threat instead of simply counting the cost to an external attacker starting with zero ADA.

An established SPO or pool group that already has large amounts of stake could, at any point, become adversarial for any number of reasons. It could be that they sold their pool(s), they could become disgruntled at the state of Cardano, they could have their cold keys compromised, etc. I don't think it is necessary or even possible to come up with an exhaustive list of reasons why someone could turn adversarial, but it is important to still recognize that the threat exists. Some pool groups might already have sufficient stake to pull off certain kinds of attacks, such as a long-range attack, a forced rollback, or governance attacks. You could also consider things like setting margin to 100% suddenly, which is not necessarily an attack but it is something that may be considered unethical.

I think the rational expectation from a security perspective is for delegators to notice irrational or malicious behavior as soon as possible and then to delegate away to a more trustworthy SPO. The specific subset of those delegators mentioned in CPS-22 are those that CAN'T delegate away, for whatever reason. This particular CIP addresses that problem, but also comes with a host of other benefits listed in the rationale section that are independent from that CPS that should also be weighed accordingly.

[Cerkoryn]

As for the idea of directing rewards from inactive stake to the treasury, I think that’s a solid approach. It also addresses my earlier concern about attackers being able to make statistical inferences about the optimal time to target the chain.

I'm not sure I understand the reasoning here. The second half of the CIP regarding full-pot distribution relies on the fact that delegators and SPOs will receive the rewards that was previously being sent to accounts that have since expired. This is as a counter-balancing mechanism to help incentivize delegation if the total stake ratio drops too low. If we send those rewards to the treasury instead, it defeats the purpose and increases the risks related to drops in total stake due to large expirations.

[fallen-icarus]

... delegators and SPOs will receive the rewards that was previously being sent to accounts that have since expired. This is as a counter-balancing mechanism to help incentivize delegation if the total stake ratio drops too low.

I want to reiterate my opinion that this will not actually incentivize total stake to rise. If a person doesn't care enough about ADA to participate in the effectively effortless staking rewards right now, offering them more ADA likely won't change their behavior.

[Cerkoryn]

@WhatisRT @fallen-icarus

I've gathered good data on the count of wallets and sum of stake that would be affected by different initial settings of delegatorInactivity.

The first chart is counting every wallet currently delegated to an active stake pool, regardless of how much ADA is in the wallet:

The second chart is the same, but only looking at wallets with >5 ADA in them:

Warning

The two above charts are not entirely correct. The Koios /account_txs endpoint includes inbound-only transactions, which caused me to unintentionally mark some wallets as active when they shouldn’t be. The true numbers are slightly higher than this and posted in a below comment. -Cerkoryn

It is worth noting that of course there would be 0 stake and 0 wallets affected if we went up to 6 years, because the Shelley hard fork was less than 6 years ago. However, the longer we wait to delay any kind of CIP like this one, the more stake that will build up in older pools over time and the harder it will be to introduce a proof-of-liveness mechanism without running into security concerns about stake expiration.

Looking at this data, if we choose an initial value in the range of 3-5 years, the upper limit of how much total stake that would be affected is 6.2%, 2.7%, and 0.5% of active stake (~21B) respectively. I agree that the balancing mechanism will probably have a marginal effect at incentivizing new delegations, but based on these numbers I think that any tradeoffs to security that result from stake expirations will also have a similarly marginal effect.

In valuation of USD, Cardano is already #1 in terms of market cap and #4 in terms of raw USD valuation when it comes to economic security (see this post). Even if this change were to result in a small 1-2% decrease in total stake we'll still be best-in-class. And if a corresponding 1-2% increase in ADA/USD valuation accompanies this change due to increased investor confidence, then we will have actually RAISED the cost of an attack.

[rphair]

@Cerkoryn I've just read through the review commentary all over again to see if there might be any grounds to progress this in our biweekly meeting cycle. In my opinion we are still getting all the community ideas & expert review on the table, and the time to conclusively bind all these together into a single strategy for the CIP hasn't come yet.

If that's true, I would have no problem letting this continue just as it is now. If it ever seems we are stalling on the blackboard forever, the 2 things you might do that could help are:

• if you (or an editor / reviewer that sees a more manageable number of possibilities than I do) would make a checklist of the issues that still need to be decided;
• if you think (and post) that putting this up for Review at a future CIP meeting would help either to settle upon that checklist or to address the items on it.

[Cerkoryn]

Have to make a correction on the data. I'll leave the above post up, but add a disclaimer explaining it.

TLDR, the Koios /account_txs endpoint includes transactions that are inbound-only, which was incorrectly marking some wallets as active when they shouldn't be. After accounting for that, the upper limits for the amount of stake that could be affected by enacting this CIP raised a little bit from our earlier estimate. Apologies for the error.

Wallets with less than 5 ADA were ignored for these queries:

=== Results ===
No tx in past 1y: 6,381,362,493 ADA across 583,961 accounts (29.36% of delegated stake in sample)
No tx in past 2y: 3,838,556,704 ADA across 454,497 accounts (17.66% of delegated stake in sample)
No tx in past 3y: 1,966,069,219 ADA across 361,726 accounts (9.04% of delegated stake in sample)
No tx in past 4y: 997,665,752 ADA across 167,816 accounts (4.59% of delegated stake in sample)
No tx in past 5y: 127,644,174 ADA across 2,820 accounts (0.59% of delegated stake in sample)

Reminder that 6y is also a viable choice, but it is obviously 0 ADA and 0 wallets affected because the Shelley Hard fork is not that old yet.

Other reminder: All of these numbers are still upper limits. Many of those wallets surely would make a simple transaction and continue earning rewards without issue.

[Cerkoryn]

I'll also add that there was another benefit to this CIP that we hadn't yet considered. The portion of stake above the saturation limit in an oversaturated pool effectively reduces the pool’s rewardable stake and those forfeited rewards are currently sent back to the reserve.

Under this CIP, when certain parameters change (e.g., raising k or lowering L per CIP-50), this sharpens the incentive to re-delegate quickly and converge to the new equilibrium. If some delegators lag (sticky stake, lost stake, etc.), the rewards they would have earned is redistributed to delegators who are eligible for rewards instead of going back to the reserve.

Additionally, stake over the saturation limit currently still participates in block production even though it earns no additional rewards. This effect carries over in the CIP so there shouldn't be any security tradeoffs to worry about in regards to this new information.

This effect is now modeled in our tool (previously it was notionally being sent to the reserve in the tool)
https://spo-incentives.vercel.app/

Notably, this requires no change to the CIP.

[rphair]

@Cerkoryn I wanted to see how this could be progressed, given it's been stalled for about a month: with editors skeptical about it and the methods & possible side effects challenged by the community. I was hoping someone would follow what I recommended in #1077 (comment) but this is generally an editor's job so I've just done it myself.

This outline omits reservations (expressed by @TerminadaPool @fallen-icarus) that I believe were answered. If those or any other reservations still remain, in anyone's opinion, feel free to emphasise them & I'll add them to this review outline so we can refer to it at meetings without sorting through the long prior comment history:

open questions to settle before final review

• proposed method vs. "'stake account expiration"
  • possibly resolved here with 636630c
• suggested simplification
  • response begins:
  • still pending working group response? (edit: NO & addressed in most recent rewrite)
• continuity of stake vs. sudden drops
  • debate begins, over balancing incentives
  • possibly resolved with participation shocks after large expirations
  • (edit: addressed in this commeint)

@perturbing @Ryun1 @Crypto2099 I would personally be in favour of approving & merging this as a "workable solution" even if the above & any future points are still debated on both sides without everyone being able to agree.

I would trust @Cerkoryn therefore to declare when this is the author's and collaborators' "best effort" to satisfy all community & Ledger feedback (cc @lehins @WhatisRT)... but we owe it to the community to get the best possible rendition so we should try to clear as many as possible of these points first.

(edit: amended after review of #1077 (comment) & no issues remaining as I see it)

[Cerkoryn]

@rphair

• proposed method vs. "'stake account expiration"

  • possibly resolved here with 636630c

That is correct. I believe this was resolved when we switched to using @lehins method of using the last witness on the reward account instead.

• suggested simplification

  • response begins:
  • still pending working group response?

Similar to above. The minor re-write was inspired by this simplification and included the things mentioned here with the exception of returning excess rewards to the treasury (since that forgoes many of the other benefits related to the full-pot distribution part of this CIP)

• continuity of stake vs. sudden drops

  • debate begins, over balancing incentives
  • possibly resolved with participation shocks after large expirations

I believe this is more or less answered by the data presented in #issuecomment-3358578912. This shows the maximum amount of ADA that could be expired in such a way based on the current state of staked ADA.

From the perspective of myself and others in our working group, we believe that this CIP is in a sufficient state such that it could be merged and presented to the community for a vote (on both the CIP itself and the initial value of delegatorInactivity).

[rphair]

OK @Cerkoryn I'm satisfied with the document, and that it has addressed all feedback (especially "participation shocks") in the last round of review: and that all pending points I could find in (updated) #1077 (review) have been addressed as further explained in response #1077 (comment).

@Ryun1 @Crypto2099 @perturbing I think therefore this can be moved back to Last Check because of this additional stage of review & response. This is not to rush through review of any further considerations: but only to keep it on the review calendar & pointed toward the merge that I think it is ready for.

[Ryun1]

really interesting proposal
pleased to see it merged🙏

[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]

@rphair @Ryun1 @Crypto2099

This one is fixed as well. It was a much simpler change because the offending charts were able to be cleanly removed from the document without materially affecting anything important. Also the git history for this one was already clean.

Please let me know if you guys recommend any further changes, thank you.

[rphair]

thanks @Cerkoryn - I think this now establishes a more general & inclusive motivation for a solution.

I assume this also means the still-remaining files CIP-0163/Fig2.png and CIP-0163/Fig2.png are artefacts of the original presentation, also intended for removal along with all the references to them. If your intention was to leave these images in then please indicate what purpose they serve: otherwise we'll wait for those files to be git rm'd in your fork before merging.

In any case I'm happy to be 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.

[Cerkoryn]

@rphair

My apologies, I had overlooked the image files. Those are now removed as well.

[EarnCoinPool]

@lehins

3. Any action that requires a witness for an account moves expiration for that account into the future.

Can you explain which actions require the witness needed here? Is it any transaction or transaction like withdrawal of rewards?

[lehins]

Can you explain which actions require the witness needed here? Is it any transaction or transaction like withdrawal of rewards?

@EarnCoinPool I am glad you asked 😁

There are three levels of ownership indication of an account:

1. Direct proof of ownership, which requires witness (i.e. cryptographic signature of a transaction or execution of a smart contract, depending on what type of account it is). This proof of ownership can be inferred from all of the actions below:

   • withdrawal of rewards
   • delegation to a stake pool and/or DRep
   • unregistration (which is a valid action to take into consideration, since account can always re-register)
   • From Conway era onwards registration certificate, whenever certificate also specifies the deposit amount. Classic registration certificate that was introduced in Shelley era did not require a witness, as such it cannot be used as proof.
   • Submission of registration or an update stake pool certificate for owners listed in stake pool parameters.

2. Indirect indication of ownership, since it does not require a witness for the account, but is closely tight to the account. Spending an output from an address that contains that staking credential. Since this action does not require a witness for that credential, it cannot be used as direct proof. However, because assets are being spent that used to be associated with the account is a good indicator that the wallet that created this staking account is still very much active, because only the owner of that wallet would be able to spent such an output.

3. Indirect hint at potential ownership:

   • There were funds send to an address with a staking credential. This is the weakest of them all, since anyone could send funds to a public address that contains a staking credential. However, it could be used to infer at least some activity. If someone is receiving a million ADA to an address, I would expect they will not be using someone else's staking credential, since they will be loosing money in the amount of rewards that will go to that account.
   • Stake pool registration or update certificate account is listed in the rewards account of stake pool parameters. Witness is not required for using account in that manner, but since funds received by that stake pool will go into that account it can be used as a vague indicator that the account is still active.

[EarnCoinPool]

@lehins

Thank you for your reply, this was very helpful.

Can I ask, if this CIP were to be implemented would all 3 of these be used to update the variable? Or would some be excluded? I assume the first item under 3 should be excluded as anyone could send some tokens to an address to game the system.

Thanks again for your help!

There are three levels of ownership indication of an account

[lehins]

I assume the first item under 3 should be excluded as anyone could send some tokens to an address to game the system.

@EarnCoinPool Yes, I would definitely agree with that. I mostly included the third point for completeness sake and as something that could be considered as potentially useful information. For example if today one would analyze historical data, it could be useful information to know whether an address that might be considered inactive is still receiving funds. Maybe such account isn't really dead, especially if it is receiving large amounts of ADA 🤷