Quantum Audit Logo
Launch App

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

Is Sapien Safe?

SAPIENBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades6/10Checks passed3 of 5Findings1 Medium · 3 Info4
SummaryAI Copilot

The SapienToken contract is a standard ERC-20 token with EIP-2612 Permit functionality, built upon well-audited OpenZeppelin libraries.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.6%
  • LP top3 unlocked holders = 85.5%
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (91.2% total → 91.2% effective; 91.2% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.6% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • LP top3 unlocked holders = 85.5% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • 1 Medium 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 43 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
91.2%Wallets8.8%Everyone else
91.2%Wallets8.8%
WalletsEveryone elseBubble area = share of supply
91.2%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell91.2%
  • Everyone elsethe rest of the supply8.8%
Effective concentrationwhat the score reads91.2%
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$773.6K across 4 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$728.6KShare of depth94.2%
Top-1 Unlocked Holder62.6%
Top-3 Unlocked85.5%
Unlocked LP held by
0x77f4…b1f70x0141…ba140x5b37…0c9c0x33ab…21fa0x8ace…f4680x0cd4…d65c0xe0ac…04e20xb333…1bd00x181c…c9070xe1db…6b12

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

Security Findings

1 Medium3 Info
Medium

Centralization Risk from Initial Token Distribution

The SapienToken contract mints its entire MAX_SUPPLY (1,000,000,000 SAPIEN tokens) to a single treasury address during deployment. This means 100% of the token supply is controlled by one address. This poses a significant centralization risk (7.4 Economic, 7.3 Access Control). If this treasury address is compromised, or if the entity controlling it acts maliciously, the entire token supply could be dumped onto the market, severely impacting liquidity and token price.M-01

Issue

The SapienToken contract mints its entire MAX_SUPPLY (1,000,000,000 SAPIEN tokens) to a single treasury address during deployment. This means 100% of the token supply is controlled by one address. This poses a significant centralization risk (7.4 Economic, 7.3 Access Control). If this treasury address is compromised, or if the entity controlling it acts maliciously, the entire token supply could be dumped onto the market, severely impacting liquidity and token price.

Fix

While this distribution model might be intentional for initial bootstrapping, it's crucial to implement robust security measures for the treasury address (e.g., multi-signature wallet, cold storage). Consider a phased distribution or vesting schedule for the tokens to mitigate the immediate impact of a potential compromise or single point of failure.

Status

Unresolved

Info

Front-Running Risk in ERC-20 Permit Function

The SapienToken contract implements the ERC20Permit (EIP-2612) standard, which allows users to approve token transfers via a signed message rather than an on-chain transaction. While correctly implemented using OpenZeppelin's robust ERC20Permit and Nonces (7.2 Code Security), the permit function is inherently susceptible to front-running (7.6 External). If a user's signed permit message is broadcasted to the mempool, a malicious actor could observe it and submit their own transaction with a higher gas price to execute the permit call first, potentially exploiting the approval before the legitimate user's intended transaction.I-01

Issue

The SapienToken contract implements the ERC20Permit (EIP-2612) standard, which allows users to approve token transfers via a signed message rather than an on-chain transaction. While correctly implemented using OpenZeppelin's robust ERC20Permit and Nonces (7.2 Code Security), the permit function is inherently susceptible to front-running (7.6 External). If a user's signed permit message is broadcasted to the mempool, a malicious actor could observe it and submit their own transaction with a higher gas price to execute the permit call first, potentially exploiting the approval before the legitimate user's intended transaction.

Fix

Users should be aware of the front-running risks associated with permit signatures. They should only broadcast permit signatures when confident in the transaction's execution and consider using privacy-preserving transaction methods if available. The contract itself correctly implements the standard, so no code changes are required.

Status

Unresolved

Info

Undefined Custom Error ZeroAddress

In the SapienToken constructor, the contract reverts with revert ZeroAddress(); if the treasury address is address(0). However, the ZeroAddress error is not explicitly defined using error ZeroAddress(); within the contract or an imported interface (7.2 Code Security). While the revert functionality works, defining custom errors is a best practice in Solidity 0.8.x as it provides more gas-efficient and descriptive error messages compared to string reverts.I-02

Issue

In the SapienToken constructor, the contract reverts with revert ZeroAddress(); if the treasury address is address(0). However, the ZeroAddress error is not explicitly defined using error ZeroAddress(); within the contract or an imported interface (7.2 Code Security). While the revert functionality works, defining custom errors is a best practice in Solidity 0.8.x as it provides more gas-efficient and descriptive error messages compared to string reverts.

Fix

Define error ZeroAddress(); within the SapienToken contract or a dedicated errors interface to ensure proper custom error handling and optimize gas usage for this specific revert condition.

Status

Unresolved

Info

Inconsistent Compiler Pragmas Across Dependencies

The SapienToken contract specifies pragma solidity 0.8.30;, while its OpenZeppelin dependencies (e.g., ERC20.sol, ERC20Permit.sol) use pragma solidity ^0.8.20; (7.2 Code Security, 7.8 Operations). While 0.8.30 is compatible with ^0.8.20, it's generally a best practice to align all pragma versions to the exact compiler version used for deployment. This ensures consistent compilation behavior across all files and reduces potential for unexpected issues with future compiler updates or specific version-dependent optimizations.I-03

Issue

The SapienToken contract specifies pragma solidity 0.8.30;, while its OpenZeppelin dependencies (e.g., ERC20.sol, ERC20Permit.sol) use pragma solidity ^0.8.20; (7.2 Code Security, 7.8 Operations). While 0.8.30 is compatible with ^0.8.20, it's generally a best practice to align all pragma versions to the exact compiler version used for deployment. This ensures consistent compilation behavior across all files and reduces potential for unexpected issues with future compiler updates or specific version-dependent optimizations.

Fix

Consider aligning all pragma solidity statements to the specific compiler version intended for deployment (e.g., pragma solidity 0.8.30; for all files). This practice enhances build reproducibility and clarity.

Status

Unresolved

Analysis

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

The SapienToken contract is a standard ERC-20 token with EIP-2612 Permit functionality, built upon well-audited OpenZeppelin libraries. The contract's technical implementation is robust, demonstrating good security practices against common vulnerabilities like reentrancy and integer overflows. The primary area of concern is the economic model's initial token distribution, where the entire supply is minted to a single treasury address, introducing a centralization risk.

Technical8/10Low risk

The technical architecture (7.1 Architecture) of SapienToken is sound, leveraging battle-tested OpenZeppelin contracts for ERC-20 and ERC-20 Permit functionalities. The code (7.2 Code Security) demonstrates robust handling of common issues like reentrancy and integer overflows, benefiting from Solidity 0.8.x's default overflow checks and OpenZeppelin's unchecked blocks where appropriate. For instance, the _update function correctly handles balance adjustments. A minor point is the inconsistent compiler pragmas across dependencies (7.8 Operations), though 0.8.30 is compatible with ^0.8.20.

Governance1/10High risk

The economic model (7.4 Economic) of SapienToken involves minting the entire MAX_SUPPLY to a single treasury address during deployment. This creates a significant centralization risk (7.3 Access Control), as 100% of the token supply is controlled by one entity. While this might be an intentional initial distribution strategy, it exposes the protocol to potential market manipulation or severe impact if the treasury address is compromised. There are no governance mechanisms (7.5 Governance) within the token contract itself.

Upgrades6/10Medium risk

The SapienToken contract is implemented as a standard, non-upgradable ERC-20 token. It does not utilize any proxy patterns (7.7 Upgrades) or upgradeability mechanisms. This design choice simplifies the contract's architecture and eliminates potential upgrade-related risks, ensuring immutability post-deployment.

Final RecommendationWhat to do about this score

Implement robust security measures for the treasury address, such as a multi-signature wallet, to mitigate the centralization risk associated with the initial token distribution.

Educate users about the inherent front-running risks when utilizing the permit function. For future development, consider defining custom errors explicitly for improved gas efficiency and clarity, and align compiler pragmas across all contract files for consistency.

Contract & Record

1 audit on record
TypeSapienToken
NetworkBase
Token age1y
Contract0xc729…14e3
Deployer0x6c03…6815
Badge for your website
Sapien 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. Sep 4, 202644Medium
  2. Aug 11, 202633Low

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

Related Audits

6 more on the recordAll audits
Aerodrome FinanceAERO · Base44MediumRaveDAORAVE · Base44MediumMocaBase44MediumNockchainNOCK · Base45MediumSolana (Universal)USOL · Base45MediumElsaBase45Medium

Would You Like a More Detailed Audit of Sapien?

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