defirisk.co
rubric v1.7.0

StakeWise v3

Over-collateralised liquid staking protocol on Ethereum and Gnosis Chain; osETH minted against permissionless Vaults; SWISE governance token.

Sector lst
TVL $794.9M
Reviewed May 16, 2026
Factors 184
Categories 13
Risk score 29.1
DeploymentsEthereum · $793.6M
01

Risk profile at a glance

1 red · 3 yellow · 8 green
02

Categories & evidence

184 factors · 13 categories
Code & audits Green 16 25 of 25
RD-F-009 red Formal verification coverage No formal verification found — no Certora, Halmos, Kani, or equivalent tooling directories exist in the v3-core repository. The repo contains only a slither.config.json for static analysis. Per U8 rule: LST at ~$795M TVL with zero formal verification scores red even with 5+ traditional audits (Rocket Pool precedent). Profile §8 explicitly flagged this gap for code-security-analyst. RD-F-183 red Bug bounty scope gap on highest-TVL contracts Critical scope gap confirmed. The Immunefi bug bounty program at immunefi.com/bug-bounty/stakewise/scope/ lists exactly 12 in-scope contracts — all are StakeWise v2 contracts (Pool, PoolEscrow, PoolValidators, StakedEthToken, RewardEthToken, StakeWiseToken, Oracles, VestingEscrow, VestingEscrowFactory, MerkleDistributor, Roles, Proxy Admin). The v3 contracts bearing ~$795M TVL — VaultsRegistry (0x3a0008...), OsToken/osETH (0xf1C9...), Keeper (0x6B5815...), OsTokenVaultController (0x2A261...), all EthVault instances, all factory contracts — are not listed in scope. The program was created May 2022 (before v3 launched October 2023) and scope was not updated. The $200K maximum payout exists but no whitehath has economic incentive to disclose v3 vulnerabilities. RD-F-001 yellow Audit scope mismatch Statemind audit signed off 2026-04-20. Post-audit 'Audit fixes' commit v5.0.0c (SHA 49fa993) was merged April 21, 2026, and v5.0.0 final (SHA 31b2da5) was released April 29, 2026 — both after audit sign-off. The currently deployed v5.0.0 therefore includes code not covered by the most recent audit. However, the PR is labeled 'Audit fixes' (addressing findings rather than introducing new scope) and 8 overlapping prior engagements provide background coverage. Bytecode-to-commit-SHA diff not programmatically verified. RD-F-003 yellow Resolved-without-proof findings Audit PDFs are binary-inaccessible via WebFetch; individual finding resolution cannot be verified. The v5.0.0c release message 'Audit fixes' (PR #134) indicates Statemind findings were addressed in a discrete commit, providing partial on-chain-linkable evidence. Cannot confirm 0 unverifiable resolutions without PDF access. RD-F-007 yellow Bug bounty presence & max payout Active Immunefi program with $200K maximum payout for critical smart-contract bugs. Program active since May 2022, last updated March 10 2026. Payout threshold meets yellow (≥$50K). However, scope covers only v2 contracts (see F183) — the v3 contracts holding ~$795M TVL are absent from scope, which limits the effective whitehath incentive for the highest-TVL surface. Scored yellow for payout adequacy despite scope gap (F183 captures the scope gap separately). RD-F-022 yellow Public initialize() without initializer modifier VaultsRegistry (0x3a0008...) and Keeper (0x6B5815...) expose initialize(address _owner) functions. Etherscan source confirms these use a custom _initialized boolean flag (reverts with Errors.AccessDenied() on second call) rather than OZ's initializer modifier. These are direct non-upgradeable implementations (not proxy targets), so the one-tx proxy-takeover vector does not directly apply — they cannot be re-initialized through a proxy. EthVault and EthPrivVault proxy implementations correctly use _disableInitializers() in constructors and reinitializer(_version). The non-standard custom guard pattern reduces auditability and tool-detectability (Slither would flag this as missing-initializer-modifier) but contracts are currently initialized and not exploitable in the deployed state. RD-F-024 yellow Code complexity vs audit coverage 31 deployed mainnet contracts with 3+ active audit engagements from Sep 2024 to Apr 2026 covering the latest v5.x versions. ABDK PDF is 6.7MB indicating substantial scope. Exact LOC and audit-day count unavailable (binary PDFs). The rapid release cadence (v3.0.0 Dec 2024, v4.0.0 Sep 2025, v5.0.0 Apr 2026) introduces fresh attack surface faster than a typical protocol. Yellow applied conservatively — coverage appears adequate given the cadence, but LOC-per-audit-day ratio cannot be confirmed. RD-F-010 gray Static-analyzer high-severity count Slither is integrated in CI (slither.config.json confirmed at repo root, configured to output only high-severity findings). No published Slither high-severity finding count for the current deployed version is accessible. Running Slither locally is outside this assessment's tooling scope. Cannot independently triage findings. RD-F-018 gray Signed/unsigned arithmetic confusion Signed/unsigned arithmetic confusion requires Slither/Manticore run on verified source. Cannot run tools locally. No published finding across 8 audits, but absence of published finding from binary-inaccessible PDFs is incomplete evidence.
RD-F-002 green Audit recency Most recent audit is Statemind, signed off 2026-04-20 — 26 days before assessment date 2026-05-16. Well within the 365-day green threshold.
RD-F-004 green Audit count Five distinct audit firms: Halborn (2 engagements), Sigma Prime (3 engagements), Consensys Diligence (1 engagement), ABDK (1 engagement), Statemind (1 engagement). Hats Finance competition (2023-08 to 2023-09) adds crowd-sourced coverage. Total engagements = 8 plus competition. Well above the green threshold of ≥2 distinct firms.
RD-F-005 green Audit firm tier Sigma Prime (Tier-1) conducted 3 engagements (Aug 2023, Jun 2024, Sep 2024). Consensys Diligence (Tier-1) conducted 1 engagement (Mar 2024). Both are Tier-1 firms per the curator registry. At least one Tier-1 firm has reviewed the deployed code.
RD-F-006 green Audit-to-deploy gap Statemind audit signed off 2026-04-20; v5.0.0 deployed 2026-04-29 — 9 days gap. Well within 60-day green threshold. Prior Sigma Prime Sep 2024 and ABDK Sep 2025 engagements also show short deploy gaps consistent with continuous audit cadence.
RD-F-008 green Ignored bounty disclosure No prior post-mortem documents an ignored disclosure. The 2025-11-03 Balancer exploit was a Balancer v2 vulnerability, not a StakeWise smart-contract exploit. No StakeWise-specific rekt entry in hacksdatabase. No evidence of a whitehath disclosure that was ignored before any exploit.
RD-F-011 green SELFDESTRUCT reachable from non-admin path No SELFDESTRUCT finding reported across 8 audit engagements. Protocol uses UUPS proxies (EthVault family) and Ownable2Step for non-proxy contracts; SELFDESTRUCT is not part of the vault or token architecture. Cannot run Slither locally; based on published audit history.
RD-F-012 green delegatecall with user-controlled target No user-controlled delegatecall finding reported across 8 audit engagements. UUPS proxy upgrade target is admin-controlled via Ownable. Cannot run Slither locally.
RD-F-013 green Arbitrary call with user-controlled target No arbitrary call with user-controlled target finding reported across 8 audit engagements. Cannot run Slither locally.
RD-F-014 green Reentrancy guard on external-calling functions No reentrancy finding reported in any published audit summary. Tier-1 firms (Sigma Prime x3, Consensys Diligence) specifically reviewed vault entry/exit functions. Cannot run Slither locally; based on published audit coverage.
RD-F-015 green ERC-777/1155/721 hook without reentrancy guard OsToken is ERC-20 + ERC-2612 (no ERC-777 callback). OsTokenFlashLoans uses flash-loan standard callbacks, not ERC-777 tokensReceived. No ERC-777/1155/721 integration without guard reported across audits.
RD-F-016 green Divide-before-multiply pattern No divide-before-multiply finding reported across 8 audits. ABDK (specialising in mathematical/economic review, Sep 2025) specifically targeted arithmetic precision. Cannot run Slither locally.
RD-F-017 green Mixed-decimals math without explicit scaling StakeWise osETH/ETH relationship is within the same ETH-denominated ecosystem. ABDK mathematical review (Sep 2025) specifically covers decimal-scaling and economic arithmetic. No mixed-decimals finding reported.
RD-F-019 green ecrecover zero-address return unchecked Keeper contract uses EIP-712 and OZ ECDSA for oracle signature verification. Standard OZ ECDSA `recover()` includes zero-address check. Etherscan confirms `eip712Domain()` function in Keeper read interface. No ecrecover-unchecked finding in any audit.
RD-F-020 green EIP-712 domain separator missing chainId Keeper implements EIP712 with standard OZ EIP712 base contract (confirmed `eip712Domain()` function). Standard OZ EIP712 includes chainId in the domain separator. No chainId-missing finding reported.
RD-F-021 green UUPS _authorizeUpgrade correctly permissioned EthVault uses UUPS with `_disableInitializers()` in the constructor and `reinitializer(_version)` on initialize(). The `_authorizeUpgrade` function is gated by vault ownership. Consensys Diligence specifically reviewed vault upgrade mechanics. No improperly permissioned _authorizeUpgrade finding reported.
RD-F-023 green Constructor calls _disableInitializers() EthVault (TVL-bearing UUPS proxy implementation) correctly calls _disableInitializers() in its constructor. EthPrivVault confirmed same pattern. VaultsRegistry and Keeper are not proxy implementations — _disableInitializers() is not required for direct non-upgradeable contracts. The OZ pattern is correctly applied where it matters (vault implementations).
Governance & admin Red 54 24 of 24
RD-F-032 red Timelock duration on upgrades No timelock. governance.timelock_address confirmed null in pipeline data cache. No TimelockController between Snapshot vote passage and Safe execution. The 4-of-7 Safe is the only execution gate; wall-clock latency depends on signer availability only, not a protocol-enforced delay. All upgrade/admin actions can execute immediately upon Safe co-signing. RD-F-033 red Timelock on sensitive actions Zero sensitive actions timelocked. Mint authority (via setController), pause/upgrade (via Safe owner role on Ownable2Step contracts), oracle config (Keeper addOracles/removeOracles), rescue equivalent (emergency controller grant) — all route through 4-of-7 Safe with no timelock. Demonstrated by Nov 2025 Balancer recovery where emergency controller was granted and exercised in a single block sequence. RD-F-034 red Guardian/pause-keeper distinct from upgrader No separate guardian/pauser role distinct from the upgrader. The DAO Treasury Safe is simultaneously the upgrader, the emergency responder (Nov 2025), and holds the SafeSnap veto capability. The SafeSnap veto (documented: DAO can reject malicious proposals) is held by the same Safe that executes them — no independence between cancel role and execute role. RD-F-035 red Role separation: upgrade ≠ fee ≠ oracle All three roles (upgrade/admin, fee/collateral parameters via OsTokenConfig, oracle config via Keeper addOracles/removeOracles) route through the single DAO Treasury Safe 0x144a98cb1CdBb23610501fE6108858D9B7D24934. No distinct addresses for upgrade vs. fee vs. oracle roles. RD-F-036 red Flash-loanable voting weight [★ CRITICAL] Snapshot space stakewise.eth uses erc20-balance-of strategy on SWISE token (0x48c3399719b582dd63eb5aadf12a40b4c3f52fa2) — a standard transferable ERC-20 with no lock or checkpoint mechanism. Voting power = raw token balance at snapshot block. Quorum has been formally removed (governance process post: quorum removed until more SWISE circulates). An entity controlling sufficient SWISE at the snapshot block can dominate a vote. SafeSnap veto by the 4-of-7 Safe partially mitigates but does not eliminate the risk (the Safe could be the attacker or fail to act). No on-chain flash-loan prevention exists. RD-F-037 red Quorum achievable via single-entity flash loan No quorum exists (formally removed per governance process). Relative majority required. Any entity achieving a plurality of participating voter weight can pass proposals. Combined with erc20-balance-of strategy (no lock), the quorum floor is effectively zero — a flash-loan-funded voter only needs to outvote existing participation. RD-F-038 red Proposal execution delay < 24h No mandatory execution delay between Snapshot vote closing and Safe execution. SafeSnap encodes passed proposal transactions directly to Safe queue; co-signing can occur in minutes of vote closure. timelock_delay_seconds confirmed null in data cache. No delay module is documented in the SafeSnap configuration. RD-F-042 red Admin has mint() with unlimited max [★ CRITICAL] OsToken.sol mint(address account, uint256 value) is callable by authorized controllers. No supply cap exists. DAO Treasury Safe (4-of-7) owns OsToken and can call setController() to authorize any address (including itself) to mint unlimited osETH immediately, with no timelock. This power was exercised in November 2025 (Balancer exploit recovery: burned hacker osETH, minted identical amount to DAO wallet). Emergency controller functionality has NOT been formally removed on-chain as of 2026-05-16 — no confirmed SWIP executing revocation found. RD-F-025 yellow Admin key custody type Admin/owner of all core contracts is the DAO Treasury Safe 0x144a98cb1CdBb23610501fE6108858D9B7D24934 (Gnosis Safe Mastercopy 1.1.1, 4-of-7 threshold). Classification: multisig without timelock. VaultsRegistry (Ownable2Step), OsToken (Ownable2Step), Keeper (Ownable2Step), OsTokenVaultController all owned by this Safe. Yellow because no timelock layer sits above the multisig. RD-F-026 yellow Upgrade multisig signer configuration (M/N) 4-of-7 multisig. Threshold=4, owner_count=7. Seven owner addresses enumerated in cache and profile. Same 7 owners on Gnosis Chain Safe (0x8737f638E9af54e89ed9E1234dbC68B115CD169e, also 4-of-7). Yellow: threshold is at lower edge of peer norm for $795M TVL LST; signer identities not fully publicly verified (only tsudmi.eth confirmed). RD-F-028 yellow Low-threshold multisig vs TVL 4-of-7 Safe at $795M TVL. Peer LST norm (Lido Emergency multisig 5-of-9; Rocket Pool oDAO similar) indicates 4-of-7 is at the lower edge of acceptability — not critically low but below ideal for the TVL tier. No timelock above the Safe. Signer identities: only 0x61B01a33... maps to tsudmi.eth; six other signers unidentified. Effective security depends on signer independence which is unverifiable from public data. RD-F-040 yellow Emergency-veto multisig present Partial veto mechanism: SafeSnap allows the 4-of-7 DAO Safe to reject/cancel a SafeSnap-queued transaction before execution if a malicious contract is flagged (documented in governance process and profile §6). However, this veto is held by the same Safe that executes proposals — not a separate independent guardian. Cancel role and execute role share the same 4-of-7 set. RD-F-041 yellow Rescue/emergencyWithdraw without timelock No dedicated rescue()/emergencyWithdraw() function in OsToken.sol or VaultsRegistry. However, the setController() function on OsToken (owner-only, no timelock) enables equivalent capability: the 4-of-7 Safe can grant itself temporary mint/burn controller authority in one transaction, demonstrated in the Nov 2025 Balancer recovery where osETH was burned from the hacker's wallet and minted to the DAO. Gated by 4-of-7 multisig but no timelock. Yellow (multisig-gated, no dedicated rescue function, but equivalent power exists). RD-F-029 gray Multisig signers co-hosted Cannot assess: signer identity insufficient to determine ASN/infrastructure distribution. Six of seven signer addresses are not publicly identified. No OSINT or Chainalysis cluster data available within budget. RD-F-030 gray Hot-wallet signer flag Cannot assess: hot-wallet signing pattern analysis requires extended on-chain tx-behavior study per signer address. Not feasible within assessment budget. RD-F-044 gray Admin wallet interacts with flagged addresses Cannot assess within budget. Requires Chainalysis/TRM cluster analysis on 7 Safe signer addresses and the DAO Safe itself. No CTI feed configured in data cache. RD-F-045 gray Constructor args match governance proposal Cannot assess for historical deploys without retrieving each governance proposal calldata against each constructor invocation — beyond budget scope. RD-F-047 gray Governance token concentration (Gini) Gini coefficient not computed. SWISE is a standard ERC-20 (0x48c3399719b582dd63eb5aadf12a40b4c3f52fa2). Holder distribution requires subgraph query or Etherscan holders-list scrape. Not performed within budget. RD-F-167 n/a Deprecated contract paused but pause reversible by live admin Not applicable. StakeWise v3 is an original-architecture full rewrite of v1/v2 with no shared admin roles across deprecated surfaces. Legacy v1/v2 contracts (sETH2, rETH2, LegacyPoolEscrow) are historical migration artifacts — not governed by current DAO admin in a way that creates ongoing reversible-pause exposure over a deprecated surface.
RD-F-027 green Single admin EOA No EOA holds protocol admin. All core contract ownership routes to the 4-of-7 Gnosis Safe 0x144a98cb1CdBb23610501fE6108858D9B7D24934. VaultsRegistry owner = Safe (Ownable2Step); OsToken owner = Safe (Ownable2Step); Keeper owner = Safe. Deployer EOA 0x229f53ef905545aa53a721d82dbfe4ced7aff65d is NOT the current admin.
RD-F-031 green Signer rotation recency No signer rotation events identified. The Safe was configured at v3 launch (~October 2023) with the same 7-address owner set in place as of assessment date. Etherscan Safe history shows 88 transactions including the November 2025 Balancer recovery — no AddedOwner/RemovedOwner/ChangedThreshold events found. No DPRK-precursor threshold-reduction pattern.
RD-F-039 green delegatecall/call in proposal execution without allowlist No on-chain Governor contract (governor_address null in cache). Governance execution = Snapshot off-chain vote then 4-of-7 Safe manual co-signing then Safe execTransaction. Each Safe transaction requires explicit construction and co-signing by 4 of 7 signers. No automated executor contract accepting proposal-supplied arbitrary targets. delegatecall/call with user-supplied targets is not present in the execution path.
RD-F-043 green Admin = deployer EOA after 7 days Deployer EOA 0x229f53ef905545aa53a721d82dbfe4ced7aff65d is NOT the current admin of any core contract. All ownership transferred to DAO Treasury Safe at or before v3 launch (VaultsRegistry deployed October 2023, OsToken owned by Safe at deploy). Well beyond 7-day threshold.
RD-F-046 green Contract unverified on Etherscan/Sourcify All core contracts verified on Etherscan. Multiple audit firms (Halborn, Sigma Prime, Consensys Diligence, ABDK, Statemind) required verified source access. Profile §3 lists all addresses with Etherscan-verified source tabs. OsToken, VaultsRegistry, Keeper, VaultFactory all verified.
Oracle & external dependencies Yellow 42 17 of 17
RD-F-051 red Fallback behavior on oracle failure No fallback behavior on oracle failure. KeeperRewards.sol _verifySignatures() reverts if fewer than rewardsMinOracles (6 of 11 per docs) submit valid signatures. KeeperOracles.sol analysis confirms: no secondary oracle path, no last-known-price fallback, no degraded-mode pause. If oracle quorum is not met, updateRewards() call fails; vault state (avgRewardPerSecond) stalls at last valid update. Exit processing (validator approvals) also stalls — requires 8-of-11 signatures. No circuit-breaker pause or graceful degradation is implemented in KeeperRewards or KeeperOracles. StakeWise docs confirm: 'no manual actions involved' (oracles are automated) but provide no fallback description. RD-F-057 red Circuit breaker on price deviation No price-deviation circuit breaker detected in the oracle path. OsTokenVaultController does not implement a check that halts or reverts if avgRewardPerSecond deviates beyond a threshold from a reference. PriceFeed passes getRate() output directly with no deviation guard. KeeperRewards enforces a `_maxAvgRewardPerSecond` cap (one-sided upper bound on reward rate submitted by oracles, not a bidirectional price-deviation circuit breaker). If the oracle network submits an anomalously low reward rate (e.g., due to a compromised operator), there is no downside circuit breaker to trigger a pause. RD-F-059 red Oracle staleness check present No consumer-side staleness check detected. The PriceFeed adapter wraps getRate() with no `updatedAt` timestamp comparison or maximum-age rejection. OsTokenVaultController does not expose a `lastUpdated` timestamp that the PriceFeed checks. The Keeper enforces a minimum-cadence floor (`rewardsDelay = 43200s`) between updates but there is no maximum-age ceiling that causes the system to reject or flag a stale rate. If the oracle network becomes unresponsive for >12h, PriceFeed continues to return the last-known rate without any staleness signal to downstream consumers (Aave CAPO adapter may implement its own check, but that is external to StakeWise). RD-F-049 yellow Oracle role per asset For osETH/ETH: Primary oracle = Keeper network feeding avgRewardPerSecond to OsTokenVaultController; role = sole price/rate setter for osETH exchange rate. PriceFeed wraps getRate() as Chainlink-compatible latestAnswer() for Aave CAPO. No secondary oracle or fallback within the StakeWise core path. RedStone feed (DEX-aggregate) is used by external integrators only. The absence of a documented secondary/fallback role for any asset in the core path scores yellow. RD-F-050 yellow Dependency graph (protocols depended upon) StakeWise v3 depends on: (1) Ethereum Beacon Chain — required for validator reward computation by oracle operators; (2) Keeper oracle network (11 operators, 6-of-11 quorum) — required for reward/rate updates; (3) OsTokenVaultController — required for rate computation and PriceFeed output; (4) Aave v3 (indirect, via osETH collateral use by holders — not a direct protocol contract call). All dependencies are single-path with no documented redundancy at the protocol-contract level. Scored yellow: major dependencies covered but no primary-dep redundancy. RD-F-052 yellow Breakage analysis per dependency Breakage analysis: (1) Keeper quorum failure — reward accrual stalls; vault state freezes; exit processing stalls; no fund loss short-term but yield degradation and potential osETH depeg over extended period; severity HIGH operational impact, LOW direct-loss. (2) OsTokenVaultController unresponsive/stale — PriceFeed returns stale rate; Aave CAPO may freeze or use stale collateral price for osETH. (3) Beacon chain disruption — same as keeper quorum failure. (4) Gnosis Keeper failure — affects only ~$1.3M (0.17% TVS). Analysis is partial — mitigations for major deps are not documented by protocol; scored yellow for partial coverage of major deps. RD-F-062 yellow External keeper/relayer not redundant The Keeper oracle network (11 operators) provides meaningful redundancy for the keeper/relayer function: any 5 nodes can be simultaneously offline without halting reward updates (6-of-11 quorum). Operators are independent entities (P2P, Gnosis, DSRV, Chorus One, Bitfly, Finoa, Telekom, Gateway.fm, Stake.Fish, Senseinode + StakeWise Labs per docs). However, no automated fallback exists if quorum fails; the entire reward-update and exit-processing mechanism halts without degraded-mode operation. Scored yellow: meaningful redundancy via multi-node design, but single-mechanism dependency with no failover if quorum not reached. RD-F-180 yellow Immutable oracle address [★ CRITICAL-CANDIDATE per T-12 PD-017] Yellow. The Keeper oracle operator set is NOT EVM-immutable: addOracle(address) and removeOracle(address) are onlyOwner functions (Keeper owner = DAO Treasury Safe 0x144a98, 4-of-7). rewardsMinOracles and validatorsMinOracles are mutable via onlyOwner setters. Oracle set can be replaced by 4-of-7 Safe signing immediately (no Snapshot vote required, no timelock). Separately, PriceFeed 0x8023518b constructor-embeds OsTokenVaultController address with no admin setter — this sub-dependency IS effectively immutable within the PriceFeed contract (no setOsTokenVaultController function). OsTokenVaultController itself is Ownable2Step and has admin paths. Scored yellow (not red): (1) Keeper oracle set IS replaceable by DAO Safe; (2) 11-node, 6-of-11 consensus reduces per-node criticality; (3) PriceFeed immutability is mitigated because OsTokenVaultController has its own admin path and a new PriceFeed could be deployed. FLAG: PD-017 CRITICAL-CANDIDATE — orch RD-F-054 n/a TWAP window duration StakeWise v3 does not use DEX TWAP oracles in any core price path. The Keeper reward-update cadence (rewardsDelay = 43200s / 12h) is an oracle-update-frequency control, not a DEX TWAP window. OsTokenVaultController computes the rate from beacon-chain-state accumulator, not DEX pools. Factor applies only to protocols using DEX TWAP for asset pricing. RD-F-055 n/a Oracle pool depth (USD) No DEX pool feeds any StakeWise core oracle. The primary osETH/ETH rate is beacon-chain-state derived; pool depth is irrelevant to its manipulation resistance. Factor applies only to protocols using DEX-based oracles where pool depth determines manipulation cost. RD-F-056 n/a Single-pool oracle (no medianization) No DEX pool in the core oracle path. The Keeper network uses 11 independent oracle operators with 6-of-11 consensus — this is operator-level medianization over signed submissions, not DEX-venue medianization. Factor definition targets single-pool DEX oracle reads without medianization across venues, which does not apply here. RD-F-058 gray Max-deviation threshold (bps) Partial data: KeeperRewards enforces _maxAvgRewardPerSecond (upper bound, ~6.34B per Etherscan constructor description) preventing extreme upward reward-rate values. This is a one-sided cap, not a bidirectional bps-threshold circuit breaker. No circuit breaker in the traditional deviation-from-reference sense is configured (per F057 finding). Cannot confirm the exact bps equivalent of _maxAvgRewardPerSecond without direct RPC call; data insufficient for a green/yellow/red grade on this factor. RD-F-060 n/a Chainlink aggregator min/max bound misconfig StakeWise does not consume any Chainlink aggregator feeds in its core oracle path. The PriceFeed contract mimics the Chainlink AggregatorV3Interface but IS the adapter, not a Chainlink consumer. Chainlink's ETH/USD feed is consumed only by Aave's external CAPO adapter (outside StakeWise's contracts). Factor applies to protocols that consume Chainlink feeds where minAnswer/maxAnswer misconfiguration is possible. RD-F-181 n/a Permissionless-pool lending oracle StakeWise v3 is an LST protocol, not a lending protocol. It does not accept spot prices from permissionlessly-created DEX pools as collateral oracle inputs. The internal osETH/ETH rate is beacon-chain-state derived (OsTokenVaultController accumulator). This factor targets lending protocols that accept arbitrary DEX pool oracle sources as collateral pricing — inapplicable to this protocol type.
RD-F-048 green Oracle providers used StakeWise v3 uses a custom permissioned Keeper oracle network (11 operators, contract 0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5) for all reward/state updates. OsTokenVaultController provides an internal beacon-chain accumulator (`avgRewardPerSecond`). PriceFeed adapter at 0x8023518b wraps this in a Chainlink-compatible interface for downstream protocols (Aave CAPO). RedStone aggregates DEX prices for third-party integrators only — StakeWise core contracts do not consume any external DEX-based price feed. Oracle provider map: (1) Keeper network — primary for reward updates; (2) OsTokenVaultController — internal rate accumulator; (3) PriceFeed — Chainlink-compatible wrapper for downstream.
RD-F-053 green Oracle source = spot DEX pool (no TWAP) [★ CRITICAL] Green. osETH's internal exchange rate is computed by OsTokenVaultController via beacon-chain-state-based accumulator (avgRewardPerSecond × elapsed time), not from any DEX spot price. PriceFeed 0x8023518b calls getRate() on OsTokenVaultController — confirmed no slot0(), getReserves(), or DEX TWAP call in the source. Aave's CAPO adapter prices osETH via this internal rate: search evidence confirms 'value of osETH on Aave is linked to the price of ETH, not the value of osETH on DEXs.' RedStone's DEX-aggregate feed (Balancer osETH-WETH, Uniswap v3 osETH-USDC, Curve osETH-rETH) is consumed only by external third-party protocols (Gravita, Morpho Blue, Enzyme) — StakeWise core contracts do not read this feed. No spot DEX oracle dependency in any core path.
RD-F-061 green LP token balanceOf used for pricing No LP token `balanceOf` call detected in any oracle/pricing path. OsTokenVaultController computes osETH/ETH rate using an internal totalAssets/totalShares accumulator with staking rewards (avgRewardPerSecond × time), which is not manipulable by direct LP token transfers or donations. PriceFeed reads this internal rate only.
Economic risk Yellow 27 13 of 13
RD-F-063 yellow TVL (current + 30d trend) TVL $794.9M as of 2026-05-16. 30-day change -17.89% driven by ETH price correction from $977M peak on 2026-05-04, not protocol-specific outflow. 90-day CoV 0.0696 (stable). TVL well above $100M green threshold, but >20% 30d decline triggers yellow. RD-F-065 yellow Liquidity depth per major asset osETH/ETH liquidity distributed across Curve, Balancer, and Uniswap V3. LlamaRisk collateral assessment (2024) measured osETH daily volatility at 3.42% vs ETH 3.37%, indicating adequate depth for normal conditions. Balancer pool (primary venue pre-November 2025) was disrupted by Balancer exploit; liquidity since reconstructed. 2%-slippage depth in USD not retrieved from live DEX subgraph — specific depth unknown, yielding yellow rather than green due to uncertainty and historical Balancer disruption. RD-F-070 yellow Empty cToken-style market (zero supply/borrow) [STAR CRITICAL — assessed as yellow] StakeWise v3 Vaults are NOT Compound V2 lending forks. The classic empty-cToken-market pattern does not apply directly. However, the structurally analogous share-inflation risk applies to the vault-share model. VaultState.sol source confirms: convertToShares() returns 1:1 when totalShares_==0, no MINIMUM_SHARES constant, no virtual-share offset, no explicit seed-deposit requirement. VaultEnterExit.sol shows no dead-shares mechanism. VaultOsToken.sol shows no first-depositor guard. Risk is materially bounded by: (1) osETH minting at 90% LTV — an attacker manipulating empty-vault share price would also need to corrupt the osETH mint path against over-collateralised backing; (2) permissionless vaults start empty with zero depositors, limiting blast radius; (3) six independent audit engagements (Halborn x2, Sigma Prime x3, Consensys Diligence, Hats Finance, ABDK, Statemind through 2026-04-20) reviewed vault architecture without flagging a share-inflatio RD-F-075 yellow First-depositor / share-inflation guard VaultState.sol source confirms no MINIMUM_SHARES constant, no seed deposit on vault deploy, no virtual-share offset. The zero-state (totalShares_==0) case in convertToShares returns assets directly (1:1) — standard unguarded share vault behavior. VaultEnterExit.sol _deposit lacks seed deposit mechanism. VaultOsToken.sol does not add a first-depositor guard. However: (1) 6 independent audit engagements reviewed vault architecture (including Sigma Prime x3, Consensys Diligence, ABDK, Statemind 2026-04-20) without flagging share-inflation as a critical finding; (2) osETH over-collateralisation (90% LTV) provides structural indirect protection against system-level share-inflation attack. Scored yellow: absence of explicit on-chain guard is confirmed, but audit coverage and structural mitigation prevent red. RD-F-064 gray TVL concentration (top-10 wallet share) Top-10 depositor concentration cannot be computed from available data. StakeWise v3 uses permissionless per-vault ERC-20 share tokens across dozens of independent vaults; cross-vault TVL aggregation by depositor address requires a subgraph query not available within this assessment budget. RD-F-066 n/a Utilization rate (lending protocols) Utilization rate is a lending-protocol metric (borrowed/supplied ratio). StakeWise v3 is an LST protocol with no lending markets. DefiLlama cache confirms borrow.present=false, total_borrowed_usd=null. Not applicable per PD-024. RD-F-067 n/a Historical bad-debt events Bad-debt events are a lending-protocol concept where undercollateralized borrower positions are socialized. StakeWise v3 has no borrow-side; validator slashing is absorbed by per-vault over-collateralisation buffer, a structurally different mechanism. Not applicable per PD-024. RD-F-068 n/a Collateralization under stress Lending-collateral stress test (top-3 collateral drops 50%, collateral ratio below 110%) does not map to an LST protocol. StakeWise v3 holds staked ETH as collateral against osETH issuance — the collateral IS the staked ETH, not a multi-asset mix. Not applicable per PD-024. RD-F-071 n/a Seed-deposit requirement for new market listing Seed-deposit requirement for new market listing is a Compound V2 lending-market pattern. StakeWise v3 has permissionless vault creation via VaultsRegistry factories — vaults are staking vaults, not lending markets. No market-listing seed-deposit concept exists. Not applicable per PD-024. RD-F-072 n/a Market-listing governance threshold Market-listing governance threshold is a Compound V2 / Aave-family concept. StakeWise v3 uses permissionless vault creation — anyone can deploy a vault via the VaultFactory without governance approval. No market-listing governance threshold concept maps to this architecture. Not applicable per PD-024. RD-F-073 n/a Oracle-manipulation-proof borrow cap Oracle-manipulation-proof borrow cap applies to protocols that use DEX-TWAP oracles to price collateral for borrowing. StakeWise v3 does not have borrow caps in the lending sense. The osETH/ETH price is determined by the Keeper oracle network (not a DEX TWAP), and there is no borrow-side. Not applicable per PD-024. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) ERC-4626 virtual-share offset factor applies to formal ERC-4626 vault implementations. StakeWise v3 Vaults do not formally inherit from ERC-4626 (VaultState.sol does not import ERC-4626; VaultEnterExit.sol implements core functions without the OZ ERC-4626 base). The applicable first-depositor guard check is covered under F075. Not applicable as this factor is specifically scoped to ERC-4626 compliant vaults.
RD-F-069 green Algorithmic / under-collateralized stablecoin osETH is not a stablecoin. It is an over-collateralised liquid staking token: users stake >1 ETH to mint 1 osETH (90% LTV = 111% collateralisation). Not algorithmic, not fiat-backed, not partially collateralised — fully backed by staked ETH with surplus buffer. LiqThresholdPercent=92% ensures osETH never exceeds the underlying ETH value before liquidation. LlamaRisk (2024): osETH volatility 3.42% vs ETH 3.37%.
Operational history Green 11 15 of 15
RD-F-089 red Insurance coverage active No active third-party insurance coverage for StakeWise v3 / osETH as of 2026-05-16. The Nexus Mutual slashing-cover purchase (July 2022) was a 3-month trial for v2, expired October 2022 — not applicable to v3. StakeWise docs page for osETH confirms no insurance provider mentioned. No Sherlock, Unslashed, or Nexus Mutual v3 coverage found via search. The overcollateralization mechanism (>1 ETH per osETH minted) is protocol mechanics — not external insurance. At $795M TVL with zero third-party insurance, this is a structural red. Per briefing: near-default red for large LSTs — verified and confirmed. RD-F-081 yellow Post-exploit response score No StakeWise smart-contract exploit to score against the primary F081 definition. Scored against the 2025-11-03 Balancer-adjacent incident as the only observable response event. Response quality: (a) DAO multisig mobilized within ~30 minutes; (b) on-chain burn/mint recovery executed; (c) public communications within hours; (d) governance proposal to remove emergency powers submitted. Recovery was 73.5% (~$19M of ~$26M). Yellow rather than green because ~26.5% (~$7M) was unrecovered (attacker swapped to ETH before DAO acted), and the promised full StakeWise post-mortem was not confirmed published as of assessment date. The response demonstrated strong operational capability and transparency. RD-F-082 gray Post-mortem published within 30 days No StakeWise smart-contract exploit occurred that would require a StakeWise-authored post-mortem per the F082 definition. The Balancer-adjacent incident (2025-11-03) was a Balancer v2 vulnerability; Balancer published its own post-mortem. StakeWise announced a full post-mortem was forthcoming but a published StakeWise-authored post-mortem was not confirmed as of assessment date. F082 strictly measures the protocol's post-mortem on its own incident; that trigger does not apply here. RD-F-083 gray Auditor re-engaged after last exploit No StakeWise smart-contract exploit occurred. F083 measures whether a reputable auditor performed re-audit after the protocol's own exploit. No such trigger exists. Ongoing audit cadence (Statemind April 2026, ABDK September 2025) reflects routine security maturity, not post-exploit re-engagement. RD-F-087 n/a Pause > 7 consecutive days No pause events detected for StakeWise v3 core contracts in trailing 12 months. No period of consecutive pause > 7 days. Score: green. [orchestrator §14.3 honest downgrade: only curator_note (data-cache/hacksdatabase absence) available for pause-duration; no primary source -> not_assessed.]
RD-F-076 green Protocol age (days) VaultsRegistry deployed 2023-10-31 (block 18,470,116). As of 2026-05-16 this is ~928 days (~31 months) live. Threshold: green >= 365 days. Confirmed from Etherscan contract creation timestamp and profile §2.
RD-F-077 green Prior exploit count Zero StakeWise smart-contract exploits found across hacksdatabase (311 entries, 0 matches for stakewise/oseth/swise), rekt.news (cache rekt.incidents=[]), DeFiLlama hacks API, and web search. The 2025-11-03 Balancer v2 exploit affecting osETH LP holders is excluded from F077 count per U2 directive — it was a Balancer v2 manageUserBalance bug, not a StakeWise contract vulnerability. Score: 0 prior StakeWise exploits = green.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Derived from F077: 0 StakeWise contract exploits. Chronic flag threshold is >= 3 incidents. 0 < 3 — not chronic.
RD-F-079 green Same-root-cause repeat exploit 0 StakeWise contract incidents — no repeat root-cause pattern possible. No same-root-cause repeat exploit.
RD-F-080 green Days since last exploit No StakeWise contract exploit in protocol history. Days since last exploit: N/A / > 365 days (v3 launched October 2023, no exploit). Threshold: green = > 365 days or no incidents.
RD-F-084 green TVL stability (CoV over 90d) TVL CoV (coefficient of variation) over trailing 90 days = 0.069555 (6.96%). Threshold: green < 0.15. Mean TVL $861M, std $59.9M, 90-sample window ending 2026-05-16. CoV 0.070 is well below the 0.15 threshold. TVL decline is ETH-price correlated, not protocol-specific outflow. Score: green.
RD-F-085 green Incident response time (minutes) For the Balancer-adjacent incident (2025-11-03), the only StakeWise-relevant response event: DAO multisig mobilized and executed recovery within approximately 30 minutes to a few hours of the Balancer exploit. Multiple sources describe the recovery as occurring the same night as the exploit (late Monday night, November 3, 2025). For a governance action requiring 4-of-7 multisig signatures, response under a few hours is exceptionally fast. Score: green.
RD-F-086 green Pause activations (trailing 12 months) No on-chain pause activation events found for StakeWise v3 core contracts in the trailing 12 months. The 2025-11-03 Balancer incident did not trigger a StakeWise protocol pause; the DAO response was a token controller action (burn/mint), not a pause. Data cache contains no pause events. Threshold: green = 0 pauses.
RD-F-088 green Re-deployed to new addresses in last year No full redeployment of StakeWise v3 to new contract addresses in the trailing 12 months. The v2 to v3 migration was completed in late 2023, outside the 12-month window. The most recent GitHub release v5.0.0 (2026-04-29) represents code updates and vault implementation upgrades, not a protocol redeployment. Core contracts (VaultsRegistry, Keeper, OsToken) maintain their addresses. Score: green.
RD-F-166 green Deprecated contracts still holding value LegacyPoolEscrow (0x2296e122c1a20Fca3CAc3371357BdAd3be0dF079) is listed in mainnet.json as a legacy v2 contract. On-chain check: ETH balance ~0 at assessment time. The contract actively routes v2 Beacon Chain withdrawal ETH to GenesisVault (CommunityVault successor); most recent large transfer was 13,956 ETH on 2025-03-25. This is a live routing bridge, not an abandoned deprecated surface with stuck funds. The v2 sETH2/rETH2 tokens are in managed wind-down with active redemption pathways. No deprecated surface holds material stranded value (>$100K) in an inaccessible state. Score: green.
Real-time signals Green 6 22 of 22
RD-F-102 yellow Admin/upgrade transaction in mempool Signal applicable and elevated. The 4-of-7 DAO Safe (0x144a98cb…) can execute any admin action — setController on osETH, addOracles/removeOracles on Keeper (0x6B5815…), upgradeTo on VaultFactory proxy (0x7A8cbBf…) — without any on-chain timelock. The T-09 suppression rule (tx originates from timelock contract fed by queued governance proposal) cannot engage because no on-chain timelock exists (governance.timelock_address: null per cache). The only suppression path is a curator-maintained Snapshot proposal allowlist. No admin tx currently in mempool at assessment date. However, the structural posture is persistently elevated: any unannounced 4-of-7 Safe execution would fire this signal immediately. The 2025-11-03 emergency burn/mint demonstrates willingness to act without on-chain pre-announcement queue. RD-F-182 yellow Security-Council threshold reduction (RT) F182 (batch-24, Cat 6B): Security-Council threshold-reduction event signal. Applicable and elevated. Current state: 4-of-7 threshold verified via Safe Transaction Service API (cache: threshold=4, owner_count=7). No ChangedThreshold event detected at assessment date. Posture is yellow because: (1) no timelock exists between a threshold-reduction transaction and its effect — a reduction from 4/7 to 3/7 or 2/7 would complete instantaneously within a single Safe execution, replicating the Drift Protocol 3/5→2/5 precursor pattern; (2) F182 signal suppression requires a matching Snapshot proposal in the preceding window, but the SafeSnap → Safe pathway has no on-chain queue where suppression can be verified before execution; (3) the 2025-11-03 emergency action demonstrated willingness to execute without on-chain pre-announcement, establishing that the Safe can and will act unilaterally. No current threshold change is detected, but structural posture is elevated relative to protocols with an RD-F-090 gray Mixer withdrawal → protocol interaction Signal applicable. No mixer-proximate wallet interaction with StakeWise v3 core contracts detected via Etherscan public labels. Deployer (0x229f53ef) funded by Binance 16 (CEX withdrawal — clean). DAO Safe signers show no mixer-label flags via public Etherscan data. Full 3-hop proximity analysis requires Chainalysis/TRM licensed feed, which is unavailable in this static dry run. Would not fire today based on available public evidence. RD-F-092 gray Unusual mempool pattern from deployer wallet Signal applicable — deployer 0x229f53ef is active (v3-core v5.0.0 released 2026-04-29). Mempool listener required for production monitoring. No mempool anomaly from deployer wallet detectable in static dry run without mempool subscription. RD-F-093 gray Abnormal gas-price willingness from attacker wallet No abnormal gas-price willingness from attacker-profile wallets targeting StakeWise contracts detected. Requires mempool listener and per-protocol attacker wallet set — pipeline not implemented for this signal. RD-F-094 gray New contract with similar bytecode to exploit template Bytecode-similarity baseline for StakeWise v3 exploit-template detection not established. The vault-factory architecture produces frequent legitimate vault deployments (permissionless), making bytecode-similarity signal high-noise without a curated template database. No attack-template similar deployment detected in web search. Pipeline not implemented. RD-F-096 gray New ERC-20 approval to unverified contract from whale Signal applicable — osETH ERC-20 (0xf1C9acDc…) Approval events are monitorable. No new ERC-20 approval from high-TVL user to an unverified contract interacting with StakeWise detected. Requires continuous monitoring of Approval events + unverified-contract lookup. Pipeline not implemented. RD-F-097 gray Sybil surge of identical-pattern transactions Signal applicable — permissionless vault creation could be probed via Sybil EOAs creating test vaults. No Sybil surge detected. Requires on-chain clustering and transaction-pattern analysis. Pipeline not implemented. RD-F-103 n/a Bridge signer-set change proposed/executed StakeWise has no bridge surface (coverage_flags.layerzero_bridge: false; has_bridge_surface: false per protocol profile). Gnosis Chain deployment is a separate native contract set, not a bridge of Ethereum osETH. No bridge validator/signer set exists to monitor. This signal is structurally inapplicable to this protocol architecture. RD-F-106 n/a Cross-chain bridge unverified mint pattern StakeWise has no bridge surface. No cross-chain bridge message passing is used in the protocol architecture. Gnosis Chain deployment is a separate native deployment. This signal is structurally inapplicable to this protocol. RD-F-107 gray Admin EOA signing from new geography/device Signal applicable — 7 DAO Safe signers are the relevant admin population. Assessment requires device/IP telemetry from signing infrastructure. No signing telemetry is publicly accessible; this is a proprietary feed requirement. Cannot assess in static dry run. RD-F-110 gray Unusual pending/executed proposal ratio StakeWise has no on-chain Governor; canonical on-chain proposal ratio is not computable. Snapshot space (stakewise.eth) can be monitored via Snapshot API for proposal velocity, but the signal requires a 30-day baseline of Snapshot proposal cadence vs execution cadence. No anomalous Snapshot proposal velocity detected. Pipeline not implemented for Snapshot-only governance protocols.
RD-F-091 green Partial-drain test transactions No partial-drain test-transaction pattern detected on StakeWise v3 core contracts (VaultsRegistry 0x3a0008a5, OsTokenVaultController 0x2A261e60). No anomalous small-withdrawal burst observed. rekt.incidents: [] (no prior exploit providing a pre-strike pattern baseline). Vault withdrawal events are permissionless but no coordinated pre-drain pattern detected.
RD-F-095 green Known-exploit function-selector replay No prior direct exploit of StakeWise v3 contracts (rekt.incidents: []); no exploit template applicable to the vault-factory + overcollateralised LST architecture. No known-exploit-replay selector sequence exists for this protocol class. The 2025-11 Balancer event was a Balancer v2 vulnerability, not a StakeWise contract exploit.
RD-F-098 green TVL anomaly — % drop in <1h TVL $794.9M at assessment date; 30-day decline -17.89% is orderly (ETH price correction, cross-protocol); 90-day mean $861M; CoV 0.0696. The 1-hour 30% drop threshold (tier-A instant flip) is not breached. Sector-wide ETH price decline suppresses this signal (peer LSTs also declining proportionally). Signal is wired and production-ready with DeFiLlama integration. Would not fire today.
RD-F-099 green Oracle price deviation >X% from secondary PriceFeed (0x8023518b…) provides osETH/ETH rate via OsTokenVaultController.getRate(). Keeper oracle network (10 operators: P2P, Gnosis, DSRV, Chorus One, Bitfly, Finoa, Telekom, Gateway.fm, Stake.Fish, Senseinode) is functional. No oracle deviation between PriceFeed reported rate and DEX-observable osETH/WETH rate detected at assessment date. osETH trades near peg. Signal is applicable; requires per-protocol secondary-source mapping for production (phase 2 gating work). Would not fire today.
RD-F-100 green Flash loan >$10M targeting protocol tokens OsTokenFlashLoans contract (0xeBe12d858E55DDc5FC5A8153dC3e117824fbf5d2) exists; osETH is flash-loanable. No large flash loan (>$10M) targeting StakeWise core contracts (oracle, vault controller, Keeper) detected at assessment date. Governance is fully off-chain (Snapshot), materially reducing the flash-loan-governance vector severity compared to on-chain Governor protocols (flash loans cannot manipulate Snapshot vote weight). Would not fire today.
RD-F-101 green Large governance proposal queued No on-chain Governor emitting ProposalCreated events exists (governance.governor_address: null per data cache). SafeSnap bridges Snapshot votes to Safe execution. No SafeSnap payload with admin-change or upgrade selector currently queued. Last documented SafeSnap execution was 2025-11-03 emergency osETH burn/mint (response to Balancer exploit; not a malicious-pattern proposal). Signal requires custom adapter for SafeSnap queue monitoring rather than standard on-chain Governor subscription. Would not fire today.
RD-F-104 green Stablecoin depeg >2% on shared-LP venue StakeWise is an ETH-staking LST; primary collateral is ETH-denominated validators, not stablecoins. No stablecoin dependency above 5% TVL identified in core protocol. Post-Balancer-exploit osETH liquidity migrated away from Balancer (stablecoin-adjacent venue). Major stablecoins (USDT, USDC, DAI) are currently at peg. Even under a stablecoin depeg scenario, StakeWise protocol TVL impact is below the 5% exposure threshold. Signal applicable in principle but dependency is below trigger threshold.
RD-F-105 green DNS/CDN/frontend hash drift stakewise.io registered 2018-09-11 (7+ years, creation delta 2,804 days); registrant StakeWise Labs (Harjumaa, Estonia); Cloudflare nameservers. No DNS drift, TLS cert change, or JS bundle hash drift detected at assessment date. No anomalous certificate transparency log entries found. Cloudflare CDN provides DDoS protection and stable DNS management. Change-management allowlist would suppress scheduled Cloudflare reconfigurations. Signal wired and applicable. Would not fire today.
RD-F-108 green GitHub force-push to sensitive branch GitHub v3-core repo (github.com/stakewise/v3-core) last commit 2026-04-29, release v5.0.0 same date. No force-push or anomalous sensitive-branch push from non-protocol accounts detected. GitHub API accessible; commit history consistent with ongoing legitimate protocol development. Main branch protected by standard GitHub practices.
RD-F-109 green Social-media impersonation scam spike No Discord/Telegram/X impersonation scam spike targeting StakeWise team or fake airdrops detected in available web sources. StakeWise has Discord (discord.com/invite/2BSdr2g), Telegram (t.me/stakewise_io), and X (@stakewise_io). No social-media monitoring feed subscription in static dry run, but web search found no current scam spike.
Dev identity & insider risk Green 13 16 of 16
RD-F-112 yellow Team public accountability surface Founder accountability surface is strong: Dmitri Tsumak has active GitHub, X, Crunchbase, IQ.wiki, and multiple podcast appearances. Kirill Kutakov has LinkedIn with full employment history (Avaron Asset Management analyst, Gunvor Group intern, Warwick SLSC), IOSG Singapore video panel (Sept 2023), Token Terminal full-length video interview, and The Block text interview. However 5 of 7 DAO Safe signers lack any confirmed public profile linking wallet to real identity — these wallets control the 4-of-7 execution threshold for all DAO transactions. Score yellow: partial accountability surface concentrated in founders, thin for majority of signers. RD-F-117 yellow ENS/NameStone identity bound to deployer Primary v3 deployer address 0x229f53ef905545aa53a721d82dbfe4ced7aff65d has NO ENS name bound — Etherscan shows no .eth domain for this wallet. The protocol founder's personal signer wallet 0x61B01a33 (Safe creator) has ENS 'tsudmi.eth' (Dmitri Tsumak). Two Safe signers have ENS handles (ottodv.eth at 0x7E36F1fF, mopsko.eth at 0xc0c9707B). The deployer address itself — the specific address scored in this factor — is ENS-free. Score yellow per factor definition: deployer does not have bound ENS resolvable to verifiable identity. RD-F-119 yellow Commit timezone consistent with stated geography Team states Estonia (EET/EEST = UTC+2/+3). Dmitri Tsumak's GitHub profile lists location: Tallinn, Estonia. Kirill Kutakov confirmed Estonian origin (IQ.wiki). Last commit 2026-04-29 (profile §2). No full programmatic commit-timezone distribution analysis completed within assessment budget — would require GitHub API enumeration across 200+ commits. No DPRK-style commit-time anomaly flagged in qualitative review. Yellow scored for incomplete automated verification (gap: programmatic timezone distribution not run). No red signal identified. RD-F-121 yellow Contributor OSINT depth score Founder OSINT depth is strong: Dmitri Tsumak has GitHub, X, Crunchbase, IQ.wiki, multiple podcast recordings; Kirill Kutakov has LinkedIn with full employment history, conference video recordings, press interviews (The Block), Token Terminal. Estimated per-founder score ~4-5/5. However 5 of 7 DAO Safe signers have no publicly linkable identity (signers 1, 2, 3, 5 with no ENS or label; ottodv.eth and mopsko.eth have ENS but no name attribution confirmed). Safe signers control the 4-of-7 execution threshold. Combined contributor set OSINT depth: 2 strong, 5 weak/none. Yellow reflects meaningful gap in signer-set accountability. RD-F-122 yellow Contributor paid to DPRK-cluster wallet No evidence that any contributor payment wallet routes within 3 hops to DPRK-labelled cluster found on public OSINT. Web search 'StakeWise DPRK Lazarus North Korea developer' returned zero StakeWise-specific results. OFAC SDN public list: no StakeWise entities or addresses. However full 3-hop trace of all 7 Safe signers not completed (requires Arkham/Nansen paid tier for signers 0xC46e791d, 0x9cC9c3de, 0x9Aa6Db87, 0x1C86117 — all with unlabelled first-hop funding). Yellow reflects incomplete trace on 4 of 7 signers; no positive DPRK signal found. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion [★ CRITICAL FACTOR] On 2025-11-03, following the Balancer v2 exploit, the DAO emergency multisig executed an on-chain ACL change without any preceding SWIP or governance forum discussion: (1) added DAO Safe as osETH and osGNO token controller, (2) burned ~5,041 osETH and 13,495 osGNO from the hacker's wallet, (3) minted equivalent amounts to DAO wallet, (4) revoked controller status — all within the same transaction series on the night of the exploit. SWIP-37 ('Renounce osETH & osGNO Token Contract Ownership') was posted 2025-11-04, the day AFTER the emergency action. The StakeWise governance process document specifies no emergency exception to the standard 3-phase SWIP process. Context for yellow (not red): (a) action was defensive — recovering stolen user funds from an external exploit, not a protocol exploit; (b) immediately and publicly announced on X same evening; (c) controller privileges were self-revoked within the same transaction series; (d) post-hoc governance completed via RD-F-184 gray Real-capital social-engineering persona Factor requires curator OSINT: a 'team contributor or external integrator persona with >=1M real-capital deposits to build credibility ahead of social-engineering attack' (Drift UNC4736 precedent). No such indicator identified in public data for StakeWise: team is publicly named (Tsumak, Kutakov); no unidentified contributor with large anomalous deposits flagged in public threat intel; no UNC-series attribution in Chainalysis or US Treasury public reports covering StakeWise. However 5 of 7 DAO Safe signers are pseudonymous with incomplete identity trace — a future curator pass with Arkham/Nansen paid-tier traces plus DPRK threat intel feed cross-reference is required before this factor can be scored. Comparator: Drift Protocol was scored red on F184 after Chainalysis published UNC4736 attribution (Feb 2026). StakeWise has no equivalent public attribution on record as of 2026-05-16.
RD-F-111 green Team doxx status Founders are publicly named with real-world identities: Dmitri Tsumak (GitHub: tsudmi, location Tallinn Estonia, Crunchbase Founder profile, X @tsudmi, IQ.wiki profile, multiple podcast appearances) and Kirill Kutakov (LinkedIn active, BSc University of Warwick 2014/2017, Avaron Asset Management analyst 2017-2020, IOSG Singapore panel on-video Sept 2023, Token Terminal full video interview). Both have consistent 5+ year public track records. Five of seven DAO Safe signers are pseudonymous with no confirmed name-wallet attribution; ENS handles available for two (ottodv.eth, mopsko.eth). Overall: real-name founders with pseudonymous supporting signers — hybrid 'real-name / pseudonym-with-track-record' profile.
RD-F-113 green Team other-protocol involvement history Dmitri Tsumak: StakeWise only (v2 2021, v3 2023); no prior DeFi protocol involvement found; no rug affiliation. Kirill Kutakov: Avaron Asset Management (TradFi value investing, CEE focus, 2017-2020); no prior DeFi protocol involvement. Both founders entered DeFi with StakeWise as their first protocol, with continuous 5+ year operation. Hacksdatabase grep returned zero StakeWise incidents (profile §10: rekt.incidents: []). No OSINT evidence of prior rug or exit-scam involvement for any team member.
RD-F-114 green Deployer address prior on-chain history v3 deployer 0x229f53ef905545aa53a721d82dbfe4ced7aff65d is labelled 'StakeWise: Deployer 1' on Etherscan. Transaction history shows: initial ETH funding from Binance 16; subsequent contract creations include EthGenesisVault, EthErc20Vault, EthBlocklistVault (Oct 2024 activity) — consistent with legitimate protocol development. No linked-to-prior-rug history found. On-chain history is definitively 'normal-dev-history' for a protocol deployer.
RD-F-115 green Prior rug/exit-scam affiliation No OSINT evidence linking Tsumak or Kutakov to prior rugged or exit-scam protocols. Web search 'StakeWise rug exit scam fraud team' returned only generic rug-pull education articles with zero StakeWise-specific results. Protocol has operated since 2021 (~5 years) with ~$795M peak TVL. Hacksdatabase: rekt.incidents: []. No handle or wallet reuse linking team to prior failed projects found.
RD-F-116 green Contributor tenure at admin-permissioned PR All admin-permissioned PRs in v3-core verified as authored by tsudmi (Dmitri Tsumak, founder): PR #134 audit fixes (Apr 21, 2026), PR #137 BalancedCurator deploy (Apr 23, 2026), PR #127 redeploy V4 contracts (Sep 16, 2025), PR #123 Gnosis vault fix (Sep 8, 2025). Tsudmi's GitHub org tenure begins at least 2021 (v2 contracts at github.com/stakewise/contracts). Tenure at most recent admin PR: >5 years. No short-tenure contributors in admin-permissioned paths identified.
RD-F-118 green Handle reuse across failed/rugged projects No OSINT evidence of social handle reuse across failed or rugged projects for @tsudmi or @kirill_kutakov (Kirill Kutakov's LinkedIn handle). Both handles have been associated exclusively with StakeWise since at least 2021. No prior alias migrations or secondary handle associations identified. Protocol x-handle @stakewise_io similarly consistent throughout 5-year operation.
RD-F-120 green Video-off/voice-consistency flag Kirill Kutakov confirmed on-video appearances: IOSG Singapore OFR panel (Sept 12, 2023 — YouTube recording public); Token Terminal full-length interview (video); The Block interview (audio/text). Dmitri Tsumak: podcast appearances (D-Core podcast #38, Blockchain People, audio/video). No video-off pattern or voice-inconsistency flag identified in any reviewed interview. Both founders have participated in real-time on-camera or on-audio public appearances consistently across 2021-2025.
RD-F-124 green Deployer wallet mixer-funded within 30 days [★ CRITICAL FACTOR] v3 deployer 0x229f53ef905545aa53a721d82dbfe4ced7aff65d: Etherscan 'Funded By' label = 'Binance 16' (address 0xdfd5293d8e347dfe59e90efd55b2956a1343963d). Funding event pre-dates the October 2023 v3 mainnet deploy by approximately 2 years 201 days — far outside the 30-day window threshold. No Tornado Cash or Railgun interactions on this wallet found. Binance 16 is a confirmed, labelled major centralised exchange address. DAO Safe signers checked: signer 4 (ottodv.eth) funded by Binance 18 (labelled CEX); signer 6 (mopsko.eth) funded by Coinify 1 (labelled regulated payment processor). No mixer funding detected on any address within the 30-day pre-deploy window or at any accessible hop.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus [★ CRITICAL FACTOR] No DPRK/Lazarus cluster proximity identified across all accessible hops. Deployer 0x229f53ef: 1-hop = Binance 16 (major CEX, definitionally not a DPRK cluster). Checked Safe signers: signer 4 (1-hop = Binance 18 — clean), signer 6 (1-hop = Coinify 1 — clean regulated processor), signer 7/tsudmi.eth (1-hop = unlabelled peer-to-peer, pre-2021, no DPRK label). Web search 'StakeWise DPRK Lazarus North Korea developer': returned zero StakeWise-specific results. OFAC SDN public list: no StakeWise entities or addresses. Protocol leadership (Tsumak, Kutakov) based in Tallinn, Estonia with verifiable real-world employment histories spanning TradFi (Avaron AM) and engineering — no DPRK proximity indicators. No escalation required.
Fork / dependency lineage Green 0 10 of 10
RD-F-126 n/a Is-a-fork-of StakeWise v3 is an original protocol. Profile §5 states: 'Not forked / original. The v3 codebase is an independent Solidity design.' GitHub repo shows no fork declaration, no upstream remote, no fork-merge commits. F126 is_a_fork_of: upstream = none. Per §6 template for original protocols, Cat 8 fork-lineage factors (F126-F132) are not_applicable by construction. RD-F-127 n/a Upstream patch not merged No upstream protocol identified (see F126). Upstream patch merging is structurally irrelevant for an original protocol. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream protocol identified (see F126). Upstream vulnerability disclosure monitoring is structurally irrelevant for an original protocol. RD-F-129 n/a Code divergence from upstream (%) Code divergence from upstream cannot be computed — no upstream protocol exists. The measurement is structurally inapplicable. RD-F-130 n/a Fork depth (generations from original audit) Fork depth is structurally zero/inapplicable — StakeWise v3 is an original protocol with no upstream fork lineage. Depth-from-original-audit is effectively 0 (direct fresh audit coverage on original code). RD-F-131 n/a Fork retains upstream audit coverage No upstream audit to retain. All 8 audit engagements are fresh, directly covering v3-core. The concept of 'retaining upstream audit coverage' does not apply to an original protocol. RD-F-132 n/a Fork has different economic parameters than upstream No upstream economic parameters to compare against. StakeWise v3's collateralisation ratios, fees, and vault parameters are original design choices, not deviations from an upstream protocol's audited defaults.
RD-F-133 green Dependency manifest uses unpinned versions The lib/ directory confirms OpenZeppelin contracts-upgradeable is pinned to a specific commit SHA (60b305a8f3ff0c7688f02ac470417b6bbf1c4d27) and forge-std is pinned to commit SHA b93cf4b. Pinning by exact commit hash is stricter than semantic version ranges (^ or ~) — no floating dependency. No ^ or ~ version specifiers for security-critical libraries found in foundry.toml.
RD-F-134 green Dependency had malicious-release incident (last 90d) No malicious-release advisory found for OpenZeppelin contracts-upgradeable or forge-std in the trailing 90 days (Feb 14 – May 16, 2026). Both are maintained by reputable organisations with active security programmes and public GHSA advisories. The most recent OZ advisories are historical (pre-5.x series).
RD-F-135 green Shared-library version with known-vuln status OpenZeppelin contracts-upgradeable pinned at commit 60b305a (v5.x series — latest v5.6.1 as of Feb 27 2026). Historical OZ advisories (GHSA-q4h9-46xg-m3x9 UUPSUpgradeable fixed in v4.3.2; GHSA-9c22-pwxw-p6hx initializer reentrancy fixed in v4.4.1) do not affect the 5.x series. Solidity 0.8.22 and 0.8.26 have no high-severity compiler bugs per Etherscan solcbuginfo — the most recent high-severity bug (TransientStorageClearingHelperCollision) first appeared in 0.8.28.
Post-deploy hygiene & change mgmt Yellow 30 13 of 13
RD-F-138 red Hot-patch deploys without timelock (last 30 days) All upgrades executed without timelock. The protocol has no TimelockController (timelock_address null). Every upgrade executed by the DAO Safe is structurally a hot-patch from a timelock perspective. The November 2025 emergency osETH controller action is the clearest example: controller authority granted and exercised without any delay. Count of hot-patch deploys in last 30 days: at minimum the v5.0.0 deployment (2026-04-29, 17 days before assessment). RD-F-136 yellow Deployed bytecode matches signed release tag Multiple GitHub releases exist (v5.0.0 2026-04-29; 13 total releases). Active development confirmed. Statemind April 2026 audit covered current codebase. Rigorous bytecode-vs-signed-tag diff not performed. Yellow due to inability to independently verify bytecode diff against each release tag without code-security tooling. RD-F-137 yellow Upgrade frequency (per 90 days) Multiple upgrades in trailing 90 days: v5.0.0 (2026-04-29, Statemind-audited) represents new vault implementation deployments. Recent SWIP-28 exit queue fix also within or near 90-day window. Upgrade frequency is moderate (~2-3 events per 90 days across vault implementation stack). Upgrade-per-se is not problematic given accompanying Sigma Prime/Statemind reviews, but frequency is elevated. RD-F-139 yellow Post-audit code changes without re-audit [★ not-critical yellow] Major upgrades received external reviews: Vaults v2.0 — Sigma Prime June 2024; SWIP-25 Vault Factory v3 — Sigma Prime + Hexens per forum post; SWIP-28 exit queue fix — Sigma Prime approval; v5.0.0 — Statemind April 2026. However: (1) Nov 2025 emergency controller action was NOT preceded by audit — used pre-existing capability; (2) SWIP-28 review is described as approval rather than formal full-scope re-audit. Pattern is review-for-each-upgrade, not no-review; yellow for coverage gaps on rapid-review completeness. RD-F-145 yellow Deployed bytecode reproducibility Foundry build parameters available: Solidity 0.8.26, optimizer 200 runs, via_ir=true (data cache). v5.0.0 release tag exists on GitHub. Build parameters are documented and sufficient for reproducibility attempt. Formal reproducibility verification not performed — yellow. RD-F-146 yellow New contract deploys in last 30 days v5.0.0 released 2026-04-29 (17 days before assessment date). This release includes new vault implementation contracts deployed via VaultsRegistry. Fresh attack surface within 30 days. Partially mitigated by Statemind April 2026 audit covering this codebase. RD-F-142 gray Storage-layout collision risk across upgrades Storage-layout collision analysis across multiple vault implementation versions (v1, v2.0, v3, v5.0.0) requires OZ upgrades-plugin verification or manual curator analysis. Not performable within governance-admin-analyst scope. Gap flagged for code-security-analyst. RD-F-144 gray CREATE2 factory permits same-address redeploy CREATE2 factory redeployment analysis requires static analysis of vault factory contracts. StakeWise uses factory patterns for vault deployment (VaultFactory, Erc20VaultFactory, etc.). Cannot assess CREATE2 salt uniqueness enforcement without code-security tooling. RD-F-168 n/a Stale-approval exposure on deprecated router Not applicable. StakeWise v3 is not a router-based protocol. The architectural pattern (Vault + osETH minting) does not involve routers with ERC-20 token approvals in the manner this factor measures. Legacy v2 contracts are fully separate from v3 and any stale approvals there are not a v3 protocol-level risk. No active deprecated router surface exists in the v3 architecture. RD-F-185 n/a Bridge rate-limiter / chain-pause as positive mitigant Not applicable. StakeWise v3 has no bridge surface (has_bridge_surface false, layerzero.present false, coverage_flags.layerzero_bridge false in data cache). RD-F-185 measures bridge rate-limiter and chain-pause as positive mitigants for bridge exploit scenarios — structurally inapplicable to this LST protocol with no cross-chain bridge.
RD-F-140 green Fix-merged-but-not-deployed gap No known vulnerability with fix-merged-but-not-deployed pattern identified. Statemind April 2026 audit covers current codebase; v5.0.0 release followed on 2026-04-29. No post-audit-disclosed-but-undeployed fix found in public channels.
RD-F-141 green Test-mode parameters in deploy No test-mode parameters in production. OsToken deployed with real owner (DAO Safe, not deployer EOA). Keeper uses 10 production oracle operators (P2P, Gnosis, DSRV, Chorus One, etc.). VaultsRegistry uses production oracle operator whitelist. OsTokenConfig uses production LTV parameters. All consistent with production deployment.
RD-F-143 green Reinitializable implementation (no _disableInitializers) OsToken.sol is a direct deployment (non-proxy), uses standard constructor (not initialize()), and does not require _disableInitializers(). VaultsRegistry and Keeper are also direct Ownable2Step deployments. The reinitializer risk applies to proxied vault implementation contracts (EthVault, etc.) which use factory-based initialize() — this is a Cat 1 handoff for code-security-analyst to verify _disableInitializers() in vault impl constructors. Governance-relevant contracts are not re-initializable.
Cross-chain & bridge Gray 0 12 of 12
RD-F-147 n/a Protocol has bridge surface StakeWise v3 has no bridge surface. Profile §7 explicitly states has_bridge_surface: false and is_a_bridge: false. Data cache sources.layerzero.present: false; coverage_flags.layerzero_bridge: false. Gnosis Chain deployment is a separate native v3 instance (independent Keeper, VaultsRegistry, osGNO), not a bridge or cross-chain messaging system. All Cat 10 factors are not_applicable. RD-F-148 n/a Bridge validator count (M) No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-149 n/a Bridge validator threshold (k-of-M) No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-150 n/a Bridge validator co-hosting No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) [★ CRITICAL — bridge-only] Not applicable. StakeWise has no bridge surface and does not implement cross-chain message verification. No ecrecover call in any bridge verification path exists because there is no bridge. See RD-F-147. RD-F-152 n/a Bridge binds message to srcChainId No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-153 n/a Bridge tracks nonce-consumed mapping No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-154 n/a Default bytes32(0) acceptable as valid root [★ CRITICAL — bridge-only] Not applicable. StakeWise has no bridge inbox or Merkle root acceptance path. No bytes32(0) default-value root vulnerability can exist without a bridge. See RD-F-147. RD-F-155 n/a Bridge validator-set rotation recency No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-156 n/a Bridge uses same key custody for >30% validators No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-157 n/a Bridge TVL per validator ratio No bridge surface — Cat 10 fully N/A for this protocol. See RD-F-147. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) No LayerZero OFT integration. StakeWise v3 has no bridge surface and no LayerZero endpoint. Data cache sources.layerzero.present: false; coverage_flags.layerzero_bridge: false. F179 applies only to LayerZero OFT adapters — not applicable here. See RD-F-147.
Threat intelligence & recon Green 8 8 of 8
RD-F-158 yellow Known-threat-actor cluster has touched protocol No public attribution of Lazarus/DPRK-labeled wallet interaction with StakeWise v3 core contracts found (web search: zero protocol-specific results for 'StakeWise DPRK Lazarus'). StakeWise is a passive venue: a $795M ETH-staking LST is a plausible laundering target for post-exploit DPRK proceeds (ETH is the primary post-exploit conversion asset for Lazarus group per 2024-2026 public reporting). Per U4 rule (§15 of briefing): DPRK passive-venue risk does not contaminate Cat 7 team assessment. Scored yellow because: (1) no confirmed interaction; (2) no licensed feed clearance available in static dry run; (3) passive-venue structural risk at this TVL level is non-negligible. RD-F-161 gray Protocol-impersonator domain registered (typosquat) F161 typosquat delta computation: stakewise.io creation date = 2018-09-11; assessment date = 2026-05-16; registration delta = 2,804 days (7 years 8 months). Domain is extremely well-established; structural risk for a same-registration-window impersonation domain is very low. Web search for common typo variants ('stakewiise', 'stake-wise.io', 'stakewyse', 'stakeewise') returned no active impersonation domains. However, dedicated continuous domain-monitoring feed (DNSTwist or equivalent) is not implemented in pipeline; cannot provide a comprehensive negative result. Scored gray because absence of evidence from web search alone is insufficient for a clean green in production without feed. RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols No same-class LST protocol exploit reconnaissance baseline available from hacksdatabase (StakeWise-class vault-factory LST is novel). The Balancer-adjacent 2025-11 event was a Balancer v2 vulnerability, not a direct StakeWise reconnaissance-then-strike event. Peer-class reconnaissance baseline (e.g., typical reconnaissance duration for ETH-staking LSTs) requires curator research across comparable protocols. Cannot populate without curator input. RD-F-164 gray Leaked credential on paste/sentry site No paste-site or credential-dump mention of StakeWise infrastructure endpoints, API keys, or signing credentials detected in public web search. Dedicated paste/credential-dump feed (HaveIBeenPwned API, BreachDirectory, Sentry-alt feeds) not implemented in pipeline. Cannot provide a definitive negative result without continuous feed subscription. RD-F-165 gray Protocol social channel has scam-coordinator flag StakeWise Discord (discord.com/invite/2BSdr2g) and Telegram (t.me/stakewise_io) are active channels. No curator-maintained social scam-coordinator watchlist subscription implemented. No public report of a scam-coordinator flagged in StakeWise channels found in web search. Gray because pipeline watchlist is not implemented.
RD-F-159 green Attacker wallet pre-strike probe (low-gas failing txs) No mempool probe pattern (failing/low-gas txs from threat-actor wallets) detected targeting StakeWise contracts. Requires licensed TI feed + mempool subscription for production. Public web search and Etherscan label data show no such activity. No prior exploit establishing an attacker-wallet baseline (rekt.incidents: []).
RD-F-160 green GitHub malicious-dependency incident touching protocol deps StakeWise v3-core uses Foundry toolchain (foundry.toml confirmed in data cache; no package.json; Solidity 0.8.26). Primary external dependency is OpenZeppelin contracts. No GitHub Security Advisory (GHSA) flagging a malicious release in OpenZeppelin contracts, Solidity 0.8.26 toolchain, or Forge-std in the trailing 90 days identified via web search. No malicious-dependency incident affecting relevant deps detected.
RD-F-162 green Known-exploit-template selector deployed by any address No prior direct exploit of StakeWise v3 contracts means no exploit template exists from which to derive a selector-pattern for this specific architecture (vault-factory + overcollateralised LST minting). No contract deployment with selector-pattern matching a StakeWise-class exploit template detected. The 2025-11 event was a Balancer v2 vulnerability — does not contribute to a StakeWise-specific exploit template.
Tooling / compiler / AI Green 0 5 of 5
RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation StakeWise v3 is an original protocol with no audited upstream to compare against. The AI-copy risk pattern (bytecode similarity >80% with state-mutation order deviation relative to an upstream) cannot apply when no upstream exists.
RD-F-170 green Solc version used (known-bug versions flagged) foundry.toml specifies solc 0.8.26 with evm_version = cancun for the default profile. Etherscan confirms VaultsRegistry and Keeper compiled with v0.8.22+commit.4fc1097e; VaultFactory and newer contracts compiled with v0.8.26+commit.8a97fa7a. Etherscan solcbuginfo confirms no high-severity known bugs in either version. The high-severity TransientStorageClearingHelperCollision bug first appears in 0.8.28 and does not affect 0.8.22 or 0.8.26.
RD-F-172 green Repo shows AI-tool co-authorship in critical files GitHub commit history for v3-core shows commits primarily from tsudmi with human co-authors evgeny-stakewise and CJ42. Commit messages are standard technical descriptions. No Co-authored-by: github-copilot[bot] or ChatGPT Code Interpreter trailers detected in the recent (April 2026) commit series visible in the commit feed. No AI co-authorship pattern in security-critical files detected.
RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure by StakeWise team of AI-generated Solidity in security-critical paths found. Profile does not flag any AI disclosure. No Medium posts, Twitter/X disclosures, or forum posts mentioning AI-generated contract code were identified in research.
RD-F-174 green Dependency tree uses EOL Solidity version Deployed contracts use Solidity 0.8.22 (older contracts) and 0.8.26 (newer contracts per foundry.toml). Both are within the actively maintained 0.8.x series. Neither is EOL. OZ contracts-upgradeable 5.x requires Solidity ^0.8.20, consistent with both deployed versions. No EOL version in production contracts.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public No acknowledgment-time SLA publicly stated by StakeWise. The Immunefi program page does not include a specific response-time commitment from StakeWise (e.g., '72h acknowledgment'). No security policy page found at docs.stakewise.io. SECURITY.md absent from v3-core GitHub repo (confirmed: security_md_present: false). Disclosure channel exists (F175 green) but no published SLA — score yellow per methodology (SLA not stated).
RD-F-175 green Disclosure channel exists Immunefi bug bounty program confirmed at immunefi.com/bug-bounty/stakewise/. Active program with 15 in-scope contracts, $200K max critical payout, $50K high severity. Rewards in SWISE or USDC. No KYC required. PoC required for all reports. This constitutes a functional public security-disclosure channel.
RD-F-177 green Prior known-ignored disclosure No evidence found of a vulnerability disclosure being known to StakeWise and ignored prior to an exploit. No StakeWise smart-contract exploit exists in the record (RD-F-077 = 0). The Balancer-adjacent incident (2025-11-03) was a Balancer v2 bug, not a disclosed-but-ignored StakeWise vulnerability. No post-mortems, news articles, or researcher reports indicate a StakeWise-specific 'warned but ignored' pattern. Score: green.
RD-F-178 green CVE/GHSA advisory issued against protocol GitHub Advisory Database query for 'stakewise' returned 0 results (no GHSA issued). Web search for 'StakeWise protocol CVE GHSA advisory security vulnerability' returned no relevant results. No CVE or public security advisory filed against StakeWise v3-core or any related contracts as of 2026-05-16.
rubric_version v1.7.0 graded_at 2026-05-16 01:37:43 factors 184 protocol stakewise