Quantum Audit Logo

Is SIXSEVEN Safe?

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

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

SIXSEVEN 67
0xe7e5…c452
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive 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. 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.

2 Medium1 Low1 Informational
Volume 24h
$80.5K
Liquidity
$109.4K
Price
$0.02199
Token Age
26d
Top 10 Holders
12.8%

Security Findings

2 Med1 Low1 Info
Medium

Centralized Control by Owner

M-01The 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).
IssueThe 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).
FixConsider 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.
StatusUnresolved
Medium

Reliance on LayerZero Configuration and Operational Risks

M-02The 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved
Low

Potential Misconfiguration of Initial Owner

L-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Info

Hardcoded Decimals

I-01The `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.
IssueThe `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.
FixNo 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium5/10

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.

UpgradesHigh2/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 1-of-1
ImplementationVerified source

Holder Composition

12.8% in top 10
7.6% in wallets5.1% in contracts
Effective Concentration9.7%

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

$109.4K

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

2 addresses
Deployer
0x0a51…c508
Unlocked LP Held By
0xb242…8e76

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 — 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

Related Audits

6 more on the record
ChainOpera AI (COAI)High RiskYooldo Games (ESPORTS)High RiskAKEHigh RiskOPENHigh RiskBaby Ansem (BABYANSEM)High RiskEVAAHigh Risk

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