Is PAAL AI ($PAAL) Safe? Smart Contract Security Analysis

Security Findings

1 High3 Med2 Low1 Info

High

Centralized Control and Single Point of Failure

H-01The `onlyOwner` modifier grants extensive control over critical contract parameters, including tax rates, swap thresholds, tax wallets, and the ability to enable/disable trading and contract swaps. This centralization presents a significant single point of failure. A compromise of the owner's private key could lead to malicious changes, such as setting exorbitant fees, redirecting tax funds, or disabling trading, severely impacting the protocol's integrity and user funds. (7.3 Access Control, 7.5 Governance)

IssueThe `onlyOwner` modifier grants extensive control over critical contract parameters, including tax rates, swap thresholds, tax wallets, and the ability to enable/disable trading and contract swaps. This centralization presents a significant single point of failure. A compromise of the owner's private key could lead to malicious changes, such as setting exorbitant fees, redirecting tax funds, or disabling trading, severely impacting the protocol's integrity and user funds. (7.3 Access Control, 7.5 Governance)

FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `_owner` address to manage critical functions. This requires multiple trusted parties to approve transactions, significantly reducing the risk of a single point of compromise. Consider implementing time-locks for highly sensitive operations to allow users to react to pending changes.

StatusUnresolved

Medium

Unused `_isExcludedFromProtection` Mapping

M-01The `_isExcludedFromProtection` mapping is declared but not initialized or used anywhere in the provided contract code. This suggests either an incomplete feature implementation, a misunderstanding of intended functionality, or dead code. If it was intended for a specific protection mechanism (e.g., against bot attacks or certain transfer restrictions), its absence could lead to unexpected behavior or a lack of intended security. (7.2 Code Security)

IssueThe `_isExcludedFromProtection` mapping is declared but not initialized or used anywhere in the provided contract code. This suggests either an incomplete feature implementation, a misunderstanding of intended functionality, or dead code. If it was intended for a specific protection mechanism (e.g., against bot attacks or certain transfer restrictions), its absence could lead to unexpected behavior or a lack of intended security. (7.2 Code Security)

FixClarify the intended purpose of the `_isExcludedFromProtection` mapping. If it's an incomplete feature, either implement its functionality fully or remove the unused variable to improve code clarity and reduce potential confusion. If it's dead code, remove it.

StatusUnresolved

Medium

Potential for High Tax Rates and Economic Manipulation

M-02The contract allows the owner to set `buyFee`, `sellFee`, and `transferFee` up to `maxBuyTaxes`, `maxSellTaxes`, `maxTransferTaxes` (1000, meaning 10% when `masterTaxDivisor` is 10000). While the `taxesAreLocked` flag can prevent future changes, initially high or maliciously modified taxes could significantly impact token liquidity, trading volume, and user trust. The current default fees are 4% buy/sell, which is already substantial. (7.4 Economic, 7.3 Access Control)

IssueThe contract allows the owner to set `buyFee`, `sellFee`, and `transferFee` up to `maxBuyTaxes`, `maxSellTaxes`, `maxTransferTaxes` (1000, meaning 10% when `masterTaxDivisor` is 10000). While the `taxesAreLocked` flag can prevent future changes, initially high or maliciously modified taxes could significantly impact token liquidity, trading volume, and user trust. The current default fees are 4% buy/sell, which is already substantial. (7.4 Economic, 7.3 Access Control)

FixConsider implementing a community-driven governance mechanism or a time-lock for changes to tax rates, even before `taxesAreLocked` is set. Clearly communicate the maximum potential tax rates to users. Ensure that the `taxesAreLocked` function is called promptly after launch to provide immutability and build user confidence.

StatusUnresolved

Medium

Dependency on External `Initializer` Contract

