Quantum Audit Logo

Is Stargate Finance Safe?

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

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

Stargate Finance STG
0xaf51…2cd6
Ethereum
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.Own this token? Put it under verification →
Last checked 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The StargateToken contract is an ERC20 token with omnichain capabilities powered by LayerZero. It implements a standard lock/burn and mint/unlock mechanism for cross-chain transfers. The contract utilizes OpenZeppelin's battle-tested libraries for ERC20 and access control. Key findings include significant centralized control by the owner, inherent reliance on the LayerZero endpoint's security, and a minor concern regarding inline assembly for address decoding. The contract is not upgradeable, simplifying its security profile in that regard.

1 High1 Medium1 Low2 Informational
Volume 24h
$1.9K
Liquidity
$16.4K
Price
$0.1697
Token Age
4y
Top 10 Holders
93.9%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control by Owner

H-01The `Ownable` pattern grants the contract owner extensive control over critical functions, including `pauseSendTokens`, `setDestination`, and various LayerZero endpoint configurations (`setConfig`, `setSendVersion`, `setReceiveVersion`, `forceResumeReceive`). A compromise of the owner's private key could lead to the pausing of cross-chain transfers, misdirection of funds by setting malicious destination contracts, or manipulation of LayerZero configurations. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
IssueThe `Ownable` pattern grants the contract owner extensive control over critical functions, including `pauseSendTokens`, `setDestination`, and various LayerZero endpoint configurations (`setConfig`, `setSendVersion`, `setReceiveVersion`, `forceResumeReceive`). A compromise of the owner's private key could lead to the pausing of cross-chain transfers, misdirection of funds by setting malicious destination contracts, or manipulation of LayerZero configurations. (7.3 Access Control, 7.4 Economic, 7.8 Operations)
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for ownership of the contract to distribute control and reduce the single point of failure risk. Consider time-locks for critical administrative actions to allow for community review or emergency response.
StatusUnresolved
Medium

Reliance on External LayerZero Endpoint Security

M-01The contract's core cross-chain functionality relies entirely on the security and correct operation of the LayerZero endpoint. Any vulnerabilities, misconfigurations, or compromises within the LayerZero protocol or its specific endpoint implementation could directly impact the integrity of token transfers, potentially leading to loss of funds or incorrect token supply across chains. (7.6 External)
IssueThe contract's core cross-chain functionality relies entirely on the security and correct operation of the LayerZero endpoint. Any vulnerabilities, misconfigurations, or compromises within the LayerZero protocol or its specific endpoint implementation could directly impact the integrity of token transfers, potentially leading to loss of funds or incorrect token supply across chains. (7.6 External)
FixWhile direct mitigation within this contract is limited, it is crucial to maintain a strong understanding of LayerZero's security posture, monitor their announcements, and have contingency plans in place for potential LayerZero-related incidents. Ensure the LayerZero endpoint address used is the official and correct one.
StatusUnresolved
Low

Assembly for Address Decoding

L-01The `lzReceive` function uses an inline assembly block (`assembly { toAddress := mload(add(_to, 20)) }`) to extract an `address` from a `bytes` variable `_to`. While this pattern can be efficient, it relies on specific knowledge of how `bytes` are encoded in memory and assumes `_to` will always contain a 20-byte address at the expected offset. If the encoding of `_to` were to change or if `_to` were not exactly 20 bytes, this could lead to incorrect address extraction or unexpected behavior. (7.2 Code Security)
IssueThe `lzReceive` function uses an inline assembly block (`assembly { toAddress := mload(add(_to, 20)) }`) to extract an `address` from a `bytes` variable `_to`. While this pattern can be efficient, it relies on specific knowledge of how `bytes` are encoded in memory and assumes `_to` will always contain a 20-byte address at the expected offset. If the encoding of `_to` were to change or if `_to` were not exactly 20 bytes, this could lead to incorrect address extraction or unexpected behavior. (7.2 Code Security)
FixConsider using `abi.decode` directly if the `_to` parameter is consistently an `address` type encoded as `bytes`. For example, if `_to` is always `abi.encodePacked(address_value)`, then `(address toAddress, uint256 qty) = abi.decode(_payload, (address, uint256));` would be safer and more readable. If the current assembly is strictly necessary due to LayerZero's specific payload structure, ensure thorough testing covers edge cases for `_to`'s length and content.
StatusUnresolved
Info

Renounce Ownership Disabled

I-01The `renounceOwnership()` function is overridden to be a no-op (`function renounceOwnership() public override onlyOwner {}`). This prevents the owner from accidentally or intentionally renouncing ownership, which can be a security feature to avoid leaving the contract unmanaged. However, it also means that ownership cannot be permanently removed without transferring it to another address. (7.3 Access Control, 7.8 Operations)
IssueThe `renounceOwnership()` function is overridden to be a no-op (`function renounceOwnership() public override onlyOwner {}`). This prevents the owner from accidentally or intentionally renouncing ownership, which can be a security feature to avoid leaving the contract unmanaged. However, it also means that ownership cannot be permanently removed without transferring it to another address. (7.3 Access Control, 7.8 Operations)
FixThis is a design choice. If the intention is to always have an owner, this implementation is acceptable. Ensure that the owner address is securely managed and that there are clear operational procedures for ownership transfers.
StatusUnresolved
Info

BUSL-1.1 License

I-02The contract uses the Business Source License 1.1 (BUSL-1.1). This is a non-open source license that typically restricts usage for a certain period or until specific conditions are met, after which it may convert to an open-source license like MIT. While not a security vulnerability, it's important for users and integrators to be aware of the licensing terms and their implications for usage and modification.
IssueThe contract uses the Business Source License 1.1 (BUSL-1.1). This is a non-open source license that typically restricts usage for a certain period or until specific conditions are met, after which it may convert to an open-source license like MIT. While not a security vulnerability, it's important for users and integrators to be aware of the licensing terms and their implications for usage and modification.
FixEnsure all parties interacting with or building upon this contract understand the terms and conditions of the BUSL-1.1 license.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's battle-tested ERC20 and SafeMath for token operations, enhancing code security (7.2). It implements a standard lock/burn and mint/unlock mechanism for cross-chain transfers via LayerZero, demonstrating a clear architectural design (7.1). However, the reliance on LayerZero as an external dependency introduces inherent risks (7.6), and the use of inline assembly for address decoding in `lzReceive` (7.2) could be a source of subtle errors if not handled precisely.

GovernanceHigh1/10

The contract employs an `Ownable` access control pattern, granting the owner significant power over critical functions such as pausing token transfers and setting destination contracts (7.3). This centralized control (7.4) presents a single point of failure; a compromised owner key could lead to severe economic consequences. The `renounceOwnership` function is intentionally disabled (7.8), ensuring continuous management but also requiring robust operational security for the owner's key.

UpgradesMedium6/10

The contract is deployed as a standard, non-upgradeable implementation (7.7). This design choice eliminates the complexities and risks associated with proxy upgrade mechanisms, such as storage collisions or upgrade path vulnerabilities. However, it means that any future bug fixes or feature enhancements would require a new deployment and migration, which can be a complex and costly process.

Security Checklist

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

Holder Composition

93.9% in top 10
88.1% in wallets5.8% in contracts
Effective Concentration90.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

$23.1K across 4 pairs
CurveUSDCanalysed$16.4K71.1%CurvecrvFRAX$5.7K24.7%Pancakeswap v3USDC$8123.5%BalancerUSDC$1570.7%

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
0x1d7c…e28d
Unlocked LP Held By
0x50e9…3645

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 — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 70% (93.9% total → 90.4% effective; 88.1% in EOAs, 5.8% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($23,086 across 4 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 71% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 71% of DEX liquidity)
  • 1 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
DIAToken (DIA)High RiskTERAFABHigh RiskWrapped Pulse from PulseChain (WPLS)High RiskTrace Token (TRAC)High RiskFLOKIHigh RiskPowerLedger (POWR)High Risk

Would You Like a More Detailed Audit of Stargate Finance?

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

Get Detailed Audit