Is EURC Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedFail

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

1 audit on record

Jul 2476

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

This audit covers the FiatTokenV2_2 contract, which serves as the implementation logic for a USDC stablecoin proxy on the Base network. The contract implements ERC-20 functionalities, EIP-712 signed messages, and a custom blacklisting mechanism. The codebase is generally well-structured and follows established patterns for stablecoin operations, including upgradeability. Key findings highlight the inherent centralization risks typical for stablecoins and the complexity introduced by a non-standard blacklist storage method.

Final Recommendation: It is recommended to enhance the security posture of critical administrative roles, particularly the proxy admin, by transitioning from a single EOA to a robust multi-signature wallet with a high threshold or a time-locked governance mechanism. Thorough internal documentation for the custom blacklist storage mechanism should be maintained to mitigate future integration risks. Additionally, ensure comprehensive testing of upgrade paths on testnets, especially for functions involving state migrations like `initializeV2_2`, to prevent potential issues during live deployments.

Category Ratings

TechnicalHigh

3/10

The technical architecture (7.1) is robust, leveraging an upgradeable proxy pattern and EIP-712 for off-chain signed transactions. Code security (7.2) is generally strong, with appropriate checks for reentrancy and integer overflows, and a specific check in `receiveWithAuthorization` to prevent fron

GovernanceHigh

2/10

The economic model (7.4) is that of a centralized stablecoin, backed by fiat reserves, which inherently carries a high level of governance risk (7.5). Critical functions such as blacklisting, pausing, and upgrades are controlled by privileged addresses, typically EOAs or multi-signature wallets. Thi

UpgradesHigh

2/10

The contract utilizes a ZeppelinOS legacy proxy pattern, allowing for seamless upgrades of the token logic (7.7). The `initializeV2_2` function is designed for a controlled, single-time execution during an upgrade, ensuring proper state migration and versioning. However, the proxy's admin addre

What Raised This Score

7 factors

Ownership NOT renounced — owner is an EOA (single private key)
Mintable supply — no cap found, dilution unbounded
Contract source NOT verified
Liquidity NOT locked (owner can withdraw — rug-pull risk)
1 High finding(s) from audit
1 Medium finding(s) from audit
2 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

Security Findings

5 total

1 High 1 Medium 2 Low 1 Info

H-01HighUnresolved

Centralized Control and Single Point of Failure

The contract design, typical for a centralized stablecoin, grants significant power to a small set of privileged addresses (admin, owner, pauser, blacklister). These roles can pause transfers, blacklist accounts, and control contract upgrades. The proxy's admin is an EOA, representing a single point of failure for upgradeability and overall contract control. A compromise of this EOA could lead to unauthorized upgrades or manipulation of critical contract functions (7.3 Access Control, 7.5 Governance, 7.8 Operations).

Recommendation: While inherent to stablecoin design, consider implementing multi-signature wallets or a time-locked governance mechanism for critical administrative functions, especially the proxy admin, to reduce the risk associated with a single EOA compromise. This enhances operational security and resilience against key loss.

M-01MediumUnresolved

Non-Standard Balance and Blacklist Storage Mechanism

The contract employs a custom storage mechanism where `balanceAndBlacklistStates` uses a single `uint256` to store both an account's balance (lower 255 bits) and its blacklist status (most significant bit). While the implementation appears correct and includes checks like `_balance <= ((1 << 255) - 1)` to prevent overflow into the blacklist bit, this non-standard approach increases complexity and could be a source of subtle bugs or integration issues if not perfectly maintained or understood by external systems (7.1 Architecture, 7.2 Code Security).

Recommendation: Ensure thorough internal documentation and testing for this custom storage logic. Future upgrades or integrations should exercise extreme caution when interacting with or modifying this specific storage pattern to prevent unintended side effects or data corruption.

L-01LowUnresolved

Self-Blacklisting in `initializeV2_2`

The `initializeV2_2` function explicitly blacklists the contract's own address (`_blacklist(address(this))`). While this might be intended to prevent tokens from being accidentally sent to and locked within the contract itself, it is an unusual pattern that could have unforeseen implications for future interactions or integrations if not fully understood by all parties (7.2 Code Security, 7.8 Operations).

Recommendation: Document the precise rationale behind blacklisting the contract address. Confirm that this action does not interfere with any expected contract functionalities, such as receiving tokens from other contracts, or future upgrade paths that might require the contract to hold tokens temporarily.

L-02LowUnresolved

Reliance on `_chainId()` for EIP-712 Domain Separator

The `_domainSeparator()` function uses `_chainId()` (which retrieves the chain ID via assembly) as part of the EIP-712 domain separator. While standard practice for EIP-712, if the contract were to be deployed on a chain with an unexpected chain ID, or if a chain's ID were to change (highly improbable for established networks), it would invalidate all existing EIP-712 signatures, requiring users to re-sign (7.2 Code Security, 7.6 External).

Recommendation: This is generally robust for stable chains like Base. No direct action is required, but it's a consideration for deployment on new or less stable networks, or if the contract were to be forked to a chain with a different ID, as it would necessitate re-issuing signatures.

I-01InformationalUnresolved

Single-Use Upgrade Initialization Function

The `initializeV2_2` function includes a `require(_initializedVersion == 2);` check, ensuring it can only be called once and only when the previous version was correctly initialized. This is a standard and secure pattern for upgradeable contracts. However, if the initialization process were to fail mid-execution (e.g., due to an out-of-gas error or an unexpected revert within the `accountsToBlacklist` loop), the function could not be retried, potentially leaving the contract in an inconsistent state (7.7 Upgrades, 7.8 Operations).

Recommendation: Ensure that the `accountsToBlacklist` array is processed efficiently and within gas limits, especially for large lists. Consider robust pre-deployment testing of the upgrade path on a testnet with realistic data to minimize the risk of failure during the single allowed execution.

Is EURC Safe? EURC