<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

# Decentralization Efforts 


## Description	

In the contract `LottoAdmin` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoAdmin-LottoAdmin-_owner.svg)


In the contract `LottoAdmin` the role `executor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoAdmin-LottoAdmin-executor.svg)


In the contract `LottoAdmin` the role `owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoAdmin-LottoAdmin-owner.svg)


In the contract `LottoAdmin` the role `pendingExecutor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoAdmin-LottoAdmin-pendingExecutor.svg)


In the contract `LottoAdmin` the role `pendingOwner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoAdmin-LottoAdmin-pendingOwner.svg)


In the contract `LottoCore` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoCore-LottoCore-_owner.svg)


In the contract `LottoCore` the role `executor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoCore-LottoCore-executor.svg)


In the contract `LottoCore` the role `owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/449a22f7dcec47408fdfce6e97d9e55f/diagrams/centralization_LottoCore-LottoCore-owner.svg)

---

In the latest commit of the codebase [f69ba461ac71aec33cc3a7c944fea647358c1d00](https://github.com/yearntogether/platform-contracts/tree/f69ba461ac71aec33cc3a7c944fea647358c1d00), the above privileged roles and functions have been updated as below:


In the contract `PlatformAdmin` the role `executor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformAdmin-PlatformAdmin-executor.svg)


In the contract `PlatformAdmin` the role `owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformAdmin-PlatformAdmin-owner.svg)


In the contract `PlatformAdmin` the role `pendingExecutor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformAdmin-PlatformAdmin-pendingExecutor.svg)


In the contract `PlatformAdmin` the role `pendingOwner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformAdmin-PlatformAdmin-pendingOwner.svg)

In the contract `PlatformCore` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformCore-PlatformCore-_owner.svg)


In the contract `PlatformCore` the role `executor` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformCore-PlatformCore-executor.svg)


In the contract `PlatformCore` the role `owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/31a63f9a4a094c5cac391ff307674739/diagrams/centralization_PlatformCore-PlatformCore-owner.svg)


Any compromise to the privileged account may allow the hacker to take advantage of this authority:

In `PlatformAdmin` contract:

- `_withdrawLiquidityFunds`: allows the owner to withdraw liquidity funds from the contract, with onlyOwner privilege
- `_withdrawExchangeListingFunds`: allows the owner to withdraw exchange listing funds from the contract, with onlyOwner privilege
- `_withdrawCharityFunds`: allows the owner to withdraw charity funds from the contract, with onlyOwner privilege
- `_withdrawMarketingFunds`: allows the owner to withdraw marketing funds from the contract, with onlyOwner privilege
- `isOwnerClaimActive`: returns whether the owner claim is active, with public visibility
- `_withdrawFunds`: allows the owner to withdraw the remaining funds from the contract after all draws are ended, with onlyOwner privilege
- `_withdrawYearnTokens`: allows the owner to withdraw the remaining yearn tokens from the contract after all draws are ended, with onlyOwner privilege
- `_updateFreeUserReferralBonusesPercentage`: allows the owner to update free user referral bonus percentages, with onlyOwner privilege
- `_updateFreeUserDrawBonusPercentage`: allows the owner to update the free user draw bonus percentage, with onlyOwner privilege
- `addToWhitelist`: allows the executor to add users to the whitelist, with onlyExecutor privilege
- `removeFromWhitelist`: allows the executor to remove users from the whitelist, with onlyExecutor privilege
- `_changeDrawStatus`: allows the owner to pause or resume the draw to update administrator features, with onlyOwner privilege
- `_updateYearnTokenAddress`: allows the owner to change the ytg token address, with onlyOwner privilege
- `_updateCallbackGasLimit`: allows the owner to update the callback gas limit, with onlyOwner privilege
- `enableTokenWithdrawal`: allows the owner to enable/disable token withdrawal with specified percentage and duration, with onlyOwner privilege
- `_updateUnitAddresses`: allows the owner to update all unit addresses, with onlyOwner privilege
- `_updateReferralPoolAddress`: allows the owner to update the referral pool address, with onlyOwner privilege
- `_setPendingOwner`: allows the owner to set a new pending owner, with onlyOwner privilege
- `_acceptOwner`: allows the new pending owner to accept the transfer of ownership, with public visibility
- `_setPendingExecutor`: allows the owner to set a new pending executor, with onlyOwner privilege
- `_acceptExecutor`: allows the new pending executor to accept the transfer of executorship, with public visibility

- 

In `PlatformCore` contract:

- `_initiateDraw`: Owner start the initial the draw, with onlyOwner privilege
- `_startNextDraw`: Executor start the next draw, with onlyExecutor privilege
- `pickDrawWinner`: Executor pick the draw winner, and based on the draw, 10k and 100k draw are calculated, with onlyExecutor privilege
- `pick10KDrawWinner`: Calculate 10k draw winner, with onlyExecutor privilege
- `pick100KDrawWinner`: Calculate 100k draw winner, with onlyExecutor privilege
- `processDrawWinner`: Executor process the draw winner of 1k, 10k and 100k draw, with onlyExecutor privilege
- `processDrawReferralPayout`: Executor process the draw referral payout of 1k, 10k and 100k draw, with onlyExecutor privilege
- `transfer1kTop10RererralBonus`: Owner process top 10 1K draw referral bonus, with onlyExecutor privilege
- `transfer100kTop10RererralBonus`: Owner process top 10 global 100K draw referral bonus, with onlyOwner privilege




Centralization Risks 

When transferring deflationary ERC20 tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user sends 100 deflationary tokens (with a 10% transaction fee), only 90 tokens actually arrived to the contract. However, a failure to discount such fees may allow the same user to withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction.

Reference:
https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

```solidity=23
        tokenAddress.safeTransfer(liquidityAddress, amount);
