On-chain security analysis — is it a scam or legit?
The ELSA token contract implements ERC20, ERC20Permit, and ERC3009 (Transfer With Authorization).
Read the full analysisEach 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
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.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x3b80…2013No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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).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).
If 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.
Unresolved
transferWithAuthorizationtransferWithAuthorization 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.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.
Educate 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.
Unresolved
block.timestamp for Authorization Validity_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).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).
Acknowledge 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.
Unresolved
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).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).
Consider 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.
Unresolved
The ELSA token contract implements ERC20, ERC20Permit, and ERC3009 (Transfer With Authorization). It leverages OpenZeppelin libraries for robust and standard-compliant functionality. The primary risks identified relate to the initial centralized token distribution and the inherent front-running potential of EIP-3009's transferWithAuthorization function.
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).
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.
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.
It is recommended to carefully consider the implications of the highly centralized initial token distribution.
If decentralization is a long-term goal, a plan for gradual distribution or a multi-signature wallet for the deployer's address should be implemented. For EIP-3009 authorizations, users should be educated on the front-running risks associated with transferWithAuthorization and advised to use private transaction relays or monitor the mempool if sensitive to execution order.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
