Is ARC Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low2 Info

High

Critical Dependency on External Tax Module

H-01The `ARCEnhanced` token's core transfer logic in the `_update` function is critically dependent on the external `ITaxModule` contract. The `processTransfer` function of `ITaxModule` dictates the `netAmount` of tokens transferred and the `taxCollector` address. A malicious or compromised `ITaxModule` could manipulate transfer amounts (e.g., return `0` for `netAmount` to effectively burn tokens, or return an incorrect `netAmount`), block transfers by reverting, or redirect funds to an unauthorized `taxCollector`, severely impacting the token's functionality and economic stability (7.6 External, 7.4 Economic).

IssueThe `ARCEnhanced` token's core transfer logic in the `_update` function is critically dependent on the external `ITaxModule` contract. The `processTransfer` function of `ITaxModule` dictates the `netAmount` of tokens transferred and the `taxCollector` address. A malicious or compromised `ITaxModule` could manipulate transfer amounts (e.g., return `0` for `netAmount` to effectively burn tokens, or return an incorrect `netAmount`), block transfers by reverting, or redirect funds to an unauthorized `taxCollector`, severely impacting the token's functionality and economic stability (7.6 External, 7.4 Economic).

FixImplement robust validation and safeguards for the `taxModule` address, such as a timelock for `setTaxModule` changes. Crucially, a thorough security audit of the `ITaxModule` implementation is paramount to ensure its integrity and prevent potential exploits. Consider implementing circuit breakers or emergency mechanisms within `ARCEnhanced` to disable the tax system if the `ITaxModule` misbehaves.

StatusUnresolved

Medium

Centralized Control over Tax Module

M-01The `owner` has sole authority to set and remove the `taxModule` via `setTaxModule` and `removeTaxModule` functions. This centralization allows a single entity to introduce or remove a contract that can arbitrarily tax or block all token transfers, posing a significant economic and operational risk to token holders. A compromised owner key could lead to severe consequences (7.3 Access Control, 7.5 Governance, 7.8 Operations).

IssueThe `owner` has sole authority to set and remove the `taxModule` via `setTaxModule` and `removeTaxModule` functions. This centralization allows a single entity to introduce or remove a contract that can arbitrarily tax or block all token transfers, posing a significant economic and operational risk to token holders. A compromised owner key could lead to severe consequences (7.3 Access Control, 7.5 Governance, 7.8 Operations).

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the contract's ownership. Additionally, consider introducing a timelock mechanism for `setTaxModule` and `removeTaxModule` functions to provide a delay before changes take effect, allowing the community to react to potentially malicious or erroneous updates.

StatusUnresolved

Low

Lack of Robust Input Validation for `setTaxModule`

L-01The `setTaxModule` function only checks that the `_taxModule` address is not `address(0)`. There is no further validation to ensure that the provided address actually implements the `ITaxModule` interface correctly or behaves as expected. Setting an arbitrary contract address that does not conform to the interface or contains malicious logic could lead to unexpected reverts in `_update` or incorrect tax calculations, effectively disrupting token transfers (7.2 Code Security).

IssueThe `setTaxModule` function only checks that the `_taxModule` address is not `address(0)`. There is no further validation to ensure that the provided address actually implements the `ITaxModule` interface correctly or behaves as expected. Setting an arbitrary contract address that does not conform to the interface or contains malicious logic could lead to unexpected reverts in `_update` or incorrect tax calculations, effectively disrupting token transfers (7.2 Code Security).

FixEnhance the `setTaxModule` function with more robust validation. This could include checking for specific function selectors (e.g., `ITaxModule(newModule).processTransfer.selector`) or using `try-catch` blocks during a test call to ensure the new module responds as expected before setting it. Alternatively, ensure that any `ITaxModule` implementation is thoroughly audited and whitelisted.

StatusUnresolved

Info

Unspecified `ITaxModule` Access Control and Governance

I-01The `ITaxModule` interface includes critical functions such as `setTaxRates`, `setTaxCollector`, `setTaxEnabled`, `setTaxExemption`, and `emergencyDisableTax`. The access control and governance mechanisms for these functions within the `ITaxModule` contract itself are not specified in the provided `ARCEnhanced` code. This creates an implicit dependency on the `ITaxModule`'s internal security and governance, which is outside the scope of this audit (7.5 Governance, 7.6 External).

