Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Staking Contract #192

Closed
julio4 opened this issue May 26, 2024 · 7 comments · Fixed by #202
Closed

Feature: Staking Contract #192

julio4 opened this issue May 26, 2024 · 7 comments · Fixed by #202
Assignees

Comments

@julio4
Copy link
Member

julio4 commented May 26, 2024

Description

In this example, we want to create a smart contract that allows users to deposit a IERC20 stakingToken and earn rewards in the form of a IERC20 rewardToken. The contract will track user balances, and participants will be able to deposit and withdraw tokens at any time.

Rewards will be distributed based on the rewardRate, rewardPerToken, and finishAt variables, which are set during the contract's deployment. Users will be able to claim their rewards at any time.

Criteria:

  • Rewards must be allocated during the contract deployment
  • Emit specific events for deposit, withdrawal, and when the reward balance reaches zero
  • Include comprehensive tests
  • Deploy the contract on a testnet

Resources:

ODHack

To be eligible for additional rewards, be sure to review and follow the ODHack Common Guidelines and Contributing Guidelines.
Be sure to join the telegram group and introduce yourself.

@julio4 julio4 added the ODHack label May 26, 2024
@hudem1
Copy link
Contributor

hudem1 commented May 26, 2024

Hi @julio4,

I would like to work on this issue if possible !

I have been learning and experimenting with cairo and starknet as I have been more and more interested in those techs, and would love to contribute to the community and gain some hands-on experience by taking a shot at addressing this issue :)

@Oshioke-Salaki
Copy link

Please I would love to handle this issue

@julio4
Copy link
Member Author

julio4 commented May 26, 2024

I assigned @hudem1, good luck!

@Oshioke-Salaki
Copy link

@julio4 if there are more issues I would love to it.

@the-first-elder
Copy link
Contributor

I can do this

@hudem1
Copy link
Contributor

hudem1 commented May 28, 2024

@julio4, I think the rewardRate cannot be set in the constructor of the contract because we need to make sure the contract has indeed the reward amount (used for computing the rewardRate) in its rewardToken balance. And as we are in the constructor, the contract cannot have beforehand received reward tokens as we didn't know its address before.
So, should we do like https://solidity-by-example.org/defi/staking-rewards/, where the owner can add rewards and duration at anytime ? or maybe i could do something similar to the example but make sure the owner can set the rewards amount and duration only once ? (as you initially wanted the reward amount and duration to be set in the constructor)

@julio4
Copy link
Member Author

julio4 commented May 28, 2024

@julio4, I think the rewardRate cannot be set in the constructor of the contract because we need to make sure the contract has indeed the reward amount (used for computing the rewardRate) in its rewardToken balance. And as we are in the constructor, the contract cannot have beforehand received reward tokens as we didn't know its address before. So, should we do like https://solidity-by-example.org/defi/staking-rewards/, where the owner can add rewards and duration at anytime ? or maybe i could do something similar to the example but make sure the owner can set the rewards amount and duration only once ? (as you initially wanted the reward amount and duration to be set in the constructor)

To allow anyone to join and exit at any time while receiving their portion of the reward, we need to handle the "out of reward" scenario. It's a bit complex, because we need to ensure that everyone who deposited before the "out of reward" time can still withdraw their share at any time.

An alternative, simpler approach is to set a fixed reward with an end date. The reward rate will determine the distribution of shares, but users can only claim their rewards after the end date, based on: userShares / totalShares.

Feel free to adjust this if needed, but please ensure the mechanism is clearly explained!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants