Quantum Audit Logo

Is OpenServ Safe?

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

OpenServ SERV
0x5576…37ea
Base
Not verifiedThis 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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The BridgeToken contract, implemented as a BeaconProxy, provides standard ERC-20 functionalities along with owner-controlled minting, burning, and metadata updates. It incorporates EIP-712 Permit functionality. While the code adheres to good practices for ERC-20 and proxy patterns, significant centralization risks exist due to the owner's control over token supply and the BeaconProxy's upgrade mechanism. The owner is an external contract, which can mitigate some single-point-of-failure risks if it's a robust multi-sig or governance system.

2 High1 Medium1 Low1 Informational
Volume 24h
$79.6K
Liquidity
$834.5K
Price
$0.02308
Token Age
1y
Top 10 Holders
39.9%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Control of Token Supply

H-01The `mint` and `burn` functions are protected by the `onlyOwner` modifier, allowing the contract owner to arbitrarily increase or decrease the total supply of tokens. While this is a common design for bridge or wrapped tokens, it introduces a high degree of centralization and economic risk. A compromise of the owner's private key or the owner contract could lead to uncontrolled token supply manipulation, devaluing the token or causing significant financial loss to users.
IssueThe `mint` and `burn` functions are protected by the `onlyOwner` modifier, allowing the contract owner to arbitrarily increase or decrease the total supply of tokens. While this is a common design for bridge or wrapped tokens, it introduces a high degree of centralization and economic risk. A compromise of the owner's private key or the owner contract could lead to uncontrolled token supply manipulation, devaluing the token or causing significant financial loss to users.
FixEnsure the owner address () is secured with robust multi-signature controls, time-locks, or a well-audited governance mechanism. Implement strict operational procedures for minting and burning, and consider transparent reporting of such operations.
StatusUnresolved
High

Beacon Proxy Centralization Risk

H-02The contract is an implementation for a BeaconProxy. This pattern means that the `BridgeToken` proxy's logic can be updated by changing the implementation address stored in the Beacon contract. The security of the Beacon contract itself, and the entity controlling its upgrades, is a critical single point of failure. If the Beacon or its owner is compromised, all associated proxies could be upgraded to a malicious implementation, leading to potential loss of funds or control.
IssueThe contract is an implementation for a BeaconProxy. This pattern means that the `BridgeToken` proxy's logic can be updated by changing the implementation address stored in the Beacon contract. The security of the Beacon contract itself, and the entity controlling its upgrades, is a critical single point of failure. If the Beacon or its owner is compromised, all associated proxies could be upgraded to a malicious implementation, leading to potential loss of funds or control.
FixImplement stringent security measures for the Beacon contract and its owner. This should include multi-signature wallets, time-locks for upgrade proposals, and thorough auditing of any new implementation contracts before they are set in the Beacon. Clearly communicate the upgradeability mechanism and its associated risks to users.
StatusUnresolved
Medium

Immutable Owner After Initialization

M-01The contract's owner is set during the `initialize` function via the `owner_` parameter and stored in `_state.owner`. There is no dedicated `transferOwnership` or `renounceOwnership` function provided in the `TokenImplementation` contract. This means that once initialized, the owner address cannot be changed through a standard function call. While an upgrade via the BeaconProxy pattern could theoretically change the owner by modifying the storage slot directly, the lack of a explicit transfer mechanism increases operational rigidity and could complicate owner management or recovery in certain scenarios.
IssueThe contract's owner is set during the `initialize` function via the `owner_` parameter and stored in `_state.owner`. There is no dedicated `transferOwnership` or `renounceOwnership` function provided in the `TokenImplementation` contract. This means that once initialized, the owner address cannot be changed through a standard function call. While an upgrade via the BeaconProxy pattern could theoretically change the owner by modifying the storage slot directly, the lack of a explicit transfer mechanism increases operational rigidity and could complicate owner management or recovery in certain scenarios.
FixConsider adding a `transferOwnership(address newOwner_)` function, protected by `onlyOwner`, to allow for a secure and explicit transfer of administrative control. This would enhance operational flexibility and provide a standard way to manage the owner role.
StatusUnresolved
Low

Metadata Update Invalidates EIP-712 Permit Signatures

L-01The `updateDetails` function allows the owner to change the token's `name` and `symbol`. When these parameters change, the EIP-712 domain separator, which is derived from the token's name, version, chain ID, and verifying contract, will also change. This will invalidate any existing EIP-712 `permit` signatures that were generated using the old domain separator. While this behavior is inherent to the EIP-712 standard when domain parameters are modified, it could lead to unexpected failures for users or dApps relying on pre-signed permits.
IssueThe `updateDetails` function allows the owner to change the token's `name` and `symbol`. When these parameters change, the EIP-712 domain separator, which is derived from the token's name, version, chain ID, and verifying contract, will also change. This will invalidate any existing EIP-712 `permit` signatures that were generated using the old domain separator. While this behavior is inherent to the EIP-712 standard when domain parameters are modified, it could lead to unexpected failures for users or dApps relying on pre-signed permits.
FixInform users and integrated dApps that changes to the token's name or symbol via `updateDetails` will invalidate previously signed EIP-712 permits. Ensure clear communication channels are in place to announce such updates.
StatusUnresolved
Info

`TokenState` Contract Not Provided for Full Review

I-01The `TokenImplementation` contract inherits from `TokenState`, which is responsible for defining the contract's storage layout and likely includes critical state variables such as `balances`, `allowances`, `totalSupply`, and `nonces` for EIP-712 permits. The source code for `TokenState` was not provided for this audit. While the `TokenImplementation` appears to correctly interact with `_state`, a full review of `TokenState` is necessary to confirm its storage layout, variable types, and overall security, especially for proxy compatibility and nonce management.
IssueThe `TokenImplementation` contract inherits from `TokenState`, which is responsible for defining the contract's storage layout and likely includes critical state variables such as `balances`, `allowances`, `totalSupply`, and `nonces` for EIP-712 permits. The source code for `TokenState` was not provided for this audit. While the `TokenImplementation` appears to correctly interact with `_state`, a full review of `TokenState` is necessary to confirm its storage layout, variable types, and overall security, especially for proxy compatibility and nonce management.
FixProvide the source code for the `TokenState` contract for a comprehensive security review, ensuring its storage layout is compatible with the proxy pattern and that all state management logic is robust and secure.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract implements ERC-20 standards correctly, including transfer, approval, and balance management with appropriate checks for zero addresses and sufficient balances (7.2 Code Security). EIP-712 Permit functionality is well-integrated, utilizing OpenZeppelin's ECDSA library and a robust caching mechanism for the domain separator (7.2 Code Security). The use of Solidity 0.8+ inherently protects against integer overflow/underflow. However, the full `TokenState` contract was not provided, preventing a complete review of its storage layout and nonce management (7.1 Architecture).

GovernanceHigh3/10

The contract grants the owner significant control over the token's economic parameters, specifically the ability to `mint` and `burn` arbitrary amounts of tokens (7.4 Economic, 7.3 Access Control). This centralization, while common for bridge tokens, presents a high economic risk if the owner's address (an external contract) is compromised. The `updateDetails` function allows the owner to change the token's name and symbol, which could impact integrations or user perception if not managed carefully (7.4 Economic). The owner is set during initialization and cannot be changed via a dedicated `transferOwnership` function (7.5 Governance).

UpgradesHigh1/10

The contract is designed as an implementation for a BeaconProxy, which allows for upgradeability (7.7 Upgrades). The `initializer` modifier correctly prevents re-initialization of the implementation contract. Storage is managed through inheritance of `TokenState`, ensuring proper slot allocation for proxy compatibility (7.1 Architecture). However, the BeaconProxy pattern introduces a critical centralization point: the security of the Beacon contract and its owner is paramount, as a compromise could lead to malicious upgrades affecting all associated proxies (7.7 Upgrades).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

39.9% in top 10
8.0% in wallets32.0% 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

$879.2K across 6 pairs
AerodromeWETHanalysed$834.5K94.9%AerodromeWETH$38.2K4.3%Uniswap v3WETH$4.5K0.5%Hydrex CLAMMWETH$1.1K0.1%Uniswap v4USDC$8460.1%AerodromeWETH$30.0%

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 Holder82.7%
Top-3 Unlocked100.0%

Key Addresses

7 addresses
Deployer
0x8db4…00f6
Unlocked LP Held By
0x7df5…29170xf85c…0ee10xbc19…0d810x6313…1a600xf5d2…23970x2e39…01b3

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

What Raised This Score

11 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 20% (39.9% total → 20.8% effective; 8.0% in EOAs, 32.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 82.7% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 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

Related Audits

6 more on the record
Wrapped Coinbase Global Inc ST0x (WTCOIN)High RiskMorpho Token (MORPHO)High RiskTether USD (USDT)High RiskOMI Token (OMI)High RiskevoHigh RiskSilencio (SLC)High Risk

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