Quantum Audit Logo
Launch App

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

Is SIXSEVEN Safe?

67BNB Chain
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades2/10Checks passed2 of 5Findings2 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The SixSevenOFT contract is an upgradeable Omnichain Fungible Token (OFT) implementation built on LayerZero V2. It utilizes a TransparentUpgradeableProxy pattern with a multisig as the proxy admin.

Read the full analysis
What raised the score
  • Ownership not renounced — weak Multisig
  • Proxy contract
  • OZ ProxyAdmin -> Weak Multisig
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — weak Multisig (1-of-1)
  • Proxy contract (upgradeable — admin can replace logic)
  • OZ ProxyAdmin -> Weak Multisig (1-of-1)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)
  • 2 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
5.1%7.6%87.2%Everyone else
5.1%7.6%87.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
12.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking5.1%
  • Walletsanonymous holders, free to sell7.6%
  • Everyone elsethe rest of the supply87.2%
Effective concentrationwhat the score reads9.7%
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$109.4K

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$109.4KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xb242…8e76

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

Security Findings

2 Medium1 Low1 Info
Medium

Centralized Control by Owner

The contract uses the Ownable pattern, granting significant administrative control to a single owner address (a multisig in this case). This owner has the power to configure critical LayerZero parameters (e.g., setTrustedRemote, setMinDstGas), set delegates, and potentially upgrade the contract. While a multisig mitigates some risk, it still represents a centralized point of failure or potential misuse if the multisig's security is compromised or its members act maliciously (7.3 Access Control, 7.5 Governance).M-01

Issue

The contract uses the Ownable pattern, granting significant administrative control to a single owner address (a multisig in this case). This owner has the power to configure critical LayerZero parameters (e.g., setTrustedRemote, setMinDstGas), set delegates, and potentially upgrade the contract. While a multisig mitigates some risk, it still represents a centralized point of failure or potential misuse if the multisig's security is compromised or its members act maliciously (7.3 Access Control, 7.5 Governance).

Fix

Consider implementing a timelock for critical administrative functions to introduce a delay before changes take effect, allowing for community review or emergency intervention. Ensure the multisig governance process is robust, transparent, and follows best practices for key management and transaction approval.

Status

Unresolved

Medium

Reliance on LayerZero Configuration and Operational Risks

The contract's core functionality as an Omnichain Fungible Token (OFT) heavily relies on the correct and ongoing configuration of LayerZero parameters by the contract owner. Misconfiguration of parameters such as setTrustedRemote, setMinDstGas, or setFeeManager could lead to funds being stuck, lost during cross-chain transfers, or unexpected fee structures (7.6 External, 7.8 Operations). The security and reliability of the LayerZero protocol itself are also external dependencies.M-02

Issue

The contract's core functionality as an Omnichain Fungible Token (OFT) heavily relies on the correct and ongoing configuration of LayerZero parameters by the contract owner. Misconfiguration of parameters such as setTrustedRemote, setMinDstGas, or setFeeManager could lead to funds being stuck, lost during cross-chain transfers, or unexpected fee structures (7.6 External, 7.8 Operations). The security and reliability of the LayerZero protocol itself are also external dependencies.

Fix

Implement rigorous testing and verification procedures for all LayerZero parameter changes. Establish clear operational guidelines for the owner to manage these configurations. Monitor LayerZero's official channels for any security advisories or updates to the protocol. Consider integrating monitoring tools to detect unusual activity or misconfigurations.

Status

Unresolved

Low

Potential Misconfiguration of Initial Owner

The initialize function, which sets the token's name, symbol, and the initial owner via __Ownable_init(_delegate), is public. While protected by the initializer modifier to prevent re-initialization, if the _delegate parameter is incorrectly specified during the initial deployment and initialization of the proxy, the contract's ownership could be assigned to an unintended address (7.3 Access Control). Given the contract is live, this is primarily a deployment-time risk.L-01

Issue

