Quantum Audit Logo

Is Staked USDe Safe?

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

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

Staked USDe SUSDE
0x9d39…3497
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The StakedUSDeV2 contract implements a staking mechanism with a cooldown period, building upon the StakedUSDe contract which provides ERC4626 vault functionality, reward distribution, and a robust access control system. The contract utilizes OpenZeppelin libraries for security primitives like `ReentrancyGuard` and `AccessControl`. Key findings include the significant power of the `DEFAULT_ADMIN_ROLE`, a dependency on an external `USDeSilo` contract, and minor limitations regarding data types and precision.

1 High1 Medium1 Low2 Informational
Volume 24h
$24.3K
Liquidity
$52.24M
Price
$1.2400
Token Age
1y
Top 10 Holders
77.7%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control by DEFAULT_ADMIN_ROLE

H-01The `DEFAULT_ADMIN_ROLE` in `SingleAdminAccessControl` and `StakedUSDe` possesses extensive control over critical contract parameters and operations. This includes the ability to set `cooldownDuration` (effectively disabling cooldowns), add/remove users from blacklists, rescue arbitrary ERC20 tokens (excluding the asset token), and redistribute locked amounts from full-restricted stakers. While a 2-step transfer mechanism is implemented for the admin role, a compromise of this single role could lead to significant financial loss or protocol manipulation. (7.3 Access Control, 7.8 Operations)
IssueThe `DEFAULT_ADMIN_ROLE` in `SingleAdminAccessControl` and `StakedUSDe` possesses extensive control over critical contract parameters and operations. This includes the ability to set `cooldownDuration` (effectively disabling cooldowns), add/remove users from blacklists, rescue arbitrary ERC20 tokens (excluding the asset token), and redistribute locked amounts from full-restricted stakers. While a 2-step transfer mechanism is implemented for the admin role, a compromise of this single role could lead to significant financial loss or protocol manipulation. (7.3 Access Control, 7.8 Operations)
FixEnsure the `DEFAULT_ADMIN_ROLE` is controlled by a robust multi-signature wallet with a timelock, as indicated by the prefill data. Implement strict operational procedures and multi-party approvals for any sensitive actions taken by this role. Consider further decentralizing control over time if feasible.
StatusUnresolved
Medium

Dependency on USDeSilo Contract Security

M-01The `StakedUSDeV2` contract relies on the `USDeSilo` contract to temporarily hold user funds during the cooldown period. The `USDeSilo` contract is deployed by `StakedUSDeV2`'s constructor, making its address immutable. The security and correctness of `USDeSilo` are paramount, as any vulnerability in `USDeSilo` (e.g., reentrancy, unauthorized withdrawals, or incorrect accounting) could directly impact the safety of funds in `StakedUSDeV2`. The code for `USDeSilo` was not provided for this audit. (7.6 External, 7.1 Architecture)
IssueThe `StakedUSDeV2` contract relies on the `USDeSilo` contract to temporarily hold user funds during the cooldown period. The `USDeSilo` contract is deployed by `StakedUSDeV2`'s constructor, making its address immutable. The security and correctness of `USDeSilo` are paramount, as any vulnerability in `USDeSilo` (e.g., reentrancy, unauthorized withdrawals, or incorrect accounting) could directly impact the safety of funds in `StakedUSDeV2`. The code for `USDeSilo` was not provided for this audit. (7.6 External, 7.1 Architecture)
FixConduct a thorough and independent security audit of the `USDeSilo` contract to ensure it is secure, correctly handles asset transfers, and does not introduce any unexpected behaviors or vulnerabilities. Verify that its withdrawal logic is robust and cannot be exploited.
StatusUnresolved
Low

`UserCooldown` `underlyingAmount` Type Limitation

L-01The `underlyingAmount` in the `UserCooldown` struct is defined as `uint152`. While `uint152` can hold a very large value (~1.6 * 10^45), it is smaller than `uint256`, which is the standard type for ERC20 token balances. If a single user attempts to put an amount of assets into cooldown that exceeds `type(uint152).max`, the explicit cast `uint152(assets)` in `cooldownAssets` or `cooldownShares` would revert. This acts as a safety measure, but it represents a hard limit on the maximum amount a single user can put into cooldown. (7.2 Code Security)
IssueThe `underlyingAmount` in the `UserCooldown` struct is defined as `uint152`. While `uint152` can hold a very large value (~1.6 * 10^45), it is smaller than `uint256`, which is the standard type for ERC20 token balances. If a single user attempts to put an amount of assets into cooldown that exceeds `type(uint152).max`, the explicit cast `uint152(assets)` in `cooldownAssets` or `cooldownShares` would revert. This acts as a safety measure, but it represents a hard limit on the maximum amount a single user can put into cooldown. (7.2 Code Security)
FixDocument this limitation clearly for users and administrators. If there is a theoretical possibility of users needing to cooldown amounts larger than `uint152` can hold, consider using `uint256` for `underlyingAmount` to remove this constraint, acknowledging the slight increase in storage costs.
StatusUnresolved
Info

