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

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2332Jul 230

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The REI token contract is a standard ERC20 implementation, inheriting from a robust base. Its supply is fixed at deployment, and it lacks complex features, which inherently reduces the attack surface. The contract adheres closely to established ERC20 patterns, demonstrating a strong foundation for security.

Final Recommendation: The REI token contract is a straightforward ERC20 implementation that adheres to established security practices. It is recommended to ensure the initial supply minted in the constructor aligns precisely with the project's economic model and distribution strategy. For any future integrations, thoroughly review the interaction logic with external protocols to prevent unforeseen vulnerabilities arising from external dependencies.

Category Ratings

TechnicalLow

10/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 techni

GovernanceMedium

5/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). Thi

UpgradesMedium

6/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

LP Distribution

Top-1 Unlocked Holder19.6%

Top-3 Unlocked53.5%

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

Security Findings

4 total

4 Info

I-01InformationalUnresolved

Fixed Supply Token

The `_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.

Recommendation: This 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.

I-02InformationalUnresolved

Use of `unchecked` blocks for arithmetic operations

The 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.

Recommendation: No 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.

I-03InformationalUnresolved

Absence of Pause Mechanism

The 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.

Recommendation: This 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.

I-04InformationalUnresolved

Absence of Blacklist Mechanism

The 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.

Recommendation: This 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.

Is Unit 00 - Rei Safe? REI