WePad

Smart Contract Audit Report

Audit Summary

WePad is building a new IDO launchpad which is part of the WeWay Ecosystem. WePad aims to be positioned as one of the most transparent and community-driven IDO launchpads in the space.

For this audit, we reviewed the project team's KYCregistry, TierSystemManual, and Tokensale contracts at commit 799acd8114ff255013e83151213b4016d1977b9e on the team's GitHub repository.

We previously reviewed the project team's staking contract here.

Audit Findings

No findings were identified.
Date: July 1st, 2022.

Contracts Overview

KYCregistry Contract:

• The owner can use this contract to add/remove any address from the KYC Registry list.
• Addresses added to the KYC Registry list can participate in the team's IDO.

TierSystemManual Contract:

• The owner can use this contract to allocate a BUSD amount to any number of users for the Tokensale contract.

Tokensale Contract:

• Upon deployment, the owner will set the start time, end time, token address, number of tokens for sale, Maximum BUSD cap, Timelock value, and vesting duration.
• The sale will begin when the team deposits the total number of tokens for sale into the contract. The caller must grant the contract an approval in order for this transaction to successfully occur.
• Any user can initiate a purchase once the start time of the contract has passed by specifying an amount of BUSD.
• The user must have been added to the KYC Registry list by the team in the KYCregistry contract in order to purchase tokens.
• The amount of supplied BUSD cannot exceed the total allocation value set by the owner in the TierSystemManual contract for the user.
• The BUSD supplied by the user is transferred to the contract. The caller must grant the contract an approval in order for this transaction to successfully occur.
• The number of tokens due to the user is based on the token price of the contract. The token price is calculated based on the proportion of total tokens for sale to the maximum BUSD cap value set by the deployer.
• The sale will be finished when the total number of sold tokens reaches the total number of tokens for sale.
• If the end time of the sale has passed and all of the tokens have not been sold, the owner can start the bonus round.
• During the bonus round, the total BUSD allocation for each user is increased by a value set by the owner.
• The bonus round (and the sale) will conclude when all of the tokens have been sold.
• When the sale ends, the vesting start time will be set to the sale end time plus the Timelock value set by the deployer.
• Any user can begin releasing the tokens that are due to them once the vesting start time has passed.
• The user will receive 100% of the tokens after the vesting duration time has passed.
• If the full vesting duration time has not passed and the user releases tokens, the number of tokens the user will receive is proportional to the amount of time that has passed in the vesting schedule and the withdraw interval set by the deployer.
• The owner can withdraw any tokens from the contract at any time.
• The owner can pause the contract at any time which disables all purchases.

Audit Results

KYCregistry Contract

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public
 
 +  Context 
    - [Int] _msgSender
    - [Int] _msgData

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

 +  KYCRegistry (Ownable)
    - [Prv] setAcceptStatus #
    - [Pub] setAcceptStatuses #
       - modifiers: onlyOwner

TierSystemManual Contract

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public
 
 +  Context 
    - [Int] _msgSender
    - [Int] _msgData

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

 +  TierSystemManual (Ownable)
    - [Pub] setupAllocations #
       - modifiers: onlyOwner
    - [Pub] getAllocation

Tokensale Contract

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public
 
 +  Context 
    - [Int] _msgSender
    - [Int] _msgData

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

 + [Int] IERC20 
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

 +  Pausable (Context)
    - [Pub]  #
    - [Pub] paused
    - [Int] _requireNotPaused
    - [Int] _requirePaused
    - [Int] _pause #
       - modifiers: whenNotPaused
    - [Int] _unpause #
       - modifiers: whenPaused

 + [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] verifyCallResultFromTarget
    - [Int] verifyCallResult
    - [Prv] _revert

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

 +  TierSystem 
    - [Pub] getAllocation

 +  IKYCRegistry 

 +  Tokensale (Ownable, Pausable)
    - [Pub]  #
    - [Pub] getTokenPrice
    - [Pub] getAllocation
    - [Pub] getAvailableParticipateAmount
    - [Pub] depositTokens #
    - [Pub] emergencyWithdrawTokens #
       - modifiers: onlyOwner
    - [Pub] startBonusRound #
       - modifiers: onlyOwner
    - [Pub] pause #
       - modifiers: onlyOwner
    - [Pub] unpause #
       - modifiers: onlyOwner
    - [Pub] participate #
       - modifiers: whenNotPaused
    - [Pub] getStatus
    - [Int] _startVesting #
    - [Int] _finish #
    - [Int] _vestingSchedule
    - [Pub] vestedAmount
    - [Pub] release #

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.

• Go Home