```
- Transferring tokens by `amount`.

```solidity=21
        liqidityFunds -= amount;
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=35
        tokenAddress.safeTransfer(exchangeListingAddress, amount);
```
- Transferring tokens by `amount`.

```solidity=33
        exchangeListingFunds -= amount;
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=47
        tokenAddress.safeTransfer(charityAddress, amount);
```
- Transferring tokens by `amount`.

```solidity=45
        charityFunds -= amount;
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=59
        tokenAddress.safeTransfer(marketingChannelAddress, amount);
```
- Transferring tokens by `amount`.

```solidity=57
        marketingFunds -= amount;
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=230
        tokenAddress.safeTransferFrom(msg.sender, address(this), amount);
```
- Transferring tokens by `amount`.

```solidity=237
        uint256 drawAmount = amount - (draws[_draw].fee * numberOfTickets);
```
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=292
        depositInternal(currentDraw, _referrer, amount);
```
- Transferring tokens by `amount`.
- This function call executes the following operation.
- In `LottoCore.depositInternal`,
    - `tokenAddress.safeTransferFrom(msg.sender, address(this), amount);`

```solidity=292
        depositInternal(currentDraw, _referrer, amount);
```
- This function call executes the following operation.
- In `LottoCore.depositInternal`,
    - `uint256 drawAmount = amount - (draws[_draw].fee * numberOfTickets);`
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.


---
```solidity=308
        depositInternal(currentDraw, _referrer, amount);
```
- Transferring tokens by `amount`.
- This function call executes the following operation.
- In `LottoCore.depositInternal`,
    - `tokenAddress.safeTransferFrom(msg.sender, address(this), amount);`

```solidity=308
        depositInternal(currentDraw, _referrer, amount);
```
- This function call executes the following operation.
- In `LottoCore.depositInternal`,
    - `uint256 drawAmount = amount - (draws[_draw].fee * numberOfTickets);`
- The `amount` appears to be used for bookkeeping purposes without compensating the potential transfer fees.



Incompatibility with Deflationary Tokens

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

```solidity=159
        platformAddress = _platformAddress;
```
- `_platformAddress` is not zero-checked before being used.


---
```solidity=160
        liquidityAddress = _liquidityAddress;
```
- `_liquidityAddress` is not zero-checked before being used.


---
```solidity=161
        marketingAddress = _marketingAddress;
```
- `_marketingAddress` is not zero-checked before being used.


---
```solidity=162
        ecoSystemAddress = _ecoSystemAddress;
```
- `_ecoSystemAddress` is not zero-checked before being used.


