Quantum Audit Logo

Is KGEN Safe?

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

Is this your token? Publish your own audit on this page →

KGEN KGEN
0xf3d5…3a1e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The KgenOFT contract implements an Omnichain Fungible Token (OFT) utilizing LayerZero for cross-chain functionality. It incorporates robust access control via OpenZeppelin's `AccessControl` and `Ownable2Step` patterns, along with pausing mechanisms and a blacklist. Critical administrative roles are managed by a 2/3 multisig, enhancing security. The contract demonstrates good adherence to security best practices for EVM development.

1 High1 Medium2 Low1 Informational
Volume 24h
$25.8K
Liquidity
$20.8K
Price
$0.1805
Token Age
10mo
Top 10 Holders
93.2%

Security Findings

1 High1 Med2 Low1 Info
High

Centralized Control Over Critical Functions

H-01The `DEFAULT_ADMIN_ROLE`, held by a 2/3 multisig, possesses extensive control over critical contract functions. This includes the ability to pause the contract (`setPaused`), pause cross-chain operations (`setCrossChainPaused`), blacklist users (`setBlacklistStatus`, `batchSetBlacklistStatus`), manage trusted forwarders (`addTrustedForwarder`, `removeTrustedForwarder`, `updateTrustedForwarder`), and recover ERC20/ETH (`recoverERC20`, `recoverETH`). While a multisig mitigates single-point-of-failure risks, the concentration of such broad power in a single entity (the multisig) represents a significant centralization risk. Compromise or malicious action by the multisig signers could lead to a…
IssueThe `DEFAULT_ADMIN_ROLE`, held by a 2/3 multisig, possesses extensive control over critical contract functions. This includes the ability to pause the contract (`setPaused`), pause cross-chain operations (`setCrossChainPaused`), blacklist users (`setBlacklistStatus`, `batchSetBlacklistStatus`), manage trusted forwarders (`addTrustedForwarder`, `removeTrustedForwarder`, `updateTrustedForwarder`), and recover ERC20/ETH (`recoverERC20`, `recoverETH`). While a multisig mitigates single-point-of-failure risks, the concentration of such broad power in a single entity (the multisig) represents a significant centralization risk. Compromise or malicious action by the multisig signers could lead to a…
FixWhile a multisig is a good mitigation, consider further decentralizing control where feasible, or implementing time-locks/governance delays for highly sensitive operations. Ensure the multisig signers are diverse, trusted, and follow stringent key management practices. Implement robust monitoring for all administrative actions.
StatusUnresolved
Medium

Potential Gas Limit Issues in `batchSetBlacklistStatus`

M-01The `batchSetBlacklistStatus` function iterates through an array of `accounts` to update their blacklist status. If the `accounts` array contains a very large number of addresses, the transaction's gas cost could exceed the block gas limit. This would prevent the function from being executed, making it impossible to blacklist a large batch of users in a single transaction, potentially hindering administrative operations during an incident.
IssueThe `batchSetBlacklistStatus` function iterates through an array of `accounts` to update their blacklist status. If the `accounts` array contains a very large number of addresses, the transaction's gas cost could exceed the block gas limit. This would prevent the function from being executed, making it impossible to blacklist a large batch of users in a single transaction, potentially hindering administrative operations during an incident.
FixWhile this is an administrative function, consider implementing a mechanism to process large batches in smaller, manageable chunks off-chain, or add a maximum array size check to prevent accidental gas limit overruns. Alternatively, ensure that the expected usage of this function will always involve a reasonable number of accounts.
StatusUnresolved
Low

Unindexed Event Parameter in `UpdateFeeVault`

L-01The `UpdateFeeVault` event, emitted by the `updateFeeVault` function, includes `new_fee_vault` and `old_fee_vault` parameters. However, neither of these parameters is indexed. Indexing critical event parameters allows for more efficient and faster filtering and retrieval of event data by off-chain applications, block explorers, and analytics tools. Without indexing, searching for specific fee vault changes requires scanning all events.
IssueThe `UpdateFeeVault` event, emitted by the `updateFeeVault` function, includes `new_fee_vault` and `old_fee_vault` parameters. However, neither of these parameters is indexed. Indexing critical event parameters allows for more efficient and faster filtering and retrieval of event data by off-chain applications, block explorers, and analytics tools. Without indexing, searching for specific fee vault changes requires scanning all events.
FixIndex the `new_fee_vault` and `old_fee_vault` parameters in the `UpdateFeeVault` event to improve off-chain data querying efficiency. For example: `event UpdateFeeVault(address indexed new_fee_vault, address indexed old_fee_vault);`
StatusUnresolved
Low

