CIP Add the ability for SPO to refuse stake addresses

Developers CIPs
1

This is a draft of a Cardano Improvement Proposal (CIP) impacting some delegation rules.
I hope it will start a sane discussion on this forum as required to submit it as a CIP.

Preamble

I would like to propose to give SPOs the ability to refuse a delegation from a given stake address, for some reasons as you will see. This is a problem concerning resistance to censorship and it is certainly a very delicate problem to deal with, but I think these are issues that request attention and, maybe, actions.

Abstract

Currently SPOs are completely passive referring to delegations acceptance. They can do nothing to block or remove a particular stake address from their stake pool. They can do nothing to address over-saturation and they can do also nothing to address some regulatory problems, existing or future.

Motivation

This proposal try to resolve two problems I think exists in current implementation:

  • Over-saturated pools
    Over-saturation harms the health of the network itself and the earnings of the delegators. At this stage SPOs are unable to protect their pool from this problem and sometime the economic disincentive is not enough. Due to FOMO in some cases or distraction in others, some Stake Pools remain over saturated for a long time and this causes losses to them and their delegators.

  • Regulatory problems
    Some SPOs from some country may need to avoid delegation from some person or from someone coming from some country because of regulatory problems. SPOs are completely passive in this process and there is no way to address it. This is a delicate problem to deal with and a fair solution may be difficult to find, but something should be done.

Specification

Any SPO can reject a delegation from a specified stake address with this command:

cardano-cli node stake-reject
  --stake-pool-id (the stake pool id)
  --reject-stake-addr (offending stake address)
  --out-file reject.raw

The --reject-stake-addr parameter can be repeated many times.

Than it can be signed with the appropriate key (to be defined at this time, on a cold machine if you will need the “cold.skey”):

cardano-cli transaction sign
  --tx-body-file reject.raw
  --signing-key-file (the key that will need to be used)
  --mainnet
  --out-file reject.signed

And finally on an hot machine:

cardano-cli transaction submit
  --tx-file reject.signed
  --mainnet

Rationale

While this is not a complete solution, at least on the regulatory front, this implementation is powerful and flexible enough to be used in many cases. On the regulatory front SPOs who need to follow some local law can easily setup a KYC procedure on their own and create a white list of allowed stake addresses. Than SPOs can run a script every epoch to keep things clean and respect the laws as they need to do. Proposed implementation is not definitive and is subject to review as soon as obvious concern will arise, especially regarding resistance to censorship.

Backwards compatibility

TO BE DEFINED

Path to Active

TO BE DEFINED

6 Likes
2

Very interesting… thx for sharing

Cheers,

2 Likes
3

Then it would perhaps make sense to also have the white-list option in the protocol to not only reject certain addresses, but to only allow white-listed addresses in the first place.

This would also allow wallet apps to check that before even submitting the delegation transaction.

The stake-reject would leave the delegators without any delegation. If they do not check regularly, they could miss quite a lot of rewards. And if the pool operator gets to decide, which delegators to kick, it’s not even guaranteed that these are the last ones having over-saturated the pool, but they could just kick arbitrarily.

On the other hand, this functionality could be good to (on a voluntary pool-operator-controlled basis) exclude known scammers/thiefs from staking.

4

Perhaps include a “switch” for SPOs to blanket-refuse additional delegators, too.

5

BTW: Do the pools really have losses due to over-saturation?

I thought, they just do not get more blocks for additional stake, then. But they still get to produce the maximum number of blocks (on average). So, no loss there. Only for the delegators that have to divide these among more stake.

But, then, the pool operators are in that group with their pledge, also, so, that would be losses for them.

6

There is sort of ‘a way’ now, namely increasing your margin until some delegators leave again. This might not be useful if you have some big delegators and more delegators than you want can leave though. Won’t help with the regulatory problems of course.

No, no, no! You cold keys (skey and vkey) should not reside on an online machine, so this won’t be possible. If implemented, it should probably be somewhat analogue to stake pool registration.

I think IOG is already investigating the possibility of sometime like this (also an opt-in scheme, were the SPO will have to accept each delegation). It might be nothing more than an idea or thought for now and nothing concrete though…

2 Likes
7

He did not specify that this command should be run on the hot machine, could as well be on the air-gapped machine. Ah, but then it would at least need to put out a signed transaction file to be sent from the hot machine.

But, yes, build stake rejection transaction (it has to be a transaction, everything has to be a transaction) on hot machine, sign on cold machine, send on hot machine, would be the correct way.

1 Like
8

Then it would perhaps make sense to also have the white-list option in the protocol to not only reject certain addresses, but to only allow white-listed addresses in the first place.

But I think the protocol itself should remain as generic and abstract as possible, also to avoid global censorship this is something that should be managed by SPOs, I think.

