stHYPE (Valantis Labs)

Liquid staking token (LST) for Hyperliquid's native HYPE token, issued by Valantis Labs (acquired from Thunderhead August 2025). Two token representations on HyperEVM: stHYPE (rebasing ERC-20) and wstHYPE (non-rebasing share-valued wrapper). Actual HYPE custody and validator delegation occur on HyperCore (Hyperliquid's non-EVM L1) via 7 stake accounts (5 standard HyperCore Staking Modules, 1 HIP-3/HyENA module, 1 USDe quote-asset module). First LST on HyperEVM. Hybrid-substrate architecture: HyperEVM contracts are EVM-inspectable; HyperCore stake accounts are not. Admin: 4-of-6 Gnosis Safe on HyperEVM. No on-chain governor, no Snapshot, no standalone timelock contract. 6 audit engagements (Three Sigma Feb 2025 through Obsidian Apr 2026). No active public bug bounty program.

Sector lst

TVL $144.5M

Reviewed May 17, 2026

Factors 184

Categories 13

Risk score 42.1

DeploymentsHypercore · $144.5M

Risk profile at a glance

2 red · 5 yellow · 3 green

25 24 17 13 15 22 16 10 13 12 8 5 4

Categories & evidence

184 factors · 13 categories

Code & audits Yellow 33 25 of 25

RD-F-007 red Bug bounty presence & max payout No active bug bounty program. Immunefi directory search returns no stHYPE or Valantis program. Cache confirms bug_bounty.platform: null. docs.valantis.xyz/stakedhype/transparency-and-risks explicitly states 'no active bug bounty program.' Legacy stakedhype.fi claimed a bounty but it is not republished on current Valantis docs. The Hyperliquid L1 bug bounty is a separate program and does not cover stHYPE contracts. RD-F-009 red Formal verification coverage No Certora, Halmos, or Kani formal verification work found for stHYPE contracts. ValantisLabs GitHub does not contain a Certora specs directory. No FV report linked from docs.valantis.xyz/resources/audits. Six audit engagements are traditional code reviews, not formal verification. 0% FV coverage = red. RD-F-001 yellow Audit scope mismatch Six audit engagements span Feb 2025–Apr 2026; most recent (Obsidian Apr 2026) covers the April 10 2026 upgrade per changelog. All three core contracts verified on hyperevmscan.io with 'Exact Match' status. Audit PDFs are GitHub-hosted binaries — commit SHAs inside PDFs are not parseable via WebFetch, so bytecode-to-report-commit cross-check cannot be independently confirmed. No evidence of deployed bytecode post-dating the most recent audit. RD-F-005 yellow Audit firm tier Four firms: Three Sigma (Tier-2 established), Pashov Audit Group (Tier-2 established boutique), Guardian Audits (Tier-2 established), Obsidian Security (boutique/Tier-2). No Tier-1 firm (Trail of Bits, OpenZeppelin, ConsenSys Diligence, Certora, Sigma Prime, Spearbit, Zellic) has audited stHYPE core contracts. Yellow = Tier-2 only. RD-F-022 yellow Public initialize() without initializer modifier stHYPE token implementation (0xe71cAF5c): initialize() confirmed with OZ initializer modifier and constructor calls _disableInitializers(). wstHYPE implementation (0x104324): minimal constructor, OZ Initializable pattern. OverseerV1 implementation (0xaC43e7a1): ABI shows initialize() and initializeV3() functions; source is verified on hyperevmscan but modifier text was not confirmed via parsed source — ABI-only inspection is inconclusive. No unprotected initialize() confirmed; marking yellow rather than green due to residual uncertainty on OverseerV1 modifier from ABI-only view. Protocol's 4-firm audit history makes an unprotected initialize extremely unlikely. RD-F-023 yellow Constructor calls _disableInitializers() stHYPE token implementation: confirmed — source explicitly shows constructor calls _disableInitializers(). wstHYPE: minimal constructor() nonpayable, OZ pattern. OverseerV1: constructor ABI shows inputs:[], nonpayable — whether _disableInitializers() is called inside cannot be confirmed from ABI alone. Yellow due to OverseerV1 uncertainty. RD-F-003 gray Resolved-without-proof findings All audit PDFs are GitHub-hosted binary files not parseable via WebFetch. Finding resolution status cannot be verified against on-chain commits. No parsed findings table is publicly available. Marking gray rather than red as positive evidence of unresolved critical findings is absent. RD-F-008 gray Ignored bounty disclosure No prior exploits on stHYPE contracts documented. No post-mortem exists. Cannot assess ignored-disclosure factor without prior incidents. RD-F-010 gray Static-analyzer high-severity count No published Slither/Mythril/Semgrep output available for stHYPE contracts. Contracts are verified on hyperevmscan.io (not mainnet Etherscan). No static analysis was run in this assessment per T-10 dry run discipline. Needs tool run. RD-F-011 gray SELFDESTRUCT reachable from non-admin path No Slither run available. SELFDESTRUCT presence cannot be confirmed without tool run. OZ-pattern upgradeable contracts would not typically include SELFDESTRUCT in user-accessible paths. RD-F-012 gray delegatecall with user-controlled target No static analysis output available. delegatecall with user-controlled target cannot be confirmed without tool run. RD-F-013 gray Arbitrary call with user-controlled target No static analysis output available. Arbitrary call with user-controlled target cannot be confirmed without tool run. RD-F-014 gray Reentrancy guard on external-calling functions No static analysis output available. Reentrancy guard coverage cannot be confirmed without tool run. OverseerV1 interacts with HyperCore via L1 read/write addresses — cross-layer call surface is a potential reentrancy concern. RD-F-015 gray ERC-777/1155/721 hook without reentrancy guard stHYPE and wstHYPE are ERC-20 tokens; no ERC-777/1155/721 hook integration expected for core LST contracts. Cannot confirm without source inspection. ABI confirms standard ERC-20 interface. RD-F-016 gray Divide-before-multiply pattern No Slither run available. Divide-before-multiply pattern cannot be confirmed without tool run. RD-F-017 gray Mixed-decimals math without explicit scaling stHYPE rebasing uses shares (balancePerShare, totalShares) — cross-decimal arithmetic risk depends on normalization in the shares accounting. Cannot confirm without source inspection. RD-F-018 gray Signed/unsigned arithmetic confusion No symbolic execution or static analysis available. Signed/unsigned arithmetic confusion cannot be assessed without tool run. RD-F-019 gray ecrecover zero-address return unchecked stHYPE uses EIP-712 via VotesUpgradeable; ecrecover guard status cannot be confirmed without source inspection of signature paths. RD-F-020 gray EIP-712 domain separator missing chainId EIP-712 used for governance delegation (VotesUpgradeable). stHYPE is HyperEVM-only (no cross-chain deployment) so replay across chains is unlikely. chainId inclusion in DOMAIN_SEPARATOR cannot be confirmed without source inspection. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned All three core contracts use EIP-1967 Transparent Upgradeable Proxy pattern, not UUPS. The _authorizeUpgrade function does not exist in a transparent proxy setup; the proxy admin controls upgrades directly. Factor is N/A for non-UUPS contracts. RD-F-183 gray Bug bounty scope gap on highest-TVL contracts No active bug bounty program exists at all (confirmed via Immunefi search, docs, and cache). Per methodology template: 'gray = no bug bounty program exists (see RD-F-007).' F183 measures scope gap within an existing program; with no program, the scope-gap question is moot. The bug bounty absence is captured under RD-F-007 (red).

