Quantum Audit Logo

Is NEAR Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

NEAR NEAR
0x85f1…f6a4
Ethereum
Not verifiedThis 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 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The eNear contract serves as an ERC20 token for the NEAR-Ethereum Rainbow Bridge. It facilitates cross-chain transfers by minting tokens on Ethereum upon verified NEAR proofs and burning tokens for transfers to NEAR. The contract utilizes a robust proof verification system and standard ERC20 implementation. However, the `AdminControlled` component introduces severe centralization risks through highly privileged functions like `adminDelegatecall` and `adminSstore`, granting the administrator complete control over the contract's logic and state. This centralization, coupled with a critical external dependency on the `INearProver`, elevates the overall risk to Critical.

2 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$147.3K
Liquidity
$399.6K
Price
$2.3700
Token Age
2y
Top 10 Holders
34.4%

Security Findings

2 Crit1 High1 Med1 Low1 Info
Critical

Centralized Control via `adminDelegatecall`

C-01The `adminDelegatecall` function in the `AdminControlled` contract allows the `admin` to execute arbitrary code in the context of the `eNear` contract. This grants the administrator complete and unrestricted control over the contract's logic and state. A malicious or compromised admin could mint arbitrary tokens, drain funds, modify critical bridge parameters, or even self-destruct the contract.
IssueThe `adminDelegatecall` function in the `AdminControlled` contract allows the `admin` to execute arbitrary code in the context of the `eNear` contract. This grants the administrator complete and unrestricted control over the contract's logic and state. A malicious or compromised admin could mint arbitrary tokens, drain funds, modify critical bridge parameters, or even self-destruct the contract.
FixRemove the `adminDelegatecall` function entirely. If dynamic functionality is required, implement a well-defined, audited, and time-locked upgrade mechanism (e.g., UUPS proxy with a governance delay) instead of arbitrary delegatecall. If removal is not feasible, restrict its usage to a multi-signature wallet with a significant delay.
StatusUnresolved
Critical

Arbitrary Storage Modification via `adminSstore`

C-02The `adminSstore` function allows the `admin` to write any arbitrary value to any storage slot within the contract. This means the administrator can unilaterally change any state variable, including critical parameters like the `admin` address itself, the `prover` address, `nearConnector`, `minBlockAcceptanceHeight`, the `usedProofs` mapping, or even ERC20 token balances by manipulating storage slots. This constitutes a critical backdoor.
IssueThe `adminSstore` function allows the `admin` to write any arbitrary value to any storage slot within the contract. This means the administrator can unilaterally change any state variable, including critical parameters like the `admin` address itself, the `prover` address, `nearConnector`, `minBlockAcceptanceHeight`, the `usedProofs` mapping, or even ERC20 token balances by manipulating storage slots. This constitutes a critical backdoor.
FixRemove the `adminSstore` function. Direct manipulation of storage should never be exposed to an external account. All state modifications should occur through well-defined, validated functions.
StatusUnresolved
High

Critical External Dependency on `INearProver`

H-01The security of the `finaliseNearToEthTransfer` function, which is responsible for minting eNear tokens on Ethereum, is entirely dependent on the `INearProver` contract correctly verifying proofs from the NEAR blockchain. Any vulnerability, bug, or compromise in the `INearProver` contract or the underlying NEAR proof system could lead to unauthorized or fraudulent minting of eNear tokens, directly impacting the token's supply and value.
IssueThe security of the `finaliseNearToEthTransfer` function, which is responsible for minting eNear tokens on Ethereum, is entirely dependent on the `INearProver` contract correctly verifying proofs from the NEAR blockchain. Any vulnerability, bug, or compromise in the `INearProver` contract or the underlying NEAR proof system could lead to unauthorized or fraudulent minting of eNear tokens, directly impacting the token's supply and value.
FixConduct a comprehensive security audit of the `INearProver` contract and the entire NEAR proof generation and verification mechanism. Implement robust monitoring for the `INearProver` contract's behavior and consider circuit breakers or emergency pause mechanisms that can be triggered if anomalies are detected in the proof verification process.
StatusUnresolved
Medium

Limited Front-running Potential in `finaliseNearToEthTransfer`

M-01While the `usedProofs` mapping prevents the reuse of the same proof, an attacker could potentially front-run a legitimate user's `finaliseNearToEthTransfer` transaction if they can observe the proof data in the mempool and submit their own transaction with the same proof (if multiple parties can generate the same proof) or a different valid proof for the same recipient. This could allow an attacker to claim tokens intended for another party or to claim tokens faster.
IssueWhile the `usedProofs` mapping prevents the reuse of the same proof, an attacker could potentially front-run a legitimate user's `finaliseNearToEthTransfer` transaction if they can observe the proof data in the mempool and submit their own transaction with the same proof (if multiple parties can generate the same proof) or a different valid proof for the same recipient. This could allow an attacker to claim tokens intended for another party or to claim tokens faster.
FixWhile the impact is mitigated by the single-use nature of proofs, consider if the proof generation process can be designed to include a unique user-specific nonce or commitment to prevent one user's proof from being used by another. Ensure that the `receiptId` is sufficiently unique and tied to the intended recipient.
StatusUnresolved
Low

Gas Inefficiency in `_parseAndConsumeProof` Comparison

L-01The comparison `keccak256(fullOutcomeProof.outcome_proof.outcome_with_id.outcome.executor_id) == keccak256(nearConnector)` involves hashing two byte arrays. While functionally correct, comparing the raw bytes directly (after ensuring length equality) could be more gas efficient if `executor_id` and `nearConnector` are expected to be of fixed or similar lengths. Hashing adds an unnecessary computational overhead if direct byte comparison is feasible.
IssueThe comparison `keccak256(fullOutcomeProof.outcome_proof.outcome_with_id.outcome.executor_id) == keccak256(nearConnector)` involves hashing two byte arrays. While functionally correct, comparing the raw bytes directly (after ensuring length equality) could be more gas efficient if `executor_id` and `nearConnector` are expected to be of fixed or similar lengths. Hashing adds an unnecessary computational overhead if direct byte comparison is feasible.
FixIf `executor_id` and `nearConnector` are always of the same length, consider comparing them directly after a length check to save gas. If lengths can vary, hashing is a safer approach for content comparison.
StatusUnresolved
Info

Use of Older Solidity Version

I-01The contract is compiled with `pragma solidity 0.6.12`. While this version is functional, newer Solidity versions (e.g., 0.8.x) offer built-in overflow/underflow checks by default, reducing reliance on `SafeMath` (though `SafeMath` is still good practice for clarity), and include various language improvements, optimizations, and bug fixes. Using an older compiler version might miss out on these benefits.
IssueThe contract is compiled with `pragma solidity 0.6.12`. While this version is functional, newer Solidity versions (e.g., 0.8.x) offer built-in overflow/underflow checks by default, reducing reliance on `SafeMath` (though `SafeMath` is still good practice for clarity), and include various language improvements, optimizations, and bug fixes. Using an older compiler version might miss out on these benefits.
FixConsider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x) and re-auditing the contract. Ensure all dependencies are compatible with the new compiler version.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The technical architecture (7.1) of the eNear bridge involves a standard ERC20 token integrated with a proof-based cross-chain mechanism. The `Bridge` contract implements robust proof verification, including checks for minimum block height and proof reuse (7.2). However, the `AdminControlled` contract introduces critical access control flaws (7.3). Specifically, `adminDelegatecall` allows the administrator to execute arbitrary code, and `adminSstore` enables modification of any storage slot, effectively bypassing all security controls. The system also has a critical external dependency (7.6) on the `INearProver` contract for proof validity.

GovernanceHigh1/10

The governance and economic model (7.5, 7.4) of the eNear contract is highly centralized. The `admin` role possesses absolute control over critical contract functions, including the ability to pause transfers, modify any state variable, and execute arbitrary code via `adminDelegatecall`. This single point of failure creates a significant trust assumption, as a compromised or malicious administrator could lead to a complete loss of funds or system integrity. The economic stability relies entirely on the integrity of the `admin` and the `INearProver` external dependency.

UpgradesHigh1/10

While the eNear contract is not explicitly designed with a proxy upgrade pattern, the `adminDelegatecall` function (7.7) effectively provides an uncontrolled upgrade mechanism. The administrator can use this function to delegate calls to any address with arbitrary data, allowing them to change the contract's logic or state without any community oversight or standard upgrade safety checks. This bypasses typical upgrade safeguards and introduces a significant risk of unauthorized modifications.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint Function?
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

34.4% in top 10
3.3% in wallets31.1% in contracts
Effective Concentration15.8%

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

$680.2K across 7 pairs
Uniswap v3USDCanalysed$399.6K58.7%Uniswap v3WETH$195.9K28.8%SushiswapWETH$60.7K8.9%Uniswap v4ETH$22.7K3.3%Uniswap v4TrumpBucks$1.3K0.2%SushiswapUSDC$00.0%

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 Holder69.2%
Top-3 Unlocked83.3%

Key Addresses

11 addresses
Deployer
0x015e…a3b1
Unlocked LP Held By
0x9a97…950d0x33ab…21fa0xc405…775f0x0141…ba140x8d8a…2d6b0x97c9…65f40xcb93…bbf30xa166…bee40x351a…8be20xc096…129c

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

What Raised This Score

10 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Mint capability UNKNOWN (implementation ABI unreadable)
  • Proxy contract (upgradeable — admin can replace logic)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 69.2% (independent LP — depth risk, pool = 59% of DEX liquidity)
  • LP top3 unlocked holders = 83.3% (independent LP — depth risk, pool = 59% of DEX liquidity)
  • 2 Critical finding(s) from audit
  • 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

Related Audits

6 more on the record
Humanity (H)Critical RiskVision (VSN)Critical RiskApple (Ondo Tokenized) (AAPLON)Critical RisktapCritical RiskSpaceX xStock (SPCXX)Critical RiskBananaCritical Risk

Would You Like a More Detailed Audit of NEAR?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit