📎Tokenomics
This page is to provide transparency and a better understanding of the full CART tokenomics.
The CryptoCart Token (CART)
Contract Address - 0x60418Aab642a431ac4De5831358F034C54e7c956
Our contract address is currently only live on the Ethereum chain.
Maximum Supply - 1,000,000
Circulating Supply - X (To Update post launch). This will continuously decrease as our CryptoCart Vault continues to accumulate supply from token and platform volume.
Buy Tax - 0%
Sale Tax - 4%. This 4% is split into three different allocations.
2% goes towards the CryptoCart Vault. Buying supply from the open market and removing it from circulation.
0.5% goes towards development and team expansion to accelerate delivery of products.
1.5% goes towards marketing, expanding awareness and onboarding.
Team Tokens - 50,000. Since inception back in 2021, our team tokens have remained untouched and have not been required to cover any costs due to all developments being done in-house. https://etherscan.io/address/0xf5796eddcc7a1367faabb2717c35fe59eb5f030e
CryptoCart Vault - 70,000+. This will continuously increase with token and platform volume. For more information regarding how the CryptoCart works, please refer below. https://etherscan.io/address/0x15e54c22f4195142222ed7130521e9636ec3ccec
💰CryptoCart VaultToken Distribution
On the topic of tokenomics, we thought it would be good to touch on our current token distribution, and give a little insight to the top wallets.
Uniswap Liquidity Pool
CryptoCart Vault
Team Tokens
Wallets 4 - 10 are all community members that bought their tokens on the open market. As it stands right now, only 5 holders own above 2% of the supply, 6 holders own above 1% of the supply, and the rest is sub 1%. We have never had any type of investment from any VCs, nor do we have any token unlocks.
Update with Coingecko link once live
Token Security
Security is a journey, not a destination. We'll continue to prioritize it in everything we do. Ahead of launch, we conducted a pre-audit of our contract to ensure all functionality operates exactly as intended and remains fully aligned with our migration paper and published tokenomics. This review was completed using Hashlock’s AI-powered audit tools, which systematically analyze smart contracts, flag potential vulnerabilities, and provide security recommendations based on industry best practices.
As with most automated audit systems, the tool flags all theoretical risks, including edge cases and worst-case scenarios. Some findings are precautionary in nature or assume conditions that do not apply to our contract’s structure (such as smart contract treasury wallets). Below you can find the full audit report, along with clear explanations of the flagged items, why certain functions exist, and why they are being retained as part of the intended design.
Full audit report:
https://aiaudit.hashlock.com/audit/0a5a3f10-2758-4015-8435-6133ccb70414
Below you can find some clear explanations of the flagged items, why certain functions exist, and why they are being retained as part of the intended design.
Critical – Owner can drain CART tokens from the contract
This function is a failsafe mechanism designed to recover CART tokens that have accumulated in the contract as part of the tax/fee system. These tokens are already designated for the treasury through the automatic swap process (CART → ETH). In rare cases where the automatic swap fails, stalls, or a transaction drops, fees can remain stuck inside the contract. This owner function allows us to manually complete the intended conversion and move those accumulated fees to the treasury. It does not affect user wallets, liquidity pools, or LP tokens. It only applies to tokens already collected by the contract as fees. The purpose is operational reliability, not access to user funds.
High – Reentrancy via Treasury Wallet
The audit notes a theoretical reentrancy risk if the treasury wallet were a smart contract capable of executing code upon receiving ETH. Our treasury is a verified EOA (externally owned account), not a smart contract, meaning it has no code and cannot perform reentrant calls. Therefore, this scenario does not apply in our setup. The finding assumes a contract-based treasury, which is not the case and is not planned.
High – Integer Underflow via unchecked
The report describes a scenario where an underflow could inflate a balance if a value changed mid-transaction. Ethereum transactions are atomic, meaning state cannot be externally altered during execution. Additionally, balance validations occur before arithmetic operations. The unchecked block is intentionally used as a gas optimization in a controlled context where the preconditions are enforced. There is no realistic path for balances to change mid-execution in a way that would cause the described overflow scenario.
High – DoS Through Failed ETH Transfer in swapBack
This finding assumes the treasury wallet could reject ETH transfers and cause the swap function to revert. That situation only applies if the treasury is a smart contract programmed to reject ETH. Our treasury is a regular EOA wallet, which cannot reject ETH because it has no executable code. As such, this denial-of-service scenario is not applicable to our structure.
High – Centralization Risk Through Owner Powers
The owner permissions flagged in the audit are intentional and necessary for controlled token management, particularly to gradually reduce tax rates down to 0% as outlined in our migration documentation. Without these permissions, taxes and operational parameters would be permanently fixed. These controls are standard in modern token contracts and allow us to responsibly transition the tokenomics over time. They are not arbitrary levers, but tools to execute the roadmap as communicated.
Last updated