Quantum Audit Logo

Is ElonRWA a Scam?

Honeypot, rug-pull and ownership checks

ElonRWA ELONRWA
0xaa6c…4898
Base Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audited code primarily consists of OpenZeppelin's ERC20 and ERC20Permit standard implementations. These contracts are well-audited and widely adopted, contributing to a low overall technical risk. The specific custom logic for the 'ElonRWA' contract was not fully provided, limiting the scope of the audit to the inherited OpenZeppelin components. Identified risks are generally low or informational, primarily related to inherent design patterns like permit function front-running.

1 Low3 Informational
i Our automated scanner reviewed ElonRWA (ELONRWA) on Base. 3 of 5 security checks passed — see the full breakdown below.
Volume 24h
$34.3K
Liquidity
$625.8K
Price
$0.00002554
Age
2y
Top 10 Holders
80.0%

Security Findings

Low

Permit Function Front-Running Risk

L-01The `permit` function, while implementing EIP-2612 correctly with nonces to prevent replay attacks, is inherently susceptible to front-running. A malicious actor observing a signed `permit` message off-chain could submit their own transaction with a higher gas price, potentially causing the original user's transaction to fail or be delayed. This is a known characteristic of the EIP-2612 design and not a flaw in the implementation itself.
IssueThe `permit` function, while implementing EIP-2612 correctly with nonces to prevent replay attacks, is inherently susceptible to front-running. A malicious actor observing a signed `permit` message off-chain could submit their own transaction with a higher gas price, potentially causing the original user's transaction to fail or be delayed. This is a known characteristic of the EIP-2612 design and not a flaw in the implementation itself.
FixEducate users about the potential for front-running when using the `permit` function. Advise users to set reasonable `deadline` values to limit the window of opportunity for front-running. While not a direct vulnerability, awareness helps manage user expectations and potential transaction failures.
StatusUnresolved
Info

Reliance on OpenZeppelin Standard Libraries

I-01The contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts for ERC20 and ERC20Permit functionalities. This significantly reduces the likelihood of common vulnerabilities found in custom implementations, such as reentrancy, integer overflows/underflows, and ERC standard non-compliance. This is a strong security practice.
IssueThe contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts for ERC20 and ERC20Permit functionalities. This significantly reduces the likelihood of common vulnerabilities found in custom implementations, such as reentrancy, integer overflows/underflows, and ERC standard non-compliance. This is a strong security practice.
FixContinue to leverage established and audited libraries like OpenZeppelin. Ensure that any custom modifications or extensions to these libraries are carefully reviewed and tested to maintain the high security standards.
StatusUnresolved
Info

Hardcoded Decimals Value

I-02The `decimals()` function is hardcoded to return `18`. This is a common practice for ERC20 tokens, aligning with Ethereum's native Ether. While not a vulnerability, it is a fixed design choice that cannot be changed post-deployment.
IssueThe `decimals()` function is hardcoded to return `18`. This is a common practice for ERC20 tokens, aligning with Ethereum's native Ether. While not a vulnerability, it is a fixed design choice that cannot be changed post-deployment.
FixConfirm that a fixed `18` decimals is the intended and desired behavior for the token throughout its lifecycle and ecosystem integrations. No action is required if this is the intended design.
StatusUnresolved
Info

Limited Scope Due to Truncated Contract Code

I-03The provided contract text primarily includes OpenZeppelin's base ERC20 and ERC20Permit implementations. The specific custom logic, additional functions, or modifications within the `ElonRWA` contract itself were truncated. This limits the audit's scope to the inherited OpenZeppelin components, meaning any unique vulnerabilities or design flaws introduced by the `ElonRWA` specific implementation could not be assessed.
IssueThe provided contract text primarily includes OpenZeppelin's base ERC20 and ERC20Permit implementations. The specific custom logic, additional functions, or modifications within the `ElonRWA` contract itself were truncated. This limits the audit's scope to the inherited OpenZeppelin components, meaning any unique vulnerabilities or design flaws introduced by the `ElonRWA` specific implementation could not be assessed.
FixProvide the complete source code for the `ElonRWA` contract, including any custom logic, constructor parameters, and function implementations, for a comprehensive security review. Pay particular attention to how internal functions like `_mint` and `_burn` are exposed and protected.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) relies on battle-tested OpenZeppelin ERC20 and ERC20Permit contracts, which are known for their robust security and adherence to standards. Code security (7.2) is high, with proper use of `unchecked` blocks in Solidity 0.8+ for gas efficiency while maintaining safety through explicit checks (e.g., `fromBalance < value`). The implementation utilizes custom errors (e.g., `ERC20InsufficientBalance`) for gas-efficient and clear error handling. Access control (7.3) for core token functions like `transfer` and `approve` follows ERC20 standards, and the `permit` function correctly implements EIP-2612 with nonces to prevent replay attacks.

GovernanceHigh1/10

The economic model (7.4) of the token is standard ERC20, with `_mint` and `_burn` functions provided internally. The `decimals()` function is hardcoded to 18, which is a common and expected design choice for most tokens. The governance (7.5) aspects are minimal within the provided base contracts, as `_mint` and `_burn` are internal functions. Any external exposure of these functions in the inheriting `ElonRWA` contract would require robust access control mechanisms to prevent unauthorized supply manipulation. The current structure provides a solid foundation for a stable token economy.

UpgradesMedium6/10

Based on the provided information (is_proxy: false), the contract is not designed to be upgradeable (7.7). This simplifies the deployment and reduces the complexity associated with upgrade mechanisms, eliminating risks related to proxy patterns or upgradeability logic. Therefore, upgrade safety concerns are not applicable to this specific deployment.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

37.3% in wallets42.7% in contracts
Effective Concentration54.4%

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

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

Deployer
0x0aae…72cc
Unlocked LP Held By
0xa6b9…11240x032c…4fa90xb2a5…39890xf25e…37b10x8b0f…1a190xae2f…774b0x7671…198f

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 50% (80.0% total → 54.4% effective; 37.3% in EOAs, 42.7% in contracts — heavy)
  • 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 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

Related Audits

Moltbook (MOLT)Medium RiskKellyClaudeMedium RiskOWBMedium RiskVirtual Protocol (VIRTUAL)Medium RiskFlowerMedium RiskCookieMedium Risk

Would You Like a More Detailed Audit of ElonRWA?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit