Auto Mining Token

Smart Contract Audit Report

Audit Summary

Auto Mining Token Audit Report Auto Mining Token is building a new platform where $AMT holders can earn rewards in $BTCB.

For this audit, we reviewed the following contracts on the Binance Smart Chain Mainnet:

Audit Findings

All findings have been resolved, though some centralized aspects are present.
Date: June 17th, 2022.
Updated: September 6th, 2022 to reflect the project's newly deployed Mainnet addresses.

Finding #1 - marketvault - High (Resolved)

Description: In the charge() function, any user can pass in an arbitrary address representing the Master contract to drain the marketvault contract of its backingCoin balance. 
function charge(uint256 snapId, address master_) public{
	Master master = Master(master_);
	uint256 amount = master.charge(snapId);        
	backingCoin.transfer(msg.sender,amount);
}
Risk/Impact: A malicious contract that contains a charge() function can be passed in as the Master address that can return any arbitrary value in order to drain the contract of its backingCoin balance.
Recommendation: The team should disallow the user's ability to provide a Master address in the charge() function, and should instead create a function that allows the owner to set the address of the Master contract one time.
Resolution: The team has implemented the above recommendation.

Finding #2 - marketvault - Low (Resolved)

Description: In the backingWithdrawl() function, although an amount of tokens are calculated based on the fee percentage, both transfers of the backingCoin are sent to the caller of the function. 
function backingWithdrawl(uint256 amount) public {                     
	require(amount < amt.balanceOf(msg.sender), "not enought amt");
	amt.burnFrom(msg.sender, amount);
	uint256 backRate = getBackRate();
	backingCoin.transfer(msg.sender, (amount*(100-fee))/(backRate*100));     
	backingCoin.transfer(msg.sender,(amount*fee)/(backRate*100));           
}
Risk/Impact: A fee is not collected on backingWithdrawl() transactions.
Recommendation: The team should either remove the fee logic altogether for additional gas savings on each call, or modify the backingWithdrawl() function to fit their intended functionality.
Resolution: The team has modified the backingWithdrawl() function to transfer tokens to the Admin wallet.

Contracts Overview

  • As the contracts are implemented with Solidity v0.8.x, they are safe from any possible overflows/underflows.
AMT Contract:
  • The total supply of the token is currently 39,687,498 $AMT.
  • Ownership has been transferred to the Master contract.
  • The owner can mint any number of tokens to any address up to the maximum supply of 100 million tokens.
  • Any user can burn their own tokens to reduce the total supply.
  • Any user can burn tokens on behalf of another user if an allowance has been granted.
  • The contract utilizes ERC20Snapshot functionality to record the total supply and token balances of all holders at the time a snapshot is created.
  • The owner can create a snapshot at any time.
  • The contract complies with the BEP-20 token standard.
LIQUIDITYAMT Contract:
  • The total supply of the token is currently 7,035 $liqAMT.
  • 99.99% of the total supply is stored in an unverified token locking contract and will unlock in 2 years.
  • Ownership has been transferred to the Master contract.
  • The owner can use this contract to mint tokens to any specified address.
  • Any user can burn their own tokens to reduce the total supply.
  • Any user can burn tokens on behalf of another user if an allowance has been granted.
  • The contract utilizes ERC20Snapshot functionality to record the total supply and token balances of all holders at the time a snapshot is created.
  • The owner can create a snapshot at any time.
  • The contract complies with the BEP-20 token standard.
marketvault Contract:
  • Upon deployment, the AMT token, Backing coin, Buy coin, sell rate value, fee percentage, and admin wallet will be set by the team.
  • Any user can initiate a backing withdrawal transaction by entering an amount of their AMT tokens that will be burned. The user must grant the contract an allowance in order for this transaction to occur successfully.
  • In return, the user will be transferred an amount of the Backing coin based on the proportion of the total supply of AMT to the contract's current balance of the Backing coin.
  • A fee is charged and allocated to the team's Admin wallet on backing withdrawals.
  • Any user can initiate a buy transaction by entering an amount of the Buy coin that will be transferred to the Admin wallet. The user must grant the contract an allowance in order for this transaction to occur successfully.
  • In return, the user will be transferred an amount of AMT tokens based on the sell rate ratio set by the team.
  • The owner can initiate a charge transaction by entering a snapshot ID.
  • The owner will be transferred an amount of the Pay coin, set in the Master contract, based on the proportion of the tokens allocated to the charge fund and the contract's Master coin balance at the time of the snapshot to the difference between the total supply of the Master coin and the liquidity pool's Master coin balance.
