Quantum Audit Logo

Is JPY Coin Safe?

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

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

JPY Coin JPYC
0xe7c3…3c29
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 4d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The FiatTokenV1 contract serves as the implementation for an ERC-20 compatible token, incorporating features like pausing, blocklisting, minting/burning, and UUPS upgradeability. The contract demonstrates robust access control for critical functions and adheres to Solidity 0.8.x's default overflow/underflow protection. However, a significant issue was identified where the contract blocklists itself, preventing the rescue of its own tokens if accidentally sent to the contract address. Other findings include limitations in EIP-712 versioning during upgrades and the inherent centralization of control, albeit mitigated by a multisig owner.

1 High1 Medium1 Low1 Informational
Volume 24h
$563.0K
Liquidity
$63.0K
Price
$0.00643
Token Age
6mo
Top 10 Holders
100.0%

Security Findings

1 High1 Med1 Low1 Info
High

FiatTokenV1 Tokens Locked Due to Self-Blocklisting

H-01The `initialize` function explicitly blocklists the contract's own address by setting `blocklisted[address(this)] = 1;`. This action prevents any `_transfer` operation where the `from` address is the contract itself, due to the `notBlocklisted(from)` modifier. Consequently, if FiatTokenV1 tokens are accidentally sent to the FiatTokenV1 contract address, the `rescueERC20` function (inherited from `Rescuable`) will fail when attempting to transfer these tokens out, as it would call `_transfer` with `from = address(this)`. This leads to the permanent locking of any FiatTokenV1 tokens sent to the contract address.
IssueThe `initialize` function explicitly blocklists the contract's own address by setting `blocklisted[address(this)] = 1;`. This action prevents any `_transfer` operation where the `from` address is the contract itself, due to the `notBlocklisted(from)` modifier. Consequently, if FiatTokenV1 tokens are accidentally sent to the FiatTokenV1 contract address, the `rescueERC20` function (inherited from `Rescuable`) will fail when attempting to transfer these tokens out, as it would call `_transfer` with `from = address(this)`. This leads to the permanent locking of any FiatTokenV1 tokens sent to the contract address.
FixRemove the line `blocklisted[address(this)] = 1;` from the `initialize` function. Instead, implement a specific check within the `_transfer` function to prevent transfers *to* `address(this)` if the intent is to prevent tokens from being held by the contract, or ensure that the `rescueERC20` function explicitly bypasses the blocklist check for `address(this)` when rescuing its own token.
StatusUnresolved
Medium

Hardcoded EIP-712 Version Limits Upgrade Flexibility

M-01The `VERSION` string used for the EIP-712 domain separator is hardcoded to '1' in the `initialize` function. While the `initialize` function prevents re-initialization, this means that if a future upgrade requires changing the token's `name` or the EIP-712 `VERSION` (e.g., for a major protocol revision), the `DOMAIN_SEPARATOR` cannot be updated. This could lead to incompatibility with existing signed messages or limit branding flexibility in future versions.
IssueThe `VERSION` string used for the EIP-712 domain separator is hardcoded to '1' in the `initialize` function. While the `initialize` function prevents re-initialization, this means that if a future upgrade requires changing the token's `name` or the EIP-712 `VERSION` (e.g., for a major protocol revision), the `DOMAIN_SEPARATOR` cannot be updated. This could lead to incompatibility with existing signed messages or limit branding flexibility in future versions.
FixConsider making the EIP-712 `VERSION` configurable by the owner or `minterAdmin` through a dedicated function, or ensure that future upgrade plans account for the immutability of this parameter. If the token name is expected to remain constant, this issue's impact is reduced.
StatusUnresolved
Low

Centralized Control by Owner Role

