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.

On-chain security analysis — is it a scam or legit?
Is KGEN Safe?
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 →The KgenOFT contract implements an Omnichain Fungible Token (OFT) utilizing LayerZero for cross-chain functionality.
Read the full analysis- Ownership not renounced — Multisig
- Top-10 concentration > 70%
- Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
- Liquidity < $50k
- LP top1 unlocked holder = 100.0%
- LP top3 unlocked holders = 100.0%
- 1 High finding(s) from audit
- 1 Medium finding(s) from audit
- 2 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking31.2%
- Walletsanonymous holders, free to sell61.9%
- Everyone elsethe rest of the supply6.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- 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 LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x283a…d4170x6458…2df50x52e7…db4dNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Control Over Critical Functions
The 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…H-01
Issue
The 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…
Fix
While 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.
Status
Unresolved
MediumPotential Gas Limit Issues in batchSetBlacklistStatus
The 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.M-01
batchSetBlacklistStatusIssue
The 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.
Fix
While 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.
Status
Unresolved
LowUnindexed Event Parameter in UpdateFeeVault
The 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.L-01
UpdateFeeVaultIssue
The 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.
Fix
Index 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);`
Status
Unresolved
LowRedundant Modifier in setCrossChainPaused
The 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.L-02
setCrossChainPausedIssue
The 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.
Fix
Remove 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.
Status
Unresolved
InfoRedundant Ownable Inheritance in Constructor
The 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.I-01
Ownable Inheritance in ConstructorIssue
The 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.
Fix
Remove the explicit Ownable(_delegate) call from the constructor's inheritance list. The Ownable constructor will be correctly called via the Ownable2Step inheritance.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 4The 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).
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).
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.
It is recommended to carefully review the distribution of roles and responsibilities within the multisig to ensure robust operational security and prevent potential misuse of administrative powers.
Consider indexing all critical event parameters to enhance off-chain monitoring capabilities. Maintain strict security protocols for the multisig keys and ensure a clear emergency response plan is in place for potential security incidents.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Aug 14, 202678High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the KGEN contract address?
The KGEN contract on BNB Chain is 0xf3d5b4c34ed623478cc5141861776e6cf7ae3a1e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is KGEN a scam?
Quantum Audit's risk score for KGEN is 78/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Is KGEN liquidity locked?
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $20.9K.
Who holds KGEN?
As of Sep 4, 2026, the 10 largest holders own 93.2% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page