Is Rekt Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Token Supply

H-01During contract deployment, a substantial amount of 420,690,000,000,000 tokens (420.69 quadrillion) was minted to a single address (0x424D…7C98). This concentration of nearly the entire token supply in one address creates a single point of control, enabling potential market manipulation, rug pulls, or significant influence over any DeFi protocols integrating this token. This poses a severe economic risk to other token holders and the overall ecosystem.

IssueDuring contract deployment, a substantial amount of 420,690,000,000,000 tokens (420.69 quadrillion) was minted to a single address (). This concentration of nearly the entire token supply in one address creates a single point of control, enabling potential market manipulation, rug pulls, or significant influence over any DeFi protocols integrating this token. This poses a severe economic risk to other token holders and the overall ecosystem.

FixFor future token deployments, consider implementing a more decentralized initial distribution strategy. This could involve vesting schedules, fair launch mechanisms, or distributing tokens across multiple addresses controlled by different entities to mitigate the risk associated with a single point of failure and control.

StatusUnresolved

Medium

Unpausable Token After Ownership Renouncement

M-01The contract inherits `ERC20Pausable` and includes `pause()` and `unpause()` functions, which are restricted to the `onlyOwner` modifier. However, the provided prefill indicates that ownership has been renounced. While renouncing ownership removes the centralization risk of an owner arbitrarily pausing transfers, it also renders the token permanently unpausable. This means that in the event of a critical vulnerability in an integrated DeFi protocol or a severe market exploit, there is no mechanism to halt token transfers to prevent further damage.

IssueThe contract inherits `ERC20Pausable` and includes `pause()` and `unpause()` functions, which are restricted to the `onlyOwner` modifier. However, the provided prefill indicates that ownership has been renounced. While renouncing ownership removes the centralization risk of an owner arbitrarily pausing transfers, it also renders the token permanently unpausable. This means that in the event of a critical vulnerability in an integrated DeFi protocol or a severe market exploit, there is no mechanism to halt token transfers to prevent further damage.

FixAcknowledge the trade-off between decentralization (no owner to pause) and emergency response capability (no ability to pause). If an emergency pause mechanism is deemed necessary for future versions or similar projects, consider alternative decentralized governance-controlled pause mechanisms (e.g., multi-sig or DAO-controlled) rather than relying solely on `Ownable`.

StatusUnresolved

Low

Immutability of Core Logic

L-01The Rekt token contract is deployed without any upgradeability pattern (e.g., proxy contracts). This design choice makes the contract's logic immutable once deployed. While immutability provides certainty and reduces upgrade-related risks, it also means that any bugs discovered post-deployment cannot be fixed, and new features or protocol adjustments cannot be implemented without deploying an entirely new token contract.

IssueThe Rekt token contract is deployed without any upgradeability pattern (e.g., proxy contracts). This design choice makes the contract's logic immutable once deployed. While immutability provides certainty and reduces upgrade-related risks, it also means that any bugs discovered post-deployment cannot be fixed, and new features or protocol adjustments cannot be implemented without deploying an entirely new token contract.

FixEnsure that the current contract logic is thoroughly tested and deemed final, as no changes can be made. For projects requiring flexibility or long-term maintenance, consider implementing an upgradeable contract pattern in future iterations, along with robust upgrade safety procedures.

StatusUnresolved

Info

Reliance on OpenZeppelin Libraries

I-01The Rekt token contract extensively utilizes well-regarded and audited OpenZeppelin contracts (ERC20, Ownable, ERC20Burnable, ERC20Pausable, ERC20Permit). This significantly enhances the baseline security of the contract by leveraging battle-tested code. However, the security of the Rekt token is inherently dependent on the continued security and correct implementation of these external libraries.

IssueThe Rekt token contract extensively utilizes well-regarded and audited OpenZeppelin contracts (ERC20, Ownable, ERC20Burnable, ERC20Pausable, ERC20Permit). This significantly enhances the baseline security of the contract by leveraging battle-tested code. However, the security of the Rekt token is inherently dependent on the continued security and correct implementation of these external libraries.

FixContinue to monitor OpenZeppelin's security advisories and updates. While OpenZeppelin contracts are highly secure, any newly discovered vulnerabilities in their libraries could potentially affect dependent contracts. Ensure that the specific versions used are up-to-date and free from known issues.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The Rekt token contract (7.1 Architecture, 7.2 Code Security) is built upon well-audited OpenZeppelin ERC20, Ownable, Burnable, Pausable, and Permit libraries, significantly reducing the likelihood of common coding vulnerabilities like reentrancy or integer overflows. The custom logic is minimal, primarily consisting of a constructor for initial minting and simple `pause`/`unpause` functions. The `_update` override correctly integrates the pausable functionality. No complex or novel attack vectors were identified within the custom code.

GovernanceMedium6/10

The economic model (7.4 Economic) presents a high centralization risk due to the initial minting of 420,690,000,000,000 tokens (420.69 quadrillion) to a single address () during deployment. This address holds virtually the entire token supply, granting it immense control over market dynamics and potential for price manipulation. While the `Ownable` contract (7.3 Access Control) initially provided the deployer with control over pausing transfers, the prefill indicates ownership has been renounced (7.5 Governance), which removes this centralized control but introduces immutability regarding pausing.

UpgradesLow9/10

The Rekt token contract is not designed with upgradeability features (7.7 Upgrades). This means its logic is immutable post-deployment, preventing any future modifications or bug fixes. While this eliminates upgrade-related risks, it also removes the flexibility to adapt to new requirements or address unforeseen issues.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

45.5% in top 10

5.9% in wallets39.7% in contracts

Effective Concentration21.7%

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

$1.32M across 4 pairs

Uniswap v3WETHanalysed$1.12M Uniswap v4USDC$196.0K Uniswap v4ETH$1.5K Uniswap v4ETH$54

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 Holder99.9%

Top-3 Unlocked100.0%

Key Addresses

8 addresses

Deployer

0xf779…eefb

Unlocked LP Held By

0xf60e…669f0x6d8d…00120xa63b…fbee0x8cf6…9cdf0x9abc…9d9d0x81df…fdb60x47b6…b1a5

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

What Raised This Score

7 factors

Top-10 concentration > 20% (45.5% total → 21.7% effective; 5.9% in EOAs, 39.7% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 85% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 85% of DEX liquidity)
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

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

Is Rekt Safe?

Security Findings

Centralized Token Supply

Unpausable Token After Ownership Renouncement

Immutability of Core Logic

Reliance on OpenZeppelin Libraries

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 Rekt?