Smart Contract Analysis Statement
Contract Analysis

The Token contract implements the Smart Props Solution (SPS) token initialization, fixed token supply distribution, dynamic transaction taxing (liquidity and marketplace taxes), and basic token burning mechanics. While the overall design correctly inherits and implements the OpenZeppelin ERC20 standard for core accounting, several critical areas require attention: the entire total supply is minted permissionlessly upfront to hardcoded externally owned accounts (EOAs) rather than governed protocol vaults; the taxation logic allows the owner to arbitrarily change tax percentages to any amount without limits; and the administrative controls can be updated in a single transaction with no timelock or DAO governance enforcement.

Ownership Privileges

The privileges within the contract are distributed across three roles: the Initial Recipients (who receive the entire supply upon deployment), the Owner (who governs the dynamic tax configuration), and End Users (who hold, transfer, and burn tokens).

Initial Recipients (Hardcoded in constructor)

• Upon deployment, the entire 600,000,000 SPS token supply is minted and distributed across five hardcoded wallet addresses representing the presale, staking, marketplace, DEX/CEX listings, and treasury reserves.
• Limitation: These accounts have no special on-chain administrative privileges after receiving the initial mint; they function purely as standard token holders.
• Critical Note: Because these receiving addresses are not strictly bound to timelock contracts or vesting schedules on-chain at the time of token deployment, the entire functional token supply is immediately liquid and reliant entirely on the off-chain trust and management of the keyholders.

Contract Owner (onlyOwner modifier)

• The owner can call setTaxes to arbitrarily change the liquidityTax and marketTax percentages at any point.
• The owner can call updateExcludedFromTaxMapping to whitelist specific addresses from paying transfer taxes.
• The owner can call updateLiquidityWallet and updateMarketWallet to instantly change the destination where all dynamically collected token taxes are routed during user transfers.
• The owner can call setEnableTax to globally toggle the transaction tax system on or off.
• Limitation: Cannot mint new tokens — the _mint function is strictly internal and is only executed once during the constructor phase. The supply is hard-capped.
• Limitation: Cannot freeze user wallets or directly pause the token contract via a global pause function (though setting taxes to 100% acts as a pseudo-pause for non-whitelisted users).
• Critical Note: All administrative actions (updating wallets, changing taxes) take effect immediately. There is no timelock, cooldown, or multisig voting enforcement natively built into the token contract itself.

End Users (Token Holders)

• Any user can transfer tokens natively, subject to the active liquidityTax and marketTax deductions if enableTaxing is set to true and their address is not whitelisted.
• Any user can call burn to permanently destroy their own tokens, progressively making the token deflationary and reducing the _totalSupply.
• Limitation: Users have no control or voting power over the tax rates applied to their transfers.
• Limitation: The contract automatically deducts taxes during the standard transfer and transferFrom flows, meaning users will receive slightly fewer tokens than the requested transfer amount unless explicitly excluded by the owner.

Note — This audit report consists of a security analysis of the Token.sol contract. This analysis did not include functional testing, unit testing, or simulation of token transfer mechanics under live network conditions. Furthermore, we only audited the mentioned contract associated with this project. Other contracts related to this project were not audited by our team. We recommend investors conduct their own research before engaging with the protocol.