Master Contract:
  • Upon deployment, the owner will set the Master coin, Pay coin, Buy coin, Liquidity token, and Vault address.
  • The team's Payer wallet can initiate a rent payment by entering an amount of the Pay coin and a vault participation percentage between 1-100.
  • A percentage of the Pay coin is sent to the Vault address based on the vault participation percentage.
  • The remaining tokens are sent to the contract where one portion of those tokens are allocated to Liquidity token holders as rewards and the remaining portion is allocated to AMT holders as rewards.
  • A snapshot is created in both the Master coin and Pay coin contracts at the time of a rent payment transaction. The owner of both token contracts must be the Master contract address in order for this transaction to successfully occur.
  • Any user can initiate a charge transaction by entering a snapshot ID. The user will receive an amount of Pay coin based on the proportion of the tokens allocated to the charge fund and the user's Master coin balance at the time of the snapshot to the difference between the total supply of the Master coin and the liquidity pool's Master coin balance.
  • Any user can initiate a liquidity charge transaction by entering a snapshot ID. The user will receive an amount of Pay coin based on the proportion of the tokens allocated to the liquidity fund and the contract's Liquidity Token balance at the time of the snapshot to the total supply of the Master coin at the time of the snapshot.
  • The owner can add liquidity one time to the Master coin and Buy coin liquidity pool by entering an amount of tokens for each coin. The owner must grant the contract an approval for each coin in order for this transaction to occur successfully.
  • Upon adding liquidity, a new liqLocker contract is created and the generated LP tokens will be locked in this contract.
  • A number of Liquidity tokens will also be minted to the newly created liqLocker contract at a 1:1 ratio to the number of generated LP tokens.
  • The owner can release the LP tokens at any time after the lock time has passed. Upon release, the LP tokens are sent to the Master contract and the Liquidity tokens are transferred to the owner.
  • Any user can initiate a liquidity charge transaction from the liqLocker contract by entering a snapshot ID. The contract will receive an amount of Pay coin based on the proportion of the tokens allocated to the liquidity fund and the contract's Liquidity Token balance at the time of the snapshot to the total supply of the Master coin at the time of the snapshot.
  • The full Pay coin balance of the contract is subsequently sent to the owner from the contract.
  • Any user can add liquidity to the Master coin and Pay coin liquidity pool by entering an amount of tokens for each coin. The user must grant the contract an approval for each coin in order for this transaction to occur successfully.
  • The LP tokens generated through this process are sent to the contract address.
  • Upon adding liquidity, the user is minted Liquidity tokens at a 1:1 ratio to the number of generated LP tokens.
  • Users can remove liquidity from the liquidity pool at any time by entering a token amount. The Master coin and Pay coin will be returned to the user for the amount passed in, and the user's Liquidity tokens will be burned at a 1:1 ratio. The user must grant the contract an allowance in order for this transaction to occur successfully.
  • The owner can mint any number of the Master coin to any address at any time.
  • The owner can grant an approval of any number of tokens to the Router address for the Buy coin and Master coin.
  • The owner can update the Payer wallet at any time.

Audit Results

Vulnerability Category Notes Result
Arbitrary Jump/Storage Write N/A PASS
Centralization of Control The team retains the ownership controls listed above. PASS
Compiler Issues N/A PASS
Delegate Call to Untrusted Contract N/A PASS
Dependence on Predictable Variables N/A PASS
Ether/Token Theft N/A PASS
Flash Loans N/A PASS
Front Running N/A PASS
Improper Events N/A PASS
Improper Authorization Scheme N/A PASS
Integer Over/Underflow N/A PASS
Logical Issues N/A PASS
Oracle Issues N/A PASS
Outdated Compiler Version N/A PASS
Race Conditions N/A PASS
Reentrancy N/A PASS
Signature Issues N/A PASS
Unbounded Loops N/A PASS
Unused Code N/A PASS
Overall Contract Safety   PASS

marketvault, Master, liqLocker, AMT and LIQUIDITYAMT Contracts

Smart Contract Audit - Inheritance

