Quantum Audit Logo

Is PRXVT Safe?

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

PRXVT PRXVT
0x4b5d…c5a9
Base
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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The AgentTokenV2 contract is an ERC-20 token deployed as an EIP-1167 minimal clone, meaning its logic is immutable and cannot be upgraded. The contract exhibits significant centralization, with an owner or factory address possessing extensive control over token parameters, transfer mechanisms, and even user balances. Key risks include the ability to directly manipulate token balances, blacklist users, modify transfer taxes, and redirect funds, posing a substantial risk to token holders.

3 High4 Medium2 Low4 Informational
Volume 24h
$54.0K
Liquidity
$267.4K
Price
$0.002933
Token Age
9mo
Top 10 Holders
81.4%

Security Findings

3 High4 Med2 Low4 Info
High

Ignored Return Value for ERC-20 Transfers

CD-02The `_addInitialLiquidity` function performs an ERC-20 token transfer but does not check the boolean return value of the `transfer` call. If the external token's `transfer` function fails (e.g., due to reentrancy guards or insufficient balance), the contract will not revert, potentially leading to an inconsistent state or loss of funds.
IssueThe `_addInitialLiquidity` function performs an ERC-20 token transfer but does not check the boolean return value of the `transfer` call. If the external token's `transfer` function fails (e.g., due to reentrancy guards or insufficient balance), the contract will not revert, potentially leading to an inconsistent state or loss of funds.
FixToken holders should be aware that if an internal token transfer fails within the `_addInitialLiquidity` function, the contract might not detect it. The project team should ensure that all external ERC-20 transfer calls check their return values to prevent silent failures and maintain contract integrity.
StatusUnresolved
High

Privileged Address Can Manipulate Token Balances

CP-02The `ownerorfactory` address has the ability to directly change token balances of any holder. Specifically, the `addInitialLiquidity(address)` function can write to other holders' balances, allowing the controller to burn or move tokens out of any targeted address without their consent.
IssueThe `ownerorfactory` address has the ability to directly change token balances of any holder. Specifically, the `addInitialLiquidity(address)` function can write to other holders' balances, allowing the controller to burn or move tokens out of any targeted address without their consent.
FixToken holders should be aware that a privileged address can directly modify their token balances. The project team should ensure that the `ownerorfactory` role is secured with robust access controls, such as a multi-signature wallet, and that any use of this function is transparently communicated to the community.
StatusUnresolved
High

Privileged Address Can Redirect Critical Contract Logic

CP-03The `ownerorfactory` address can change the address of a critical external contract that influences how transfers behave. The `setProjectTaxRecipient` function allows the controller to replace the address that receives project taxes. Whoever controls this setting can redirect funds or potentially manipulate the flow of tokens.
IssueThe `ownerorfactory` address can change the address of a critical external contract that influences how transfers behave. The `setProjectTaxRecipient` function allows the controller to replace the address that receives project taxes. Whoever controls this setting can redirect funds or potentially manipulate the flow of tokens.
FixToken holders should understand that a privileged address can change where tax funds are sent. The project team must ensure the `ownerorfactory` role is highly secured and that any changes to the `projectTaxRecipient` are publicly announced and justified.
StatusUnresolved
Medium

Privileged Address Can Control Transfer Permissions

CP-05The `ownerorfactory` address can enable or disable transfers for all token holders. Functions like `addInitialLiquidity` and `setProjectTaxRates` can change an on/off setting (`_autoSwapInProgress`, `_tokenHasTax`) that determines whether transfers or sales are allowed or refused, potentially freezing or unfreezing all token movements.
IssueThe `ownerorfactory` address can enable or disable transfers for all token holders. Functions like `addInitialLiquidity` and `setProjectTaxRates` can change an on/off setting (`_autoSwapInProgress`, `_tokenHasTax`) that determines whether transfers or sales are allowed or refused, potentially freezing or unfreezing all token movements.
FixToken holders should be aware that a privileged address can unilaterally halt or resume all token transfers. The project team should implement clear policies and communication channels for any changes to transfer permissions, ensuring transparency and accountability.
StatusUnresolved
Medium

Privileged Address Can Blacklist Individual Holders