RD-F-002 green Audit recency Most recent audit is Obsidian April 2026, approximately 17 days before assessment date 2026-05-17. Well within the 365-day green threshold.

RD-F-004 green Audit count Four distinct audit firms: Three Sigma (Feb 2025), Pashov Audit Group (Oct 2025, Nov 2025), Guardian Audits (Nov 2025, Jan 2026), Obsidian Security (Apr 2026). Green threshold of ≥2 distinct firms met with 4 firms. Pashov Oct 2025 report is independently hosted at pashov/audits repo.

RD-F-006 green Audit-to-deploy gap Three Sigma Feb 2025 audit timed to HyperEVM mainnet launch (Feb 18 2025) — gap likely ≤30 days. Subsequent audits (Pashov Oct/Nov, Guardian Nov/Jan, Obsidian Apr) are documented in the changelog as tied to specific upgrades, indicating audits precede or coincide with deployments. Best inference is ≤60 days for all engagements.

RD-F-024 green Code complexity vs audit coverage Six audit engagements in 15 months for 3 focused core contracts. Multiple iterative audits (Oct 2025, Nov 2025×2, Jan 2026, Apr 2026) strongly suggest adequate audit coverage. Protocol scope is a focused LST system, not a large multi-protocol ecosystem. Green inference.

Governance & admin Red 51 24 of 24

RD-F-032 red Timelock duration on upgrades No on-chain timelock. AccessControlDefaultAdminRules delay = 0 explicitly documented. April 9 2026 upgrade tx (0x11482a6a) executed directly via Safe.execTransaction with no TimelockController interaction. Docs state 'no protocol-wide on-chain upgrade timelock guarantee.' The '48-hour' in changelog is off-chain policy only. RD-F-033 red Timelock on sensitive actions No timelock on any sensitive action (mint, pause, rescue, upgrade). AccessControl delay = 0. No TimelockController deployed. All five action types (mint, pause, rescue, setOracle/rebase, upgrade) are immediately executable by the Safe with no enforced delay. RD-F-034 red Guardian/pause-keeper distinct from upgrader PAUSER_ROLE and DEFAULT_ADMIN_ROLE (upgrader) both held by the same Safe (0x97dEe0eA4Ca10560f260A0f6f45bdC128A1D51f9). No distinct guardian multisig. No role separation between pauser and upgrader. RD-F-040 red Emergency-veto multisig present No emergency-veto or guardian multisig exists separate from the main admin Safe. PAUSER_ROLE held by the same Safe as upgrade role. Docs confirm 'no active on-chain veto mechanism.' No cancel role held by an independent party. RD-F-041 red Rescue/emergencyWithdraw without timelock rescueTokens(address token, address to, uint256 amount) confirmed present on stHYPE implementation (0xe71cAF5c) and wstHYPE (0x104324863cfb) via hyperevmscan.io ABI. Callable by DEFAULT_ADMIN_ROLE = Safe. No timelock or delay (AccessControl delay=0, no TimelockController). 4-of-6 quorum can drain all tokens in one transaction. [CRITICAL] RD-F-042 red Admin has mint() with unlimited max mint(address to, uint256 amount) on stHYPE implementation restricted to MINTER_ROLE held by Safe and OverseerV1. No maxSupply or cap function confirmed in ABI. No timelock on mint. Safe can mint unbounded stHYPE via MINTER_ROLE. LST design does not inherently cap supply. [CRITICAL] RD-F-025 yellow Admin key custody type Gnosis Safe 4-of-6 (0x97dEe0eA4Ca10560f260A0f6f45bdC128A1D51f9) holds DEFAULT_ADMIN_ROLE and ProxyAdmin ownership across all three proxy contracts (stHYPE, wstHYPE, OverseerV1). Classification: multisig without timelock. Yellow because no on-chain timelock enforced; timelock = 0. RD-F-026 yellow Upgrade multisig signer configuration (M/N) Documented 4-of-6 threshold. Safe API unavailable on HyperEVM (api_status: error). Docs-sourced with medium confidence. All 6 signer addresses enumerated in roles-and-controls-registry. Yellow because threshold is below the multisig+timelock green threshold. RD-F-028 yellow Low-threshold multisig vs TVL 4-of-6 threshold is at or near peer norm for $144M TVL. However, all privileged roles are concentrated in a single Safe (no role-separation across distinct multisigs), and 6 signer identities are not publicly attested. Effective resilience reduced by concentration. RD-F-031 yellow Signer rotation recency Docs note threshold updated to 4-of-6 on 2026-04-07 (prior threshold unknown). No on-chain Safe event history accessible. No threshold-reduction precursor pattern (DPRK-class) identified. Direction of change (increase vs decrease from prior) unknown. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle FEE_RECIPIENT_ROLE (0xa2666b4dd) and MANAGER_ROLE (0x53D6c6594d) are distinct from the admin Safe. REBASER_ROLE (0x4eb038eb) distinct from Safe. However, upgrade role and PAUSER_ROLE are held by the same Safe — no upgrade/pause separation. Two of three pairs are separated; upgrade=pause is not. RD-F-029 gray Multisig signers co-hosted 6 signer addresses not publicly attested to known individuals. Co-hosting cannot be confirmed or denied. Safe API blocked on HyperEVM. No OSINT match between Safe signer addresses and public identities found. RD-F-030 gray Hot-wallet signer flag HyperEVM Safe API unavailable; signer EOA transaction history not accessible for behavioral hot-wallet analysis. Cannot confirm or deny hot-wallet pattern for any signer. RD-F-036 n/a Flash-loanable voting weight No on-chain governance contract exists. Protocol is multisig-only with no Governor, no Snapshot, no DAO token used for vote-weighting. Flash-loan voting attack surface does not exist by construction. RD-F-037 n/a Quorum achievable via single-entity flash loan No on-chain governance with quorum mechanism. Multisig-only by construction. RD-F-038 n/a Proposal execution delay < 24h No on-chain Governor or proposal-execution mechanism. Multisig executes directly. No proposal delay concept applies. RD-F-039 n/a delegatecall/call in proposal execution without allowlist No on-chain Governor or proposal-execution contract exists. Safe executes transactions directly via execTransaction with explicit to/value/data/operation params; there is no proposal execution path. delegatecall/call in proposal payload is not an applicable attack vector. RD-F-044 gray Admin wallet interacts with flagged addresses No Chainalysis/TRM cluster feed available for HyperEVM addresses. Safe API blocked. HyperEVM signer address tx history not accessible for flagged-address interaction check. RD-F-045 gray Constructor args match governance proposal No formal governance proposal process exists (multisig-only; no Governor, no Snapshot). Deploy and upgrade arguments are not tracked via public governance proposals. Factor presupposes a governance proposal that does not exist for this protocol type. RD-F-047 n/a Governance token concentration (Gini) No governance token exists. stHYPE and wstHYPE are yield-bearing LSTs, not governance tokens. Protocol is multisig-governed with no token-voting mechanism. Gini coefficient not applicable.

RD-F-027 green Single admin EOA Admin is Gnosis Safe (GnosisSafeProxy confirmed on hyperevmscan.io), not a single EOA. Deployer EOA (0x20e97805af96ec2adeb7b2f0cea61b1414d5328c) is not the current admin. Transfer to Safe occurred at or before launch.

RD-F-043 green Admin = deployer EOA after 7 days Deployer EOA (0x20e97805af96ec2adeb7b2f0cea61b1414d5328c, labeled 'stakedhype: Deployer') is not the current admin. DEFAULT_ADMIN_ROLE and ProxyAdmin are held by Safe 0x97dEe0eA4Ca. Transfer occurred at or before HyperEVM mainnet launch (Feb 18, 2025).

RD-F-046 green Contract unverified on Etherscan/Sourcify stHYPE proxy, wstHYPE proxy, OverseerV1 proxy, and all current implementation contracts are source-verified with 'Exact Match' on hyperevmscan.io. HyperEVMScan is the canonical EVM explorer for HyperEVM.

RD-F-167 green Deprecated contract paused but pause reversible by live admin No formally deprecated contracts holding material value identified. Prior stHYPE implementations (0xd770c65f, 0xA2Fdc8ec) are inactive implementation contracts without TVL. Proxy addresses unchanged across upgrades — users interact with the same proxy address. No deprecated router or proxy shell holds material value.

Oracle & external dependencies Yellow 22 17 of 17

RD-F-050 yellow Dependency graph (protocols depended upon) Critical non-redundant dependencies: (1) Hyperliquid HyperCore L1 validator set — existential, non-EVM, non-inspectable; (2) 5 standard HyperCore Staking Modules — hold HYPE custody; (3) HIP-3/HyENA module — Ethena-linked, HIP-3 slashing mechanics; (4) USDe quote-asset module — novel permissionless spot quote asset slashing. Secondary: REBASER_ROLE keeper (single address, liveness); STEX AMM (instant-unstake only, not core path). Yellow because HyperCore modules are non-inspectable existential dependencies with no redundancy or fallback path. RD-F-051 yellow Fallback behavior on oracle failure No oracle failure mode in the traditional sense. If REBASER_ROLE keeper stops submitting rebases, syncSupply is not called; no revert or auto-pause is triggered. No declared fallback oracle path. Docs state 'no guaranteed insolvency backstop.' If HyperCore L1 system fails, no alternative data source exists. Yellow: no fallback on keeper failure; fund custody unaffected but LST ceases to accrue rewards. RD-F-052 yellow Breakage analysis per dependency Breakage per dependency: HyperCore L1 halt → all staking operations cease, ~$144M TVL stranded in unbonding; HIP-3 slashing → partial NAV loss + extended withdrawals; USDe module slashing → partial NAV loss (novel model); REBASER_ROLE keeper offline → rebase stale, no capital loss; STEX AMM illiquid → instant-unstake unavailable, standard path unaffected. Yellow because breakage analysis is partially complete — HyperCore module allocation percentages (needed to quantify partial-slashing impact) are not accessible from HyperEVM. RD-F-057 yellow Circuit breaker on price deviation No circuit breaker on rebase function. OverseerV1 rebase(uint256 l1Balance) does not have a maxDeviationBps or price-guard function in the ABI. No deviation check between old and new l1Balance. Trusted REBASER_ROLE keeper controls submission; DEFAULT_ADMIN_ROLE (4-of-6 Safe) can replace keeper if compromised. Yellow: liveness risk (incorrect l1Balance submission), no direct capital-loss vector. RD-F-059 yellow Oracle staleness check present No explicit staleness check on the l1Balance parameter in rebase(). The ABI shows lastRebaseTime() and syncInterval() state variables, suggesting time-based cadence, but no on-chain staleness rejection of the input value is evident from the function signature. Staleness protection relies on keeper reliability, not contract enforcement. Yellow: absence of on-chain staleness check on keeper-submitted balance. RD-F-062 yellow External keeper/relayer not redundant Single REBASER_ROLE keeper at 0x4eb038eb501045daa520b972fcad48c429531e10. Only one address holds REBASER_ROLE per roles-and-controls-registry. No redundant keeper or permissionless rebase path documented in ABI or docs. If keeper goes offline, rebases stop; stHYPE ceases to accrue rewards until DEFAULT_ADMIN_ROLE Safe grants REBASER_ROLE to a new address. Fund custody unaffected. Yellow: single non-redundant liveness keeper. RD-F-054 n/a TWAP window duration No TWAP oracle used. stHYPE uses keeper-submitted L1 balance for rebase, not a DEX TWAP. Factor does not apply. RD-F-055 n/a Oracle pool depth (USD) No DEX pool oracle used. Factor does not apply to this LST. RD-F-056 n/a Single-pool oracle (no medianization) No DEX pool oracle used. Medianization question does not apply. RD-F-058 n/a Max-deviation threshold (bps) No circuit breaker exists (see RD-F-057); therefore max-deviation threshold is not configured. Factor not applicable in absence of a circuit breaker. RD-F-060 n/a Chainlink aggregator min/max bound misconfig No Chainlink feed used anywhere in stHYPE. Factor not applicable. RD-F-061 n/a LP token balanceOf used for pricing No LP token pricing. stHYPE/HYPE exchange rate uses shares math (balancePerShare() = totalSupply / shares) derived from internal state + keeper-submitted l1Balance. No balanceOf() call in price computation path. RD-F-180 n/a Immutable oracle address [★ CRITICAL — NOT_APPLICABLE] No oracle adapter address exists in stHYPE. Confirmed: no oracle state variables, no setOracle function, no oracle adapter in OverseerV1 or stHYPE ABIs. The rebase uses the Hyperliquid L1 precompile (system infrastructure at 0x0800+ range) — not a third-party oracle with a configurable/immutable address. Per PD-023 substrate-generalization: the precompile address is Hyperliquid L1 system infrastructure analogous to Ethereum precompiles (0x01-0x09), not a removable oracle adapter. F180's failure mode (lending cannot reprice when asset depegs because oracle address is immutable) does not apply to this LST: there is no pricing oracle, no lending market, and no oracle address to be immutable. RD-F-181 n/a Permissionless-pool lending oracle stHYPE is an LST, not a lending protocol. RD-F-181 applies to lending protocols that accept spot prices from permissionlessly-created DEX pools. Not applicable by protocol-type definition.

RD-F-048 green Oracle providers used No third-party oracle providers used. OverseerV1 rebase uses Hyperliquid L1 read-precompile (system infrastructure at 0x0800+ range) submitted by REBASER_ROLE keeper. No Chainlink, Pyth, Uniswap-TWAP, or RedStone feed addresses appear in OverseerV1 or stHYPE ABIs. Data cache confirms oracle_feeds: [].

RD-F-049 green Oracle role per asset No oracle-to-asset mapping exists. stHYPE/HYPE exchange rate derived from internal shares math (balancePerShare()). The rebase 'feed' is the keeper-submitted uint256 l1Balance — a staking balance read, not a price oracle. No primary/secondary/fallback oracle roles to map.

RD-F-053 green Oracle source = spot DEX pool (no TWAP) [★ CRITICAL — GREEN] No spot DEX pool oracle. OverseerV1 rebase(uint256 l1Balance) accepts HyperCore staking balance as a keeper-submitted parameter. No slot0(), getReserves(), or DEX pool call in contract ABIs. stHYPE is an LST — exchange rate based on shares math (balancePerShare()), not a DEX price. Confirmed: no oracle_feeds in data cache, no oracle interface in contract ABIs.

Economic risk Yellow 22 13 of 13

RD-F-063 yellow TVL (current + 30d trend) Current TVL ~$144–153M (DefiLlama sthype slug ~$145.7M; HTML render ~$144.54M; competitor-table cross-check ~$153M). 12-month peak ~$424–500M (DefiLlama time-series shows ~$424M peak; press coverage cites $500M). TVL is 100% single-asset (HYPE) and single-chain (Hyperliquid), amplifying concentration risk. TVL declined ~66% from peak; current level appears stabilized. Pipeline slug 'staked-hype' returns HTTP 400; slug 'sthype' returns data. HYPE price $43.06 (CoinGecko 2026-05-17). On-chain totalSupply not independently verified (hyperevmscan.io returns 403 on WebFetch). Yellow: TVL above $100M threshold but significant historical decline and single-asset concentration. RD-F-065 yellow Liquidity depth per major asset STEX AMM (Stake Exchange) provides secondary-market instant-unstake liquidity for stHYPE/wstHYPE at a fee. Native unstake queue is 7 days (HyperCore), making STEX AMM the primary rapid-exit mechanism. STEX AMM liquidity depth not quantifiable — Dune queries and hyperevmscan.io pool data inaccessible (403). Kinetiq (kHYPE) holds ~$846M TVL vs stHYPE ~$145M, indicating stHYPE is a minority liquidity venue in the HYPE LST space. In a broad stress scenario with HYPE price decline, STEX liquidity may be insufficient for full TVL exit within short windows. Additionally, HIP-3/USDe modules have withdrawal windows of up to 90 days at low TVL thresholds. Yellow: structural exit-liquidity dependency with unverifiable depth. RD-F-064 gray TVL concentration (top-10 wallet share) On-chain holder concentration scan not possible. HyperEVM explorer (hyperevmscan.io) returns HTTP 403 on WebFetch for token holder data. Community codes doc states '25% of all stHYPE has a validator selected' but this describes validator delegation coverage, not depositor-wallet concentration. No alternative on-chain scan path available for HyperCore-native accounts. RD-F-066 n/a Utilization rate (lending protocols) stHYPE is a Liquid Staking Token (LST), not a lending protocol. No borrow/supply markets, no utilization rate applicable. Lending-specific factor per PD-024. RD-F-067 n/a Historical bad-debt events stHYPE is an LST, not a lending protocol. No debt socialization, no bad-debt events applicable. Lending-specific factor per PD-024. RD-F-068 n/a Collateralization under stress stHYPE is an LST, not a lending or CDP protocol. No collateralization ratio applicable. Lending-specific factor per PD-024. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) NOT APPLICABLE. stHYPE is a Hyperliquid-native LST (Liquid Staking Token) operated by Valantis Labs on HyperEVM/HyperCore. It is not a Compound V2 fork and does not implement cToken-style money-market share accounting with totalSupply/totalBorrow per market. The empty-market donation-exploit vector has no structural analogue in this LST architecture. Taxonomy Cat 4 PD-024 note explicitly states: 'Compound-fork-only (subset of lending-only): RD-F-070 — N/A for non-Compound-fork protocols.' stHYPE profile §5 confirms: not forked from any EVM protocol; original implementation. RD-F-071 n/a Seed-deposit requirement for new market listing stHYPE is an LST, not a lending protocol. No market listing mechanism. Lending-specific factor per PD-024. RD-F-072 n/a Market-listing governance threshold stHYPE is an LST, not a lending protocol. No market listing governance threshold applicable. Lending-specific factor per PD-024. RD-F-073 n/a Oracle-manipulation-proof borrow cap stHYPE is an LST, not a lending protocol. No borrow cap applicable. Lending-specific factor per PD-024. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) wstHYPE is a non-rebasing share-valued wrapper of rebasing stHYPE. Docs describe it as reading share balances from the stHYPE contract with admin transfer rights. No explicit statement that wstHYPE implements ERC-4626 or uses an OZ >=4.9 virtual-share offset. SDK (sthype-sdk) has only viem ^2.0.0 as runtime dependency — no OpenZeppelin library dependency. Contracts source repo not confirmed public (ValantisLabs GitHub has SDK and audits repos but no confirmed Solidity contracts repo). hyperevmscan.io returns 403 on WebFetch blocking on-chain inspection of wstHYPE proxy 0x94e8396e0869c9F2200760aF0621aFd240E1CF38. Audit PDFs (Pashov Oct/Nov 2025, Guardian Nov 2025/Jan 2026, Obsidian Apr 2026) not readable via WebFetch. Cannot confirm or deny virtual-share offset without contract source. RD-F-075 n/a First-depositor / share-inflation guard Same constraints as F074. wstHYPE uses a custom share accounting model (stHYPE balance-based). No documentation of seed-deposit, virtual-share offset, or floor-check guard against first-depositor inflation. 6 audit engagements (most recent Obsidian Apr 2026) cover the architecture but findings not accessible (PDF binary format on GitHub). Contract source not publicly confirmed. wstHYPE proxy 0x94e8396e0869c9F2200760aF0621aFd240E1CF38 on hyperevmscan.io inaccessible via WebFetch (403). First-depositor guard status unverifiable without contract source inspection. Note: multiple audit engagements make it less likely a critical share-inflation vulnerability was missed, but this inference cannot substitute for evidence.

RD-F-069 green Algorithmic / under-collateralized stablecoin stHYPE is not an algorithmic or under-collateralized stablecoin. 1 stHYPE pegs to ~1 HYPE at mint; rebase accrues staking rewards upward. wstHYPE exchange rate to HYPE increases monotonically as rewards accrue. Mechanism is fully collateralized (1:1 backing with staked HYPE plus rewards). No stablecoin de-peg history identified. No de-peg events between stHYPE and HYPE found in profile §10 or web search. No under-collateralization design.

Operational history Green 4 15 of 15

RD-F-084 yellow TVL stability (CoV over 90d) TVL declined significantly from ~$500M peak (shortly after Feb 2025 HyperEVM launch) to ~$144M current — approximately -71% decline over protocol lifetime. The 30-day trend is unavailable (DefiLlama API slug 'staked-hype' returns null per pipeline defillama_blocked: true). Decline is attributable to HYPE token price correction and competitive pressure from kHYPE (~$769M). Recent trend appears to have stabilized around $140-145M in 2026 Q1-Q2 based on available data, but exact 90-day CoV is not computable. Yellow reflects TVL volatility and data gap, not an operational failure. RD-F-089 yellow Insurance coverage active No active insurance coverage found on Nexus Mutual, Sherlock, or Unslashed for stHYPE or Valantis LST contracts as of 2026-05-17. HyperEVM is not yet covered by mainstream DeFi insurance providers. Scored yellow rather than red: protocol has 6 security audits, 15 months clean record, and the absence reflects HyperEVM ecosystem immaturity rather than a protocol-specific decision to avoid coverage. The gap is real at ~$144M TVL.

RD-F-076 green Protocol age (days) stHYPE launched 2025-02-18 (HyperEVM mainnet day one). As of 2026-05-17: ~453 days live, exceeding the 365-day A-grade eligibility threshold. Protocol has operated through HYPE price cycles and a planned ownership transition (Thunderhead → Valantis, 2025-08-19) without operational interruption.

RD-F-077 green Prior exploit count 0 protocol-contract exploits in 15 months of operation. Hacksdatabase grep ('sthype', 'staked-hype', 'valantis', 'thunderhead') returned no matches. Rekt pipeline: incidents: []. Purrlend exploit (April 2026, ~$1.52M) involved wstHYPE as stolen collateral — this is a Purrlend contract vulnerability, not a stHYPE protocol vulnerability (U22 disambiguation). JELLY/HLP episode (March 2025) affected Hyperliquid exchange, not stHYPE contracts.

RD-F-078 green Chronic-exploit flag (≥3 incidents) 0 prior exploits; chronic flag (>=3 incidents) does not apply. Derived from RD-F-077.

RD-F-079 green Same-root-cause repeat exploit 0 prior exploits; same-root-cause repeat flag does not apply. Derived from RD-F-077.

RD-F-080 green Days since last exploit No prior exploit on record. 453 days of clean operation as of 2026-05-17. Factor renders as never-exploited; green by construction.

RD-F-081 green Post-exploit response score Vacuously green — no incidents to score. Protocol has not been exploited in 15 months of operation. The Valantis docs reference an incident-response commitment but no actual response has been triggered or tested.

RD-F-082 green Post-mortem published within 30 days Vacuously green — no incidents; no post-mortem needed or published. 0 exploits in 15 months of operation.

RD-F-083 green Auditor re-engaged after last exploit Vacuously green — no incidents triggered re-audit requirement. Post-acquisition audit cadence is strongly positive: 5 new engagements in 9 months (Pashov Oct + Nov 2025; Guardian Nov 2025 + Jan 2026; Obsidian Apr 2026) without any incident trigger. This represents proactive re-audit posture.

RD-F-085 green Incident response time (minutes) Vacuously green — no incidents; response time not applicable. 0 exploits in 15 months.

RD-F-086 green Pause activations (trailing 12 months) No pause activations identified in trailing 12 months on HyperEVM layer. PAUSER_ROLE held by 4/6 Safe; max pause duration configured at 7 days. No on-chain evidence of pause events. Structural limitation: HyperCore layer (actual HYPE custody) is non-EVM-inspectable; pause monitoring for HyperCore stake accounts is structurally limited. EVM layer contracts show no pause activation.

RD-F-087 green Pause > 7 consecutive days No pause activation of any duration in last 12 months. Maximum configured pause duration is 7 days (structural cap). No pause > 7 consecutive days structurally possible under current configuration. No pause events observed on EVM layer.

RD-F-088 green Re-deployed to new addresses in last year No contract address redeployment in last 12 months. Core contract addresses (stHYPE 0xfFaa4a3D97..., OverseerV1 0xB96f073..., wstHYPE 0x94e8396..., Safe 0x97dEe0eA4...) unchanged from launch through 2026-05-17. April 2026 upgrade implemented implementation changes via proxy pattern — no new top-level addresses. Thunderhead → Valantis acquisition transferred ownership of same contracts; no address migration.

RD-F-166 green Deprecated contracts still holding value No deprecated contracts identified. April 2026 upgrade removed setSelfDisableTransfer() functionality via in-place proxy upgrade — no address deprecation. No Thunderhead-era legacy contract addresses deprecated-and-abandoned. Acquisition transferred same live contracts. No protocol announcement of deprecated contract addresses found in docs or on-chain.

Real-time signals Gray 0 22 of 22

Dev identity & insider risk Green 6 16 of 16

RD-F-121 yellow Contributor OSINT depth score Named individuals: Addison Spiegel (~3/5: LinkedIn since 2021, personal website, MIT HTMAA, Thunderhead blog, RootData), Deven Matthews (~3/5: LinkedIn prior employer, Crunchbase, The Block citation), Eduardo Carvalho (~3/5: LinkedIn + educational credentials, Crunchbase, gen.xyz). All three have verifiable multi-platform OSINT trails. However, the 6 Safe multisig signers are pseudonymous with no public attribution found; they hold a 4-of-6 threshold over all admin operations. The effective OSINT depth of the on-chain key-holders is lower than the named leadership, creating a governance-key-holder gap. Overall depth is moderate — green for named leadership, near-zero for multisig signers. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion Two April 2026 admin-side changes: (1) April 7 — multisig signer rotation 3/5 → 4/6 (two signers deprecated, three new added) recorded in roles-and-controls-registry with transaction hashes; (2) April 10 — proxy upgrades with '48-hour timelock' + removal of setSelfDisableTransfer from DEFAULT_ADMIN_ROLE. ValantisLabs X tweet (status/1983210512310804719) is a public upgrade announcement: 'No action is needed by any user/protocol for this upgrade... Details on expansion via Modular CoreWriter can be found in last week's announcement:' — confirming a public pre-announcement existed on X before execution. However: no GitHub issue/PR or governance forum thread found for either change (no forum exists for this protocol). Per §7-rule-5 framing: multisig-only protocol with no DAO/forum means Twitter + docs-registry is the expected communication venue. Yellow (not red) because: public X pre-announcement present; roles-and-controls-registry documents changes with tx hashes; April 10 change was a RD-F-116 n/a Contributor tenure at admin-permissioned PR Only public GitHub repo is ValantisLabs/sthype-sdk (TypeScript SDK, 3 commits all 2025-04-16 by tomheather-50). No Solidity contracts source repo is publicly identified (foundry_toml_present: false per cache). Admin-permissioned code changes are executed on-chain by the Safe multisig, not via GitHub PRs. The April 2026 proxy upgrade was an on-chain transaction — no corresponding GitHub PR or commit. Contributor tenure at time of admin-permissioned change cannot be evaluated from available OSINT. RD-F-117 n/a ENS/NameStone identity bound to deployer HyperEVM does not have an ENS registry or NameStone equivalent. The deployer address 0x20e97805... and all Safe signer addresses operate exclusively on HyperEVM (not Ethereum mainnet). ENS is an Ethereum-mainnet concept; there is no analogous on-chain naming system for HyperEVM that would allow binding a verifiable identity to a deployer address. Per non_evm_substrate: true in coverage_flags. RD-F-120 gray Video-off/voice-consistency flag No video-off or voice inconsistency flags identified in public OSINT. Addison Spiegel has a substantive public personal website. Deven Matthews and Eduardo Carvalho have LinkedIn profiles with employment history. This is a manual-observation factor (M-only) requiring curator observation of interviews, conference appearances, or AMA recordings. No concerns identified at OSINT tier but definitive scoring requires curator review of video/audio appearances. RD-F-122 n/a Contributor paid to DPRK-cluster wallet Off-chain payroll for Thunderhead and Valantis Labs employees; no on-chain payment streams to contributor wallets were identified. The factor requires tracing contributor payment wallets to within 3 hops of DPRK-labeled cluster addresses. No HR/payroll wallet streams are observable at OSINT tier for either entity. Per process-learnings.md F122 guidance: cannot be meaningfully assessed at OSINT tier for companies with off-chain payroll beyond the deployer address (which was separately assessed under RD-F-124/125). RD-F-184 gray Real-capital social-engineering persona Curator-level OSINT factor (M-only, P1). No on-chain evidence of a 'team contributor' or 'external integrator' persona accumulating ≥$1M real capital in stHYPE/wstHYPE or peer protocols as a credibility-building social-engineering exercise. The Drift Apr 2026 reference pattern (UNC4736, 6-month conference/in-person build-up + real capital deployment before durable-nonce pre-signing exploit) was not found in stHYPE-adjacent threat intel. By definition this attack pattern leaves limited public trace. Cannot confirm or rule out at OSINT tier. Scored GRAY per process-learnings.md F184 guidance: mark gray + note Drift comparator.

RD-F-111 green Team doxx status Both teams publicly identified by real name with multi-platform corroboration. Thunderhead: Addison Spiegel (founder) — real name, MIT affiliation, personal website (addison.is), LinkedIn, MIT HTMAA 2024 page. Valantis Labs: Deven Matthews (CEO, ex-Nethermind CSO) + Eduardo Carvalho (CTO, ex-Nethermind DeFi engineering director) — both have LinkedIn profiles with prior employer histories, Crunchbase, cited in The Block/CoinDesk acquisition coverage. Thunderhead team of ~6 total; Safe signers 2–6 not individually attributed (pseudonymous). Classification: real-name / consistent-pseudonym-with-track-record for named individuals; pseudonym-no-track-record for unnamed Safe signers.

RD-F-112 green Team public accountability surface Deven Matthews: LinkedIn with prior employment (Nethermind CSO), Crunchbase, cited in The Block and DL News. Eduardo Carvalho: LinkedIn (Imperial College London, Univ Lisbon, Nethermind Director), Crunchbase, educational credentials corroborated independently. Addison Spiegel: addison.is, MIT HTMAA 2024 page, LinkedIn, blog.thunderhead.xyz (author page), RootData. Valantis raised $7.5M with institutional investors (Cyber Fund, Kraken, SevenX) providing investor-accountability surface. GitHub committer `tomheather-50` (tom@thunderhead.xyz) corroborates a named team member. Three named individuals with multi-platform verifiable public trails.

RD-F-113 green Team other-protocol involvement history Addison Spiegel: prior work on Pocket Network liquid staking (leanPOKT core-client, -95% cost reduction); Thunderhead operated ~2021–2025, peaked $90–400M AUM, profitable since inception with no external funding — no documented rug or exit scam. Deven Matthews: Nethermind CSO 2021–2023, Valantis Labs 2023–present. Eduardo Carvalho: Nethermind DeFi protocol engineering director, Valantis Labs CTO. Valantis DEX product line (Valantis Core, HOT AMM, STEX, Validly) has 6+ third-party audits, no documented rug or exploit attributable to team conduct. No negative protocol history found for any named individual via REKT database search or web OSINT.

RD-F-114 green Deployer address prior on-chain history Deployer `0x20e97805af96ec2adeb7b2f0cea61b1414d5328c` labeled 'stakedhype: Deployer' on hyperevmscan.io. 257 total transactions all related to stHYPE operations (staking/delegation to OverseerV1). No on-chain history predating 2025-02-18 (HyperEVM launch day). Profile: normal-dev-history with clean label from the explorer. No linked-to-prior-rug pattern identified. Deployment tx hash 0x5779aea508e36ad7a6d240cddfa85fbb97341cd6974ccca0f71849f2929bbe44 confirmed as stHYPE contract creation.

RD-F-115 green Prior rug/exit-scam affiliation Web searches for 'Thunderhead Addison Spiegel rug exit scam' and 'Valantis Labs Deven Matthews Eduardo Carvalho rug hack incident' returned no relevant results. Thunderhead's profile (profitable since inception, no external funding, $90–400M AUM peak) is inconsistent with typical rug-deployer characteristics. Valantis Labs received institutional investment from SevenX, Cyber Fund, Kraken — these investors conduct due diligence that provides additional screening. REKT database confirmed empty for stHYPE/Thunderhead/Valantis per pipeline data cache.

RD-F-118 green Handle reuse across failed/rugged projects @ValantisLabs (X), @stakedhype (X), and blog.thunderhead.xyz were not previously associated with any failed or rugged project under different aliases. Thunderhead's prior Pocket Network work (leanPOKT) was a legitimate open-source core-client contribution. ValantisLabs Twitter branding has been consistent since company formation in 2023. No handle-reuse pattern identified across web searches targeting both teams.

RD-F-119 green Commit timezone consistent with stated geography tomheather-50 (tom@thunderhead.xyz) commits show timestamps +0100 (BST) and +0000 (UTC) on 2025-04-16 at 10:37–12:15 UTC — consistent with UK/Western Europe working hours. No off-hours DPRK-implant-style commit pattern. Sample is limited (only 3 commits public). Addison Spiegel previously based in Houston TX; both Valantis co-founders have European educational credentials (Imperial College London, Univ Lisbon) consistent with a UK/European timezone. Commit geography is plausibly consistent with stated team context.

RD-F-124 green Deployer wallet mixer-funded within 30 days Deployer 0x20e97805af96ec2adeb7b2f0cea61b1414d5328c was funded by Hyperliquid: System Address (0x2222222222222222222222222222222222222222) on 2025-02-18 (HyperEVM launch day), tx 0xa1458c354dde79ca82da1bc73efebb6fb3a9cd32b9746a305308ee66baa7e1b5. The Hyperliquid System Address is the HyperEVM native protocol bridge/distribution infrastructure — not Tornado Cash, Railgun, or any equivalent privacy mixer. This funding pattern is structurally equivalent to a new-chain genesis allocation, not a rug-precursor mixer-funded wallet. No mixer interaction found at any timeframe on the deployer address.

RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus Deployer 1-hop neighbor is Hyperliquid System Address (0x2222...2222), a Hyperliquid protocol-level infrastructure contract — no OFAC SDN list hit, no Chainalysis/public Lazarus cluster label. Web search for 'Thunderhead stHYPE DPRK Lazarus North Korea' returned zero relevant results. Web search for 'Valantis Labs Deven Matthews Eduardo Carvalho DPRK rug hack' returned zero relevant results. The Bybit Feb 2025 and Kelp DAO Apr 2026 Lazarus incidents used Hyperliquid ecosystem as a settlement venue — per U4 rule, these are NOT team identity contamination events. Safe signers 2–6 not individually traced (HyperEVM Safe API gap), but no affirmative DPRK evidence exists to elevate to yellow or red.

Fork / dependency lineage Gray 0 10 of 10

RD-F-126 n/a Is-a-fork-of Original implementation — no upstream fork. stHYPE is the first HyperEVM-native LST, developed from scratch by Thunderhead and acquired by Valantis Labs in August 2025. No documented fork of any prior EVM protocol codebase. RD-F-127 n/a Upstream patch not merged No upstream fork — factor is not applicable. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream fork — factor is not applicable. RD-F-129 n/a Code divergence from upstream (%) No upstream fork — code divergence factor is not applicable. RD-F-130 n/a Fork depth (generations from original audit) No upstream fork — fork depth factor is not applicable. Original implementation at depth 0. RD-F-131 n/a Fork retains upstream audit coverage No upstream fork — upstream audit coverage retention factor is not applicable. Protocol has its own independent audit history (6 engagements). RD-F-132 n/a Fork has different economic parameters than upstream No upstream fork — divergent economic parameters factor is not applicable. RD-F-133 gray Dependency manifest uses unpinned versions No public Solidity contracts repository found for stHYPE. The sthype-sdk repo is TypeScript only; no foundry.toml is available for the stHYPE contracts. Cannot assess dependency version pinning. RD-F-134 gray Dependency had malicious-release incident (last 90d) No public Solidity contracts repo or dependency manifest available. Cannot inspect for malicious-release events in last 90 days. OZ upgradeable contracts (inferred in use) have had no such events. RD-F-135 gray Shared-library version with known-vuln status OZ upgradeable contracts (AccessControlDefaultAdminRulesUpgradeable, VotesUpgradeable, ERC20Upgradeable) inferred in use from source snippets but exact OZ version not determinable — no foundry.toml or package.json with version pinning found. Cache oz_contracts_version: null. solc 0.8.28 known-vuln addressed under Cat 12.

Post-deploy hygiene & change mgmt Yellow 36 13 of 13

RD-F-138 red Hot-patch deploys without timelock (last 30 days) April 9 2026 stHYPE upgrade (within last 30 days) executed without any TimelockController. Safe.execTransaction directly triggered Upgraded event with no timelock contract in the call chain. AccessControl delay = 0 confirms no enforced delay. All upgrades in protocol history follow this pattern. RD-F-143 red Reinitializable implementation (no _disableInitializers) stHYPE implementation (0xe71cAF5c) uses OZ Initializable with initialize(address gov_, address overseer, address wrapper). _disableInitializers() NOT confirmed present in constructor from source code inspection. OverseerV1 impl (0xaC43e7a1) and wstHYPE impl (0x104324863cfb) similarly use initialize() with no _disableInitializers() confirmed. Re-initialization of implementation contracts is possible if called directly. [CRITICAL — curator verification of source code constructor recommended] RD-F-137 yellow Upgrade frequency (per 90 days) Approximately 2 upgrades across core contracts in trailing 90 days: stHYPE proxy upgrade April 9 2026; OverseerV1 upgrade Feb 19 2026. Each has a corresponding audit (Obsidian Apr 2026; Guardian Jan 2026). Elevated cadence but audit-covered. RD-F-139 yellow Post-audit code changes without re-audit April 2026 upgrade covered by Obsidian April 2026 audit — best alignment. July 2025 and OverseerV1 upgrades have proximate but not commit-level-confirmed audits. 6 audits in 15 months represents high audit frequency. No-timelock posture means code can be deployed without delay post-audit, but no evidence of unaudited changes found. Yellow due to unverifiable commit-level alignment. RD-F-142 yellow Storage-layout collision risk across upgrades Three upgrades of stHYPE proxy and three of OverseerV1 occurred. TransparentUpgradeableProxy (EIP-1967) is inherently storage-safe (impl slot separate from data). No public OZ upgrades-plugin storage-layout diff report found. Obsidian April 2026 audit likely covered storage layout but PDF content not confirmable. RD-F-145 yellow Deployed bytecode reproducibility Source verified on hyperevmscan.io with 'Exact Match' for all core contracts. However, no public Solidity contracts repo confirmed — independent build reproducibility requires access to the private build environment. Explorer verification confirms bytecode-to-source fidelity but not third-party reproducibility. RD-F-146 yellow New contract deploys in last 30 days stHYPE implementation 0xe71cAF5c deployed and activated April 9 2026 (within 30 days of assessment date 2026-05-17). New attack surface from this implementation. Covered by Obsidian Apr 2026 audit. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant No protocol-level rate-limiter on stHYPE deposit/withdrawal outflow. PAUSER_ROLE (held by Safe) can pause but is manual action. Hyperliquid's HyperCore L1 has a chain-level validator halt capability as an upstream structural control, but this is not owned or controllable by Valantis and is not an stHYPE-specific mitigant. No bridge surface means bridge rate-limiter dimension is N/A. RD-F-136 gray Deployed bytecode matches signed release tag No public Solidity contracts repository confirmed for ValantisLabs (github.com/ValantisLabs has sthype-sdk TypeScript and audits PDFs only). No signed release-tag SHA confirmable for deployed implementation bytecodes. Cannot verify bytecode-to-commit match. RD-F-140 gray Fix-merged-but-not-deployed gap No public Solidity contracts repository; cannot compare deployed bytecode to any open PR or branch. No public CVE or security advisory identifies a known unfixed vulnerability. Cannot assess without curator access to private source.

RD-F-141 green Test-mode parameters in deploy No test-mode parameters identified. AccessControl delay = 0 is the documented production state (not a test artifact — explicitly described as current deployment configuration). PAUSER_ROLE and MINTER_ROLE held by production admin Safe.

RD-F-144 green CREATE2 factory permits same-address redeploy No CREATE2 factory usage identified. All proxies and implementations deployed via standard CREATE. No selfdestruct+redeploy pattern observed.

RD-F-168 green Stale-approval exposure on deprecated router No deprecated router or protocol contracts with material value identified. Prior implementations are inactive and hold no TVL. Proxy addresses unchanged across upgrades — no stale user approvals to deprecated routing contracts. stHYPE LST does not use router-pattern contracts that users approve to directly.

Cross-chain & bridge Gray 0 12 of 12

Threat intelligence & recon Yellow 33 8 of 8

RD-F-161 yellow Protocol-impersonator domain registered (typosquat) Protocol-impersonator domain registered (typosquat) signal. stakedhype.fi registered 2024-10-09 by Thunderhead Interests LLC (the legitimate original creator) — confirmed NOT impersonation; 585 days before assessment date, outside the 90-day window. No novel typosquat domain (stakedhype.com, valantis-hype.xyz, sthype-stake.fi, etc.) confirmed as registered within the 90-day window preceding 2026-05-17. Yellow: no confirmed typosquat exists but no formal brand-protection or typosquat monitoring program has been identified for valantis.xyz or stHYPE at ~$144M TVL. The monitoring gap itself is a yellow finding. RD-F-163 yellow Avg attacker reconnaissance time for peer-class protocols Attacker wallet reconnaissance time before strike (analytical/contextual factor). No prior exploits against stHYPE contracts. For peer-class LST protocols on Hyperliquid, the Drift Protocol April 2026 DPRK exploit (adjacent Hyperliquid ecosystem, $285M) and JELLY/HLP episode (March 2025, Hyperliquid L1) confirm that DPRK/sophisticated actors target Hyperliquid-adjacent protocols. HyperCore opacity limits visibility of reconnaissance at the stake-account level. No stHYPE-specific reconnaissance detected but ecosystem context elevates the prior probability. Yellow: elevated ecosystem reconnaissance risk without stHYPE-specific confirmation. RD-F-158 gray Known-threat-actor cluster has touched protocol Known-threat-actor wallet cluster touches protocol (T-09 v1, phase 2, tier C). Applicable on HyperEVM surface. No DPRK/Lazarus-labeled wallet interaction with stHYPE HyperEVM contracts found in public OSINT. Web searches for Valantis/stHYPE + Lazarus/DPRK returned no hits. Drift Protocol April 2026 DPRK exploit and Hyperliquid JELLY/HLP episode are ecosystem events that do not implicate stHYPE team addresses (U22 disambiguation applied). Requires Chainalysis/TRM cluster feed on HyperEVM not available at assessment time. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) Mempool probe from attacker wallet signal. Applicable on HyperEVM. No low-gas failing transactions to stHYPE contracts from threat-actor-labeled wallets detected. Requires mempool monitor + cluster feed not implemented. T-09 v2/deferred signal. RD-F-160 gray GitHub malicious-dependency incident touching protocol deps GitHub malicious-dependency incident signal. ValantisLabs sthype-sdk (TypeScript, public) is observable; Solidity contracts repo not found as public. No security advisory or malicious release in sthype-sdk npm dependencies detected. SDK last commit 2025-04-16; no recent npm advisory flagged. Requires GitHub advisory feed subscription. RD-F-162 gray Known-exploit-template selector deployed by any address Known-exploit-template selector-pattern deployed signal. No prior stHYPE exploits means no protocol-specific known-exploit template in the database. Purrlend exploit (April 2026) involved wstHYPE as stolen collateral but used Purrlend's own contracts — not an stHYPE-targeting exploit template. T-09 v2/deferred signal. RD-F-164 gray Leaked credential on paste/sentry site Leaked credential on paste/sentry site signal. No credential dump or paste-site leak for valantis.xyz or stakedhype.fi found in public OSINT. Requires specialized TI feed monitoring not available in current pipeline. Manual curator TI feed required. RD-F-165 gray Protocol social channel has scam-coordinator flag Telegram/Discord scam-coordinator flag signal. ValantisLabs has active Discord (discord.com/invite/9cUzQ7EgJQ). No flagged scam-coordinator in Discord identified via public OSINT. Manual M-curation factor requiring curator watchlist access.

Tooling / compiler / AI Green 11 5 of 5

RD-F-170 yellow Solc version used (known-bug versions flagged) All three core contracts compiled with v0.8.28+commit.7893614a (EVM version: prague). Solidity 0.8.28 is affected by the TransientStorageClearingHelperCollision bug (HIGH severity, affects 0.8.28–0.8.33, fixed in 0.8.34). Exploitation requires ALL THREE: viaIR enabled + delete on transient storage variable + matching persistent storage clear in same unit. hyperevmscan.io compiler settings do not show viaIR enabled; no evidence of transient storage usage found. Bug is also flagged by second known issue LostStorageArrayWriteOnSlotOverflow (LOW). Effective risk likely low given missing prerequisites, but compiler version IS on the known-bug list for a high-severity vulnerability. RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Original implementation — no upstream audited codebase to compare against for bytecode similarity or behavior deviation. Factor is not applicable. RD-F-172 gray Repo shows AI-tool co-authorship in critical files No public Solidity contracts repository found for stHYPE. The only public ValantisLabs repo with commits is sthype-sdk (TypeScript), last commit 2025-04-16. No AI co-author disclosure tags found in SDK commits. Cannot assess for the smart contracts themselves.

RD-F-173 green Team self-disclosure of AI-generated Solidity No public statements from Valantis Labs or Thunderhead disclosing AI-generated Solidity in security-critical paths. Valantis X posts (@ValantisLabs) focus on product features and acquisition; no AI tooling disclosure found. Absence of self-disclosure + no secondary source = green per factor definition.

RD-F-174 green Dependency tree uses EOL Solidity version solc 0.8.28 is not EOL. It is in the supported 0.8.x branch. The TransientStorageClearingHelperCollision fix is in 0.8.34, but 0.8.28–0.8.33 are not classified as end-of-life by the Solidity maintainers. EOL would require a major version end-of-support declaration.

Response & disclosure hygiene Red 50 4 of 4

RD-F-175 red Disclosure channel exists No public security disclosure channel for stHYPE LST core contracts. Transparency-and-risks page explicitly states: 'stHYPE currently does not run an active public bug bounty program.' No security@ email, no security.txt, no Immunefi program (pipeline bug_bounty.platform: null). Remedy 'valantis-stex' program covers STEX AMM peripheral contracts (stHYPEWithdrawalModule, STEXAMM) — NOT the stHYPE LST core (stHYPE ERC-20, OverseerV1, wstHYPE). Hyperliquid L1 bug bounty (hyperliquid.gitbook.io) is not a Valantis/stHYPE program. Legacy docs.stakedhype.fi/technical/security 301-redirects to general overview with no security contact. At ~$144M TVL, the absence of any LST-core disclosure mechanism is a genuine hygiene gap. RD-F-176 red Disclosure SLA public No acknowledgment-time SLA published. No disclosure channel exists for stHYPE LST core (per F175 red). Without a disclosure channel, an SLA is structurally absent. No SLA text found in docs, security pages, or any SIRT communications.

RD-F-177 green Prior known-ignored disclosure Vacuously green — no prior incidents on record; no post-mortems exist; no evidence of any disclosed-but-ignored vulnerability. 0 exploits in 15 months. Does not offset red findings on F175/F176.

RD-F-178 green CVE/GHSA advisory issued against protocol No CVE or GHSA advisory found against stHYPE, wstHYPE, OverseerV1, or ValantisLabs stHYPE-specific codebase. GitHub org shows no public security advisories. Note: stHYPE contracts source repo not confirmed public (SDK only is public), which limits automated GHSA coverage, but no advisory has been published.

rubric_version v1.7.0 graded_at 2026-05-17 13:02:40 factors 184 protocol staked-hype