Is OpenServ (SERV) Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med2 Low1 Info

High

Centralized Control and Blacklisting Capability

H-01The `Ownable` contract grants the owner extensive control over critical parameters and the ability to blacklist addresses. This includes setting transaction limits (`maxTransactionAmount`, `maxWallet`), fees (`buyTotalFees`, `sellTotalFees`, `treasuryFee`), and preventing transfers for any address via `addRemoveBlackList`. This centralization poses a significant trust risk, as a malicious or compromised owner could manipulate the token's economy or censor users (7.3 Access Control, 7.4 Economic, 7.8 Operations).

IssueThe `Ownable` contract grants the owner extensive control over critical parameters and the ability to blacklist addresses. This includes setting transaction limits (`maxTransactionAmount`, `maxWallet`), fees (`buyTotalFees`, `sellTotalFees`, `treasuryFee`), and preventing transfers for any address via `addRemoveBlackList`. This centralization poses a significant trust risk, as a malicious or compromised owner could manipulate the token's economy or censor users (7.3 Access Control, 7.4 Economic, 7.8 Operations).

FixConsider implementing a multi-signature wallet for ownership to distribute control and reduce the risk of a single point of failure. For blacklisting, evaluate if such a powerful censorship mechanism is truly necessary for the protocol's long-term vision, and if so, consider a decentralized governance mechanism for its activation.

StatusUnresolved

Medium

High and Configurable Transaction Fees

M-01The contract implements `buyTotalFees` (5%), `sellTotalFees` (5%), and `treasuryFee` (10%), which are high and can be updated by the owner. While common in certain token designs, such high and mutable fees can deter legitimate usage and introduce uncertainty for users. The owner's ability to change these at will creates a potential for abuse or unexpected changes in token economics. The exact application of these fees could not be fully verified due to the truncation of the `_transfer` function (7.4 Economic).

IssueThe contract implements `buyTotalFees` (5%), `sellTotalFees` (5%), and `treasuryFee` (10%), which are high and can be updated by the owner. While common in certain token designs, such high and mutable fees can deter legitimate usage and introduce uncertainty for users. The owner's ability to change these at will creates a potential for abuse or unexpected changes in token economics. The exact application of these fees could not be fully verified due to the truncation of the `_transfer` function (7.4 Economic).

FixClearly communicate the fee structure and the owner's ability to modify it to users. Consider implementing a time-lock or a governance vote for fee changes to provide transparency and reduce immediate manipulation risk. Ensure the complete `_transfer` function is available for audit to verify correct fee application.

StatusUnresolved

Medium

Potential for Price Impact from `swapBack` Mechanism

M-02The `swapBack` function is triggered when the contract's token balance reaches `SwapTokensAtAmount`. If `SwapTokensAtAmount` is set too low relative to the available liquidity on Uniswap, frequent swaps could occur. This can lead to increased transaction costs, higher slippage, and potential negative price impact, especially during periods of low liquidity or high trading volume. The implementation of `swapBack` was truncated, limiting full analysis (7.4 Economic).

IssueThe `swapBack` function is triggered when the contract's token balance reaches `SwapTokensAtAmount`. If `SwapTokensAtAmount` is set too low relative to the available liquidity on Uniswap, frequent swaps could occur. This can lead to increased transaction costs, higher slippage, and potential negative price impact, especially during periods of low liquidity or high trading volume. The implementation of `swapBack` was truncated, limiting full analysis (7.4 Economic).

FixCarefully monitor and adjust `SwapTokensAtAmount` based on liquidity and trading volume to minimize negative price impact. Consider implementing a minimum time interval between `swapBack` calls or a maximum swap amount to prevent excessive market activity. Ensure the complete `swapBack` function is available for audit to verify its implementation details.

StatusUnresolved

Low

Lack of Emergency Pause Mechanism

L-01The contract lacks a mechanism to globally pause transfers or critical functions in case of an emergency (e.g., a major exploit, critical bug discovery, or extreme market instability). While the owner can blacklist individual addresses, a global pause would offer a more robust and immediate response to widespread issues affecting the entire protocol (7.8 Operations).

IssueThe contract lacks a mechanism to globally pause transfers or critical functions in case of an emergency (e.g., a major exploit, critical bug discovery, or extreme market instability). While the owner can blacklist individual addresses, a global pause would offer a more robust and immediate response to widespread issues affecting the entire protocol (7.8 Operations).

FixConsider implementing a pause functionality that can halt transfers or other critical operations in an emergency. This mechanism should ideally be controlled by a multi-signature wallet or a time-locked governance process to prevent arbitrary activation.

StatusUnresolved

Low

Reliance on `pragma experimental ABIEncoderV2`

L-02The contract uses `pragma experimental ABIEncoderV2;`. While this pragma is widely used and generally stable in recent Solidity versions (0.8.x), it is still marked as experimental. In very rare cases, experimental features might have undiscovered edge cases or subtle bugs that could lead to unexpected behavior (7.2 Code Security).

IssueThe contract uses `pragma experimental ABIEncoderV2;`. While this pragma is widely used and generally stable in recent Solidity versions (0.8.x), it is still marked as experimental. In very rare cases, experimental features might have undiscovered edge cases or subtle bugs that could lead to unexpected behavior (7.2 Code Security).

FixWhile the risk is low in Solidity 0.8.x, it's generally good practice to avoid experimental pragmas if possible. If `ABIEncoderV2` is not strictly necessary for specific data structures, consider removing it. Otherwise, ensure thorough testing of all functions that might implicitly or explicitly use this encoder.

StatusUnresolved

Info

Immutability of Contract Logic

I-01The contract is not designed with an upgrade mechanism (e.g., proxy pattern). This means that any discovered bugs, vulnerabilities, or desired feature enhancements cannot be implemented without deploying an entirely new contract and migrating users. This is a complex and costly process that can fragment liquidity and user base (7.7 Upgrades).

IssueThe contract is not designed with an upgrade mechanism (e.g., proxy pattern). This means that any discovered bugs, vulnerabilities, or desired feature enhancements cannot be implemented without deploying an entirely new contract and migrating users. This is a complex and costly process that can fragment liquidity and user base (7.7 Upgrades).

FixAcknowledge the immutability of the contract. For future projects, consider using an upgradeable proxy pattern (e.g., UUPS) if the ability to fix bugs or add features post-deployment is desired. For this contract, ensure all logic is thoroughly tested before deployment, as changes will not be possible.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements standard ERC-20 functionality with custom transfer logic, including anti-whale/bot limits and fee mechanisms. The use of `SafeERC20` for external transfers is a good practice (7.2 Code Security). However, the provided `_transfer` function was truncated, preventing a complete analysis of its fee application and balance update logic. The contract also uses `pragma experimental ABIEncoderV2`, which, while common, is an experimental feature (7.2 Code Security).

GovernanceHigh1/10

The contract exhibits a high degree of centralization, with the owner possessing extensive control over critical economic parameters and user access (7.3 Access Control, 7.4 Economic). The owner can blacklist addresses, effectively censoring users, and can unilaterally adjust transaction fees and limits. The `swapBack` mechanism, while intended for liquidity management, could lead to price impact if not carefully managed (7.4 Economic).

UpgradesMedium6/10

The contract is not designed with an upgrade mechanism, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates upgrade-specific risks but also prevents any future bug fixes or feature enhancements without a full redeployment and migration process.

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

41.8% in top 10

6.9% in wallets34.9% in contracts

Effective Concentration20.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.36M across 3 pairs

Uniswap v3WETHanalysed$1.31M Uniswap v2WETH$44.8K Uniswap v4ETH$2.2K

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.9%

Top-3 Unlocked100.0%

Key Addresses

7 addresses

Deployer

0x8db4…00f6

Unlocked LP Held By

0x42ca…f1680x09b1…6c640x6c3e…ac1d0x51f1…21890x46a3…bc210x9135…a98b

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

8 factors

Ownership NOT renounced — Multisig (2-of-5)
Top-10 concentration > 20% (41.8% total → 20.8% effective; 6.9% in EOAs, 34.9% in contracts — mild)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
LP top1 unlocked holder = 99.9% (exit-liquidity risk, pool = 97% of DEX liquidity)
LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 97% of DEX liquidity)
1 High finding(s) from audit
2 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

Is OpenServ Safe?

Security Findings

Centralized Control and Blacklisting Capability

High and Configurable Transaction Fees

Potential for Price Impact from `swapBack` Mechanism

Lack of Emergency Pause Mechanism

Reliance on `pragma experimental ABIEncoderV2`

Immutability of Contract Logic

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