M-03The `PAALAI` contract relies on an external `Initializer` interface for critical functions like `setLaunch` and `setLpPair`. The security and trustworthiness of this external contract are paramount. If the `Initializer` contract is compromised, contains vulnerabilities, or behaves maliciously (e.g., setting a malicious LP pair or incorrect launch parameters), it could directly impact the `PAALAI` token's functionality, security, and economic stability. (7.6 External)

IssueThe `PAALAI` contract relies on an external `Initializer` interface for critical functions like `setLaunch` and `setLpPair`. The security and trustworthiness of this external contract are paramount. If the `Initializer` contract is compromised, contains vulnerabilities, or behaves maliciously (e.g., setting a malicious LP pair or incorrect launch parameters), it could directly impact the `PAALAI` token's functionality, security, and economic stability. (7.6 External)

FixConduct a thorough security audit of the `Initializer` contract. Ensure that the `Initializer` contract itself has robust access control, is immutable after its intended use, or is controlled by a highly secure multi-signature wallet. Clearly document the interaction model and trust assumptions regarding the `Initializer` contract.

StatusUnresolved

Low

Lack of Event Emission for Critical State Changes

L-01Several critical state changes, such as modifications to `_taxRates`, `_ratios`, `swapThreshold`, `swapAmount`, `piSwapPercent`, or `_taxWallets`, do not emit corresponding events. This makes it difficult for off-chain monitoring tools, block explorers, and users to track important configuration changes, reducing transparency and auditability of the contract's operational parameters. (7.2 Code Security, 7.8 Operations)

IssueSeveral critical state changes, such as modifications to `_taxRates`, `_ratios`, `swapThreshold`, `swapAmount`, `piSwapPercent`, or `_taxWallets`, do not emit corresponding events. This makes it difficult for off-chain monitoring tools, block explorers, and users to track important configuration changes, reducing transparency and auditability of the contract's operational parameters. (7.2 Code Security, 7.8 Operations)

FixEmit events for all functions that modify critical state variables. This provides a transparent and auditable log of changes, enhancing user trust and enabling better monitoring by external services. For example, `event TaxRatesUpdated(uint16 buyFee, uint16 sellFee, uint16 transferFee);`.

StatusUnresolved

Low

Hardcoded Tax Wallets in Constructor

L-02The `_taxWallets` are hardcoded in the constructor. While the owner can change these addresses later via an `onlyOwner` function (assuming one exists, though not shown in the provided snippet), it's generally better practice to allow for more flexible initialization or to ensure these addresses are thoroughly vetted before deployment. If any of these addresses are incorrect or compromised at deployment, it could lead to misdirection of funds until the owner manually updates them. (7.2 Code Security, 7.8 Operations)

IssueThe `_taxWallets` are hardcoded in the constructor. While the owner can change these addresses later via an `onlyOwner` function (assuming one exists, though not shown in the provided snippet), it's generally better practice to allow for more flexible initialization or to ensure these addresses are thoroughly vetted before deployment. If any of these addresses are incorrect or compromised at deployment, it could lead to misdirection of funds until the owner manually updates them. (7.2 Code Security, 7.8 Operations)

FixEnsure that all hardcoded addresses are meticulously verified before deployment. For future deployments, consider allowing the owner to set these addresses immediately after deployment through a dedicated initialization function, rather than hardcoding them, to provide more flexibility and reduce the risk of errors during deployment.

StatusUnresolved

Info

Fixed-Point Arithmetic with `uint16` for Ratios/Fees

I-01The contract uses `uint16` for `_taxRates` and `_ratios` in conjunction with a `masterTaxDivisor` of `10000`. While this is functional and sufficient for the current fee structure (max 10%), `uint16` has a maximum value of 65535. This design choice limits the maximum possible fee/ratio to 6.5535% (65535 / 10000). This is a design constraint that might limit future flexibility if significantly higher precision or larger fee values were ever considered, though it is unlikely for typical tokenomics. (7.2 Code Security)

IssueThe contract uses `uint16` for `_taxRates` and `_ratios` in conjunction with a `masterTaxDivisor` of `10000`. While this is functional and sufficient for the current fee structure (max 10%), `uint16` has a maximum value of 65535. This design choice limits the maximum possible fee/ratio to 6.5535% (65535 / 10000). This is a design constraint that might limit future flexibility if significantly higher precision or larger fee values were ever considered, though it is unlikely for typical tokenomics. (7.2 Code Security)

FixThis is a design choice and not a vulnerability. Document this limitation clearly within the project's specifications. If there's a future need for higher precision or larger fee values, consider using `uint256` for these variables, although it would slightly increase gas costs for storage and operations.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates a solid architectural foundation for an ERC-20 token with a reflection mechanism (7.1 Architecture). It incorporates common security patterns like the `inSwap` flag to prevent reentrancy during token swaps and correctly utilizes router functions for fee-on-transfer tokens (7.2 Code Security). However, the `_isExcludedFromProtection` mapping is declared but unused, indicating potentially incomplete or dead code. Additionally, several critical state changes lack corresponding event emissions, hindering transparency and off-chain monitoring (7.2 Code Security, 7.8 Operations).

GovernanceLow10/10

The contract exhibits a high degree of centralization, with the `onlyOwner` modifier controlling all critical parameters, including tax rates, swap thresholds, and tax wallet addresses (7.3 Access Control, 7.5 Governance). This single point of failure introduces significant governance risk, as a compromised owner key could lead to malicious changes or fund redirection. The economic model allows for potentially high tax rates (up to 10% for buy/sell/transfer), which, if abused, could negatively impact user trust and liquidity (7.4 Economic). The contract's reliance on an external `Initializer` contract for launch parameters and LP pair management introduces an additional trust assumption (7.6 External).

UpgradesLow10/10

The PAALAI contract is not designed to be upgradeable (7.7 Upgrades). This means that any discovered vulnerabilities, bugs, or desired feature enhancements cannot be patched or implemented without deploying an entirely new contract and migrating existing token holders. This lack of upgradeability significantly increases the long-term risk profile of the protocol.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

36.6% in top 10

20.3% in wallets16.3% in contracts

Effective Concentration26.8%

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

$1.13M across 2 pairs

Uniswap v2WETHanalysed$1.12M Uniswap v3WETH$7.6K

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

LP Locked100.0% · Null Address, UNCX

Lock Expiry2034 (verified ≥ 1 year) · UNCX V2

Key Addresses

6 addresses

Deployer

0x28e4…c5fd

Unlocked LP Held By

0x517d…f7a20xb3ac…68a00x826f…1e650x0000…8a900x1f2f…f387

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

What Raised This Score

4 factors

Top-10 concentration > 20% (36.6% total → 26.8% effective; 20.3% in EOAs, 16.3% in contracts — mild)
1 High finding(s) from audit
3 Medium finding(s) from audit
2 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

Final Recommendation

AI Copilot

To mitigate the risks associated with centralized control, consider implementing a multi-signature wallet for the `_owner` address to manage critical functions.…

Read the verdictHide

Enhance transparency by emitting events for all significant state changes, such as modifications to tax rates, swap parameters, and tax wallet addresses. Thoroughly review and test all external contract interactions, especially with the `Initializer` contract, to ensure their security and intended behavior. Given the non-upgradeable nature, ensure comprehensive testing and formal verification are conducted before any future deployments.

Contract

TypeStaking, Router, Token

Audit History

1 audit on record

Sep 237

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

Not Signed In

Is PAAL AI Safe?

Security Findings

Centralized Control and Single Point of Failure

Unused `_isExcludedFromProtection` Mapping

Potential for High Tax Rates and Economic Manipulation

Dependency on External `Initializer` Contract

Lack of Event Emission for Critical State Changes

Hardcoded Tax Wallets in Constructor

Fixed-Point Arithmetic with `uint16` for Ratios/Fees

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 PAAL AI?