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

Discrepancy in Token Allocation for IDO #58

Open
hats-bug-reporter bot opened this issue Jan 28, 2025 · 1 comment · May be fixed by #149
Open

Discrepancy in Token Allocation for IDO #58

hats-bug-reporter bot opened this issue Jan 28, 2025 · 1 comment · May be fixed by #149
Labels

Comments

@hats-bug-reporter
Copy link

Github username: --
Twitter username: --
HATS Profile: HATS Profile

Beneficiary: 0x88cBcd44a23Dc16dF47f144f6f6E111DB7433b71
Submission hash (on-chain): 0x8b8c0c3867c4b84ce17ad0ee1ee4beaea1bbad885ae1eaf030db721d5dc5b9ba
Severity: medium

Description:
Description
As per the DAOSIS documentation, 55% of the token supply should be allocated to the IDO. However, the implementation in the MasterFastIDO and MasterNormalIDO contracts sends only 45% of the token supply to the IDO. This discrepancy deviates from the intended goal outlined in the protocol's documentation.

Impact
This issue misaligns with the protocol's stated objectives, leading to incorrect token distribution and potential loss of trust from the community and investors.

Instance
Present in the constructor of both the contract:

        if (!feesInToken) {
@>            adminAmount = (tokenParams.tokenSupply * 55) / 100;
@>            idoAmount = tokenParams.tokenSupply - adminAmount;
            (bool success, ) = feeReceiver.call{value: deploymentFee}("");
            require(success, "Fee transfer failed!");
        } else {
@>            adminAmount = (tokenParams.tokenSupply * 54) / 100;
            feeAmount = (tokenParams.tokenSupply * 1) / 100;
@>            idoAmount = tokenParams.tokenSupply - (adminAmount + feeAmount);
        }
        token.transfer(
            admin,
            adminAmount * 10**uint256(tokenParams.tokenDecimal)
        );

Fix
Add this in the contructor of both the contract:

        if (!feesInToken) {
++            idoAmount = (tokenParams.tokenSupply * 55) / 100;
++            adminAmount = tokenParams.tokenSupply - idoAmount ;
--            adminAmount = (tokenParams.tokenSupply * 55) / 100;
--            idoAmount = tokenParams.tokenSupply - adminAmount;
            (bool success, ) = feeReceiver.call{value: deploymentFee}("");
            require(success, "Fee transfer failed!");
        } else {
++           idoAmount = (tokenParams.tokenSupply * 55) / 100;
            feeAmount = (tokenParams.tokenSupply * 1) / 100;
++            adminAmount = tokenParams.tokenSupply - (idoAmount + feeAmount);
--           adminAmount = (tokenParams.tokenSupply * 54) / 100;
            feeAmount = (tokenParams.tokenSupply * 1) / 100;
--            idoAmount = tokenParams.tokenSupply - (adminAmount + feeAmount);
        }
        token.transfer(
            admin,
            adminAmount * 10**uint256(tokenParams.tokenDecimal)
        );
@vishal-develop-web
Copy link
Collaborator

Yes, you are correct, but this is not a vulnerability. We are sending the supply to the admin, who can transfer remaining tokens to the contract at any time. However, we can address this and implement a fix.

hats-bug-reporter bot added a commit that referenced this issue Feb 10, 2025
hats-bug-reporter bot added a commit that referenced this issue Feb 10, 2025
@hats-bug-reporter hats-bug-reporter bot linked a pull request Feb 10, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants