Skip to content

Slither Analysis Scope & Methodology

Status: methodology only — not a completed audit report. This page does not publish an executed analysis result, a security rating, or an assurance that the deployed contracts are safe.

Overview

Slither is a static analysis framework for Solidity developed by Trail of Bits. It detects vulnerabilities, code quality issues, and provides optimization suggestions.

Proposed V2 Scope

The following V2 components are the starting scope for a source-matched analysis. Confirm the exact source commit and deployed implementations before running it. An analysis of GHO Saving must also include its strategy and conversion route; reviewing the shared V2 vault alone does not cover that integration. GHO Staking V3 is outside this page's scope.

Contract Network Description
KingsVaultV2.sol Ethereum Synchronous ERC-4626 vault
KingsVaultV2Async.sol Ethereum Async redeem vault (escrow-based)
Controller.sol Ethereum UUPS-upgradeable coordinator (NAV settlement, strategy registry, fee minting)
AaveV3Strategy.sol Ethereum Aave V3 lending strategy adapter
ERC4626Strategy.sol Ethereum Generic ERC-4626 strategy adapter (e.g. Morpho)
HyperStrategy.sol Ethereum CCTP V2 cross-chain strategy (Ethereum-side endpoint)
HyperCoreAllocator.sol HyperEVM CCTP V2 receiver; internal share accounting
HyperCoreRouter.sol HyperEVM HyperCore 4-stage asset pipeline

Review Categories

Select detectors supported by the pinned Slither version and supplement them with manual review. These categories are review questions, not findings or assigned severities.

Area Checks to perform
Reentrancy and external calls Trace token/strategy callbacks and state transitions across withdrawal requests, executeRedeem, claims, and emergency redemption. Do not assume every accounting function transfers USDC or that an Ether-transfer detector covers ERC-20 behavior.
Token movement Verify transfer return handling, approvals, caller/source authorization, and allowed recipients.
Arithmetic Check dual-pricing comparisons, precision, rounding, fee calculations, and zero-value cases.
Initialization and upgrades Verify initialization protection, UUPS authorization, implementation locking, and storage compatibility. The effective upgrade role must be confirmed against the selected deployment; the prior Admin/Developer descriptions are not a verified role mapping.
Configuration and observability Check required non-zero inputs, role administration, parameter changes, and emitted events.

Review Checklist

Configuration and Governance

  • Compiler configuration: Record and reproduce the exact compiler version and build settings.
  • Events: Verify that material administrative changes can be observed and monitored.
  • Privileged keys: Document actual Admin, Guardian, Keeper, and upgrade authority for the deployed V2 components, including any multisig or timelock protections. Do not assume those protections are deployed.

Areas of Focus

  1. Dual-pricing and rounding: Check the MAX/MIN price comparison separately from rounding. For ERC-4626 conversions, deposit rounds issued shares down, mint rounds required assets up, withdraw rounds required shares up, and redeem rounds returned assets down. Verify these directions against the ERC-4626 security considerations and the exact implementation.
  2. Access control completeness: Verify authorization on each administrative path and Investor gating on V2 user operations against the deployed role model.
  3. CCTP message validation: Verify transmitter-only authorization on receive callbacks, source-domain/sender validation, and attestation/replay handling. Check Keeper authorization separately on relay entry points such as completeDivest; do not describe a Keeper relay as a transmitter-only callback.
  4. State consistency in executeRedeem: _pendingRedeemShares, _claimableShares, _claimableAssets, and _execId must be updated atomically to prevent double-claim or skipped-batch scenarios.
  5. Processing asset tracking: _processingAssets in HyperStrategy must be decremented correctly by _updateRemoteState() — verify no underflow paths.

Running

Illustrative command only; confirm paths and configuration against the selected source repository before execution:

slither src/ --config-file slither.config.json

Evidence Required for a Published Result

An actual result must include the analysis date, source commit, compiler/build settings, tool version and command, exact scope and exclusions, raw output, triaged findings with rationale, remediation commits, and retest status. It must distinguish source-level analysis from verification of deployed bytecode and configuration. Until that evidence is published, this page must not be cited as a completed audit or a clean bill of health.