Is Arcium (ARX) Safe? Smart Contract Security Analysis

Security Findings

2 Crit1 High1 Med2 Info

Critical

Unauditable Core Logic Due to Missing `BaseToken` Source

C-01The `PeerToken` contract inherits from `BaseToken` and explicitly delegates its core `_update` function (responsible for all token transfers, mints, and burns) to `BaseToken._update`. Without the source code for `BaseToken.sol`, it is impossible to audit the fundamental mechanics of token transfers, balance updates, and total supply management. This introduces an unknown and potentially severe vulnerability, as `BaseToken` could contain critical flaws (e.g., incorrect balance updates, reentrancy vectors, or improper handling of zero addresses) that would directly impact `PeerToken`'s integrity (7.1 Architecture, 7.2 Code Security).

IssueThe `PeerToken` contract inherits from `BaseToken` and explicitly delegates its core `_update` function (responsible for all token transfers, mints, and burns) to `BaseToken._update`. Without the source code for `BaseToken.sol`, it is impossible to audit the fundamental mechanics of token transfers, balance updates, and total supply management. This introduces an unknown and potentially severe vulnerability, as `BaseToken` could contain critical flaws (e.g., incorrect balance updates, reentrancy vectors, or improper handling of zero addresses) that would directly impact `PeerToken`'s integrity (7.1 Architecture, 7.2 Code Security).

FixProvide the complete and verified source code for `src/BaseToken.sol`. A full audit of `BaseToken` is required to ensure the security and correctness of `PeerToken`'s core functionality. Until `BaseToken` is audited, the security of `PeerToken` cannot be guaranteed.

StatusUnresolved

Critical

Critical `_update` Override Bypassing ERC20 Standard Logic

C-02The `PeerToken` contract overrides the `_update` function, which is a critical internal function in OpenZeppelin's ERC20 implementation responsible for handling all token movements. Instead of calling `super._update()` to ensure the standard ERC20 logic (e.g., balance checks, total supply updates, event emissions) is executed, `PeerToken` directly calls `return BaseToken._update(_from, _to, _value);`. This design choice means that `PeerToken`'s core transfer logic is entirely dependent on `BaseToken`'s implementation, potentially bypassing or incorrectly implementing crucial ERC20 safeguards provided by OpenZeppelin's `ERC20` contract. If `BaseToken._update` does not correctly replicate or…

IssueThe `PeerToken` contract overrides the `_update` function, which is a critical internal function in OpenZeppelin's ERC20 implementation responsible for handling all token movements. Instead of calling `super._update()` to ensure the standard ERC20 logic (e.g., balance checks, total supply updates, event emissions) is executed, `PeerToken` directly calls `return BaseToken._update(_from, _to, _value);`. This design choice means that `PeerToken`'s core transfer logic is entirely dependent on `BaseToken`'s implementation, potentially bypassing or incorrectly implementing crucial ERC20 safeguards provided by OpenZeppelin's `ERC20` contract. If `BaseToken._update` does not correctly replicate or…

FixReview the `_update` override in `PeerToken` and the implementation of `BaseToken._update`. Ensure that `BaseToken._update` correctly implements all necessary ERC20 transfer logic, including balance updates, total supply adjustments, and zero-address checks, or that it properly calls `super._update()` if `BaseToken` also inherits from `ERC20`. A safer approach in `PeerToken` might be to call `super._update()` directly if `BaseToken` is intended to be a simple extension, or to ensure `BaseToken`…

StatusUnresolved

High

Centralized Minting Authority and Unlimited Supply Risk

H-01The contract design grants significant power to the `minter` role, allowing them to mint an arbitrary amount of tokens via the `mint` function. Furthermore, the `owner` (a single external address) has the exclusive ability to change the `minter` at any time via `setMinter`. This creates a high centralization risk (7.4 Economic, 7.5 Governance). If the `owner` address or the `minter` address is compromised, an attacker could mint an unlimited supply of tokens, leading to hyperinflation and a complete loss of value for existing token holders. This also presents a single point of failure for the token's economic stability (7.8 Operations).

IssueThe contract design grants significant power to the `minter` role, allowing them to mint an arbitrary amount of tokens via the `mint` function. Furthermore, the `owner` (a single external address) has the exclusive ability to change the `minter` at any time via `setMinter`. This creates a high centralization risk (7.4 Economic, 7.5 Governance). If the `owner` address or the `minter` address is compromised, an attacker could mint an unlimited supply of tokens, leading to hyperinflation and a complete loss of value for existing token holders. This also presents a single point of failure for the token's economic stability (7.8 Operations).

FixConsider implementing a multi-signature wallet for both the `owner` and `minter` roles to distribute control and reduce the risk of a single point of failure. Explore mechanisms to cap the total supply or introduce rate limits for minting to prevent uncontrolled inflation. If unlimited minting is a core design choice, ensure robust operational security for the `minter` and `owner` keys.

StatusUnresolved

Medium

Lack of Role Renouncement or Multi-sig Integration

