Quantum Audit Logo

Is Wrapped State Street SPDR Portfolio S&P 500 ETF ST0x a Scam?

Early-stage security check — honeypot & rug-pull analysis

Wrapped State Street SPDR Portfolio S&P 500 ETF ST0x WTSPYM
0x31c2…c2d8
Base Not verifiedLast checked today 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The StoxWrappedTokenVault contract, serving as an ERC-4626 implementation behind a BeaconProxy, has been audited. The contract is minimal, primarily relying on well-vetted OpenZeppelin upgradeable libraries. No critical or high-severity vulnerabilities were identified. Minor issues include potential compatibility challenges with non-standard ERC-20 assets and an unused initialization function. The upgradeability mechanism is correctly implemented.

1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$164.5K
Liquidity
$744.7K
Price
$303.2300
Token Age
1d
Top 10 Holders
98.2%

Security Findings

1 Low2 Info
Low

Potential for Non-Standard ERC-20 Asset Issues

L-01The `StoxWrappedTokenVault` is an ERC-4626 vault that wraps an underlying ERC-20 asset. While OpenZeppelin's ERC-4626 implementation is robust, certain non-standard ERC-20 tokens (e.g., rebase tokens, tokens with transfer fees, tokens that revert on zero-value transfers, tokens with non-boolean return values for `transfer`/`transferFrom`) can cause unexpected behavior, accounting discrepancies, or loss of funds within an ERC-4626 vault. The current contract does not implement specific safeguards or checks for such tokens, relying solely on the standard ERC-20 interface.
IssueThe `StoxWrappedTokenVault` is an ERC-4626 vault that wraps an underlying ERC-20 asset. While OpenZeppelin's ERC-4626 implementation is robust, certain non-standard ERC-20 tokens (e.g., rebase tokens, tokens with transfer fees, tokens that revert on zero-value transfers, tokens with non-boolean return values for `transfer`/`transferFrom`) can cause unexpected behavior, accounting discrepancies, or loss of funds within an ERC-4626 vault. The current contract does not implement specific safeguards or checks for such tokens, relying solely on the standard ERC-20 interface.
FixBefore deploying with a specific asset, thoroughly review the underlying ERC-20 token's contract for any non-standard behaviors. If such behaviors are identified, consider implementing custom logic within the vault (e.g., by overriding `_deposit`, `_withdraw`, `_mint`, `_redeem` functions) to handle them gracefully, or restrict the vault to only support standard ERC-20 tokens. Comprehensive testing with the chosen asset is crucial.
StatusUnresolved
Info

Unused/Decoy `initialize(address)` Function

I-01The contract includes an `initialize(address asset) external pure returns (bytes32)` function that immediately reverts with `InitializeSignatureFn()`. This function is marked `pure`, meaning it cannot modify state, and its immediate revert makes it harmless. However, its presence alongside the actual `initialize(bytes calldata data)` function could be confusing or misleading for developers or auditors.
IssueThe contract includes an `initialize(address asset) external pure returns (bytes32)` function that immediately reverts with `InitializeSignatureFn()`. This function is marked `pure`, meaning it cannot modify state, and its immediate revert makes it harmless. However, its presence alongside the actual `initialize(bytes calldata data)` function could be confusing or misleading for developers or auditors.
FixConsider removing the unused `initialize(address asset)` function to improve code clarity and reduce potential confusion. If it serves a specific, non-obvious purpose (e.g., preventing a specific signature collision), add a comment explaining its intent.
StatusUnresolved
Info

Reliance on External `ICloneableV2` Interface

I-02The contract implements the `ICloneableV2` interface and returns `ICLONEABLE_V2_SUCCESS` from its `initialize` function. This indicates that the contract is designed to be deployed via a factory that expects this specific interface and return value. While not a vulnerability in the vault itself, this is an important architectural dependency that should be understood for proper deployment, management, and interaction with the vault instances.
IssueThe contract implements the `ICloneableV2` interface and returns `ICLONEABLE_V2_SUCCESS` from its `initialize` function. This indicates that the contract is designed to be deployed via a factory that expects this specific interface and return value. While not a vulnerability in the vault itself, this is an important architectural dependency that should be understood for proper deployment, management, and interaction with the vault instances.
FixEnsure that the factory deploying instances of this vault is correctly configured to interact with the `ICloneableV2` interface and handles the expected return value. Document this architectural dependency clearly for future development and operational teams.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract (7.1 Architecture) is a straightforward ERC-4626 vault implementation, inheriting extensively from OpenZeppelin's battle-tested upgradeable contracts. This significantly reduces the attack surface and enhances (7.2 Code Security) robustness against common vulnerabilities like reentrancy and integer overflows. The initialization logic (7.3 Access Control) correctly uses the `initializer` modifier and `_disableInitializers()` in the constructor, preventing re-initialization on the implementation contract itself. A minor concern is the potential for unexpected behavior with non-standard ERC-20 assets (7.6 External), which is a common caveat for ERC-4626 vaults.

GovernanceHigh1/10

The contract implements a standard ERC-4626 vault (7.4 Economic) without introducing complex economic models, fees, or governance mechanisms (7.5 Governance). Its economic behavior is primarily dictated by the underlying asset and the ERC-4626 standard's share-to-asset conversion logic. The primary economic risk stems from the chosen underlying asset's properties, rather than the vault's internal mechanics.

UpgradesHigh1/10

The contract is designed as an upgradeable implementation for a BeaconProxy (7.7 Upgrades), correctly utilizing OpenZeppelin's `Upgradeable` pattern. The `_disableInitializers()` function in the constructor prevents direct initialization of the implementation contract, safeguarding against storage collisions. The `initialize` function, protected by the `initializer` modifier, ensures secure, one-time initialization for each proxy instance.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

98.2% in top 10
3.0% in wallets95.2% in contracts
Effective Concentration41.1%

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

$811.2K across 10 pairs
Uniswap v4STONXanalysed$744.7K91.8%Hydrex CLAMMUSDC$64.1K7.9%Uniswap v4USDC$1.1K0.1%Uniswap v4USDC$6330.1%Uniswap v4USDC$6060.1%Uniswap v4USDC$990.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

2 addresses
Deployer
0xc4e7…6888
Unlocked LP Held By
0x1791…e359

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (98.2% total → 41.1% effective; 3.0% in EOAs, 95.2% in contracts — moderate)
  • 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, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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
BaseStonk (BSTONK)High RiskVelvetHigh RiskDiemHigh Riskether.fi governance token (ETHFI)High RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High Risk

Would You Like a More Detailed Audit of Wrapped State Street SPDR Portfolio S&P 500 ETF ST0x?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit