Lockness Vesting - Audit Report
Lockness is building a new protocol that can be used to vest BEP-20 tokens to users after a certain time period.
We reviewed the Vesting contract at 0x20971F00e1895a656B5a115b7b2AC5156110Ade9 on the Binance Smart Chain mainnet.
We previously reviewed the project team's token contract here.
Notes on the Contract:
Audit Findings Summary
- The contract allows the team to time-lock tokens and have them release to up to 25 specified users after a certain time period.
- Each user is assigned to one of three sale types by the owner that dictates the initial number of tokens a user can claim, the remaining number of tokens a user can claim, and the date of when a user can begin claiming those remaining tokens.
- Users can claim their initial number of tokens at any time. If a user's sale type is 1, their initial number of tokens is 5% of the total tokens due to them. If a user's sale type is 2, their initial number of tokens is 10% of the total tokens due to them. If a user's sale type is 3, their initial number of tokens is 30% of the total tokens due to them.
- Each of the three sale types also has a lock end date assigned to them. A user can begin to claim their remaining tokens after the lock end date associated with their sale type has passed. If a user's sale type is 1, their tokens will begin to unlock after April 17th, 2022. If a user's sale type is 2 or 3, their tokens will begin to unlock after February 16th, 2022.
- If a user's sale type is 1 or 2, all of their remaining tokens can be claimed 270 days after the lock end date has passed. If a user's sale type is 3, all of their remaining tokens can be claimed 90 days after the lock end date has passed.
- The team is responsible for supplying the Vesting contract with a sufficient amount of tokens in order for the contract to properly pay out users.
- The owner can update the token that is paid to users when claiming their vested tokens.
- The owner can update the amount of time since a user's lock end date has passed that determines when a user can claim all of their remaining tokens.
- The owner can withdraw any BNB or BEP-20 tokens from the contract address at any time.
- Although the SafeMath library is utilized, the contract is implemented with Solidity v0.8.7 which has built-in overflow checks. SafeMath could be safely removed to reduce contract size and deployment costs.
- Some gas optimizations can be achieved through declaring functions external instead of public. As the contract is already deployed, this is merely informational.
- No external threats were identified.
- Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
- Date: January 13th, 2022
- Updated: January 17th, 2022 to reflect the contract's newly deployed mainnet address.
|Arbitrary Storage Write||N/A||PASS|
|Centralization of Control||WARNING|
|Delegate Call to Untrusted Contract||N/A||PASS|
|Dependence on Predictable Variables||N/A||PASS|
|State Change External Calls||N/A||PASS|
|User Supplied Assertion||N/A||PASS|
|Critical Solidity Compiler||N/A||PASS|
|Overall Contract Safety||PASS|
($) = payable function # = non-constant function + [Int] IERC20 - [Ext] totalSupply - [Ext] balanceOf - [Ext] transfer # - [Ext] allowance - [Ext] approve # - [Ext] transferFrom # + [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 + Vesting - [Ext]
($) - [Pub] # - [Pub] extractBNB # - modifiers: onlyOwner - [Pub] getInvestorDetails - [Pub] getContractTokenBalance - [Pub] transferToken # - modifiers: onlyOwner - [Pub] setTokenAddress # - modifiers: onlyOwner - [Pub] setStartDate # - modifiers: onlyOwner - [Pub] addInvestorDetails # - modifiers: onlyOwner - [Pub] withdrawTokens #