9

Sure you should do it in this way!

At this time I don’t know which key may be needed for such a things, it’s to be defined, however I updated the draft to address this concern. Thank you.

10

As pointed out by @HeptaSean you can sign it on a cold machine, and this is my intend.

I will change the example to include “–tx-body-file” and “–out-file” so it’s more correct.

Thank you!

11

I think I fixed the “cold.skey” concern, please tell me if now it sounds better, thank you.

12

Yes it may be useful.

13

The SPO rewards does not decrease but the delegation rewards from the pledge does, not too much but does, and also this situation offends other stake pools that may lose potential delegations.

1 Like
14

But you do propose a change to the protocol. A massive one.

At each snapshot, the network would not only need to find the latest delegation transactions and the current stake on the delegated stake keys, but also if the stake pool has rejected that stake key. That is a change to the protocol.

And the longer I think about it, the less I like this. My delegation could be rejected at any time and when I look at that savings wallet three months later, I find out it has not got any rewards and it’s just bad luck?

White-listing beforehand would leave intact that if the delegation transaction has gone through, I am delegated. Period.

An additional possible rule that SPOs could get as an option would be: “No more delegations if saturated.” or “No more delegations at all.” But that also would have to be clear beforehand and only lead to delegation transactions fail, but not to revert them after the fact.
(This would not prevent over-saturation completely, because already delegated wallets could grow bigger.)

As for the regulatory thing: I suppose, a lot of law-suits could be faught over the question if I even am a customer of the stake pool I am delegating to, if KYC rules even apply. I certainly don’t feel like a customer. There are no transactions between me and the stake pool. The rewards are distributed by the network, not by you SPOs.

2 Likes
15

This is an interesting concept and one that probably needs to be considered with time. I am not able to comment on the technical side of this but I think it would be somewhat naïve for us to think that because delegation is a passive process that SPOs will be able to escape potential KYC/AML procedures if the regulators want to take this on board. At the end of the day an SPO may have 10’s of millions of USD worth of stake attached to their pool and their pool is directly attributable to that stakeholder getting paid the rewards. If the stake is somehow considered dirty money, proceeds of crime or related to terrorist financing then regulators in many countries may impose some pretty draconian expectations on behalf of the SPO. In fact this may put SPOs that operate in countries like the US, UK or Australia for example at a disadvantage as it is in these countries that regulation may be more likely. For this reason I think it is paramount that some form of controls can be put at the SPO level in preparation for any mandatory KYC requirements. Just my 2 cents worth anyway.

2 Likes
16

It has its own drawback, you can explore it: Delegators come and go over time and normally you have some deviation from the optimal saturation, sometime over and sometime under. If you blanket-refuse additional delegators your avarage saturation level will always be under the optimum level, however it may be a good solution for over-saturation. This can be done one time with a flag in the registration-certificate, maybe a subject for another CIP draft. I find it useful, you should propose it, and it’s also much easier to implement.

17

Yes this is a change to the protocol but I don’t think the capability itself imply to add some overhead, it depends on how it’s implemented. We need a comment from someone who has a deep understanding of this part of the protocol, and it’s not me, to understand how much overhead this can bring.

This is a legit concern, I understand it but I would like to add a consideration:

Even now, with current rules, if you look at your delegation every three months you could find out that the pool you delegated to does not exists any more. Just look at how many are still on retired MELD* pools…

This is true, rewards are distributed by the network and there are no transactions between delegators and the stake pool, but you know: lawmakers are not always technically competent and we must be prepared for the worst. Having the ability for an SPO to setup its own KYC and its own white-list could make the difference between being able to comply with the law or not being able to do so. Then lobbying to change the laws and make them fairer is another matter. This is a cabalility that may end up being useless with good law but I think it’s always better to have it.

18

Muy interesante, saludos

19

This sounds useful and will solve over-saturation issues. The regulatory one will be difficult to enforce as there is no way to know where the delegators reside. Thanks for suggesting the CIP.

If we start using this active method of removing delegators, I suggest to add a functionality to blacklist addresses so they are prohibited from delegating again after they are rejected. But then again, they can always use another wallet address.

For me, for the saturation problem, I would prefer this to be handled by the protocol automatically. For example, delegators will be prohibited from delegating to pools if their delegation will cause the pool to get saturated. Enforcement would then be passive with no need for SPO’s to actively remove excess delegators.

20

Understand the motivation for this but do not agree that it is a good idea. The protocol has to be neutral. The moment you permit SPOs to control who can stake they become accountable for that. And therefore it opens them up to all sorts of liabilities.

The current design ensures neutrality, which is the critical feature. The problem of over saturation always resolves itself in our experience.

2 Likes