Quantum Audit Logo
Launch App

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

Is OpenServ Safe?

SERVEthereum
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed5 of 7Findings1 High · 2 Medium · 2 Low · 1 Info6
SummaryAI Copilot

The OpenServ token contract implements a standard ERC-20 interface with additional features for anti-whale/anti-bot measures, transaction fees, and an automated swap-and-liquify mechanism.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 20%
  • Liquidity not locked
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
34.9%Contracts6.9%58.2%Everyone else
34.9%Contracts6.9%58.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
41.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking34.9%
  • Walletsanonymous holders, free to sell6.9%
  • Everyone elsethe rest of the supply58.2%
Effective concentrationwhat the score reads20.8%
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$1.36M across 3 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$1.31MShare of depth96.5%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
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.

Security Findings

1 High2 Medium2 Low1 Info
High

Centralized Control and Blacklisting Capability

The 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).H-01

Issue

The 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).

Fix

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

Status

Unresolved

Medium

High and Configurable Transaction Fees

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

Issue

The 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).

Fix

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

Status

Unresolved

Medium

Potential for Price Impact from swapBack Mechanism

The 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).M-02

Issue

The 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).

Fix

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

Status

Unresolved

Low

Lack of Emergency Pause Mechanism

The 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).L-01

Issue

The 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).

Fix

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

Status

Unresolved

Low

Reliance on pragma experimental ABIEncoderV2

The 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).L-02

Issue

The 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).

Fix

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

Status

Unresolved

Info

Immutability of Contract Logic

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

Issue

The 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).

Fix

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

Status

Unresolved

Analysis

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

The OpenServ token contract implements a standard ERC-20 interface with additional features for anti-whale/anti-bot measures, transaction fees, and an automated swap-and-liquify mechanism. The contract utilizes an Ownable pattern, granting the deployer significant control over token parameters, including the ability to blacklist addresses and adjust transaction fees and limits. A critical limitation of this audit is that the provided _transfer function was truncated, preventing a full assessment of the fee application and balance update logic. Despite this, the defined mechanisms and owner's control present notable risks.

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to decentralize control where possible, especially regarding blacklisting capabilities, or implement a multi-signature wallet for critical administrative functions to mitigate single points of failure.

Thoroughly review and complete the _transfer function to ensure correct fee application and balance updates, and consider the economic implications of high, mutable fees and the swapBack mechanism. Implement an emergency pause functionality to provide a safety net against unforeseen issues.

Contract & Record

1 audit on record
TypeVault, Router, Token
NetworkEthereum
Token age1y
Contract0x40e3…8042
Deployer0x8db4…00f6
Badge for your website
OpenServ 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. Aug 31, 202670High

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

Related Audits

6 more on the recordAll audits
SKY Governance TokenSKY · Ethereum70HighOrigin EtherOETH · Ethereum70HighWootrade NetworkWOO · Ethereum70HighrsFIROEthereum70HighGram (prev. Toncoin)GRAM · Ethereum69HighDAPPOSDOS · Ethereum71High

Would You Like a More Detailed Audit of OpenServ?

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