Quantum Audit Logo
Launch App

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

Is America Pac Safe?

PACEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance9/10Upgrades10/10Checks passed5 of 5Findings3 Low · 3 Info6
SummaryAI Copilot

This audit covers a partial Solidity contract, including standard OpenZeppelin Ownable and Context patterns, Uniswap V2 interfaces, and a SafeMath library.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 3 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (49.6% total → 30.4% effective; 17.6% in EOAs, 32.1% in contracts — moderate)
  • 3 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 Checklist

as of audit · Sep 45 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
32.1%Contracts17.6%Wallets50.4%Everyone else
32.1%Contracts17.6%Wallets50.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
49.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking32.1%
  • Walletsanonymous holders, free to sell17.6%
  • Everyone elsethe rest of the supply50.4%
Effective concentrationwhat the score reads30.4%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$90.9K

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$90.9KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Security Findings

3 Low3 Info
Low

Lack of Emergency Stop or Pause Mechanism

The provided contract snippet does not include an emergency stop or pause mechanism. In complex DeFi protocols or token contracts, such a mechanism can be crucial to mitigate unforeseen vulnerabilities, external attacks, or critical errors by temporarily halting sensitive operations. Without it, the contract remains fully operational even during a crisis. (7.8 Operations)L-01

Issue

The provided contract snippet does not include an emergency stop or pause mechanism. In complex DeFi protocols or token contracts, such a mechanism can be crucial to mitigate unforeseen vulnerabilities, external attacks, or critical errors by temporarily halting sensitive operations. Without it, the contract remains fully operational even during a crisis. (7.8 Operations)

Fix

Consider implementing a pause functionality, potentially controlled by a multi-signature wallet or a time-locked governance, to allow for emergency responses. This should be balanced with decentralization goals and clearly communicated to users.

Status

Unresolved

Low

No Reentrancy Guard for External Calls

While no direct reentrancy vector is visible in the provided code snippet, any contract that interacts with external contracts (e.g., IERC20 transfer/transferFrom, IUniswapV2Router02 swaps) and handles ETH or token transfers in a complex way should implement reentrancy guards. The absence of such guards is a general best practice deviation that could lead to vulnerabilities if the full contract logic involves state changes after external calls. (7.2 Code Security)L-02

Issue

While no direct reentrancy vector is visible in the provided code snippet, any contract that interacts with external contracts (e.g., IERC20 transfer/transferFrom, IUniswapV2Router02 swaps) and handles ETH or token transfers in a complex way should implement reentrancy guards. The absence of such guards is a general best practice deviation that could lead to vulnerabilities if the full contract logic involves state changes after external calls. (7.2 Code Security)

Fix

