Is Elsa Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Initial Token Distribution

H-01The `ELSA` contract's constructor mints the entire `TOTAL_SUPPLY` (1 billion tokens) to the `msg.sender` (the deployer). This results in a highly centralized initial distribution of all tokens to a single address. This concentration of power can lead to significant economic and governance risks, including potential market manipulation, lack of decentralization, and single point of failure if the deployer's key is compromised (7.4 Economic, 7.5 Governance).

IssueThe `ELSA` contract's constructor mints the entire `TOTAL_SUPPLY` (1 billion tokens) to the `msg.sender` (the deployer). This results in a highly centralized initial distribution of all tokens to a single address. This concentration of power can lead to significant economic and governance risks, including potential market manipulation, lack of decentralization, and single point of failure if the deployer's key is compromised (7.4 Economic, 7.5 Governance).

FixIf a decentralized token distribution is desired, consider implementing a vesting schedule, a multi-signature wallet for the initial supply, or a distribution mechanism (e.g., airdrop, liquidity pool seeding) to spread ownership. Clearly communicate the intended use and security measures for the deployer's address holding the entire supply.

StatusUnresolved

Medium

Front-Running Risk for `transferWithAuthorization`

M-01The `transferWithAuthorization` function, as per EIP-3009 design, allows any third party to execute a valid signed authorization. If a signed `transferWithAuthorization` message is broadcast publicly (e.g., via a relayer or mempool), an attacker could observe it and front-run the intended transaction by submitting their own transaction with a higher gas price, effectively executing the transfer before the intended party (7.2 Code Security). While `receiveWithAuthorization` is protected by a `msg.sender != to` check, `transferWithAuthorization` lacks such a restriction.

IssueThe `transferWithAuthorization` function, as per EIP-3009 design, allows any third party to execute a valid signed authorization. If a signed `transferWithAuthorization` message is broadcast publicly (e.g., via a relayer or mempool), an attacker could observe it and front-run the intended transaction by submitting their own transaction with a higher gas price, effectively executing the transfer before the intended party (7.2 Code Security). While `receiveWithAuthorization` is protected by a `msg.sender != to` check, `transferWithAuthorization` lacks such a restriction.

FixEducate users about the front-running risks associated with `transferWithAuthorization`. For sensitive transactions, advise users to utilize private transaction relays (e.g., Flashbots) to prevent their signed messages from being exposed in the public mempool before execution. Implement monitoring for potential front-running attempts if possible.

StatusUnresolved

Low

Reliance on `block.timestamp` for Authorization Validity

L-01The `_validateAuthorization` function uses `block.timestamp` to check `validAfter` and `validBefore` parameters. While standard practice for time-based validity, `block.timestamp` can be manipulated by miners within a small window (e.g., up to 900 seconds on Ethereum mainnet, though typically less on faster chains). This could potentially allow a miner to slightly extend or shorten the validity window of an authorization (7.2 Code Security).

IssueThe `_validateAuthorization` function uses `block.timestamp` to check `validAfter` and `validBefore` parameters. While standard practice for time-based validity, `block.timestamp` can be manipulated by miners within a small window (e.g., up to 900 seconds on Ethereum mainnet, though typically less on faster chains). This could potentially allow a miner to slightly extend or shorten the validity window of an authorization (7.2 Code Security).

FixAcknowledge that `block.timestamp` is subject to minor miner manipulation. For most use cases, this level of precision is acceptable. If extremely precise time-based validity is critical, consider alternative time sources or design patterns, though this often introduces additional complexity or centralization.

StatusUnresolved

Info

Lack of Emergency Pause Mechanism

I-01The `ELSA` token contract, being a standard ERC20 implementation with EIP-3009 extensions, does not include any emergency pause functionality. In the event of a critical vulnerability discovered in the token itself, or in a protocol that heavily relies on it, there is no mechanism to temporarily halt transfers or other operations (7.8 Operations).

IssueThe `ELSA` token contract, being a standard ERC20 implementation with EIP-3009 extensions, does not include any emergency pause functionality. In the event of a critical vulnerability discovered in the token itself, or in a protocol that heavily relies on it, there is no mechanism to temporarily halt transfers or other operations (7.8 Operations).

FixConsider whether an emergency pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) would be beneficial for the project's risk management strategy. While adding complexity and a point of control, it can provide a crucial safety switch in unforeseen circumstances. If implemented, ensure the pause functionality is controlled by a robust, multi-signature governance mechanism.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical implementation of the ELSA token contract is robust, utilizing battle-tested OpenZeppelin libraries for ERC20, ERC20Permit, and EIP712 functionalities. The custom ERC3009 extension correctly implements the 'Transfer With Authorization' standard, including nonce management to prevent replay attacks and `SignatureChecker` for secure signature verification (7.2 Code Security). The `receiveWithAuthorization` function includes a critical check to ensure only the intended recipient can execute the transfer, mitigating a common front-running vector. However, the `transferWithAuthorization` function remains susceptible to front-running by third parties (7.2 Code Security).

GovernanceHigh1/10

The economic model of the ELSA token involves minting the entire `TOTAL_SUPPLY` of 1 billion tokens to the contract deployer during construction (7.4 Economic). This creates a highly centralized initial distribution, granting the deployer significant control over the token supply and potential market manipulation (7.5 Governance). While this may be an intentional design choice, it represents a substantial economic and governance risk due to the concentration of power.

UpgradesMedium6/10

The ELSA token contract is not designed with upgradeability in mind, as it does not implement any proxy patterns (7.7 Upgrades). This means the contract's logic is immutable once deployed, eliminating risks associated with upgrade mechanisms such as proxy admin control, storage collisions, or faulty upgrade implementations. Any future changes to the token's core logic would require a new contract deployment and migration of assets.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

89.0% in top 10

16.6% in wallets72.4% in contracts

Effective Concentration45.6%

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

$356.9K across 5 pairs

PancakeswapUSDCanalysed$346.0K Uniswap v3USDC$10.8K Uniswap v4USDC$28 Uniswap v4USDC$9 0xB0C2…9C88WETH$3

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

2 addresses

Deployer

0x82cb…9978

Unlocked LP Held By

0x3b80…2013

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

What Raised This Score

8 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (89.0% total → 45.6% effective; 16.6% in EOAs, 72.4% in contracts — moderate)
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, pool = 97% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% 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 Elsa Safe?

Security Findings

Centralized Initial Token Distribution

Front-Running Risk for `transferWithAuthorization`

Reliance on `block.timestamp` for Authorization Validity

Lack of Emergency Pause 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 Elsa?