Is Unit 00 - Rei (REI) Safe? Smart Contract Security Analysis

Security Findings

4 Info

Info

Fixed Supply Token

I-01The `_mint` function is only called once in the constructor to mint the `initialSupply` to `msg.sender`. There are no other functions exposed to mint additional tokens or modify the total supply after deployment. This design choice results in a fixed-supply token.

IssueThe `_mint` function is only called once in the constructor to mint the `initialSupply` to `msg.sender`. There are no other functions exposed to mint additional tokens or modify the total supply after deployment. This design choice results in a fixed-supply token.

FixThis is a design decision. Ensure that a fixed supply aligns with the project's economic model and long-term vision. Clearly communicate this characteristic to users and stakeholders.

StatusUnresolved

Info

Use of `unchecked` blocks for arithmetic operations

I-02The contract utilizes `unchecked` blocks for several arithmetic operations, specifically in `_update` and `_spendAllowance` functions (e.g., `_balances[from] = fromBalance - value;`, `_totalSupply -= value;`, `_balances[to] += value;`). While this is a common gas optimization in Solidity 0.8.0+, it relies on explicit checks (e.g., `if (fromBalance < value)`) to prevent underflow before the `unchecked` block is executed. In this contract, these checks are correctly implemented, mitigating the risk of underflow.

IssueThe contract utilizes `unchecked` blocks for several arithmetic operations, specifically in `_update` and `_spendAllowance` functions (e.g., `_balances[from] = fromBalance - value;`, `_totalSupply -= value;`, `_balances[to] += value;`). While this is a common gas optimization in Solidity 0.8.0+, it relies on explicit checks (e.g., `if (fromBalance < value)`) to prevent underflow before the `unchecked` block is executed. In this contract, these checks are correctly implemented, mitigating the risk of underflow.

FixNo action is required as the `unchecked` blocks are used safely with preceding checks. This finding serves as an observation of a common gas optimization technique.

StatusUnresolved

Info

Absence of Pause Mechanism

I-03The contract does not include a pause mechanism, which would allow privileged accounts (e.g., an owner or multisig) to temporarily halt token transfers or other critical operations. While this enhances decentralization, it also means that in the event of a critical vulnerability in an integrated system or a severe market exploit, the token's operations cannot be stopped.

IssueThe contract does not include a pause mechanism, which would allow privileged accounts (e.g., an owner or multisig) to temporarily halt token transfers or other critical operations. While this enhances decentralization, it also means that in the event of a critical vulnerability in an integrated system or a severe market exploit, the token's operations cannot be stopped.

FixThis is a design decision. If the project prioritizes immutability and decentralization, no action is needed. If the ability to react to emergencies is desired, consider implementing a well-designed, access-controlled pause mechanism, ideally with a timelock or governance control.

StatusUnresolved

Info

Absence of Blacklist Mechanism

I-04The contract does not implement any blacklist functionality. This means there is no mechanism to prevent specific addresses from holding or transferring tokens, even if they are identified as malicious or compromised. This design choice aligns with principles of censorship resistance and decentralization.

IssueThe contract does not implement any blacklist functionality. This means there is no mechanism to prevent specific addresses from holding or transferring tokens, even if they are identified as malicious or compromised. This design choice aligns with principles of censorship resistance and decentralization.

FixThis is a design decision. If the project prioritizes censorship resistance, no action is needed. If the ability to mitigate risks from malicious actors (e.g., freezing stolen funds) is desired, consider implementing a carefully designed and access-controlled blacklist mechanism, understanding the trade-offs in decentralization.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract implements the ERC20 standard, utilizing custom error types and `unchecked` blocks for gas efficiency, with appropriate prior checks to prevent underflow (7.2 Code Security). It does not contain complex logic or external calls beyond standard token operations, contributing to its technical simplicity and security (7.1 Architecture). No reentrancy or critical integer issues were identified, indicating a robust technical foundation.

GovernanceMedium5/10

The REI token has a fixed supply minted entirely to the deployer during construction, meaning no further minting or burning capabilities exist post-deployment (7.4 Economic). There are no governance mechanisms or privileged roles beyond the initial deployer receiving the supply (7.5 Governance). This design choice promotes decentralization of control over the token's supply and minimizes economic manipulation risks.

UpgradesMedium6/10

The REI contract is a standalone token implementation and is not designed to be upgradeable (7.7 Upgrades). It does not utilize any proxy patterns, which simplifies its architecture and removes upgrade-related risks. Any future changes to the token's logic would necessitate a new deployment and a migration process.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

26.3% in top 10

7.3% in wallets19.0% in contracts

Effective Concentration14.9%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$2.24M across 11 pairs

AerodromeWETHanalysed$1.94M Uniswap v3WETH$227.3K Uniswap v4POD$54.4K AerodromeWETH$12.5K Uniswap v4ETH$5.8K AerodromeWETH$5.3K

Show 4 more pairsShow less

Uniswap v3USDC$2.1K PancakeswapWETH$52 Hydrex CLAMMUSDC$10 AerodromeVIRTUAL$7

One more pair holds $5 and is not listed.

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder30.1%

Top-3 Unlocked63.3%

Key Addresses

11 addresses

Deployer

0x1af3…247f

Unlocked LP Held By

0x2ae1…441c0x22bc…71a80xca77…a80e0x5b37…0c9c0x0141…ba140xf92e…1b560x3555…7aa40x1952…568c0x7d27…fd550x9e98…a161

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

2 factors

Ownership status UNKNOWN (owner could not be resolved)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Not Signed In

Is Unit 00 - Rei Safe?

Security Findings

Fixed Supply Token

Use of `unchecked` blocks for arithmetic operations

Absence of Pause Mechanism

Absence of Blacklist Mechanism

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Unit 00 - Rei?