Delegations are at stake - escalated slashing

User Support
1

There’s excitement around Namada staking :fire: and delegations are ramping up every epoch :rocket:

muppets kermit GIF

With that said, it’s time to bum you out–let’s talk about slashing :upside_down_face:

Delegations are at Stake

What’s slashing? Anything you stake is literally “at stake,” or at risk of being “slashed.” When validators break a protocol rule (eg. signing an invalid block), the protocol can take a proportion of each offending validator’s stake. All delegators of an offending validator will lose the same proportion of their delegation as a result.

The bigger they are, the harder they fall

How many NAM are lost to slashing? Typically it’s 1% of your delegation, unless you are delegating to a large validator.

For example, according to Explorer75 (Namada | explorer75 | Powered by pro-nodes75), a validator with 14% of the voting power that is slashed results in their delegators losing 17.7% of their delegation. The penalty size continues to escalate quickly with more voting power: the same validator just gained 1.1% in voting power, and their slashing penalty has now increased by 2.9% to a total 20.6% :scream:

So if you delegate 100k NAM to the Rank 7 validator and they’re slashed, you would lose 1,000 NAM. 100k delegated to the Rank 1 validator would be slashed 20,600 NAM.

How can I avoid this?

  • Consider distributing your delegated NAM to multiple validators
  • Delegate to smaller validators → slashing for validators with 3% voting power or lower is ~1%

Note: you can only redelegate an amount of NAM once every 14 days

Why slash?

TV gif. Ryan Reynolds as Male Nurse in Harold & Kumar Go To White Castle wears scrubs and pulls his surgical mask down. He has a blank expression and he squints, trying to think for a moment, and then says, “But Why?”
Scary :scream:

Why slash? A validators must put up NAM as their bond–their commitment to keeping the protocol secure. Their bond can also be backed by delegations. Validators must play by the rules, with their bond (and delegators’ bond) at risk of being slashed, aka “at stake.” This is an economic guarantee for Namada users: you can expect your tokens to be secure and expect the blockchain to operate as expected.

Where do slashed tokens go? The protocol removes slashed NAM from the Namada token supply.

Beyond Slashing

Currently, Rank 2 and 4 have the same operator, and if these and the current Rank 1 validator go offline, the Namada blockchain will stop making blocks. This is because we need ~67% of the voting power online to keep processing transactions.

It’s up to you to decide how to delegate, don’t let anyone pressure you into thinking otherwise. But it helps to have the information needed to effectively decide. Please feel free to reply below and/or ask questions in the Discord server. And please, spread the word :mega:

think only you GIF by ADWEEK

BTW

Rank doesn’t reflect quality. There are excellent operators and/or key contributors buried in the lower ranks, for example:

Check out the validators who are helping to run the Housefire testnet: https://namada-explorer.sproutstake.space/validators

There are many more! Please reply below with more suggestions and reasoning :pray:

5 Likes
2

Hello,

Thanks for bringing this up, as slashing has been an important discussion topic recently.
I might be wrong about this, but I feel pretty confident about the slashing mechanism, as a validator would have to either double-sign or sign invalid blocks to be slashed. That said, I’d be interested to know how a validator could sign invalid blocks. This doesn’t normally happen unintentionally, does it?

Next, centralization is a concern, and I don’t like the idea that only a few validators could stop the chain. I really hope this will change as soon as possible.

Thank you as well for highlighting some important community contributions. We truly have a strong and powerful community!
A quick reminder for anyone who would like to share their running infrastructure services: we have the Namada Ecosystem repository for that:

All the services listed there will be showcased on a new community website that I’ve recently started working on. Stay tuned !

1 Like
3

No, but you could be running your own implementation of Namada. If it has bugs in it, then slashing can easily occur.

I cannot remember what happens when a validator goes offline, and whether that can cause any problems. I suspect that Null votes are not slashed but I’m actually unsure.

When it comes to your concern about centralisation, the cubic slashing mechanism exists exactly for the reason to prevent this. Without cubic slashing incentives, then all delegations could easily accrue to the “best” validator.

Take this thought exercise:

Let’s say that there are 10 validators. However, amongst these validators, one of them is a “better validator”. All the other ones can still be good, but this one is “better” in the sense that it has slightly fewer infractions.

For simplicity, assume that the “better” validator (let’s call it “Bengt” for lolz) incurs infractions at 90% of the rate of the other validators (let’s call them “Gavins”). Let’s call the slashing rate s.

Now, in a rational economic model, without cubic slashing, all delegators should choose to stake to “bengt”. The cost is simply lower.

Mathematically:
A delegator, when delegating D amount of stake, will look at the profit function:
r * D - s * cost * D.
Where :

  • cost is the cost of getting slashed
  • r is the staking reward parameter
  • s is the slashing rate of the validator the delegator is delegating to
  • D is the total delegation allocated to this validator.

Now, we can see that if s_bengt is lower than s_gavin, everyone should stake to Bengt. Greater profits.

However, now in the cubic slashing model, we have this extra parameter attached to cost which means that the cost of the being slashed is a function of how large the validator is!

So now, the profit function becomes:
r * D - s * cost(size_of_validator) * D

In fact, we know that the cost to the specific delegator is a quadratic function, so we can just do:
r * D - s * cost(size_of_validator)^2 * D

Now, when making the delegation decision, it can be worked out that the delegator will delegate to Bengt if and only if

size_of_bengt/size_of_gavin < sqrt(1/0.9)

I.e as soon as Bengt’s delegations are 6% more than Gavin’s, then the delegator should delegate to Gavin (even though Bengt is still the more reliable validator!). This is what allows decentralisation!

Also I did the maths in my head, someone will have to double check I’m not chatting shit.

1 Like
4

That said, I’d be interested to know how a validator could sign invalid blocks. This doesn’t normally happen unintentionally, does it?

i had the same concern, and my understanding is that no, this doesn’t happen normally using the standard Namada software

1 Like