TIP-033: Staking contract upgrade

Proposals
1

Summary

Upgrading a contract is always a critical operation, but right now we have an opportunity to perform an upgrade with a reduced risk surface, since currently there’s no applications directly connected to the staking contract – the PRE application is just weakly connected, and for example, it can’t slash stakes. In this proposal, we present a reduced set of changes to the staking contract that improve the gas efficiency, the clarity and the user experience of the staking protocol. In particular, we propose the following changes:

  • In case of a stake being slashed, authorization of all applications will be reduced.
  • Applications can decide the behaviour when there’s a second request to decrease authorization while there’s still a pending request.
  • Changes to who can top-up stakes and synchronize stake owner information for legacy KEEP stakes.
  • Allow to stake exactly the minimum stake amount.

Additionally, this upgrade has a secondary purpose beyond the proposed changes, as it will allow us to test our upgrade procedures and tools. In the next section, there’s a more detailed description of the changes proposed here and their motivation.

Proposed changes to the staking contract

  • PR #87: Involuntarily decrease all authorizations in case of slashing
    • https://github.com/threshold-network/solidity-contracts/pull/87
    • Before —> If a stake is slashed, the original approach was to decrease authorization on the slashing application and decrease authorizations on other applications only if necessary, that is, if the staked amount after the slashing was lower than the authorization on the other applications.
    • After —> All applications see their authorizations decreased in case of slashing, no matter which application executed the slash.
    • Motivation —> This change allows reducing the gas cost of slashing large groups significantly; this is extremely important for random beacon and tBTC.
  • PR #99: Staking requestAuthorizationDecrease function contract update
    • https://github.com/threshold-network/solidity-contracts/pull/99
    • This PR doesn’t change code but the documentation on the expected behavior of the staking contract and applications.
    • Before —> If there’s a pending authorization decrease request, a new request will overwrite it.
    • After —> The new request will overwrite the old one only when the application logic allows it; otherwise, the request will revert.
    • Motivation —> This is important for TBTC and Random Beacon because allowing to reset authorization decrease request could lead to pool manipulation and free-riding.
  • PR #103: Let the staking provider to refresh KEEP stake owner
    • https://github.com/threshold-network/solidity-contracts/pull/103
    • Before —> Only owner could refresh a KEEP stake owner
    • After —> Owner and staking provider can refresh a KEEP stake owner
    • Motivation —> Resolving the owner of a stake is complicated when the owner is a KEEP grant contract. This PR adds a workaround that allows the staking provider to trigger a synchronization of this info that fixes certain edge cases.
  • PR #110: Allow anyone to top-up any staking provider with liquid T
    • https://github.com/threshold-network/solidity-contracts/pull/110
    • Before —> Only owner or staking provider could top up a stake
    • After —> Anyone can top up any stake
    • Motivation —> Allowing arbitrary accounts to top up a given stake facilitates composition of staking TXs into a single bundle (e.g., claim rewards and then top up), which in turn aids in the road towards compounding rewards.
  • PR #122: Allow to stake an amount equal to the minimum stake

Governance procedure for the upgrade

The plan outlined by TIP-2 was that the staking contract was to be owned by the Staker DAO, but given the overall distribution of current delegations, the deployment of the Staker DAO has been delayed. Hence, the Threshold Council is still the owner of the staking contract. Given the criticality of the upgrade process, we propose to maintain this setting for the time being and perform this upgrade in the following way:

  1. A new implementation of the staking contract is deployed to Ethereum Mainnet. The new contract should be verified on Etherscan so the changes to the code can be reviewed by the community.
  2. A Snapshot vote is created to decide whether the new implementation is accepted.
  3. If the Snapshot vote passes, the Threshold Council requests the staking proxy contract to upgrade its implementation to the contract deployed in step 1.
10 Likes
2

This all looks great

2 Likes
3

PR #110: Allow anyone to top-up any staking provider with liquid T

Does this mean that people who don’t run a node can also stake T and get rewarded?

4

No, it just means that the staker doesn’t need the one creating the top-up TX, but anyone can do it, so for example, there could be a smart contract that facilitates claiming and topping up in the same TX

2 Likes
5

I am in favor of this proposal. I strongly agree with the goal of reduced gas fees and higher efficiency, I think these offer a more level playing ground to those smaller holders wishing to enter the staking arena. I am also a fan of testing our upgrade procedures and strength of related tools. It is a great idea to test these tools within a reduced risk surface. Great work on this proposal David!

1 Like
6

I support this proposal

1 Like
7

Proposed changes were just deployed. See the contract link on Etherscan.

Note that this is just the new implementation contract, but the official proxy still points to the existing implementation. As described in my original post, we need now a Snapshot vote to decide if this implementation is accepted, and only then, the Threshold Council can request the staking proxy to upgrade to the new implementation contract.

3 Likes
8

This proposal was moved to a Snapshot vote:

https://snapshot.org/#/threshold.eth/proposal/0x8a1946d8618a4efeb01ec89d17e1e3078dd2930599bda5e318e3b8ad0d520f8b

9

This proposal was ratified by the DAO.

https://snapshot.org/#/threshold.eth/proposal/0x8a1946d8618a4efeb01ec89d17e1e3078dd2930599bda5e318e3b8ad0d520f8b

In addition, the contract upgrade was successfully executed by the Threshold Council.

2 Likes