Honeypot, rug-pull and ownership checks

Is ElonRWA a Scam?

ELONRWABase

Not verified

This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →

Last checked Sep 4, 2026 · 1 audit on record

Chart

34/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical10/10 Governance1/10 Upgrades6/10 Checks passed5 of 7 Findings1 Low · 3 Info4

SummaryAI Copilot

The audited code primarily consists of OpenZeppelin's ERC20 and ERC20Permit standard implementations.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Top-10 concentration > 50%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0%
LP top3 unlocked holders = 100.0%
1 Low finding(s) from audit

Exact factors

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

Our automated scanner reviewed ElonRWA (ELONRWA) on Base. 5 of 7 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipUnknown

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

HoneypotNone found

Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

80.0%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking42.7%
Walletsanonymous holders, free to sell37.3%
Everyone elsethe rest of the supply20.0%

Effective concentrationwhat the score reads54.4%

How holder types affect the score

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

Liquidity

as of audit · Sep 4$625.9K across 4 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$625.8KShare of depth100.0%

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

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.

Security Findings

1 Low3 Info

Low

Permit Function Front-Running Risk

The 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.L-01

Issue

Fix

Educate 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.

Status

Unresolved

Info

Reliance on OpenZeppelin Standard Libraries

The 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.I-01

Issue

Fix

Continue 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.

Status

Unresolved

Info

Hardcoded Decimals Value

The 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.I-02

Issue

Fix

Confirm 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.

Status

Unresolved

Info

Limited Scope Due to Truncated Contract Code

The 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.I-03

Issue

Fix

Provide 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical10/10Low risk

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.

Governance1/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is recommended to thoroughly audit any custom logic added in the ElonRWA contract, particularly how _mint and _burn functions are exposed and secured, to ensure robust access control.

Implement comprehensive unit and integration tests for all custom functionalities to cover edge cases and ensure expected behavior. While the permit function is secure against replay attacks, users should be aware of potential front-running, and applications integrating with it should consider this user experience aspect.

Contract & Record

1 audit on record

TypeToken

NetworkBase

Token age2y

Contract0xaa6c…4898

Deployer0x0aae…72cc

Badge for your website

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History

Aug 30, 202634Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the ELONRWA contract address?

The ElonRWA contract on Base is 0xaa6cccdce193698d33deb9ffd4be74eaa74c4898. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.