L-01The `owner` role possesses significant control over critical contract functions, including the ability to pause/unpause the contract, blocklist/unblocklist addresses, update the `minterAdmin`, and initiate contract upgrades. While the prefill indicates the owner is a multisig, this still represents a centralized point of control. A compromise or malicious action by the multisig signers could lead to severe consequences for the protocol and its users.
IssueThe `owner` role possesses significant control over critical contract functions, including the ability to pause/unpause the contract, blocklist/unblocklist addresses, update the `minterAdmin`, and initiate contract upgrades. While the prefill indicates the owner is a multisig, this still represents a centralized point of control. A compromise or malicious action by the multisig signers could lead to severe consequences for the protocol and its users.
FixMaintain strict operational security practices for the multisig wallet controlling the `owner` role. Consider exploring further decentralization strategies for critical governance functions in future iterations, such as time-locks for sensitive operations or community-driven governance mechanisms.
StatusUnresolved
Info

Storage Layout Management for UUPS Upgrades

I-01As a UUPS upgradeable contract, `FiatTokenV1` relies on careful management of its storage layout across different implementation versions. Adding, removing, or reordering state variables in future contract upgrades without proper planning and adherence to UUPS storage guidelines can lead to storage collisions, data corruption, and unexpected behavior in the upgraded contract.
IssueAs a UUPS upgradeable contract, `FiatTokenV1` relies on careful management of its storage layout across different implementation versions. Adding, removing, or reordering state variables in future contract upgrades without proper planning and adherence to UUPS storage guidelines can lead to storage collisions, data corruption, and unexpected behavior in the upgraded contract.
FixEstablish and strictly follow a robust storage layout management strategy for all future upgrades. Utilize tools like `hardhat-upgrades` or `openzeppelin-upgrades` to detect storage layout incompatibilities during development and testing. Document the storage slot usage for all state variables to aid in future upgrade planning.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract exhibits good technical design, adhering to ERC-20 standards and utilizing Solidity 0.8.11 for built-in overflow/underflow protection (7.2 Code Security). Access control mechanisms for minting, burning, pausing, and blocklisting are well-defined and appropriately enforced (7.3 Access Control). However, a critical flaw exists where the contract blocklists its own address during initialization, which prevents the `Rescuable` functionality from retrieving FiatTokenV1 tokens accidentally sent to the contract, leading to permanent fund loss (7.2 Code Security, 7.8 Operations).

GovernanceHigh1/10

The economic model centers around a controlled supply via minters, managed by a `minterAdmin` (7.4 Economic). While the `owner` role holds significant power over critical functions such as pausing, blocklisting, and upgrading, this risk is mitigated by the owner being a multisig (7.5 Governance). The separation of roles (owner, minterAdmin, pauser, blocklister, rescuer) is a strength, but the centralized nature of these roles still presents a single point of failure if the controlling entities are compromised (7.3 Access Control).

UpgradesHigh1/10

The contract implements the UUPS upgradeability pattern, ensuring future flexibility and maintainability (7.7 Upgrades). The `initialize` function correctly uses an `initializedVersion` check to prevent re-initialization after deployment or upgrade. However, the EIP-712 `VERSION` string is hardcoded, which could limit flexibility if the token's name or EIP-712 versioning needs to change in future upgrades (7.7 Upgrades). Careful storage layout management is essential for subsequent upgrades to prevent data corruption.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

100.0% in top 10
100.0% in wallets0.0% in contracts
Effective Concentration100.0%

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

$128.6K across 6 pairs
Uniswap v4DAIanalysed$63.0K49.0%Uniswap v4USDC$36.8K28.6%Uniswap v4USDC$27.7K21.5%Uniswap v4USDT$8950.7%Uniswap v4ETH$930.1%ShibaswapUSDC$640.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.

Key Addresses

1 addresses
Deployer
0x11f1…9384

What Raised This Score

8 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 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
COTICritical Riskdmt-natCritical RiskAllora (ALLO)Critical RiskGensyn (AI)Critical RiskCaldera (ERA)Critical RiskBluzelle Token (BLZ)Critical Risk

Would You Like a More Detailed Audit of JPY Coin?

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

Get Detailed Audit