CP-06The `ownerorfactory` address can prevent specific token holders from moving or selling their tokens. The `addBlacklistAddress` and `removeBlacklistAddress` functions allow the controller to add or remove addresses from a blacklist, which is checked on every transfer. This means chosen holders can be arbitrarily blocked.
IssueThe `ownerorfactory` address can prevent specific token holders from moving or selling their tokens. The `addBlacklistAddress` and `removeBlacklistAddress` functions allow the controller to add or remove addresses from a blacklist, which is checked on every transfer. This means chosen holders can be arbitrarily blocked.
FixToken holders should know that a privileged address can prevent them from transferring their tokens. The project team should establish strict, transparent criteria for blacklisting and communicate any such actions clearly to the community, ideally with a mechanism for appeal.
StatusUnresolved
Medium

Privileged Address Can Change Transfer Fees

CP-07The `ownerorfactory` address has the power to modify the fees applied to token transfers. Functions such as `setProjectTaxRates`, `addInitialLiquidity`, and `setSwapThresholdBasisPoints` allow the controller to change the percentage of tokens taken as a fee during transfers, directly impacting the net amount received by token holders.
IssueThe `ownerorfactory` address has the power to modify the fees applied to token transfers. Functions such as `setProjectTaxRates`, `addInitialLiquidity`, and `setSwapThresholdBasisPoints` allow the controller to change the percentage of tokens taken as a fee during transfers, directly impacting the net amount received by token holders.
FixToken holders should be aware that a privileged address can change transfer fees at any time. The project team should commit to transparent communication regarding any fee adjustments and consider implementing a community governance mechanism for such critical parameter changes.
StatusUnresolved
Medium

Liquidity not locked

QA-LIQUIDITY0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 3 address(es) other than the owner/deployer. One of them — a wallet, 0x5ec2…daa7 — holds 94.1% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them.
Issue0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 3 address(es) other than the owner/deployer. One of them — a wallet, 0x5ec2…daa7 — holds 94.1% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them.
FixCheck the lock's end date and beneficiary on the locker's own page before relying on it.
StatusAcknowledged
Low

Potential for Rounding Loss in Calculations

CD-01The `_autoSwap` function may experience rounding losses due to performing division before multiplication. This can lead to minor inaccuracies in calculations involving token amounts, potentially resulting in small discrepancies over time.
IssueThe `_autoSwap` function may experience rounding losses due to performing division before multiplication. This can lead to minor inaccuracies in calculations involving token amounts, potentially resulting in small discrepancies over time.
FixToken holders should be aware that minor rounding differences might occur in certain automated calculations. The project team should review the `_autoSwap` function to ensure calculations are performed in a multiplication-before-division order to minimize rounding errors.
StatusUnresolved
Low

Privileged Address Can Change Transfer Limits

CP-08The `ownerorfactory` address can modify numeric limits that affect token transfers. The `addInitialLiquidity` function can change settings like `fundedDate` and `projectTaxPendingSwap`, which might influence transfer thresholds or other operational limits checked during transactions.
IssueThe `ownerorfactory` address can modify numeric limits that affect token transfers. The `addInitialLiquidity` function can change settings like `fundedDate` and `projectTaxPendingSwap`, which might influence transfer thresholds or other operational limits checked during transactions.
FixToken holders should be aware that a privileged address can adjust certain transfer limits. The project team should clearly communicate any changes to these limits and their potential impact on token transactions.
StatusUnresolved
Info

Who holds the supply

QA-HOLDERSThe ten largest holders own 81.4% of supply. Of that, 4.4% burned — not holders that can sell, so excluded from the concentration score. What remains: 15.8% in wallets, 61.3% in other contracts. The deployer/owner wallet itself holds 2.2%. 4,917 holders in total.
IssueThe ten largest holders own 81.4% of supply. Of that, 4.4% burned — not holders that can sell, so excluded from the concentration score. What remains: 15.8% in wallets, 61.3% in other contracts. The deployer/owner wallet itself holds 2.2%. 4,917 holders in total.
FixWatch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
StatusAcknowledged
Info

Listed, but not independently verified

