Prop 818 Discussion

Going to post a link to our own explanation again:

Hopefully this can help people to make up their own minds. Our goal here is to be as clear as possible to what has happened


These are just training wheels. Work is in progress here to make slashing automatic on the Hub, and end governance gating. There are not plans to add anything like this to the Hub. However, I would be in support of a mechanism like Anoma’s cubic slashing, or Ethereum’s correlation penalty to let validators who make mistakes and are not part of a coordinated attack get off with a smaller slash.

If there’s any question that a double sign could have been part of a double spend attack attempt, I think that governance will slash them.

I don’t think so. There is no benefit to double signing unless you are part of a cartel of 1/3+ double signing on the same block, as part of a double spend attack with carefully crafted alternate histories. In this case I think that the validators involved would be slashed. There is no reason for a validator to just double sign randomly, and really no direct harm if they do so.

That being said, I wouldn’t mind if these validators are slashed just to “prove that it works”, if that’s what people need to see. At the same time, I can also understand if people want to let them off easy for this obviously non-malicious operational error.


All of this - thanks Jehan.

1 Like

To me another goal of slashing in Cosmos is to strongly incentivize a culture of operation excellence among Cosmos Hub validators.

Cosmos validators have always been advised to run TMKMS or horcrux in production. Each of these applications provides additional double sign protection but also protects against a host of other potential threats to the network like malicious node binaries getting access to keys or an attacker getting access to keys via a compromising the only validator node.

The double spend incidents are indicative a significant decay in validator operational practices.


@David_Fortson I do not view this governance proposal as discretionary. Once I was aware of the equivocation, I feel obligated to put it up for a vote.

There is also the issue that evidence must be processed promptly for the security model to hold. So the idea of posting first to the forum seems inappropriate.


Yep - I get that. I pasted in the section from Informal’s blog above that outlined why this needed to go on chain ASAP. Appreciate the prompt action and understand why.

Thanks Jehan. Is Ethereum’s correlation penalty similar to the proportional slashing module? Link not working.

:hamster: Quokka Stake here.

Seems like a clear NO for us. This is not a malicious behaviour, this is just a validators’ error, and we have quite a lot of cases of tombstones on other chains during the upgrades, and all of these times such tombstones were either discarded (like on Evmos), or reverted via a separate chain upgrade. We do not see why we should treat it any different here. NWV seems like a bad option here for us, as it’s not a harmful proposal, it’s a proposal we do not agree with.

Additionally, we should also keep in mind that ICS is still in the adoption phase, so there are not that many validators who has a lot of experience running consumer chains and knowing all the internals, so mistakes may happen.


This precisely. Its ironic how everyone has forgot that similar cases already happened before, but with much larger validators

1 Like

I agree with this sentiment to the degree that I think it might make a lot of sense to automate these governance proposals. Instead of passing a/a consumer chain could pass a governance proposal to the hub.

Thank you for spending the time to make the governance proposal by the way.

my big question

Do we want to add a layer of meat to the machines?

I remember saying in 792 that I felt that Cosmos excels with social consensus, and I most certainly still think that.

Right now humans are most likely to be able to make more accurate decisions about these slashes.

The trouble is, it’s really a rather unpleasant choice to be making.

@aidan seems to be saying that he’s basically okay with these changes (and it matters because he is a team member of a consumer chain) but if her reading his commentary correctly he does have some concern about degraded security, and I think that should be all of our concerns.


i can understand why this discussion is important,
what makes me doubtful is why so much diverse opinions there among validators.

to me it’s quite simple:

we can get a non-subjective proof that nothing was malicious → NO

we can’t - whatever the reason of that “neglicence” → YES

i really hope the YES wins.

otherwise Hub security standing is… marred.

we can get a non-subjective proof that nothing was malicious → Yes, we can and we have

I was on the fence yesterday, but I’ve changed my personal vote to a solid YES on 818.

It is true that accidental double signs don’t really cause any damage, and this was obviously accidental. One can imagine a lot of different ways to reduce punishments for accidental double signs, for instance quadratic slashing, but that is not the intention of governance-gating ICS slashes.

The intention of governance-gating ICS slashes is to avoid a scenario where a malfunctioning or malicious consumer chain generates completely bogus slash packets, and that is not what happened here.

While it may not have been intentional, the validators involved did sign two blocks at the same height. Legitimate slash packets were sent correctly from the consumer chain and were received by the Hub. Without governance-gating, they would have been slashed right away.

Furthermore, this governance-gating is a temporary feature. Work is currently underway on code that will slash validators automatically on the Hub by cryptographically verifying equivocation evidence. This new code would also have slashed the validators in 818 automatically.

From a theoretical perspective, blocking these particular slashes would not affect security. But from a social perspective, changing the social contract of PoS on the spur of the moment is a bad idea, and could negatively affect the public perception of ICS and the Hub’s security.

Can you point me to somewhere I can read more about this? Thank you!


Marty, @serejandmyself made a very good twitter thread on this topic:

Here’s another one on the anti-slash point of view:

Personally, I am pro-slash, but I want to temper these words a bit. @serejandmyself is a great contributor to the ecosystem. I hate voting to slash them. I don’t think that it is as they say “just following orders” though. I think that the right choice here is to follow the way the software is written. This is not the kind of slash that we added the governance slashing to prevent.

I could come up with only one reason not to slash @pupmos and @serejandmyself.

Here it is:

1 Like

“Slashing updates in replicated security” introduction:

“We received feedback from some validators and community members that it would be too risky to slash based solely on information transmitted from the consumer chain. The concern is that some malicious code on a consumer chain could send fake slash packets and slash a validator that had not committed any infractions.”

Did malicious code send fake slash packets? - no, packets are valid, it was validator mistake.

Is this mistake related to any ICS innovation? - no, deleteting priv_val_state during halted chain is a common (and well known) validator mistake. There is no difference in upgrading procedure on consumer chain or independed chain.

Was “Slashing in RS” created to forgive HUB validators for their mistakes? Ok, but where the line is?

1 Like

no, it wasn’t.

You are correct.

I feel this is an exercise of social consensus when the automated slashing is intendedly not implemented at this stage, and the validator community and proposers of 818 is making an example out of Pupmos and Citizen Cosmos.

I’m still dissatisfied with the rather short post-mortem tweet by Citizen Cosmos and Pupmos tweet was definitely lackluster, a 5% slashing is minimal and is a slap in the hand. A tombstone is not acceptable, but it should be if it happens again (employ a 3-strikes rule)

At this stage, this proposal is novelty at best, and serves as a reminder that we should strive for operational excellence and do our best to adhere to avoid double signing at all cost.

Having multiple keys in multiple nodes for the sake of near 100% operator uptime is not acceptable. I’d rather see individual node operators miss a few blocks, happening gradually across all node operators to implement hard fork upgrades, in order to maintain 100% network uptime (maintaining 2/3 majority consensus), rather than near 100% operator uptime with potential double signing missteps.

Being quick to act to help with a network upgrade shouldn’t take priority over operational excellence. Due to that we will vote YES on this proposal, against all odds of this proposal passing.

1 Like

Validators should get slashed (appropriate + sm amount) and simply learn from it, no?

1 Like

Yeah absolutely.

The reason that we eventually vetoed this proposal is that it’s technically flawed. That doesn’t mean that we disagree with the intent of the proposal and in fact notional supports slashing in cases of equivocation and does not wish to see that change.

1 Like