Quantum Audit Logo

Is Phala Safe?

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

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

Phala PHA
0x6c5b…2f4e
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The PHAToken contract is a standard ERC20 implementation, leveraging OpenZeppelin's `SafeMath`, `Ownable`, and `Pausable` patterns. While it demonstrates good practices for preventing integer overflows and adhering to the ERC20 standard, significant centralization risks exist due to the `Ownable` and `PauserRole` mechanisms. The contract also exhibits a known ERC20 `approve` front-running vulnerability and uses an older Solidity compiler version.

1 High1 Medium1 Low1 Informational
Volume 24h
$754.0K
Liquidity
$236.6K
Price
$0.04567
Token Age
6y
Top 10 Holders
69.5%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control via Owner and Pauser Roles

H-01The contract implements `Ownable` and `PauserRole`, granting the deployer (owner) and designated pausers significant control. The owner can transfer ownership, and pausers can halt all token transfers and manage other pauser accounts. This centralization creates a single point of failure, where a compromised or malicious owner/pauser could disrupt token operations or transfer control. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
IssueThe contract implements `Ownable` and `PauserRole`, granting the deployer (owner) and designated pausers significant control. The owner can transfer ownership, and pausers can halt all token transfers and manage other pauser accounts. This centralization creates a single point of failure, where a compromised or malicious owner/pauser could disrupt token operations or transfer control. (7.3 Access Control, 7.5 Governance, 7.8 Operations)
FixConsider implementing a multi-signature wallet for critical administrative roles (owner, pauser) to distribute control and reduce the risk of a single point of compromise. For pausing, evaluate if a more decentralized or time-locked mechanism is appropriate for the protocol's risk model.
StatusUnresolved
Medium

ERC20 `approve` Front-Running Vulnerability

M-01The standard `approve` function, while compliant with ERC20, is vulnerable to a known front-running attack. If a user attempts to increase an allowance, a malicious actor can front-run the transaction by spending the original allowance, then front-run again to spend the newly approved allowance, effectively spending more than intended. Although `increaseAllowance` and `decreaseAllowance` are provided, the direct `approve` function remains accessible. (7.2 Code Security)
IssueThe standard `approve` function, while compliant with ERC20, is vulnerable to a known front-running attack. If a user attempts to increase an allowance, a malicious actor can front-run the transaction by spending the original allowance, then front-run again to spend the newly approved allowance, effectively spending more than intended. Although `increaseAllowance` and `decreaseAllowance` are provided, the direct `approve` function remains accessible. (7.2 Code Security)
FixAdvise users to always set allowance to zero before increasing it, or exclusively use `increaseAllowance` and `decreaseAllowance` functions. Consider deprecating or adding warnings to the direct `approve` function in documentation.
StatusUnresolved
Low

Old Solidity Compiler Version

L-01The contract is compiled with `pragma solidity ^0.5.0`. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, making `SafeMath` redundant and potentially reducing gas costs and bytecode size. Older compiler versions might also lack newer optimizations or security features. (7.2 Code Security)
IssueThe contract is compiled with `pragma solidity ^0.5.0`. While `SafeMath` is used to prevent integer overflows/underflows, newer Solidity versions (e.g., 0.8.x) include built-in overflow/underflow checks by default, making `SafeMath` redundant and potentially reducing gas costs and bytecode size. Older compiler versions might also lack newer optimizations or security features. (7.2 Code Security)
FixConsider upgrading the Solidity compiler version to 0.8.x or higher. This would allow for the removal of `SafeMath` library usage, simplifying the code and leveraging modern compiler-level safety features. Thorough testing would be required after such an upgrade.
StatusUnresolved
Info

Unnecessary `Context` Abstraction for Non-Proxy Contract

I-01The `Context` contract, which provides `_msgSender()` and `_msgData()`, is typically used in proxy patterns to ensure `msg.sender` and `msg.data` correctly reflect the original caller in the context of a delegatecall. Since this contract is not a proxy (as per `is_proxy: false`), the abstraction provided by `Context` is unnecessary and adds minor overhead. The `this;` statement in `_msgData()` is also a no-op. (7.1 Architecture)
IssueThe `Context` contract, which provides `_msgSender()` and `_msgData()`, is typically used in proxy patterns to ensure `msg.sender` and `msg.data` correctly reflect the original caller in the context of a delegatecall. Since this contract is not a proxy (as per `is_proxy: false`), the abstraction provided by `Context` is unnecessary and adds minor overhead. The `this;` statement in `_msgData()` is also a no-op. (7.1 Architecture)
FixIf the contract is not intended to be used as an implementation contract in a proxy pattern, the `Context` abstraction can be removed, and `msg.sender` can be used directly. This would slightly simplify the code and reduce bytecode size.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes `SafeMath` to effectively mitigate integer overflow/underflow vulnerabilities (7.2 Code Security) and adheres to the ERC20 standard. However, the standard `approve` function remains susceptible to front-running attacks, despite the presence of `increaseAllowance` and `decreaseAllowance` functions. The use of an older Solidity compiler version (`^0.5.0`) means the contract does not benefit from modern compiler optimizations and built-in safety features (7.2 Code Security). The `Context` abstraction is also unnecessary for a non-proxy contract (7.1 Architecture).

GovernanceHigh1/10

The contract exhibits high centralization due to the `Ownable` and `PauserRole` implementations (7.3 Access Control, 7.5 Governance). A single owner address controls the ability to transfer ownership, and designated pausers can halt all token transfers, creating a single point of failure. This concentration of power introduces significant operational and economic risks, as a compromised or malicious owner/pauser could severely impact the token's functionality and user trust (7.8 Operations).

UpgradesMedium6/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), as indicated by the `is_proxy: false` status. This eliminates upgrade-specific risks such as storage collisions or faulty implementation logic. The contract's functionality is fixed upon deployment.

Security Checklist

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

Holder Composition

69.5% in top 10
40.2% in wallets29.3% in contracts
Effective Concentration51.9%

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

$260.8K across 4 pairs
Uniswap v2WETHanalysed$236.6K90.7%Uniswap v3WETH$24.2K9.3%

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 Holder93.0%
Top-3 Unlocked97.7%

Key Addresses

11 addresses
Deployer
0xb768…dd2d
Unlocked LP Held By
0x277e…74b40xba22…85710xa5cc…83880xa991…e9870xc8d6…6dbe0x0a62…59410xfd52…1f490x519d…0e4f0x9965…6dec0x0eb9…4863

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 — owner is an EOA (single private key)
  • Top-10 concentration > 50% (69.5% total → 51.9% effective; 40.2% in EOAs, 29.3% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 93.0% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • LP top3 unlocked holders = 97.7% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • 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
REHigh RiskZamaHigh RiskUNICURVEHigh RiskChain (XCN)High RiskGram (prev. Toncoin) (GRAM)High RiskDIAToken (DIA)High Risk

Would You Like a More Detailed Audit of Phala?

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

Get Detailed Audit