Quantum Audit Logo

Is Euro Coin Safe?

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

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

Euro Coin EURC
0x1aba…c33c
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the FiatTokenV2_2 implementation contract, which serves as the logic for a proxy-based ERC-20 stablecoin. The contract introduces a new storage mechanism for balances and blacklist status, combining them into a single mapping. While the new bit-packing logic is technically sound, the upgrade path from previous versions (e.g., FiatTokenV1) that used separate storage mappings for balances and blacklisted accounts appears to be critically flawed. The `initializeV2_2` function only migrates blacklisted accounts, not existing token balances, leading to a high risk of data loss for all user balances upon upgrade. Other aspects, such as EIP-712 signature handling and access controls, are implemented robustly, but the upgrade safety issue overshadows these strengths.

1 Critical3 Informational
Volume 24h
$1.25M
Liquidity
$3.52M
Price
$1.1600
Token Age
4y
Top 10 Holders
39.9%

Security Findings

1 Crit3 Info
Critical

Critical Upgrade Storage Collision and Data Loss

C-01The `FiatTokenV2_2` contract introduces a new storage mechanism by overriding `_balanceOf`, `_isBlacklisted`, `_setBalance`, and `_setBlacklistState` to use a single `balanceAndBlacklistStates` mapping. Previous versions, such as `FiatTokenV1`, utilized separate `_balances` and `_blacklisted` mappings. The `initializeV2_2` function, intended for upgrade logic, only migrates accounts from `_deprecatedBlacklisted` to the new `balanceAndBlacklistStates` format. Crucially, it lacks any migration logic for existing token balances stored in the `_balances` mapping from prior versions. This design flaw means that upon upgrading to `FiatTokenV2_2` from a version using separate balance storage, all…
IssueThe `FiatTokenV2_2` contract introduces a new storage mechanism by overriding `_balanceOf`, `_isBlacklisted`, `_setBalance`, and `_setBlacklistState` to use a single `balanceAndBlacklistStates` mapping. Previous versions, such as `FiatTokenV1`, utilized separate `_balances` and `_blacklisted` mappings. The `initializeV2_2` function, intended for upgrade logic, only migrates accounts from `_deprecatedBlacklisted` to the new `balanceAndBlacklistStates` format. Crucially, it lacks any migration logic for existing token balances stored in the `_balances` mapping from prior versions. This design flaw means that upon upgrading to `FiatTokenV2_2` from a version using separate balance storage, all…
FixIf this contract was deployed as an upgrade from a version with separate `_balances` and `_blacklisted` mappings, an immediate and comprehensive audit of the upgrade process is required. A robust migration strategy must be implemented to transfer all existing token balances from the old `_balances` mapping to the new `balanceAndBlacklistStates` mapping during the upgrade. This typically involves a dedicated migration function or a more sophisticated proxy upgrade mechanism that handles storage…
StatusUnresolved
Info

Centralized Control by Privileged Roles

I-01The contract inherits functionalities such as pausing and blacklisting, which grant significant control to privileged roles (e.g., owner, pauser, blacklister). These roles can pause all transfers, blacklist specific accounts (preventing them from sending/receiving tokens), and potentially mint/burn tokens (inherited from parent contracts). While common for stablecoins to ensure regulatory compliance and emergency response, this centralization introduces a single point of failure and trust, as a compromise of these roles could have severe consequences.
IssueThe contract inherits functionalities such as pausing and blacklisting, which grant significant control to privileged roles (e.g., owner, pauser, blacklister). These roles can pause all transfers, blacklist specific accounts (preventing them from sending/receiving tokens), and potentially mint/burn tokens (inherited from parent contracts). While common for stablecoins to ensure regulatory compliance and emergency response, this centralization introduces a single point of failure and trust, as a compromise of these roles could have severe consequences.
FixEnsure that the private keys controlling these privileged roles are secured with the highest industry standards (e.g., multi-signature wallets, hardware security modules, robust access control policies). Consider implementing a time-lock mechanism for critical administrative actions to provide a window for community review or emergency intervention.
StatusUnresolved
Info

Hardcoded EIP-712 Domain Version String