QA-IDENTITYListed on CoinGecko as PRXVT by Virtuals (PRXVT), market cap $3M, rank #2098. 4,917 holders.
IssueListed on CoinGecko as PRXVT by Virtuals (PRXVT), market cap $3M, rank #2098. 4,917 holders.
FixMatch the contract address against the project's official channels before trading.
StatusAcknowledged
Info

The market for this token

QA-MARKETLiquidity $267K (DexScreener, all pools). 24h trading volume $66K (CoinGecko, all markets, daily snapshot). 24h trading volume $54K (DexScreener, all pools).
IssueLiquidity $267K (DexScreener, all pools). 24h trading volume $66K (CoinGecko, all markets, daily snapshot). 24h trading volume $54K (DexScreener, all pools).
FixSize any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
StatusAcknowledged
Info

Asset class: Project token

QA-PROFILEA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: fixed — the contract has no mint function. Control: a single wallet (EOA). Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $267K of DEX liquidity across 1 pools. Launch: 273 days of market history.
IssueA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: fixed — the contract has no mint function. Control: a single wallet (EOA). Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $267K of DEX liquidity across 1 pools. Launch: 273 days of market history.
FixCheck the project's own documentation for what the token is used for; this report covers what the contract allows.
StatusAcknowledged

Category Ratings

TechnicalMedium6/10

The AgentTokenV2 contract implements the ERC-20 standard, providing basic token functionalities. It is deployed as an EIP-1167 minimal clone, ensuring its core logic is immutable and cannot be upgraded (7.1 Architecture). However, the contract grants extensive technical control to a privileged `ownerorfactory` address. This includes the ability to directly modify user balances via `addInitialLiquidity`, control transfer rules through blacklisting (`addBlacklistAddress`), and manage various administrative settings (7.3 Access Control). A notable code security issue is the unchecked return value of external ERC-20 transfers in `_addInitialLiquidity` (7.2 Code Security).

GovernanceHigh1/10

The economic model of AgentTokenV2 is highly centralized, with the `ownerorfactory` role having significant power over token economics and user interactions. This privileged address can set project buy and sell tax rates (`setProjectTaxRates`), determine the recipient of these taxes (`setProjectTaxRecipient`), and control a switch that enables or disables transfers (`addInitialLiquidity`, `setProjectTaxRates`) (7.4 Economic). Furthermore, the ability to blacklist individual addresses (`addBlacklistAddress`) allows for arbitrary freezing of user funds, posing a substantial economic risk to token holders (7.5 Governance). The owner can also withdraw ETH and other ERC-20 tokens from the contract (7.8 Operations).

UpgradesMedium6/10

The AgentTokenV2 contract is deployed as an EIP-1167 minimal clone, which means its implementation is fixed and cannot be upgraded (7.7 Upgrades). While this provides immutability and removes upgrade-related risks, it also means that no future bug fixes or feature enhancements can be applied to the deployed contract logic. The `Initializable` and `Upgradeable` base contracts are used for proper clone initialization, not for an upgrade mechanism.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not UpgradeablePass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

81.4% in top 10
15.8% in wallets61.3% in contracts
Effective Concentration40.3%

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

$267.4K

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 Holder94.1%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0xf96a…7e4a
Unlocked LP Held By
0x5ec2…daa70x879c…97020xd2c1…9280

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

What Raised This Score

10 factors
  • Owner can change any holder's balance (seize or credit tokens)
  • A privileged address can replace a contract every transfer depends on
  • A privileged address controls a switch that decides whether transfers go through
  • Owner can blacklist or freeze individual holders
  • Owner can change the buy/sell tax
  • A privileged address can change transfer or wallet limits
  • Liquidity NOT locked (100% of the pool) — held by independent providers — market-depth risk
  • Top-10 concentration > 30% (81.4% total → 40.3% effective; 15.8% in EOAs, 61.3% in contracts; 4.4% burned, locked or in pools excluded)
  • Code: Potential for Rounding Loss in Calculations (Low, static analysis)
  • Code: Ignored Return Value for ERC-20 Transfers (High, static analysis)

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
RecallHigh RiskThe White Wolf (WOLF)High RiskSport.fun (FUN)High RiskREPPOHigh RiskVANRYHigh RiskSIBYL by Virtuals (SIBYL)High Risk

Would You Like a More Detailed Audit of PRXVT?

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

Get Detailed Audit