Stax Token

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the Stax team, focusing on the comprehensive evaluation of the StaxToken and VestingContract contracts.

Our team conducted an initial security assessment from September 10th to September 12th, 2024. On September 13th, our team amended this report to reflect updates made to the contracts that resolve all Findings.

Stax is developing a new ERC-20 token that can be minted in exchange for ETH or SHIB. Minted tokens are automatically allocated to a vesting contract, where they are released to users over time according to a predefined vesting schedule.

Audit Scope

Name	Source Code	Visualized
StaxToken & VestingContract	`f157969`	Inheritance Chart. Function Graph.

Name	Address/Source Code	Visualized
StaxToken & VestingContract	`f157969`	Inheritance Chart. Function Graph.

Audit Findings

All findings have been resolved. In addition, minimal centralized aspects are present.

Finding #1	Staxtoken	LowResolved
Finding #1 - Staxtoken LowResolved
Description: The contract specifies a maximum supply of 1 billion tokens. However, this limit is not enforced within the airdrop(), addGroup(), and addShareholder() functions that can be called by the owner. Risk/Impact: The owner can use the above functions to mint tokens beyond the defined 1 billion token cap. Recommendation: The airdrop(), addGroup(), and addShareholder() functions should be modified to enforce the maximum supply cap, ensuring the total supply cannot exceed 1 billion tokens. Resolution: The team has implemented the above recommendation.
Finding #2	Staxtoken	LowResolved
Finding #2 - Staxtoken LowResolved
Description: The mint() function allows users to provide more ETH than the required `totalPrice` for minting tokens, but any excess ETH is not refunded to the caller. Risk/Impact: Users may unintentionally overpay in ETH, resulting in a loss of funds. Recommendation: The mint() function should be modified to transfer any excess ETH back to the caller. Resolution: The team has implemented the above recommendation.
Finding #3	StaxToken	InformationalResolved
Finding #3 - StaxToken InformationalResolved
Description: The `maxSupply` and `shibToken` state variables cannot be modified but are not declared constant. Recommendation: The above state variables could be declared constant for additional gas savings on each reference. Resolution: The team has declared the above state variables constant.
Finding #4	StaxToken & VestingContract	InformationalResolved
Finding #4 - StaxToken & VestingContract InformationalResolved
Description: The following state variables can only be set one time but are not declared immutable. `ethUsdtPriceFeed, shibEthPriceFeed, initialStaxAmount, initialVestingPeriod, staxTokenAddress` Recommendation: The above state variables could be declared immutable for additional gas savings on each reference. Resolution: The team has declared the above state variables immutable.

System Overview

Deployment & Tokenomics

The total supply of the token is initially set to zero upon deployment. The maximum supply of the token is set to 1 billion $STAX [1,000,000,000]. No burn functions are accessible on the platform. A new Vesting contract is created upon deployment representing the platform's private round contract.

Mint with ETH

Any user can initiate a mint transaction before the private listing period has ended by specifying the desired number of tokens to mint and providing an amount of ETH to cover the cost. The cost is calculated based on the token's price in USDT, which is then converted to ETH using an ETH/USDT Chainlink price feed contract. The specified number of tokens are minted to the platform's private round contract, and the caller is added as a shareholder.

Mint with SHIB

Any user can initiate a mint transaction before the private listing period has ended by specifying the desired number of tokens to mint. The cost in SHIB is calculated based on the token's price in USDT, which is first converted to ETH using an ETH/USDT Chainlink price feed, and then to SHIB using the SHIB/ETH Chainlink price feed. The SHIB cost amount is transferred from the caller to the contract. The caller must grant the contract a sufficient allowance for the transaction to successfully occur. The specified number of tokens are minted to the platform's private round contract, and the caller is added as a shareholder.

Private Listing End

The owner can end the private listing period at any time. After the private listing period ends, no further minting with ETH or SHIB is allowed. Any remaining unminted tokens, up to the maximum supply, will be minted to the designated vesting group contract and these tokens will be vested to an address specified by the owner.

Owner Minting

The owner can specify any number of tokens to mint to any address at any time.

Adding Groups

The owner can add new groups to the platform by specifying a list of shareholder addresses, corresponding values representing the maximum amount of tokens that can be allocated, and the initial vesting delay value (in months) before the shareholders can start claiming tokens. A new Vesting contract is created and the total maximum token value for all shareholders is minted to the Vesting contract.

Shareholder Claiming

Shareholders can claim vested tokens based on the time elapsed since the private listing period ended. Initially, 10% of their allocation becomes available after the initial vesting period, followed by an additional 10% unlocking each month until the full allocation is vested. Once the entire allocation is vested, any additional tokens added can be claimed immediately. The user's withdrawal balance is updated to reflect the total number of claimed tokens with each claim.

Ownership Controls

The owner can withdraw all of the ETH and SHIB from the StaxToken contract at any time. The owner can update the USDT price per STAX to any value at any time. The owner can manually add a shareholder to a specified vesting group contract at any time.

Vulnerability Analysis

Vulnerability Category	Notes	Result
Arbitrary Jump/Storage Write	N/A	PASS
Centralization of Control	The owner can mint any number of tokens up to the maximum supply cap to any address at any time.	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
Sybil Attack	N/A	PASS
Unbounded Loops	N/A	PASS
Unused Code	N/A	PASS
Overall Contract Safety		PASS

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 1800+ 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!
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!

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