IssueThe `ITaxModule` interface includes critical functions such as `setTaxRates`, `setTaxCollector`, `setTaxEnabled`, `setTaxExemption`, and `emergencyDisableTax`. The access control and governance mechanisms for these functions within the `ITaxModule` contract itself are not specified in the provided `ARCEnhanced` code. This creates an implicit dependency on the `ITaxModule`'s internal security and governance, which is outside the scope of this audit (7.5 Governance, 7.6 External).

FixEnsure the `ITaxModule` contract has robust and transparent access control mechanisms, ideally a multi-signature wallet or a well-defined governance process, to manage its critical parameters. The ownership and control of the `ITaxModule` should be clearly documented and understood by all stakeholders.

StatusUnresolved

Info

Hardcoded Token Name and Symbol

I-02The token name 'ARC' and symbol 'ARC' are hardcoded within the `initialize` function using `__ERC20_init("ARC", "ARC")` and `__ERC20Permit_init("ARC")`. While this is a common practice for ERC20 tokens, it means these values cannot be changed without performing a contract upgrade (7.1 Architecture).

IssueThe token name 'ARC' and symbol 'ARC' are hardcoded within the `initialize` function using `__ERC20_init("ARC", "ARC")` and `__ERC20Permit_init("ARC")`. While this is a common practice for ERC20 tokens, it means these values cannot be changed without performing a contract upgrade (7.1 Architecture).

FixThis is a design choice and not a vulnerability. If flexibility to change the token name or symbol post-deployment is ever desired, these values would need to be stored in state variables and managed by an owner-controlled function, which would require an upgrade to the current implementation.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin libraries for ERC20, upgradeability (UUPS), and access control (Ownable), contributing to a solid technical foundation (7.1 Architecture, 7.2 Code Security). The `_update` function is correctly overridden to integrate the tax logic, ensuring proper token flow. However, the critical dependency on the external `ITaxModule` contract introduces a significant technical risk (7.6 External), as its implementation is unknown and could lead to unexpected behavior or vulnerabilities if compromised or poorly designed. The lack of robust validation for the `taxModule` address further exacerbates this dependency (7.2 Code Security).

GovernanceHigh1/10

The contract employs an `Ownable` access control pattern, granting the owner significant power over critical functions such as pausing/unpausing transfers and managing the `taxModule` (7.3 Access Control, 7.5 Governance). This centralization, while common, poses an economic risk as a single entity can introduce or remove a tax system that directly impacts token transfers and value (7.4 Economic). The `ITaxModule` itself, whose governance is external to this contract, can dictate tax rates and collectors, creating a multi-layered governance dependency that needs careful consideration (7.5 Governance).

UpgradesHigh3/10

The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's `UUPSUpgradeable` module (7.7 Upgrades). The `_authorizeUpgrade` function is appropriately restricted to the `onlyOwner` modifier, ensuring that only the authorized entity can initiate upgrades. The `initialize` function and `_disableInitializers` in the constructor are correctly used, preventing re-initialization attacks. This setup provides a secure and standard mechanism for future contract enhancements.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

58.9% in top 10

27.7% in wallets31.2% in contracts

Effective Concentration40.2%

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

$122.6K across 2 pairs

Uniswap v2WETHanalysed$122.6K Uniswap v4ETH$28

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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xd1e0…d776

Unlocked LP Held By

0x887a…281e0xfee5…98fc

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

9 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (58.9% total → 40.2% effective; 27.7% in EOAs, 31.2% in contracts — moderate)
LP top1 unlocked holder = 100.0% (exit-liquidity risk)
LP top3 unlocked holders = 100.0% (exit-liquidity risk)
LP claimed locked but only 0.0% actually locked
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

Not Signed In

Is ARC Safe?

Security Findings

Critical Dependency on External Tax Module

Centralized Control over Tax Module

Lack of Robust Input Validation for `setTaxModule`

Unspecified `ITaxModule` Access Control and Governance

Hardcoded Token Name and Symbol

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ARC?