Dexaran commented 6 years ago

@yograterol @RideSolo @yuriy77k

I'd like to discuss the details of further Cold Staking contract implementation here.

At the moment we have 3 proposed variants:

Overview

1. Dexaran's Cold Staking

The first implementation of the Cold Staking protocol. Every action (new staker, reward claim) has a direct impact on the state of the contract which makes the final reward highly unpredictable.

Reward is computed at the moment of the claiming. Contract does not preserve the history of "staking weights". Reward depend on actual contract state and contract balance, thus it is independent of monetary policy. However, reward depends on claiming order (those, who claim their rewards first, earn more).

Advantages: Has a working reference implementation.

Disadvantages: Each staker can affect others. Too unpredictable rewards.

2. Yuriy's Cold Staking

This implementation relies on TotalStakingWeight variable which preserves the info about how much balance should be allocated for stakers who did not claim their rewards yet.

Stakers cannot directly affect each other with their claims. Reward calculation is more predictable, reward only depend on the amount of staking CLO. The reward is independent of monetary policy.

Advantages: Better reward calculation

Requires more testing.

3. RideSolo's Cold Staking

Advanced reward calculation formula. However, this version is more complex compared to the previous one and it relies on hardcoded block reward variable. Therefore it depends on monetary policy and it will be necessary to update the contract with a hardfork at each monetary policy change. Also, it is not compatible with The First Stake proposal.

Advantages: Better reward calculation

Disadvantages: higher complexity, depend on monetary policy, incompatible with The First Stake

Implementation at Callisto Network

I'm in favor of implementing the (2) Yuriy's Cold Staking version. It can solve all pressing problems and the implementation is not overcomplicated.

I believe that it is necessary to take the following steps:

Deploy the contract at testnet, test it and make a final decision if it is ready or not.
Re-deploy the testnet and launch a testnet cold staking contract that will behave exactly like the final version (automatically receive block rewards, distribute staking rewards).
Perform a security audit.
Launch an official bug bounty.
(optional) Make final changes if necessary. If everything is fine then the contract is ready to be used. Update the whitepaper.

P.S.

I'm open to any suggestions. Any proposal, feedback, comments, constructive criticism is welcome!

RideSolo commented 6 years ago

@Dexaran I do think that it is better to set the withdrawal address to the actual Callisto Staking Reserve Address, it has less activity and our community will be able to check the withdrawn amount easily (of course I hope that it will be the last possible scenario).

Dexaran commented 6 years ago

I do think that it is better to set the withdrawal address to the actual Callisto Staking Reserve

Sounds reasonable.

Geo25rey commented 3 years ago

@Dexaran Sorry, I'm late to the party, but I'm curious to why a staking contract can't have funds added to it before the end of 27 days. Surely, there can be a way to allow a user to continuously add to their stake. Maybe allow each wallet to have multiple staking contracts that can start at different times?

Another solution would be allowing certain modifications (e.g. adding funds) of a staking contract and whenever there is such a modification, the round will be reset while adding on the portion of the staking contract that has already been established to the replacement staking contract. This assumes that the rounds are local to each staking contract.

EthereumCommonwealth / Roadmap