M-01The `Ownable` pattern is used, but there is no explicit function to renounce ownership or transfer it to a zero address, which could be a desired feature for decentralization or to prevent accidental control. Similarly, there is no mechanism to renounce the `minter` role. While `setMinter` allows changing the minter, it does not prevent setting it to a malicious address or a non-existent one if not handled carefully (though `InvalidMinterZeroAddress` prevents setting to `address(0)`). The absence of multi-signature wallet integration for these critical roles increases operational risk (7.3 Access Control, 7.8 Operations).

IssueThe `Ownable` pattern is used, but there is no explicit function to renounce ownership or transfer it to a zero address, which could be a desired feature for decentralization or to prevent accidental control. Similarly, there is no mechanism to renounce the `minter` role. While `setMinter` allows changing the minter, it does not prevent setting it to a malicious address or a non-existent one if not handled carefully (though `InvalidMinterZeroAddress` prevents setting to `address(0)`). The absence of multi-signature wallet integration for these critical roles increases operational risk (7.3 Access Control, 7.8 Operations).

FixConsider adding a `renounceOwnership()` function to allow the owner to permanently give up control, if desired for future decentralization. Implement a similar `renounceMinter()` function. For enhanced security, integrate a multi-signature wallet solution for the `owner` and `minter` roles from the outset to ensure critical operations require consensus from multiple trusted parties.

StatusUnresolved

Info

Use of Custom Errors

I-01The contract utilizes custom errors (`CallerNotMinter`, `InvalidMinterZeroAddress`) instead of traditional `require()` statements with string messages. This is a good practice in Solidity as custom errors are more gas-efficient and provide clearer, structured error information to off-chain applications (7.2 Code Security).

IssueThe contract utilizes custom errors (`CallerNotMinter`, `InvalidMinterZeroAddress`) instead of traditional `require()` statements with string messages. This is a good practice in Solidity as custom errors are more gas-efficient and provide clearer, structured error information to off-chain applications (7.2 Code Security).

FixContinue using custom errors for all revert conditions throughout the codebase. This enhances gas efficiency and improves the developer experience for integrators.

StatusUnresolved

Info

Explicit `_update` Override for Clarity

I-02The `_update` function is explicitly declared with `override(ERC20, BaseToken)`, clearly indicating that it overrides implementations from both parent contracts. This improves code readability and helps prevent potential issues in complex inheritance hierarchies (7.1 Architecture, 7.2 Code Security).

IssueThe `_update` function is explicitly declared with `override(ERC20, BaseToken)`, clearly indicating that it overrides implementations from both parent contracts. This improves code readability and helps prevent potential issues in complex inheritance hierarchies (7.1 Architecture, 7.2 Code Security).

FixMaintain explicit `override` declarations for all functions that override multiple parent implementations. This practice contributes to clearer code structure and maintainability.

StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract leverages OpenZeppelin libraries for ERC20 and Ownable functionalities, which is a good practice for code security (7.2). Custom error messages are also implemented, enhancing user experience and debugging. However, a critical architectural flaw (7.1) exists where the `PeerToken`'s `_update` function directly delegates to an unaudited `BaseToken` contract, bypassing the standard `ERC20` logic. This dependency on an unknown `BaseToken` for core transfer mechanics introduces severe uncertainty and potential vulnerabilities (7.2).

GovernanceHigh1/10

The contract implements a two-tiered access control system with an `owner` and a `minter` (7.3). The `owner` has the power to set the `minter`, and the `minter` can mint an arbitrary amount of tokens (7.4). This design introduces a high degree of centralization, as a single compromised `owner` or `minter` address could lead to unlimited token inflation, severely impacting the token's economic stability (7.4). There is no mechanism to renounce these critical roles or transfer them to a multi-signature wallet, increasing operational risk (7.8).

UpgradesHigh2/10

The PeerToken contract is not designed with upgradeability features (7.7). This means its logic is immutable once deployed, eliminating risks associated with proxy patterns or upgrade mechanisms. Any future changes would require a new contract deployment and migration of assets.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

81.7% in top 10

34.6% in wallets47.1% in contracts

Effective Concentration53.4%

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

$15.4K across 3 pairs

UniswapUSDTanalysed$14.8K Pancakeswap v3USDT$631 Pancakeswap v3USDT$4

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 Holder36.5%

Top-3 Unlocked67.3%

Key Addresses

11 addresses

Deployer

0x477d…c451

Unlocked LP Held By

0xf949…02980xaaca…f41e0x81b1…548c0xfcb8…e6690x5fbe…94c40xcf61…9b2f0x1498…d27e0x35bc…01750xe6ba…8f820xb754…9c05

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

What Raised This Score

8 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 50% (81.7% total → 53.4% effective; 34.6% in EOAs, 47.1% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($15,419 across 3 pairs — thin market)
2 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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

Not Signed In

Is Arcium Safe?

Security Findings

Unauditable Core Logic Due to Missing `BaseToken` Source

Critical `_update` Override Bypassing ERC20 Standard Logic

Centralized Minting Authority and Unlimited Supply Risk

Lack of Role Renouncement or Multi-sig Integration

Use of Custom Errors

Explicit `_update` Override for Clarity

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Arcium?