Quantum Audit Logo

Is Wrapped iShares 0-3 Month Treasury Bond ETF ST0x Safe?

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

Wrapped iShares 0-3 Month Treasury Bond ETF ST0x WTSGOV
0x78c3…e935
Base
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.
Last checked 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The StoxWrappedTokenVault contract, implemented as an ERC4626 vault, has been audited. The contract leverages OpenZeppelin's upgradeable standards and follows a BeaconProxy pattern. The core logic is minimal, primarily relying on the well-vetted ERC4626 standard. Identified issues are primarily related to potential economic risks from underlying asset choices and minor code hygiene, with no critical or high-severity vulnerabilities found in the contract's direct implementation.

1 Medium1 Low3 Informational
Volume 24h
$73.9K
Liquidity
$26.4K
Price
$101.6100
Token Age
1y
Top 10 Holders
96.3%

Security Findings

1 Med1 Low3 Info
Medium

Missing Handling for Fee-on-Transfer or Rebase Tokens

M-01The ERC4626 vault does not implement specific checks or logic to handle underlying asset tokens that charge fees on transfer or rebase their balances. If such a token is used as the `asset`, the vault's `totalAssets()` calculation could become inaccurate, leading to a discrepancy between the actual assets held and the reported value. This can result in legitimate depositors losing funds or enable malicious actors to profit from the accounting imbalance (7.4 Economic, 7.2 Code Security).
IssueThe ERC4626 vault does not implement specific checks or logic to handle underlying asset tokens that charge fees on transfer or rebase their balances. If such a token is used as the `asset`, the vault's `totalAssets()` calculation could become inaccurate, leading to a discrepancy between the actual assets held and the reported value. This can result in legitimate depositors losing funds or enable malicious actors to profit from the accounting imbalance (7.4 Economic, 7.2 Code Security).
FixImplement a whitelist for approved asset tokens to ensure only standard ERC-20 tokens are used. Alternatively, if non-standard tokens must be supported, add custom logic to account for transfer fees or rebase mechanisms to maintain accurate vault accounting. Consider disallowing tokens that do not return `true` on transfer success or have other non-standard behaviors.
StatusUnresolved
Low

Absence of Emergency Administrative Controls

L-01The `StoxWrappedTokenVault` contract, as a standard ERC4626 implementation, does not include any explicit owner or administrative roles, nor does it have mechanisms for emergency actions such as pausing deposits/withdrawals. While this reduces centralization risk, it also means there is no way to halt operations in case of a critical vulnerability in the underlying asset, a severe market event, or an unforeseen exploit within the vault itself (7.3 Access Control, 7.8 Operations).
IssueThe `StoxWrappedTokenVault` contract, as a standard ERC4626 implementation, does not include any explicit owner or administrative roles, nor does it have mechanisms for emergency actions such as pausing deposits/withdrawals. While this reduces centralization risk, it also means there is no way to halt operations in case of a critical vulnerability in the underlying asset, a severe market event, or an unforeseen exploit within the vault itself (7.3 Access Control, 7.8 Operations).
FixEvaluate the operational requirements for the vault. If emergency intervention capabilities are desired, consider integrating an `OwnableUpgradeable` or `AccessControlUpgradeable` pattern to allow a trusted entity to pause the contract or perform other critical administrative functions. This would introduce a degree of centralization but enhance the ability to respond to emergencies.
StatusUnresolved
Info

Potential for Sandwich Attacks/Front-running on Deposit/Withdraw

I-01As with many DeFi protocols involving asset exchange or pooling, the standard `deposit` and `withdraw` functions of an ERC4626 vault can be susceptible to sandwich attacks or front-running. An attacker could observe a pending transaction, execute a prior transaction to manipulate the vault's share price (e.g., by making a large deposit/withdrawal), allow the victim's transaction to execute at a disadvantageous rate, and then execute a final transaction to revert the price manipulation and profit from the difference (7.4 Economic).
IssueAs with many DeFi protocols involving asset exchange or pooling, the standard `deposit` and `withdraw` functions of an ERC4626 vault can be susceptible to sandwich attacks or front-running. An attacker could observe a pending transaction, execute a prior transaction to manipulate the vault's share price (e.g., by making a large deposit/withdrawal), allow the victim's transaction to execute at a disadvantageous rate, and then execute a final transaction to revert the price manipulation and profit from the difference (7.4 Economic).
FixWhile this is an inherent market risk rather than a contract bug, users should be aware of this potential. For high-value operations, users could consider using private transaction relays or other MEV-resistant transaction methods to mitigate front-running risks.
StatusUnresolved
Info

Redundant `__ERC20_init` Call with Empty Strings

