Is Shuffle (SHFL) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Low

Critical

Incorrect Burn Implementation

C-01The `burn` function in the SHFL contract calls `_update(_msgSender(), address(0xdead), value)`. OpenZeppelin's `_update` function only decreases `_totalSupply` when the `to` address is `address(0)`. By using `address(0xdead)` instead of `address(0)`, the tokens are removed from the caller's balance but are not deducted from the `_totalSupply`. This results in an inflated `totalSupply` value, misrepresenting the actual circulating supply and breaking the core functionality of a burn mechanism.

IssueThe `burn` function in the SHFL contract calls `_update(_msgSender(), address(0xdead), value)`. OpenZeppelin's `_update` function only decreases `_totalSupply` when the `to` address is `address(0)`. By using `address(0xdead)` instead of `address(0)`, the tokens are removed from the caller's balance but are not deducted from the `_totalSupply`. This results in an inflated `totalSupply` value, misrepresenting the actual circulating supply and breaking the core functionality of a burn mechanism.

FixModify the `burn` function to correctly reduce the total supply. The recommended approach is to use OpenZeppelin's internal `_burn` function, which is designed for this purpose: `_burn(_msgSender(), value);`. Alternatively, ensure `_update` is called with `address(0)` as the recipient: `_update(_msgSender(), address(0), value);`.

StatusUnresolved

Low

Centralized Initial Token Distribution

L-01In the constructor, all 1,000,000,000 SHFL tokens (with 18 decimals) are minted directly to the contract deployer (`_msgSender()`). This results in a highly centralized initial token distribution, where a single address holds the entire supply. While common for new projects, this level of centralization gives the deployer significant control over the token's market dynamics and potential for large-scale price manipulation or rug pull scenarios if not managed transparently.

IssueIn the constructor, all 1,000,000,000 SHFL tokens (with 18 decimals) are minted directly to the contract deployer (`_msgSender()`). This results in a highly centralized initial token distribution, where a single address holds the entire supply. While common for new projects, this level of centralization gives the deployer significant control over the token's market dynamics and potential for large-scale price manipulation or rug pull scenarios if not managed transparently.

FixConsider implementing a more distributed initial token allocation strategy, such as a vesting schedule, airdrops, or a public sale, to reduce centralization risks. If the current distribution is intentional, ensure clear communication to the community regarding the deployer's plans for managing or distributing these tokens to build trust and transparency.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes OpenZeppelin's battle-tested ERC20 implementation, providing a solid foundation for standard token operations (7.2 Code Security). However, the custom `burn` function contains a critical flaw (7.2 Code Security). Instead of reducing the total supply, it transfers tokens to `address(0xdead)`, causing the `totalSupply` to remain unchanged and misrepresenting the actual tokenomics. This issue severely impacts the intended functionality of burning.

GovernanceHigh1/10

The economic model is straightforward, representing a basic ERC20 token (7.4 Economic). All initial tokens are minted to the deployer, resulting in a highly centralized distribution (7.4 Economic). This centralization grants the deployer significant control over the token supply, which could pose a risk if not managed transparently. There are no complex governance mechanisms or external dependencies identified (7.5 Governance, 7.6 External).

UpgradesMedium5/10

The SHFL contract is not designed with upgradeability in mind (7.7 Upgrades). It is a standard, non-proxy ERC20 implementation. This eliminates the risks associated with upgrade mechanisms, such as proxy misconfigurations or upgradeability pauses, but also means that any discovered vulnerabilities or desired feature changes would require a new contract deployment and token migration.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

95.3% in top 10

93.3% in wallets2.0% in contracts

Effective Concentration94.1%

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

$7.71M

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0xac93…0215

Unlocked LP Held By

0x7cd4…ab6e0x637a…66660xde51…a29f0x44c9…e623

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

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 70% (95.3% total → 94.1% effective; 93.3% in EOAs, 2.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
1 Critical 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

Not Signed In

Is Shuffle Safe?