Skip to content

v1.2.1 (Staking)

Latest
Latest
Compare
Choose a tag to compare
@pdyraga pdyraga released this 29 Sep 15:13
· 101 commits to main since this release
v1.2.1
19afdea
This commit was signed with the committer’s verified signature. The key has expired.
pdyraga Piotr Dyraga
GPG key ID: 5BA730370A97B009
Expired
Learn about vigilant mode.

This is a Threshold Staking Contract (TokenStaking) upgrade release.

The upgrade has been ratified by the DAO and discussed on Threshold forum.

The TokenStaking proxy address remains 0x01B67b1194C75264d06F808A921228a95C765dd7 .
The new TokenStaking implementation contract address is 0x57e1a87603bd1960d734243f8b2f5133911e009d.

Additionally, we applied floating pragma for IApplication and IStaking interfaces in #127.

Staking contract upgrade changes:

  • Involuntarily decrease all authorizations in case of slashing
    • 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.
  • Staking requestAuthorizationDecrease function contract update
    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.
  • Let the staking provider to refresh KEEP stake owner
    • 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.
  • Allow anyone to top-up any staking provider with liquid T
    • 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.
  • Allow to stake an amount equal to the minimum stake
    Fixes a bug that prevented staking with the minimum stake amount

The release commit hash is signed by the development team, verifiable on Keybase. Our Keybase usernames are all associated with the Threshold Network organization and with our GitHub usernames.

Commit hash for clean builds is 19afdea00e15c0322f7457693b3e806fdf3bdfc5.

Signatures of commit hash from the development team (verify these in the Keybase app):

  • @pdyraga:
    BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zk8SRO9e gN94erb57G43YvY asc2ypx7KtJhJpq tOozFkj38oVY0zG Af2X0DINkfo9dLa 5h0fcma7MM4x61S fhExzbnHczNmwPJ yHWI8grOXXpHd7v 8FaNDJ9RU4xn76m AJmSblFOdwvdIla tIRMYhk3fh35KzY 3T4TgJ2pb9me9Lu ENDOXPvhVifQBAX RZkGd0S8PbV9lFv 0DfXE0xFsVVpBEj . END KEYBASE SALTPACK SIGNED MESSAGE.

  • @nkuba:
    BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkUgHswq LONGnytauGuQ68W zKcm0YTewHXEGd3 2M8FiSegAUguFXL HuCjhrwR40ibok5 5xIW1NdCghSbFpo 6p3HmGzvwoiENnL LqnyQn0TaWdPNb6 vvC9enaELCZ8800 CQZ2Dlkgwnt55Z1 SrKBPcNMUYfViXu NSPEHFzWtW4uG1P fzi5Z2PE0EP0KJ7 bTBFX0S8PbV9lFv 0DfXE0xFsVVpBEj . END KEYBASE SALTPACK SIGNED MESSAGE.

Finally, note that the full set of work that went into the 1.2.1 version can be found in the corresponding v1.2.1 milestone.

Assets 2
Loading