I-02The `_domainSeparator()` function uses `EIP712.makeDomainSeparator` with a hardcoded version string of `"2"`. While this is a common practice for EIP-712 domains, if future contract upgrades introduce significant changes to the EIP-712 message structures or authorization logic, maintaining a static domain version might lead to confusion or require careful external communication to users about which domain version corresponds to which contract version. It might also imply that all `FiatTokenV2.x` versions share the same EIP-712 domain, which should be explicitly documented.
IssueThe `_domainSeparator()` function uses `EIP712.makeDomainSeparator` with a hardcoded version string of `"2"`. While this is a common practice for EIP-712 domains, if future contract upgrades introduce significant changes to the EIP-712 message structures or authorization logic, maintaining a static domain version might lead to confusion or require careful external communication to users about which domain version corresponds to which contract version. It might also imply that all `FiatTokenV2.x` versions share the same EIP-712 domain, which should be explicitly documented.
FixDocument the rationale behind the hardcoded EIP-712 domain version `"2"` and clarify its relationship to the contract's semantic versioning (e.g., `V2_2`). If future changes to EIP-712 message structures are anticipated, consider making the EIP-712 version string configurable or derive it from the contract's semantic version to avoid potential ambiguities.
StatusUnresolved
Info

Blacklisting of Implementation Contract Address

I-03The `initializeV2_2` function explicitly calls `_blacklist(address(this))`, which blacklists the implementation contract itself. While implementation contracts are generally not intended to hold tokens, if tokens were accidentally sent to this address, they would become permanently locked and unrecoverable due to the blacklisting status. This is an edge case but represents a potential loss of funds if such an accidental transfer occurs.
IssueThe `initializeV2_2` function explicitly calls `_blacklist(address(this))`, which blacklists the implementation contract itself. While implementation contracts are generally not intended to hold tokens, if tokens were accidentally sent to this address, they would become permanently locked and unrecoverable due to the blacklisting status. This is an edge case but represents a potential loss of funds if such an accidental transfer occurs.
FixConfirm that there are no scenarios where the implementation contract is expected to hold tokens. If there are, re-evaluate the necessity of blacklisting `address(this)`. Otherwise, ensure clear documentation and operational procedures are in place to prevent accidental token transfers to the implementation contract address.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates strong technical implementation for its core functionalities, including robust EIP-712 signature handling for delegated operations and an efficient bit-packing mechanism for combining balance and blacklist status in storage (7.2 Code Security). The use of `whenNotPaused` and `notBlacklisted` modifiers ensures proper access control during critical operations (7.3 Access Control). However, a critical vulnerability exists in the upgrade mechanism related to storage layout changes, which could lead to severe data loss (7.1 Architecture).

GovernanceMedium4/10

The contract incorporates standard stablecoin governance features such as pausing and blacklisting, which are essential for emergency response and regulatory compliance (7.5 Governance). EIP-712 authorizations enhance user experience by enabling delegated transactions. However, these features inherently centralize significant control in privileged roles, posing a medium economic risk due to potential misuse or compromise of these roles (7.4 Economic).

UpgradesHigh1/10

The contract is designed as an upgradeable proxy implementation, featuring a versioned initializer (`initializeV2_2`) to manage upgrade logic (7.7 Upgrades). This initializer includes specific migration steps for previously blacklisted accounts. Despite these efforts, a critical flaw exists: the contract changes the storage layout for balances and blacklist status from separate mappings (in `FiatTokenV1`) to a combined `balanceAndBlacklistStates` without migrating existing user balances, leading to a complete loss of all token balances upon upgrade.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeZeppelin Os Legacy
AdminEOA (single key controls upgrades)
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

39.9% in top 10
10.6% in wallets29.2% in contracts
Effective Concentration22.3%

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

$6.61M across 13 pairs
Uniswap v3USDCanalysed$3.52M53.2%Uniswap v4USDC$1.65M24.9%Uniswap v4USDC$635.8K9.6%Uniswap v4ETH$514.5K7.8%Uniswap v4USDC$199.9K3.0%Uniswap v3USDT$36.5K0.6%
Show 4 more pairsShow less
Uniswap v4USDT$30.1K0.5%SupernovaUSDC$13.2K0.2%Curve stblEURQ$12.2K0.2%Curve stblEURS$4.1K0.1%

The 3 remaining pairs hold $944 between them and are not listed.

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 Holder13.7%
Top-3 Unlocked39.2%

Key Addresses

11 addresses
Deployer
0xe0bb…e69f
Unlocked LP Held By
0xd2c3…8eb90x41df…ea1c0x1118…8af80x19a0…0feb0x27aa…a16d0xc93a…f89e0xd297…78d40x1a0e…980b0xa9d0…235c0xea57…13d2

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 20% (39.9% total → 22.3% effective; 10.6% in EOAs, 29.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical 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
Satellite Doge-1 (DOGE-1)Medium RiskBiconomy (BICO)Medium RiskLisk (LSK)Medium RiskNeiroMedium RiskCurve.Fi USD Stablecoin (CRVUSD)Medium RiskWorldcoin (WLD)Medium Risk

Would You Like a More Detailed Audit of Euro Coin?

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

Get Detailed Audit