Smart Contract Audit - Graph


 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public
 
 + [Lib] SafeMath 
    - [Int] tryAdd
    - [Int] trySub
    - [Int] tryMul
    - [Int] tryDiv
    - [Int] tryMod
    - [Int] add
    - [Int] sub
    - [Int] mul
    - [Int] div
    - [Int] mod
    - [Int] sub
    - [Int] div
    - [Int] mod

 + [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

 +  ERC20 (Context, IERC20, IERC20Metadata)
    - [Pub]  #
    - [Pub] name
    - [Pub] symbol
    - [Pub] decimals
    - [Pub] totalSupply
    - [Pub] balanceOf
    - [Pub] transfer #
    - [Pub] allowance
    - [Pub] approve #
    - [Pub] transferFrom #
    - [Pub] increaseAllowance #
    - [Pub] decreaseAllowance #
    - [Int] _transfer #
    - [Int] _mint #
    - [Int] _burn #
    - [Int] _approve #
    - [Int] _spendAllowance #
    - [Int] _beforeTokenTransfer #
    - [Int] _afterTokenTransfer #

 + [Lib] Math 
    - [Int] max
    - [Int] min
    - [Int] average
    - [Int] ceilDiv
    - [Int] mulDiv
    - [Int] mulDiv
    - [Int] sqrt
    - [Int] sqrt

 + [Lib] Arrays 
    - [Int] findUpperBound

 + [Lib] Counters 
    - [Int] current
    - [Int] increment #
    - [Int] decrement #
    - [Int] reset #

 +  ERC20Snapshot (ERC20)
    - [Int] _snapshot #
    - [Int] _getCurrentSnapshotId
    - [Pub] balanceOfAt
    - [Pub] totalSupplyAt
    - [Int] _beforeTokenTransfer #
    - [Prv] _valueAt
    - [Prv] _updateAccountSnapshot #
    - [Prv] _updateTotalSupplySnapshot #
    - [Prv] _updateSnapshot #
    - [Prv] _lastSnapshotId

 +  Ownable (Context)
    - [Pub]  #
    - [Pub] owner
    - [Int] _checkOwner
    - [Pub] renounceOwnership #
       - modifiers: onlyOwner
    - [Pub] transferOwnership #
       - modifiers: onlyOwner
    - [Int] _transferOwnership #

 +  AMT (ERC20Snapshot, Ownable)
    - [Pub]  #
       - modifiers: ERC20
    - [Pub] mint #
       - modifiers: onlyOwner
    - [Pub] snapshot #
       - modifiers: onlyOwner
    - [Pub] getCurrentSnapshotId
    - [Pub] burn #
    - [Pub] burnFrom #

 + [Int] IUniswapV2Router01 
    - [Ext] factory
    - [Ext] WETH
    - [Ext] addLiquidity #
    - [Ext] addLiquidityETH ($)
    - [Ext] removeLiquidity #
    - [Ext] removeLiquidityETH #
    - [Ext] removeLiquidityWithPermit #
    - [Ext] removeLiquidityETHWithPermit #
    - [Ext] swapExactTokensForTokens #
    - [Ext] swapTokensForExactTokens #
    - [Ext] swapExactETHForTokens ($)
    - [Ext] swapTokensForExactETH #
    - [Ext] swapExactTokensForETH #
    - [Ext] swapETHForExactTokens ($)
    - [Ext] quote
    - [Ext] getAmountOut
    - [Ext] getAmountIn
    - [Ext] getAmountsOut
    - [Ext] getAmountsIn

 + [Int] IUniswapV2Router02 (IUniswapV2Router01)
    - [Ext] removeLiquidityETHSupportingFeeOnTransferTokens #
    - [Ext] removeLiquidityETHWithPermitSupportingFeeOnTransferTokens #
    - [Ext] swapExactTokensForTokensSupportingFeeOnTransferTokens #
    - [Ext] swapExactETHForTokensSupportingFeeOnTransferTokens ($)
    - [Ext] swapExactTokensForETHSupportingFeeOnTransferTokens #

 + [Int] IUniswapV2Factory 
    - [Ext] feeTo
    - [Ext] feeToSetter
    - [Ext] getPair
    - [Ext] allPairs
    - [Ext] allPairsLength
    - [Ext] createPair #
    - [Ext] setFeeTo #
    - [Ext] setFeeToSetter #

 +  LIQUIDITYAMT (ERC20Snapshot, Ownable)
    - [Pub]  #
       - modifiers: ERC20
    - [Pub] mint #
       - modifiers: onlyOwner
    - [Pub] snapshot #
       - modifiers: onlyOwner
    - [Pub] getCurrentSnapshotId
    - [Pub] burn #
    - [Pub] burnFrom #

 + [Int] IERC20Permit 
    - [Ext] permit #
    - [Ext] nonces
    - [Ext] DOMAIN_SEPARATOR

 + [Lib] Address 
    - [Int] isContract
    - [Int] sendValue #
    - [Int] functionCall #
    - [Int] functionCall #
    - [Int] functionCallWithValue #
    - [Int] functionCallWithValue #
    - [Int] functionStaticCall
    - [Int] functionStaticCall
    - [Int] functionDelegateCall #
    - [Int] functionDelegateCall #
    - [Int] verifyCallResult

 + [Lib] SafeERC20 
    - [Int] safeTransfer #
    - [Int] safeTransferFrom #
    - [Int] safeApprove #
    - [Int] safeIncreaseAllowance #
    - [Int] safeDecreaseAllowance #
    - [Int] safePermit #
    - [Prv] _callOptionalReturn #

 +  TokenTimelock 
    - [Pub]  #
    - [Pub] token
    - [Pub] beneficiary
    - [Pub] releaseTime
    - [Pub] release #

 +  liqLocker (TokenTimelock)
    - [Pub]  #
       - modifiers: TokenTimelock
    - [Pub] charge #
    - [Pub] release #

 +  Master (Ownable)
    - [Pub]  #
    - [Pub] addressLiquidityPool
    - [Pub] addressLiquidityLocker
    - [Pub] payRent #
       - modifiers: onlyOwner
    - [Pub] charge #
    - [Pub] liqCharge #
    - [Pub] addLiquidityLocking #
       - modifiers: onlyOwner
    - [Pub] addLiquidity #
    - [Pub] removeLiquidity #
    - [Pub] mintMaster #
       - modifiers: onlyOwner

 +  MARKETVAULT (Context)
    - [Pub]  #
    - [Pub] getBackRate
    - [Pub] backingWithdrawl #
    - [Pub] buy #
    - [Pub] charge #

About SourceHat

SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1300+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value across 1500 projects!.
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 SourceHat Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat 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.