---
```solidity=163
        exchangeListingAddress = _exchangeListingAddress;
```
- `_exchangeListingAddress` is not zero-checked before being used.


---
```solidity=164
        charityAddress = _charityAddress;
```
- `_charityAddress` is not zero-checked before being used.


---
```solidity=165
        marketingChannelAddress = _marketingChannelAddress;
```
- `_marketingChannelAddress` is not zero-checked before being used.


---
```solidity=169
        referralPoolAddress = _referralPoolAddress;
```
- `_referralPoolAddress` is not zero-checked before being used.


---
```solidity=180
        pendingOwner = newPendingOwner;
```
- `newPendingOwner` is not zero-checked before being used.


---
```solidity=206
        pendingExecutor = newPendingExecutor;
```
- `newPendingExecutor` is not zero-checked before being used.



Missing Zero Address Validation

In the statement `uint40(block.timestamp);`, it casts a `uint256` value to an `uint40` without evaluating its bounds.

Unsafe Cast

```solidity=187
function _acceptOwner() external {
    // Check caller is pendingOwner and pendingOwner ≠ address(0)
    require(msg.sender == pendingOwner);
    require(msg.sender != address(0));

    // Store owner with value pendingOwner
    owner = pendingOwner;

    // Clear the pending value
    pendingOwner = address(0);
}
```

In above code snippet, the line `require(msg.sender == pendingOwner);` already checks if `msg.sender` is equal to pendingOwner, which means that `msg.sender` cannot be equal to `address(0)` (which represents the null address) because `pendingOwner` is also not equal to `address(0)`.

In other words, the line `require(msg.sender == pendingOwner);` already ensures that `msg.sender` is a valid address and not equal to the null address. Therefore, there is no need to include the additional check `require(msg.sender != address(0));` in the code.


A similar optimization chance happens in `_acceptExecutor()` function

Redundant Validation

State variables that never change should be declared as `constant` to save gas.

```solidity=109
    bytes32 keyHash = 0x4b09e658ed251bcafeebbc69400383d49f344ace09b9576fe248bb02c003fe9f;
```
- `keyHash` should be declared `constant`.


---
```solidity=120
    uint16 requestConfirmations = 3;
```
- `requestConfirmations` should be declared `constant`.


---
```solidity=124
    uint32 numWords = 1;
```
- `numWords` should be declared `constant`.


---
```solidity=198
    uint8 public EXTRA_BONUS_PURCHASE_REWARDS = 5;          // whitelisted user get extra 5% bonus token on top of purchase bonus
```
- `EXTRA_BONUS_PURCHASE_REWARDS` should be declared `constant`.



State Variable Should Be Declared Constant

```solidity=405
                tokenAddress.safeTransfer(referrer, bonus);
```

In the function `_drawReferralPayout()`, a certain amount of token will be transferred to `referrer` as a bonus. However there's validation to check if `bonus` is 0.  Bonus with a value of 0 will still be transferred to the referrer, which may result in unnecessary gas fees and token transfers.

Missing Validation

In function `_setReferrer()` there's no validation to check if `_referrer` could be `msg.sender` address itself. This may potentially violate the design.

Lack Of self-reference Check in the `_setReferrer()`

There are two functions, `claimToken()` and `claimAmount()` allows the user to withdraw `YTG` token and `USDT` token under certain conditions. The user will always select the most beneficial token to withdraw. If at the early stage, the price of `YTG` token is less than the price of `USDT`, then the user will withdraw `USDT` and depreciate the `YTG` token, which will also potentially drain the deposited `USDT` tokens in the LottoCore deployment

Meanwhile, `claimAmount()` has less validations comparing to `claimToken()`, which leads the user could favor withdrawing USDT compared to waiting `claimToken()` to be enabled. 


User Can Favor USDT and Depreciate YTG token

Yearn Together

LottoAdmin.sol

LottoCore.sol

LottoStorage.sol

The world's first ever gaming-enabled IDO

Revolutionize fundraising with our decentralized platform powered by web3. Join a global community for a gaming-style, community-driven process that's transparent, rewarding, and like nothing you've experienced before.

Leaderboards

Due Diligence Tools

Resources

KYC Status