Smart Contract Audit Report
INDDAIS is a new BEP-20 token on the Binance Smart Chain.
For this audit, we reviewed the project team's INDDAIS contract at 0x8a36F19cFb1B9b963A9bf664dd786Cc740EdC5D2 on the Binance Smart Chain Mainnet.
Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
Date: May 13th, 2022.
Finding #1 - INDDAIS - HighDescription: The INDDAIS contract contains buy/sell functionality via the contract address, but also allows users to buy/sell tokens via a liquidity pool.
Risk/Impact: Having a liquidity pool will create arbitrage opportunities for users to take advantage of the fact that they can interchangeably buy/sell tokens through both the contract and the liquidity pool.
Recommendation: The team should not add any liquidity to the existing liquidity pool or any other pool featuring the INIS token.
- The total supply of the token is currently 60 million $INIS [60,000,000].
- The owner can mint any number of tokens up to the initial supply cap of 60 million tokens when minting is enabled in the contract. Upon minting, 85% of the tokens are sent to the owner and 15% of the tokens are sent to the Promoter wallet.
- Minting can only be set to enabled when the total supply reaches 36 million tokens or less.
- Any user can burn their own tokens to reduce the total supply.
- Any user can burn tokens on another user's behalf if an allowance has been granted.
- Upon burning, the user will receive an amount of BNB in return based on the Burn rate of the contract (set by the team) if the contract holds a sufficient BNB balance.
- At the time of writing this report, there are 10 total token holders. The token allocation is as follows:
- 75% of the total supply belongs to the owner.
- 15% of the total supply belongs to the team's promoter wallet.
- 9.98% of the total supply belongs to the INDDAIS contract.
- 0.0018% of the total supply is in Pancakeswap liquidity.
- Of that liquidity, 99.9% of the LP tokens belong to the owner.
- The remaining six holders own a cumulative ~0.1% of the total supply.
- On all token transfers, if the contract's Sprinkle rate is set to any value greater than 0, the caller must own a sufficient number of tokens to cover the sum of the tokens they're attempting to transfer and the Sprinkle rate value.
- The tokens collected through the Sprinkle rate are removed from the total supply and added to the caller's total Sprinkle balance.
- The owner cannot directly transfer tokens from their own wallet, and the contract address cannot directly receive tokens on all token transfers.
- A Buy transaction is triggered every time the contract address receives BNB when the address providing the BNB is not the owner. During a Buy transaction:
- The user that provided the BNB to the contract will receive an amount of $INIS from the contract based on the contract's current CoinToken rate.
- The total Capital value will increase by 80% of the BNB value that was originally sent to the contract.
- 2% of the BNB sent to the contract will be allocated to the referral address if the caller has an associated referral address.
- The referral address must manually claim the BNB that is due to them and can do so at any time.
- Users can manually trigger a referral Buy transaction at any time by providing a referral address and a BNB value.
- Each user can initiate a Sell transaction once every 30 days by providing a specified number of $INIS tokens to transfer to the contract.
- The number of provided tokens must be less than 10% of the user's total bought balance.
- The user's bought balance must be greater than the user's total sell balance plus the number of provided tokens.
- During a Sell, the user that provided tokens to the contract will receive an amount of BNB from the contract based on the contract's current TokenCoin rate.
- The contract implements the ERC-1363 standard in order to support transfer-and-call and approve-and-call functionality.
- As the contract is deployed with Solidity v0.8.11, it is protected from overflows/underflows.
- The contract utilizes ReentrancyGuard to protect against reentrancy attacks in applicable functions.
- The owner can assign an address to a Manager role which can be used to maintain control over various role-restricted functions within the ecosystem.
- The Manager can decrease the CoinToken rate to a lower value at any time.
- The Manager can increase the TokenCoin rate to a higher value at any time.
- The Manager can increase the Burn rate to a higher value at any time.
- The owner can withdraw any tokens from the contract at any time.
- The owner can manually withdraw the total Capital value of BNB at any time.
- The owner can set the Sprinkle rate to any value less than 10 quadrillion.
- The owner can send tokens to the contract address when the contract's token balance reaches 1.2 million tokens or lower. The contract's token balance cannot exceed 6 million tokens after this transaction occurs.
|Arbitrary Jump/Storage Write||N/A||PASS|
|Centralization of Control||WARNING|
|Delegate Call to Untrusted Contract||N/A||PASS|
|Dependence on Predictable Variables||N/A||PASS|
|Improper Authorization Scheme||N/A||PASS|
|Outdated Compiler Version||N/A||PASS|
|Overall Contract Safety||PASS|
($) = payable function # = non-constant function Int = Internal Ext = External Pub = Public + [Int] IERC20 - [Ext] totalSupply - [Ext] balanceOf - [Ext] transfer # - [Ext] allowance - [Ext] approve # - [Ext] transferFrom # + [Int] IERC20Metadata (IERC20) - [Ext] name - [Ext] symbol - [Ext] decimals + Context - [Int] _msgSender - [Int] _msgData + ReentrancyGuard - [Pub]
# + ERC20 (ReentrancyGuard, Context, IERC20, IERC20Metadata) - [Pub] # - [Pub] name - [Pub] symbol - [Pub] decimals - [Pub] InitialSupply - [Pub] totalSupply - [Pub] totalSprinkle - [Pub] CirculatingSupply - [Pub] StockAdded - [Pub] TokenStock - [Pub] balanceOf - [Pub] mysprinkle - [Pub] TotalBought - [Pub] TotalSold - [Pub] Referrer - [Pub] RefCount - [Pub] SliceMade - [Pub] AssetBalance - [Pub] CapitalReserved - [Pub] BurnRate - [Pub] Coin2Token - [Pub] Token2Coin - [Pub] SprinkleRate - [Pub] transfer # - [Pub] allowance - [Pub] approve # - [Pub] transferFrom # - [Pub] increaseAllowance # - [Pub] decreaseAllowance # - [Int] _transfer # - [Int] _mint # - [Int] _burn # - [Int] _approve # - [Int] _spendAllowance # - [Int] buy # - modifiers: nonReentrant - [Pub] TransferReserve # - modifiers: nonReentrant - [Int] _TransferReserve # - [Pub] SliceTransfer # - modifiers: nonReentrant - [Pub] SupplyStock # - modifiers: nonReentrant - [Int] _SupplyStock # - [Pub] sell # - modifiers: nonReentrant - [Int] _sell # + ERC20Burnable (Context, ERC20) - [Pub] burn # - modifiers: nonReentrant - [Pub] burnFrom # - modifiers: nonReentrant + [Lib] Address - [Int] isContract + [Int] IERC165 - [Ext] supportsInterface + ERC165 (IERC165) - [Pub] supportsInterface + [Int] IERC1363 (IERC165, IERC20) - [Ext] transferAndCall # - [Ext] transferAndCall # - [Ext] transferFromAndCall # - [Ext] transferFromAndCall # - [Ext] approveAndCall # - [Ext] approveAndCall # + [Int] IERC1363Receiver - [Ext] onTransferReceived # + [Int] IERC1363Spender - [Ext] onApprovalReceived # + ERC1363 (ERC20, IERC1363, ERC165) - [Pub] supportsInterface - [Pub] transferAndCall # - [Pub] transferAndCall # - [Pub] transferFromAndCall # - [Pub] transferFromAndCall # - [Pub] approveAndCall # - [Pub] approveAndCall # - [Int] _checkAndCallTransfer # - [Int] _checkAndCallApprove # + Ownable (Context) - [Pub] owner - [Pub] manager - [Pub] promoter - [Pub] ChangeManager # - modifiers: onlyOwner + TokenRecover (Ownable) - [Pub] recoverERC20 # - modifiers: onlyOwner + ERC20Mintable (ReentrancyGuard, ERC20) - [Ext] mintingFinished - [Pub] mint # - modifiers: nonReentrant,canMint - [Ext] EnableMinting # - modifiers: canStart - [Int] _EnableMinting # + INDDAIS (ERC20Mintable, ERC20Burnable, ERC1363, TokenRecover) - [Pub] ($) - modifiers: ERC20 - [Pub] setCoinToken # - modifiers: nonReentrant,onlyManager - [Pub] setTokenCoin # - modifiers: nonReentrant,onlyManager - [Pub] setBurnRate # - modifiers: nonReentrant,onlyManager - [Pub] setSprinkleRate # - modifiers: nonReentrant,onlyOwner - [Int] _TransferReserve # - modifiers: onlyOwner - [Int] _SupplyStock # - modifiers: onlyOwner - [Int] _mint # - modifiers: onlyOwner - [Int] _EnableMinting # - modifiers: onlyOwner - [Ext] refbuy ($) - [Ext] ($) - [Ext] ($)
About Solidity Finance
Solidity Finance was founded in 2020 and quickly grew to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1000+ solidity smart contract audits covering all major project types and protocols, securing a total of over $10 billion U.S. dollars in on-chain value.
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!
Contact us today to get a free quote for a smart contract audit of your project!
What is a Solidity Audit?
Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A Solidity Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.
How Do I Interpret the Findings?
Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:
- High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
- Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
- Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
- Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.