Is Sapien Safe? Smart Contract Security Analysis

Security Findings

1 Med3 Info

Medium

Centralization Risk from Initial Token Distribution

M-01The `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.

IssueThe `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.

FixWhile 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.

StatusUnresolved

Info

Front-Running Risk in ERC-20 Permit Function

I-01The `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.

IssueThe `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.

FixUsers 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.

StatusUnresolved

Info

Undefined Custom Error `ZeroAddress`

I-02In 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.

IssueIn 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.

FixDefine `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.

StatusUnresolved

Info

Inconsistent Compiler Pragmas Across Dependencies

I-03The `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.

IssueThe `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.

FixConsider 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.

StatusUnresolved

Category Ratings

TechnicalLow8/10

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`.

GovernanceHigh1/10

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.

UpgradesMedium6/10

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.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

91.2% in top 10

91.2% in wallets0.0% in contracts

Effective Concentration91.2%

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

$773.6K across 4 pairs

AerodromeUSDCanalysed$728.6K Uniswap v3WETH$44.9K AerodromeAERO$107

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 Holder62.6%

Top-3 Unlocked85.5%

Key Addresses

11 addresses

Deployer

0x6c03…6815

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.

What Raised This Score

6 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

Is Sapien Safe?

Security Findings

Centralization Risk from Initial Token Distribution

Front-Running Risk in ERC-20 Permit Function

Undefined Custom Error `ZeroAddress`

Inconsistent Compiler Pragmas Across Dependencies

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