Open hats-bug-reporter[bot] opened 1 month ago
Thank you for your submission. Just like issue #27 . The minimum stake requirement is not meant to force users to have more than that; it's meant for bonding more than that, and it works as intended.
Thanks for your reply, however, when staking into vault, the user must actually have the amount of gas token to be staked > minimum_stake. I'm talking about the scenario when the user's next stake getting blocked by minimum_stake validation. Although if you add the current stake amount with the previous stake amount, it would be larger than the minimum_stake. Can you check this again?
@sonny2k
The minimum stake that can go through a nomination pool is 10 AZERO.
Because of this, the contract checks if azero < self.data.minimum_stake {return Err(VaultError::MinimumStake);}
.
It's not important how much is user's staked amount. Each time the user wants to stake, it must be bigger than 10 AZERO.
each time a user stakes, this amount goes through a nomination pool, so it must be bigger than minimum_stake
.
I remember that nominations pool in Aleph Zero allows bond_extra for example, what if user A 1st stake is 10 $AZERO, and 5 minutes later he wants to add 5 more $AZERO. But it fails since the 2nd stake amount is < minimum_stake which is 10. If this is not the case then why the protocol has a function which compounds rewards to the current stake amount, regardless of the fact that the rewards could be smaller than minimum_stake? It's because the current stake already satisfies the minimum_stake validation, just like my case, where user A's 1st stake has already satisfied the minimum_stake validation.
@sonny2k
Consider the following scenario:
The owner added 1 nomination agent. User A stake 20 AZERO.
After some time, a new nomination agent was added.
If this is your case and the user satisfies the minimum_stake
, the user can stake below that, but the transaction reverts as the new pool hasn't joined yet.
So it's better to always check for this stake amount. Each time It must be bigger than a minimum_stake
.
All users are considered the same as some agents, so it's not about each user's stake amount, it's about the agent's stake amount. As always we could have new agents, and we could withdraw and join again, it's better to check it each time.
However, if you think i missed something, please comment again.
@sonny2k The minimum stake for each stake within our protocol is always 10 AZERO. The reason being, that the minimum bond for a nomination pool is 10 AZERO and we don't check balance on a nomination pool. Its easier to just enforce the minimum at all times to meet network limitations. @0xmahdirostami hit the nail right on the head with this explanation
@sonny2k
Consider the following scenario:
The owner added 1 nomination agent. User A stake 20 AZERO.
After some time, a new nomination agent was added. If this is your case and the user satisfies the
minimum_stake
, the user can stake below that, but the transaction reverts as the new pool hasn't joined yet.So it's better to always check for this stake amount. Each time It must be bigger than a
minimum_stake
.All users are considered the same as some agents, so it's not about each user's stake amount, it's about the agent's stake amount. As always we could have new agents, and we could withdraw and join again, it's better to check it each time.
However, if you think i missed something, please comment again.
Github username: @sonny2k Twitter username: 0xNGOC Submission hash (on-chain): 0xbbd69410245515d489ddc431d824447c4905ea245650f466b592f1fb9029c469 Severity: medium
Description: Description\ In vault/lib.rs, there is a validation that the stake amount must be larger than
minimum_stake
. However, when the user decides to stake an additional amount adding up to the previous stake amount, if the second stake amount is lesser thanminimum_stake
, the call will be reverted. Although the total stake the user wants to make is larger than theminimum_stake
itself.Attack Scenario\ As the Aleph Zero's documents states:
Suppose Alice wants to stake
500
$AZERO and theminimum_stake
value is100
, but for now, she only has450
$AZERO remaining in the wallet and she decides to stake it anyway. After 5-10 minutes, she realizes that she also has like50
$AZERO left on the CEX for example, and wants to stake that amount adding to the original amount. However, her tx is reverted as the second amount is <minimum_stake
(50 < 100).Impact\ The user has to wait for 14 days or more to stake the whole amount, although it should have been able to stake the additional amount within the era when the user first stakes.
Attachments
Proof of Concept (PoC) File Add this test case into
drink_tests/lib.rs
to see how the transaction panics when Alice stakes the second time:Revised Code File (Optional)\ Consider adding a variable to store the user's total stake amount and comparing that with the
minimum_stake
to avoid preventing the user ability to add stake multiple times ( because the total stake amount satisfies theminimum_stake
validation).