I-02The `initialize` function calls `__ERC20_init("", "")`. While `ERC4626Upgradeable` itself inherits `ERC20Upgradeable` and correctly overrides `name()` and `symbol()` to derive them from the underlying asset, this explicit `__ERC20_init` call is redundant. It initializes the internal ERC20 state with empty strings, which is then effectively ignored by the overrides. This could be confusing or imply an unused internal ERC20 state (7.2 Code Security).
IssueThe `initialize` function calls `__ERC20_init("", "")`. While `ERC4626Upgradeable` itself inherits `ERC20Upgradeable` and correctly overrides `name()` and `symbol()` to derive them from the underlying asset, this explicit `__ERC20_init` call is redundant. It initializes the internal ERC20 state with empty strings, which is then effectively ignored by the overrides. This could be confusing or imply an unused internal ERC20 state (7.2 Code Security).
FixRemove the `__ERC20_init("", "")` call from the `initialize` function. The `ERC4626Upgradeable`'s own initialization (`__ERC4626_init`) handles the necessary ERC20 aspects, and the `name()` and `symbol()` overrides correctly fetch metadata from the asset.
StatusUnresolved
Info

Misleading `initialize(address asset)` Function

I-03The contract includes a `pure` function `initialize(address asset)` that immediately reverts with `InitializeSignatureFn()`. This function has a similar signature to the actual initializer `initialize(bytes calldata data)`, which could be confusing for users or automated tools inspecting the contract's ABI. While it prevents accidental direct initialization, its presence without a clear purpose beyond reverting adds unnecessary complexity (7.2 Code Security).
IssueThe contract includes a `pure` function `initialize(address asset)` that immediately reverts with `InitializeSignatureFn()`. This function has a similar signature to the actual initializer `initialize(bytes calldata data)`, which could be confusing for users or automated tools inspecting the contract's ABI. While it prevents accidental direct initialization, its presence without a clear purpose beyond reverting adds unnecessary complexity (7.2 Code Security).
FixConsider removing the `initialize(address asset)` function if its sole purpose is to revert. The `_disableInitializers()` in the constructor and the `initializer` modifier on `initialize(bytes calldata data)` are sufficient to prevent improper initialization. If kept, add a clear comment explaining its specific purpose.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract is built upon OpenZeppelin's battle-tested ERC4626Upgradeable standard, providing a robust foundation for a token vault (7.2 Code Security). The custom logic is minimal, primarily handling initialization and name/symbol overrides, which reduces the attack surface. A potential technical risk lies in the choice of underlying asset, as fee-on-transfer or rebase tokens could lead to accounting discrepancies within the ERC4626 framework (7.4 Economic). The contract correctly disables direct initialization of the implementation contract using `_disableInitializers()` (7.7 Upgrades).

GovernanceHigh1/10

The contract does not implement any explicit governance mechanisms (7.5 Governance), operating as a permissionless ERC4626 vault once initialized. Economic risks are primarily associated with the characteristics of the chosen underlying asset, particularly if it's a non-standard ERC-20 token (7.4 Economic). There are no built-in mechanisms for emergency pausing or administrative intervention, which reduces centralization but also limits response capabilities in unforeseen circumstances (7.8 Operations).

UpgradesHigh1/10

The contract is designed for upgradeability using the BeaconProxy pattern, with the implementation contract `StoxWrappedTokenVault` utilizing OpenZeppelin's `Initializable` base (7.7 Upgrades). The constructor correctly calls `_disableInitializers()` to prevent direct initialization of the implementation, a crucial security measure for upgradeable contracts. The `initialize` function uses `bytes calldata data` for flexible initialization, aligning with best practices for proxy deployments.

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

96.3% in top 10
38.8% in wallets57.5% in contracts
Effective Concentration61.8%

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

$32.4K across 5 pairs
AerodromeUSDCanalysed$26.4K81.3%Hydrex CLAMMUSDC$4.8K14.8%Hydrex CLAMMUSDC$1.0K3.1%AerodromeUSDC$2450.8%Uniswap v4ETH$10.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.

Key Addresses

1 addresses
Deployer
0xe2d4…733c

What Raised This Score

9 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 > 50% (96.3% total → 61.8% effective; 38.8% in EOAs, 57.5% in contracts — heavy)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Liquidity < $50k ($32,431 across 5 pairs — thin market)
  • 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
RecallCritical RiskVANRYCritical RiskXMAQUINA (DEUS)Critical RiskTownsCritical RiskICPCritical RiskGAME by Virtuals (GAME)Critical Risk

Would You Like a More Detailed Audit of Wrapped iShares 0-3 Month Treasury Bond ETF ST0x?

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

Get Detailed Audit