The initialize function, which sets the token's name, symbol, and the initial owner via __Ownable_init(_delegate), is public. While protected by the initializer modifier to prevent re-initialization, if the _delegate parameter is incorrectly specified during the initial deployment and initialization of the proxy, the contract's ownership could be assigned to an unintended address (7.3 Access Control). Given the contract is live, this is primarily a deployment-time risk.

Fix

Ensure that the _delegate address passed to the initialize function during proxy deployment is thoroughly verified and corresponds to the intended multisig owner. Implement a robust deployment checklist to prevent such misconfigurations.

Status

Unresolved

Info

Hardcoded Decimals

The decimals() and sharedDecimals() functions are hardcoded to return 9. This is a design decision for the token (7.4 Economic). Any future requirement to change the token's decimal precision would necessitate a contract upgrade, which might be a complex process.I-01

Issue

The decimals() and sharedDecimals() functions are hardcoded to return 9. This is a design decision for the token (7.4 Economic). Any future requirement to change the token's decimal precision would necessitate a contract upgrade, which might be a complex process.

Fix

No direct action is required if this is the intended design. If flexibility in decimal precision is ever anticipated, consider a design that allows the owner to update this value, though this introduces additional complexity and potential risks.

Status

Unresolved

Analysis

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

The SixSevenOFT contract is an upgradeable Omnichain Fungible Token (OFT) implementation built on LayerZero V2. It utilizes a TransparentUpgradeableProxy pattern with a multisig as the proxy admin. The contract inherits standard OFT functionality, allowing cross-chain token transfers. While the core logic is based on audited LayerZero libraries and OpenZeppelin's upgradeable patterns, the operational security heavily depends on the correct configuration and management by the contract owner. Centralized control by the owner over critical LayerZero parameters and upgradeability presents a medium risk.

Technical8/10Low risk

The contract is a standard LayerZero OFT implementation, inheriting robust cross-chain token logic. It uses a recent Solidity compiler version (0.8.22) which includes default overflow/underflow checks (7.2 Code Security). However, the contract's functionality heavily relies on the correct and ongoing configuration of LayerZero parameters by the owner, which introduces an operational risk (7.6 External, 7.8 Operations). For example, incorrect setTrustedRemote configurations could lead to stuck funds.

Governance5/10Medium risk

The contract employs an Ownable pattern, granting significant control over critical LayerZero configurations and upgradeability to a single owner address (7.3 Access Control). While the owner is a multisig, this still represents a centralized point of control (7.5 Governance). The token's decimals are hardcoded to 9, which is a design decision (7.4 Economic) and would require an upgrade to change.

Upgrades2/10High risk

The contract utilizes the Transparent Upgradeable Proxy pattern, a well-established and audited mechanism for upgradeability. The proxy's admin is controlled by a multisig, enhancing security for future upgrades (7.7 Upgrades). The initialize function is correctly protected by the initializer modifier and _disableInitializers() is called in the constructor, preventing re-initialization of the implementation contract.

Final RecommendationWhat to do about this score

It is crucial to ensure that the multisig owner maintains robust security practices, including secure key management and a well-defined process for approving transactions, especially those related to LayerZero configuration and contract upgrades.

Regular monitoring of LayerZero's official channels for security announcements and updates is also recommended to address any potential vulnerabilities in the underlying protocol. Additionally, consider implementing a timelock for critical administrative actions to provide a delay for review and potential intervention.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age26d
Contract0xe7e5…c452
Deployer0x0a51…c508
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 1-of-1
ImplementationVerified source
Badge for your website
SIXSEVEN 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 20, 202652Medium

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

Related Audits

6 more on the recordAll audits
ChainOpera AICOAI · BNB Chain52MediumYooldo GamesESPORTS · BNB Chain52MediumAKEBNB Chain52MediumOPENBNB Chain52MediumKamirai$KAMIRAI · BNB Chain52MediumBaby AnsemBABYANSEM · BNB Chain51Medium

Would You Like a More Detailed Audit of SIXSEVEN?

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