Redundant Modifier in `setCrossChainPaused`

L-02The `setCrossChainPaused` function includes the `whenCrossChainNotPaused` modifier. This modifier checks `if (crossChainPaused) revert CrossChainOperationsPaused();`. However, the purpose of `setCrossChainPaused` is to *change* the `crossChainPaused` state. Applying `whenCrossChainNotPaused` to a function that intends to pause cross-chain operations creates a logical redundancy and prevents the function from being called if cross-chain operations are already paused, which might not be the intended behavior for an 'unpause' action.
IssueThe `setCrossChainPaused` function includes the `whenCrossChainNotPaused` modifier. This modifier checks `if (crossChainPaused) revert CrossChainOperationsPaused();`. However, the purpose of `setCrossChainPaused` is to *change* the `crossChainPaused` state. Applying `whenCrossChainNotPaused` to a function that intends to pause cross-chain operations creates a logical redundancy and prevents the function from being called if cross-chain operations are already paused, which might not be the intended behavior for an 'unpause' action.
FixRemove the `whenCrossChainNotPaused` modifier from the `setCrossChainPaused` function. The function should only be gated by `whenNotPaused` (for global pause) and `onlyRole(PAUSER_ROLE)` to allow the PAUSER_ROLE to toggle the `crossChainPaused` state freely.
StatusUnresolved
Info

Redundant `Ownable` Inheritance in Constructor

I-01The `KgenOFT` contract inherits from both `Ownable2Step` and `Ownable`. In the constructor, `Ownable(_delegate)` is explicitly called. However, `Ownable2Step` itself inherits from `Ownable`, meaning the `Ownable` constructor is implicitly called when `Ownable2Step()` is invoked. Explicitly calling `Ownable(_delegate)` in the inheritance list is redundant and does not add new functionality or change behavior, but it can make the inheritance chain slightly less clear.
IssueThe `KgenOFT` contract inherits from both `Ownable2Step` and `Ownable`. In the constructor, `Ownable(_delegate)` is explicitly called. However, `Ownable2Step` itself inherits from `Ownable`, meaning the `Ownable` constructor is implicitly called when `Ownable2Step()` is invoked. Explicitly calling `Ownable(_delegate)` in the inheritance list is redundant and does not add new functionality or change behavior, but it can make the inheritance chain slightly less clear.
FixRemove the explicit `Ownable(_delegate)` call from the constructor's inheritance list. The `Ownable` constructor will be correctly called via the `Ownable2Step` inheritance.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract exhibits strong technical security, leveraging Solidity 0.8.x for automatic overflow/underflow protection, `ReentrancyGuard` for reentrancy prevention, and `SafeERC20` for secure token interactions (7.2 Code Security). Critical functions like `_send` are protected by `whenNotPaused`, `whenCrossChainNotPaused`, and `notBlacklisted` modifiers. Minor issues include a potentially redundant modifier in `setCrossChainPaused` and an unindexed event parameter in `updateFeeVault` (7.2 Code Security).

GovernanceHigh1/10

Governance is centralized, with a 2/3 multisig holding the `DEFAULT_ADMIN_ROLE`, which grants extensive control over the contract's operations (7.5 Governance). This includes the ability to pause the contract, manage the blacklist, add/remove trusted forwarders, and recover funds (7.3 Access Control, 7.4 Economic). While the multisig mitigates single-point-of-failure risks, the concentration of power remains a significant factor. The `Ownable2Step` pattern enhances the security of ownership transfers (7.3 Access Control).

UpgradesMedium6/10

The KgenOFT contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). It does not utilize proxy patterns for in-place upgrades. Any future modifications to the contract logic would necessitate the deployment of a new contract and a migration process for users and assets, which is a common and acceptable design choice for token contracts.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

93.2% in top 10
61.9% in wallets31.2% in contracts
Effective Concentration74.4%

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

$20.9K across 4 pairs
UniswapUSDTanalysed$20.8K99.3%Pancakeswap v3WBNB$890.4%Pancakeswap v3USDT$520.3%Pancakeswap v2Subject 3$50.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x17cf…b339
Unlocked LP Held By
0x283a…d4170x6458…2df50x52e7…db4d

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

What Raised This Score

9 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 70% (93.2% total → 74.4% effective; 61.9% in EOAs, 31.2% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($20,947 across 4 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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

Related Audits

6 more on the record
Based Token (BASED)Critical RiskGRVTCritical RiskFalcon Finance (FF)Critical RiskBinance Brokers (BBROKERS)Critical RiskSpaceX (SPCXB)Critical RiskLorenzo Governance Token (BANK)Critical Risk

Would You Like a More Detailed Audit of KGEN?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit