Open hats-bug-reporter[bot] opened 1 month ago
I think this is better categorized as a low instead of a medium, since no funds or functionality is at risk. It cannot be abused to DOS and only applies when a new pool is first added to the protocol or a weight is set to >0
Minimum stake is supposed to be on the user not on the agents.
Agents are nominated by the admin.
@bgibers do you think this qualify for low..? isn't something as per design.
Minimum stake is supposed to be on the user not on the agents.
Agents are nominated by the admin.
@bgibers do you think this qualify for low..? isn't something as per design.
I believe @0xmahdirostami is right here, as per the proof of concept presented. We have discussed some solutions that will fix this issue as well as several others, related to Kintsu being the initial deposit per nomination pool
After final internal review of all issues this is deemed better as a medium
Github username: @0xmahdirostami Twitter username: 0xmahdirostami Submission hash (on-chain): 0x109b9c70352753d22fcdd5f5ccae2d8b22a9b8be3293ebcf259c396fbed7008e Severity: medium
Description: Description The minimum stake that can go through a nomination pool is 10 AZERO, and the
stake
function contract checks for this value as shown here. The issue is that this check should be done for each agent, not just the input stake amount.Impact The lack of this check can cause the
stake
function to fail, leading to a Denial of Service (DoS) scenario when staking amounts that are split between multiple agents fall below the minimum required stake for each agent.Proof of Concept (PoC), Scenario Each agent's bond amount is calculated in the
delegate_bonding
function. Consider the following scenario:CallRuntimeFailed
error because the amount each agent receives (5 AZERO) is below the minimum stake requirement.Revised Code File (Optional) Instead of checking the user's stake amount, find the lowest amount that will go to an agent and check that against the minimum stake.