Apply the 'Checks-Effects-Interactions' pattern and use reentrancy guards (e.g., OpenZeppelin's ReentrancyGuard or a custom mutex) for any functions that make external calls to untrusted contracts, especially when state changes occur after the call.

Status

Unresolved

Low

Irreversible Ownership Renunciation

The contract utilizes the Ownable pattern, and according to deployment data, ownership has been renounced. While this decentralizes control and removes the risk of a malicious owner, it also means that no single entity can perform administrative actions, such as pausing the contract in an emergency, upgrading it, or fixing potential bugs. This introduces a risk of immutability if a critical vulnerability is discovered post-deployment. (7.5 Governance, 7.8 Operations)L-03

Issue

The contract utilizes the Ownable pattern, and according to deployment data, ownership has been renounced. While this decentralizes control and removes the risk of a malicious owner, it also means that no single entity can perform administrative actions, such as pausing the contract in an emergency, upgrading it, or fixing potential bugs. This introduces a risk of immutability if a critical vulnerability is discovered post-deployment. (7.5 Governance, 7.8 Operations)

Fix

Acknowledge the implications of renounced ownership. For future projects, consider implementing a multi-signature wallet for critical administrative functions or a time-locked governance mechanism if some level of post-deployment flexibility is desired, balancing decentralization with operational safety.

Status

Unresolved

Info

Redundant SafeMath Usage in Solidity 0.8.x

The contract includes the SafeMath library. In Solidity versions 0.8.0 and higher, arithmetic operations automatically revert on overflow/underflow by default. Therefore, explicit SafeMath usage for basic add, sub, mul, div functions is largely redundant and can slightly increase gas costs. The try* functions also offer limited additional benefit unless specific error handling is required beyond simple reversion. (7.2 Code Security)I-01

Issue

The contract includes the SafeMath library. In Solidity versions 0.8.0 and higher, arithmetic operations automatically revert on overflow/underflow by default. Therefore, explicit SafeMath usage for basic add, sub, mul, div functions is largely redundant and can slightly increase gas costs. The try* functions also offer limited additional benefit unless specific error handling is required beyond simple reversion. (7.2 Code Security)

Fix

For Solidity 0.8.x and above, consider removing redundant SafeMath calls for basic arithmetic operations to optimize gas usage and simplify code, relying on the compiler's default overflow/underflow checks. Keep SafeMath only for custom operations like per or if unchecked blocks are intentionally used for specific performance optimizations.

Status

Unresolved

Info

per function in SafeMath Requires Careful Usage

The SafeMath library includes a custom per function defined as a * b / 100, with a require(b <= 100). This function assumes b represents a percentage value between 0 and 100. If b is intended to be a basis point (e.g., 1/10000) or another scaling factor, its misuse could lead to incorrect calculations. (7.2 Code Security)I-02

Issue

The SafeMath library includes a custom per function defined as a * b / 100, with a require(b <= 100). This function assumes b represents a percentage value between 0 and 100. If b is intended to be a basis point (e.g., 1/10000) or another scaling factor, its misuse could lead to incorrect calculations. (7.2 Code Security)

Fix

Ensure that all usages of the per function consistently interpret b as a percentage between 0 and 100. If other scaling factors are needed, consider creating separate, clearly named functions (e.g., basisPoints, permille) to avoid ambiguity and potential calculation errors.

Status

Unresolved

Info

Incomplete Contract Code Provided

The provided Solidity source code for the main 'PAC' contract is truncated, with only interfaces, libraries, and base contracts (Context, Ownable) being fully visible. The core logic and functionality of the 'PAC' token contract itself are missing. This significantly limits the scope and depth of the security audit. (7.1 Architecture)I-03

Issue

The provided Solidity source code for the main 'PAC' contract is truncated, with only interfaces, libraries, and base contracts (Context, Ownable) being fully visible. The core logic and functionality of the 'PAC' token contract itself are missing. This significantly limits the scope and depth of the security audit. (7.1 Architecture)

Fix

Provide the complete and untruncated source code for all contracts intended for audit to enable a comprehensive security review. A full audit cannot be performed without access to the entire codebase.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

This audit covers a partial Solidity contract, including standard OpenZeppelin Ownable and Context patterns, Uniswap V2 interfaces, and a SafeMath library. The primary contract logic for 'PAC' was truncated, limiting the scope of a full security assessment. Based on the available code and deployment data indicating renounced ownership, the identified risks are primarily informational and low severity, focusing on best practices and design considerations.

Technical10/10Low risk

The contract utilizes standard OpenZeppelin Ownable and Context patterns, along with well-known Uniswap V2 interfaces (IUniswapV2Factory, IUniswapV2Pair, IUniswapV2Router02). The inclusion of SafeMath is largely redundant for basic arithmetic in Solidity 0.8.20+, which inherently checks for overflows/underflows (7.2 Code Security). Key security practices like reentrancy guards are not explicitly visible, which is a general concern for contracts interacting with external systems (7.2 Code Security). The per function in SafeMath provides a custom percentage calculation, which requires careful usage to avoid misinterpretation (7.2 Code Security).

Governance9/10Low risk

The contract employs the Ownable access control pattern (7.3 Access Control). According to deployment data, ownership has been renounced, which decentralizes control and removes the risk of a single point of failure or malicious owner actions (7.5 Governance). However, this also means that no single entity can perform administrative actions, such as pausing the contract in an emergency or upgrading it, which introduces a risk of immutability if a critical bug is discovered (7.8 Operations). There are no visible complex economic mechanisms or governance structures beyond basic ownership.

Upgrades10/10Low risk

The contract is not designed with an upgradeability pattern (e.g., proxy contracts) (7.7 Upgrades). This means the contract's logic is immutable once deployed. While this simplifies the architecture by removing upgrade-related risks, it also prevents any future bug fixes, feature enhancements, or parameter adjustments without a complete redeployment and migration of assets.

Final RecommendationWhat to do about this score

It is recommended to conduct a full audit of the complete contract code to ensure all functionalities are secure and robust, especially given the current truncation.

Implement reentrancy guards for any functions that interact with external contracts and handle token transfers to prevent potential attacks. For future projects, carefully consider the trade-offs of renouncing ownership; while it enhances decentralization, it removes the ability to respond to unforeseen issues or perform necessary administrative tasks.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age2y
Contract0x4c44…07f2
Deployer0x8efa…b37c
Badge for your website
America Pac security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 30, 20260Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
AsteroidEthereum0LowJerry The Turtle By Matt FurieJYAI · Ethereum0LowNon-Playable CoinNPC · Ethereum0LowYee TokenYEE · Ethereum0LowPikachuEthereum0LowpepeCoinEthereum0Low

Would You Like a More Detailed Audit of America Pac?

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

Get Detailed Audit Is this your token? Publish your own audit on this page