Quantum Audit Logo
Launch App

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

Is Staked USDe Safe?

SUSDEEthereum
Not verified This 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 Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades5/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
66.6%Contracts11.1%Wallets22.3%Everyone else
66.6%Contracts11.1%22.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
77.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking66.6%
  • Walletsanonymous holders, free to sell11.1%
  • Everyone elsethe rest of the supply22.3%
Effective concentrationwhat the score reads37.7%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$75.32M across 25 pairs
Show 4 more pairs

The 15 remaining pairs hold $4.1K between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$52.24MShare of depth69.4%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x22ca…a490

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

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control by DEFAULT_ADMIN_ROLE

The 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)H-01

Issue

The 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)

Fix

Ensure 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.

Status

Unresolved

Medium

Dependency on USDeSilo Contract Security

The 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)M-01

Issue

The 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)

Fix

Conduct 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.

Status

Unresolved

Low

UserCooldown underlyingAmount Type Limitation

The 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)L-01

Issue

The 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)

Fix

Document 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.

Status

Unresolved

Info

Precision Loss in Vesting Calculation

The 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)I-01

Issue

The 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)

Fix

Acknowledge 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.

Status

Unresolved

Info

Cooldown Bypass via Admin Control

The 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)I-02

Issue

The 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)

Fix

Ensure 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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.

Governance3/10High risk

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.

Upgrades5/10Medium risk

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.

Final RecommendationWhat to do about this score

It is crucial to ensure that the DEFAULT_ADMIN_ROLE is secured by a robust multi-signature wallet with a timelock, as indicated by the provided deployment information.

A comprehensive audit of the USDeSilo contract is highly recommended to ensure the security of funds held during the cooldown period. Additionally, clear documentation of administrative capabilities and operational procedures will enhance the overall security posture of the protocol.

Contract & Record

1 audit on record
TypeStaking, Token
NetworkEthereum
Token age1y
Contract0x9d39…3497
Deployer0x8de5…8fae
Badge for your website
Staked USDe security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202659Medium
  2. Aug 11, 202658Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
Token Prometeus NetworkPROM · Ethereum59MediumFake World AssetsFWA · Ethereum59MediumPrismEthereum59MediumGULDEthereum59MediumDeXeEthereum60MediumTether GoldXAUT · Ethereum58Medium

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 Is this your token? Publish your own audit on this page