Precision Loss in Vesting Calculation

I-01The `getUnvestedAmount()` function calculates the currently unvested portion of rewards using integer division: `(deltaT * vestingAmount) / VESTING_PERIOD`. This calculation can suffer from precision loss, especially if `vestingAmount` is small relative to `VESTING_PERIOD`. This might lead to a slight underestimation of the unvested amount over time, potentially leaving a tiny residual amount unvested. (7.4 Economic)
IssueThe `getUnvestedAmount()` function calculates the currently unvested portion of rewards using integer division: `(deltaT * vestingAmount) / VESTING_PERIOD`. This calculation can suffer from precision loss, especially if `vestingAmount` is small relative to `VESTING_PERIOD`. This might lead to a slight underestimation of the unvested amount over time, potentially leaving a tiny residual amount unvested. (7.4 Economic)
FixAcknowledge this inherent characteristic of integer arithmetic. For most practical purposes, the impact is negligible. If higher precision is deemed critical for the vesting mechanism, consider using a fixed-point math library, though this would add complexity and increase gas costs.
StatusUnresolved
Info

Cooldown Bypass via Admin Control

I-02The `DEFAULT_ADMIN_ROLE` has the ability to set `cooldownDuration` to 0 via the `setCooldownDuration` function. When `cooldownDuration` is 0, the `ensureCooldownOff` modifier allows direct `withdraw` and `redeem` calls, effectively bypassing the cooldown mechanism. Additionally, the `unstake` function also allows immediate withdrawal if `cooldownDuration == 0`. This is an intended design choice, granting the admin the ability to disable cooldowns. (7.3 Access Control, 7.4 Economic)
IssueThe `DEFAULT_ADMIN_ROLE` has the ability to set `cooldownDuration` to 0 via the `setCooldownDuration` function. When `cooldownDuration` is 0, the `ensureCooldownOff` modifier allows direct `withdraw` and `redeem` calls, effectively bypassing the cooldown mechanism. Additionally, the `unstake` function also allows immediate withdrawal if `cooldownDuration == 0`. This is an intended design choice, granting the admin the ability to disable cooldowns. (7.3 Access Control, 7.4 Economic)
FixEnsure this functionality is well-understood and clearly documented as a powerful administrative control. Any changes to `cooldownDuration` should follow strict governance procedures and be communicated transparently to users.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture (7.1 Architecture) is well-structured, leveraging inheritance and OpenZeppelin standards. Code security (7.2 Code Security) is enhanced by `ReentrancyGuard` in critical functions and Solidity 0.8.x's default overflow/underflow checks. However, a dependency on the external `USDeSilo` contract introduces an external risk (7.6 External) that requires separate verification. A minor data type limitation for `underlyingAmount` in `UserCooldown` was noted.

GovernanceHigh3/10

The economic model (7.4 Economic) includes a cooldown mechanism for unstaking, a vesting period for rewards, and a blacklisting feature. Access control (7.3 Access Control) is robust, with a multi-role system and a 2-step transfer for the `DEFAULT_ADMIN_ROLE`. However, the `DEFAULT_ADMIN_ROLE` holds significant power, including the ability to disable cooldowns and redistribute locked funds, which is a key governance (7.5 Governance) consideration. Operational security (7.8 Operations) relies heavily on the security of this admin role.

UpgradesMedium5/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no specific upgrade-related risks associated with proxy patterns. Any future changes to the contract logic would require deploying a new contract and migrating user funds, or implementing a separate migration strategy.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

77.7% in top 10
11.1% in wallets66.6% in contracts
Effective Concentration37.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

$75.32M across 25 pairs
Curve stblDOLAanalysed$52.24M69.4%Uniswap v4USDT$12.32M16.4%Uniswap v4USDT$6.79M9.0%Curve stblreUSD$2.31M3.1%Curve stblcrvUSD$758.5K1.0%Curve stblfrxUSD$729.4K1.0%
Show 4 more pairsShow less
Curve stblsUSDS$108.9K0.1%Uniswap v2USDC$52.7K0.1%SupernovaUSDC$7.5K0.0%Uniswap v3USDT$2.0K0.0%

The 15 remaining pairs hold $4.1K between them and are not listed.

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
0x8de5…8fae
Unlocked LP Held By
0x22ca…a490

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 — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (77.7% total → 37.7% effective; 11.1% in EOAs, 66.6% 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 = 69% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 69% 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
Token Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskPrismHigh RiskGULDHigh RiskDeXeHigh RiskTether Gold (XAUT)High Risk

Would You Like a More Detailed Audit of Staked USDe?

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

Get Detailed Audit