Is Pear Safe? Smart Contract Security Analysis

Security Findings

2 Low2 Info

Low

Initial Centralization of Supply

L-01The `PearToken` contract's constructor mints the entire `MAX_SUPPLY` (1,000,000,000 PEAR) to a single `receiver` address. This means 100% of the token supply is initially held by one address. While this is a common pattern for initial token distribution, it represents a single point of failure or control for the entire token supply at deployment (7.4 Economic). If this address is compromised or mismanaged, it could impact the token's ecosystem.

IssueThe `PearToken` contract's constructor mints the entire `MAX_SUPPLY` (1,000,000,000 PEAR) to a single `receiver` address. This means 100% of the token supply is initially held by one address. While this is a common pattern for initial token distribution, it represents a single point of failure or control for the entire token supply at deployment (7.4 Economic). If this address is compromised or mismanaged, it could impact the token's ecosystem.

FixIf the `receiver` address is intended for a team or project treasury, consider using a multi-signature wallet or a timelock contract for this address to enhance security and decentralization. This would require multiple approvals or a time delay for significant token movements, reducing the risk of a single point of compromise.

StatusUnresolved

Low

Lack of Pause Mechanism

L-02The `PearToken` contract does not include a mechanism to pause token transfers or other critical functions. In the event of an unforeseen vulnerability, a major exploit, or a critical operational issue (7.8 Operations), the project would lack the ability to temporarily halt token activity to mitigate damage or address the problem. While not strictly required for a simple token, a pause mechanism is a common security feature in many projects.

IssueThe `PearToken` contract does not include a mechanism to pause token transfers or other critical functions. In the event of an unforeseen vulnerability, a major exploit, or a critical operational issue (7.8 Operations), the project would lack the ability to temporarily halt token activity to mitigate damage or address the problem. While not strictly required for a simple token, a pause mechanism is a common security feature in many projects.

FixConsider implementing a pausable mechanism (e.g., inheriting from OpenZeppelin's `Pausable` contract) controlled by a trusted entity, such as a multi-signature wallet. This would provide an emergency stop-gap. Ensure that the access control for pausing is robust and transparent to avoid centralization risks.

StatusUnresolved

Info

Standard ERC-20 Implementation

I-01The `PearToken` contract correctly implements the ERC-20 standard by inheriting from OpenZeppelin's `ERC20` contract. This ensures adherence to well-established patterns and security practices for fungible tokens (7.2 Code Security). The custom `burn` function is also implemented correctly, utilizing the internal `_burn` function from the base contract.

IssueThe `PearToken` contract correctly implements the ERC-20 standard by inheriting from OpenZeppelin's `ERC20` contract. This ensures adherence to well-established patterns and security practices for fungible tokens (7.2 Code Security). The custom `burn` function is also implemented correctly, utilizing the internal `_burn` function from the base contract.

FixNo specific recommendation. Continue to leverage well-audited libraries for core functionalities.

StatusUnresolved

Info

Fixed Supply Token

I-02The `PearToken` has a clearly defined `MAX_SUPPLY` of 1,000,000,000 tokens, which is minted entirely during the contract's deployment. There are no functions allowing for additional minting after the initial deployment (7.4 Economic). This fixed supply model provides transparency and predictability regarding the total token circulation, which can be a desirable characteristic for certain tokenomics.

IssueThe `PearToken` has a clearly defined `MAX_SUPPLY` of 1,000,000,000 tokens, which is minted entirely during the contract's deployment. There are no functions allowing for additional minting after the initial deployment (7.4 Economic). This fixed supply model provides transparency and predictability regarding the total token circulation, which can be a desirable characteristic for certain tokenomics.

FixNo specific recommendation. This is a design choice that contributes to the token's economic transparency.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1 Architecture) of PearToken is sound, leveraging the battle-tested OpenZeppelin ERC20 implementation. This provides a strong foundation for code security (7.2 Code Security), benefiting from years of audits and community review. The contract includes a standard `burn` function, allowing users to reduce their own token balance. Access control (7.3 Access Control) is minimal, adhering to standard ERC-20 patterns where users control their own tokens, with no privileged roles beyond the initial token receiver. The use of Solidity 0.8.20 and OpenZeppelin's `unchecked` blocks where appropriate mitigates integer overflow/underflow risks.

GovernanceHigh2/10

The economic model (7.4 Economic) of PearToken is simple and transparent: a fixed `MAX_SUPPLY` is minted once during deployment to a specified receiver, and no further minting is possible. This provides clear tokenomics. The `burn` function allows for supply reduction by token holders. There are no complex DeFi primitives, staking, or lending mechanisms, which simplifies the economic risk profile. Governance (7.5 Governance) is not implemented within this contract, meaning there are no on-chain voting or administrative roles to manage, reducing governance-related attack vectors.

UpgradesMedium6/10

The PearToken contract is not designed to be upgradeable (7.7 Upgrades), as it does not implement any proxy patterns (e.g., UUPS, Transparent, Beacon). This means the contract's logic is immutable once deployed, eliminating any risks associated with upgrade mechanisms, such as proxy misconfigurations, logic contract vulnerabilities during upgrades, or administrative key compromises affecting future logic. While this removes upgrade flexibility, it ensures a fixed and predictable contract behavior.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

80.0% in top 10

23.1% in wallets56.9% in contracts

Effective Concentration45.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.21M across 6 pairs

Camelot v3USDCanalysed$945.6K UniswapWETH$257.6K Camelot v3WETH$4.0K UniswapUSDC$117 Uniswap v2WETH$34 CamelotUSDC$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 Holder99.7%

Top-3 Unlocked100.0%

Key Addresses

10 addresses

Deployer

0x92df…de96

Unlocked LP Held By

0x67f4…6a770xa708…06920xcf5c…fce70xca94…9a9b0x3f8b…f6530xeb2e…acbe0xa9ab…e6cb0xdb7c…6a380x13d2…846f

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

What Raised This Score

6 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (80.0% total → 45.8% effective; 23.1% in EOAs, 56.9% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.7% (independent LP — depth risk, pool = 78% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 78% of DEX liquidity)
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

Not Signed In

Is Pear Safe?

Security Findings

Initial Centralization of Supply

Lack of Pause Mechanism

Standard ERC-20 Implementation

Fixed Supply Token

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 Pear?