Kinetiq
Non-custodial liquid staking protocol on Hyperliquid, enabling users to stake the native HYPE token and receive kHYPE (Kinetiq Staked HYPE), a yield-bearing ERC-20 redeemable for HYPE plus accrued validator rewards. kHYPE contracts run on HyperEVM (EVM-bytecode, hyperevmscan.io-inspectable); underlying staking delegated to HyperCore (Hyperliquid L1) validators via StakeHub, an autonomous validator scoring and delegation engine. Also operates Markets (kmHYPE leveraged-kHYPE), a Launch platform for institutional white-label LSTs (flowHYPE, HiHYPE, asxnHYPE, hylqHYPE), and the KNTQ governance token (launched 2025-11-27). Original protocol — not a fork. 8 security audits from Spearbit, Zenith, Pashov, Code4rena. $5M max bug bounty on Cantina. Seed: $1.75M from Maven 11, Pier Two, Flowdesk, Chorus Ventures, Susquehanna, IMC Trading (Oct 2025). Founders: 0xOmnia (CEO) and Justin Greenberg (CTO).
DeploymentsHyperliquid · —
01
Risk profile at a glance
1 red · 4 yellow · 7 green 02
Categories & evidence
184 factors · 13 categoriesCode & audits Green 12 25 of 25
RD-F-009 red Formal verification coverage No formal verification (Certora, Halmos, Kani) found for any Kinetiq contract. Code4rena README states 52% statement test coverage — not formal verification. No FV artifacts in Code4rena repo. RD-F-001 yellow Audit scope mismatch StakingManager (7 upgrades), OracleManager and StakingAccountant upgraded April 7 2026; most recent comprehensive audit (Spearbit June 2025) predates these implementations. No public audit covers current deployed bytecode for two of five core value-path contracts. RD-F-002 yellow Audit recency Most recent audit of kHYPE core contracts is Spearbit June 2025 (~348 days before assessment). Core contracts (StakingManager, StakingAccountant, OracleManager) not comprehensively re-audited post-April 2026 upgrades (~39 days unaudited at assessment). RD-F-003 yellow Resolved-without-proof findings Code4rena April 2025: 3 HIGHs (H-01/H-02/H-03 acknowledged/disputed) and 5 MEDIUMs (M-01 confirmed); no confirmed unresolved high-severity exploit path; acknowledged findings imply awareness without documented on-chain fix proof. RD-F-017 yellow Mixed-decimals math without explicit scaling StakingAccountant _getExchangeRatio() handles 8-to-18 decimal normalization for HYPE values. Code4rena H-03 (exchange ratio inflation via receive()) was acknowledged. Without static analysis of current post-April-2026 implementation this cannot be fully confirmed clean. RD-F-024 yellow Code complexity vs audit coverage 1332 nSLOC across 8 contracts. Test coverage 52% (below 80% ideal). Code4rena ran 9 days (April 7-16 2025) competitive format. Spearbit June 2025 full review. Multiple audit rounds partially compensate for sub-ideal coverage but complexity relative to audit depth is non-trivial. RD-F-010 gray Static-analyzer high-severity count No Slither/Mythril/Semgrep run possible against HyperEVM verified source from agent context. Code4rena 4naly3er report present but not parseable (binary PDF). No published static analysis severity classification for current deployed implementations. RD-F-021 n/a UUPS _authorizeUpgrade correctly permissioned Kinetiq uses TransparentUpgradeableProxy (EIP-1967) for all five core contracts — not UUPS. The _authorizeUpgrade gate factor applies only to UUPS implementations. Upgrade authority sits with ProxyAdmin (assessed in Cat 2).
RD-F-004 green Audit count 5 distinct audit engagements covering kHYPE core (Pashov March 2025, Zenith March 2025, Code4rena April 2025, Spearbit June 2025, Pashov November 2025 instant-unstake) plus 3 additional for kmHYPE and sKNTQ products.
RD-F-005 green Audit firm tier Spearbit (Tier-1) audited kHYPE LST core (June 2025), kmHYPE (November 2025), and sKNTQ (January 2026). Code4rena (Tier-2 competitive platform), Pashov and Zenith (Tier-2 boutiques) also engaged.
RD-F-006 green Audit-to-deploy gap Spearbit June 2025 audit to July 2025 deploy gap is approximately 20 days — well within the 60-day green threshold. Earlier Pashov/Zenith March 2025 gap bridged by Code4rena April and Spearbit June engagements.
RD-F-007 green Bug bounty presence & max payout Active Cantina bug bounty launched September 15 2025. Max payout: Critical $5M (largest on HyperEVM per Cantina blog). High $50K. Program live with 7 core contracts in scope including all kHYPE value-path contracts.
RD-F-008 green Ignored bounty disclosure No confirmed security incidents affecting Kinetiq own deployed contracts found. Rekt.news leaderboard absent. Data cache rekt.incidents empty. No evidence of reported-and-ignored disclosure prior to any exploit.
RD-F-011 green SELFDESTRUCT reachable from non-admin path No SELFDESTRUCT/selfdestruct opcode found in any inspected contract (KHYPE.sol, StakingManager.sol, ValidatorManager.sol, OracleManager.sol). Consistent with Cancun EVM (EIP-6780 changed SELFDESTRUCT semantics) and modern solc 0.8.26.
RD-F-012 green delegatecall with user-controlled target No user-controlled delegatecall target found. StakingManager uses standard value-transfer calls to fixed addresses. TransparentUpgradeableProxy delegatecall target (implementation) is controlled only by ProxyAdmin, not by users.
RD-F-013 green Arbitrary call with user-controlled target StakingManager uses payable(L1_HYPE_CONTRACT).call with fixed or msg.sender targets; OracleManager uses try IOracleAdapter(oracle).getPerformance(validator) with admin-controlled oracle address. No fully user-controlled call target found.
RD-F-014 green Reentrancy guard on external-calling functions StakingManager has nonReentrant on 8 functions (stake, queueWithdrawal, confirmWithdrawal, batchConfirmWithdrawals, processValidatorWithdrawals, processValidatorRedelegation, queueL1Operations, processL1Operations). ValidatorManager has nonReentrant on 4 functions.
RD-F-015 green ERC-777/1155/721 hook without reentrancy guard kHYPE is ERC-20 (not ERC-777/1155/721). No ERC-777 or callback-hook token integrations found. Protocol receives native HYPE (no ERC token hooks). No callback-hook reentrancy vector detected.
RD-F-016 green Divide-before-multiply pattern StakingAccountant uses Math.mulDiv() for safe arithmetic (multiplies before dividing). No raw division-before-multiplication in price calculation paths. Code4rena 19-LOW findings produced no divide-before-multiply finding.
RD-F-018 green Signed/unsigned arithmetic confusion Solidity 0.8.x overflow protection applies throughout. No signed/unsigned arithmetic confusion flagged in any audit finding. Core accounting (StakingAccountant, StakingManager) uses standard uint256 throughout.
RD-F-019 green ecrecover zero-address return unchecked No ecrecover call found in any inspected contract. KHYPE uses OZ ERC20PermitUpgradeable v5.1.0 which handles ecrecover internally with proper zero-address checking. No raw ecrecover usage detected.
RD-F-020 green EIP-712 domain separator missing chainId KHYPE inherits ERC20PermitUpgradeable which calls __ERC20Permit_init(name). OZ v5.1.0 EIP712Upgradeable includes chainId in domain separator by default. ChainId-aware domain separator confirmed.
RD-F-022 green Public initialize() without initializer modifier All five core implementation contracts confirmed: initialize() protected by OZ initializer modifier and constructors call _disableInitializers(). KHYPE, StakingManager, StakingAccountant, ValidatorManager, OracleManager all verified.
RD-F-023 green Constructor calls _disableInitializers() _disableInitializers() confirmed in all five implementation constructors: KHYPE, StakingManager, StakingAccountant, ValidatorManager, OracleManager. OZ pattern consistently applied across the entire core contract suite.
RD-F-183 green Bug bounty scope gap on highest-TVL contracts Cantina bug bounty (September 15 2025) explicitly in-scopes all 7 core kHYPE contracts: kHYPE, StakingManager, StakingAccountant, ValidatorManager, PauserRegistry, OracleManager, OracleAdapter. No scope gap on highest-TVL contracts. $5M Critical payout.
Governance & admin Yellow 36 24 of 24
RD-F-032 red Timelock duration on upgrades No timelock contract exists in Kinetiq's architecture. Upgrades execute via Safe execTransaction with no mandatory delay. The April 7 2026 upgrade went from proposal to execution in a single Safe tx with no queued-operation period. Data cache confirms timelock_address=null. RD-F-033 red Timelock on sensitive actions No sensitive actions are timelocked. Mint (via MINTER_ROLE reassignment), pause (PauserRegistry), rescue (TREASURY_ROLE), setOracle (MANAGER_ROLE on OracleManager), and upgrade (ProxyAdmin Safe) all execute immediately upon multisig authorization with no time-delay buffer. No OZ TimelockController or equivalent deployed. RD-F-041 red Rescue/emergencyWithdraw without timelock rescueToken() (TREASURY_ROLE) and executeEmergencyWithdrawal() (SENTINEL_ROLE) exist in StakingManager with no timelock. Both execute immediately upon role authorization. No OZ TimelockController anywhere in the protocol. TREASURY_ROLE and SENTINEL_ROLE holders are unidentified addresses. A compromised or malicious role-holder can drain funds in one transaction. RD-F-025 yellow Admin key custody type Admin custody type is multisig-only (no timelock). 4-of-7 Gnosis Safe controls ProxyAdmin for upgrades and holds DEFAULT_ADMIN_ROLE for AccessControl contracts. Classified as multisig-without-timelock. Green would require multisig+timelock. RD-F-026 yellow Upgrade multisig signer configuration (M/N) 4-of-7 Gnosis Safe. SafeSetup event decoded from creation tx: 7 owners, threshold=4. Owners: 0x99ed257a514d81A62C3195934d4e63A1c2C3946A, 0x1a4Fdf8aE9c82b979a0fED2b9665d1E22A4D71C0, 0xF0B3a9BfF7b733bbF6B9FDcA20cC954dE5E8Aa77, 0xFCADDD4395fbC10FB6FA024a427561C1841a0849, 0xDc1c4B5d08528a25A96ba036dDD6496FA2fb6947, 0x9bD23f6e1012D490FaEE8C81d3bad9D4e4F71624, 0x64cbeD11Afe88631b7B6C12D8B50E59E8E07f42e. Signer identities not publicly attested. 4-of-7 is below 5-of-N peer norm for $840M TVL. RD-F-028 yellow Low-threshold multisig vs TVL 4-of-7 multisig at $840M TVL. Peer norm for protocols >$500M TVL is ≥5-of-N. Threshold is one below norm. Signer identities not publicly attested — effective independence of 7 signers cannot be verified. Not red because 4-of-7 is a reasonable construction; yellow because below peer norm and signer opacity. RD-F-035 yellow Role separation: upgrade ≠ fee ≠ oracle Protocol design has distinct roles: upgrade (ProxyAdmin Safe), fee/treasury (TREASURY_ROLE on StakingManager), oracle config (MANAGER_ROLE on OracleManager). Design intent is role-separated. However, the DEFAULT_ADMIN_ROLE (Safe) can reassign all subordinate roles without timelock, meaning functional separation depends on Safe discipline. Actual role-holder addresses for MANAGER/TREASURY are unconfirmed. RD-F-042 yellow Admin has mint() with unlimited max mint() on kHYPE requires MINTER_ROLE, currently assigned to StakingManager contract (not a bare EOA). No supply cap exists on kHYPE. DEFAULT_ADMIN_ROLE (Safe) can reassign MINTER_ROLE to any address without timelock. If 4-of-7 Safe is compromised, MINTER_ROLE could be granted to an EOA enabling unlimited kHYPE minting. Not red because current mint path requires contract-based intermediary, not direct admin call. RD-F-047 yellow Governance token concentration (Gini) KNTQ total supply 1 billion. Distribution: 23.5% core contributors (3y vest/1y cliff), 10% Foundation, 7.5% investors, 25% airdrop, 30% protocol growth. Team+Foundation+investors = ~41% concentrated. Governance not yet live. Gini not computed (no on-chain holder subgraph available on HyperEVM). RD-F-029 gray Multisig signers co-hosted 7 signer addresses identified from SafeSetup event but not publicly attested to identities or infrastructure providers. Cannot confirm or deny co-hosting. OSINT on anonymous addresses without public attestation is not actionable. RD-F-030 gray Hot-wallet signer flag 7 signer addresses identified but not publicly linked to identities. Hot-wallet behavioral heuristic (nonce velocity, signing-time distribution) not applied due to signer anonymity. Cannot assess. RD-F-036 n/a Flash-loanable voting weight No on-chain Governor, no Snapshot space, no Aragon voting. KNTQ governance not yet live. Flash-loanable voting weight is inapplicable by construction for a protocol with no active on-chain governance. RD-F-037 n/a Quorum achievable via single-entity flash loan No on-chain governance. Quorum-via-flash-loan inapplicable. RD-F-038 n/a Proposal execution delay < 24h No on-chain governance. Proposal execution delay inapplicable. RD-F-039 n/a delegatecall/call in proposal execution without allowlist No on-chain governance executor contract. No Governor Bravo, OpenZeppelin Governor, or equivalent deployed. delegatecall/call in proposal execution is inapplicable by construction. RD-F-040 n/a Emergency-veto multisig present No on-chain governance means no proposal-veto mechanism is needed or applicable. PauserRegistry provides emergency pause over protocol operations, which serves a different function. RD-F-044 gray Admin wallet interacts with flagged addresses Safe signer addresses not publicly identified. Cannot assess mixer/OFAC interaction history without identity attribution. Deployer EOA shows no obvious mixer labels on HyperEVMScan but full on-chain cluster analysis not performed. RD-F-045 n/a Constructor args match governance proposal No governance proposals covering contract deployments (no on-chain governor, no Snapshot). Constructor args were established at deployment by the team without a governance proposal process — standard for a team-run protocol at this stage. RD-F-167 n/a Deprecated contract paused but pause reversible by live admin No deprecated contracts identified. Protocol is 10 months old with no documented contract deprecations. Factor inapplicable.
RD-F-027 green Single admin EOA Role held by 4-of-7 Gnosis Safe (0x18A82c968b992D28D4D812920eB7b4305306f8F1), not a single EOA. ProxyAdmin ownership transferred from deployer EOA to Safe on 2026-04-21. Deployer no longer holds admin authority on core contracts.
RD-F-031 green Signer rotation recency Safe deployed 307 days ago. No AddedOwner/RemovedOwner/ChangedThreshold events detected in 77-transaction history. Threshold appears static at 4-of-7 since inception. No threshold reduction observed.
RD-F-034 green Guardian/pause-keeper distinct from upgrader PauserRegistry (0xac03CABA51e17c86c921E1f6CBFBdC91F8BB2E6b) is a separate contract holding PAUSER_ROLE and PAUSE_ALL_ROLE, distinct from the ProxyAdmin Safe (upgrader). Guardian/pause-keeper role is architecturally separated from the upgrade authority.
RD-F-043 green Admin = deployer EOA after 7 days 4-of-7 Gnosis Safe was deployed 307 days ago (~2025-07-15). Deployer EOA transferred ProxyAdmin to Safe on 2026-04-21 (initially ProxyAdmin was not yet deployed at launch; Safe was in place from early deployment). Deployer does not retain admin control. Transfer well within the 7-day window relative to any re-audit baseline.
RD-F-046 green Contract unverified on Etherscan/Sourcify All core contracts verified on HyperEVMScan (Exact Match): kHYPE (0xfD739d4e...), StakingManager (0x393D0B87...), StakingAccountant (0x9209648E...), ValidatorManager (0x4b797A93...), OracleManager (0x192826e4...), PauserRegistry (0xac03CABA...). HyperEVMScan is the Etherscan-equivalent for HyperEVM.
Oracle & external dependencies Yellow 28 17 of 17
RD-F-051 red Fallback behavior on oracle failure No fallback oracle exists for any component. DefaultOracle has no secondary data source — if Operator stops submitting, stale metrics persist indefinitely. OracleManager's MAX_ORACLE_STALENESS filter skips stale adapter data but provides no substitute source. StakingAccountant exchange rate has no independent staleness guard or fallback. Protocol does not automatically pause on oracle silence; manual PauserRegistry activation required (SENTINEL_ROLE). DefaultOracle source confirms: 'No fallback exists. The contract provides getValidatorMetrics() returns stored data or zeros if a validator hasn't been updated. If the operator fails to update metrics within the MIN_UPDATE_INTERVAL, stale data remains accessible indefinitely with no alternative data source or circuit breaker.' RD-F-050 yellow Dependency graph (protocols depended upon) Existential non-redundant dependency on Hyperliquid L1 (HyperCore). StakingManager stakes HYPE to HyperCore validators via L1Write precompile (0x3333333333333333333333333333333333333333). If HyperCore halts, staking/unstaking and reward settlement all break with no fallback. No Aave/Uniswap/Curve dependency. LST-class yellow: standard for single-chain LSTs but elevated by Hyperliquid's ~2yr age, Foundation-controlled governance, and no slashing currently (future risk per FAQ). Also depends on Operator contract liveness (see F062). RD-F-052 yellow Breakage analysis per dependency Breakage analysis: (1) HyperCore L1 halts → StakingManager L1Write calls revert → no new stakes/unstakes; reward settlement stops; exchange rate freezes at last value. (2) Operator stops → validator performance scores go stale; StakeHub rebalancing stops; bad validators may hold delegations beyond intended period. (3) Malicious DefaultOracle adapter authorized → false performance scores elevate compromised validators → yield theft. (4) OracleManager fully paused → all performance updates halt; rate computation continues on stale inputs. Yellow because these are known risks acknowledged in docs/audits, not undisclosed. Primary source: Code4rena README audit scope + StakingManager.sol L1Write pattern. RD-F-056 yellow Single-pool oracle (no medianization) OracleManager is designed to aggregate from multiple authorized adapters (EnumerableSet of adapters) — medianization is architecturally supported. In practice, only one adapter (DefaultOracle at 0xefbcCc6E33DA1C1ef638cBc0F044968D0f590fED) is published in Kinetiq docs. Single-adapter operation in practice = no independent cross-oracle validation for validator performance scores. Factor is N/A for exchange rate (accounting-based) but yellow for the validator-scoring pipeline. RD-F-057 yellow Circuit breaker on price deviation No automated circuit breaker on exchange rate deviation. OracleManager applies maxPerformanceBound cap on validator performance score inputs but this is not a circuit breaker — it caps individual metric values at a configurable max (default 10,000 bps = 100%). PauserRegistry supports manual pause by SENTINEL_ROLE but no automated deviation-triggered halt. No auto-pause if exchange rate changes by X% in one update period. RD-F-058 yellow Max-deviation threshold (bps) maxPerformanceBound in OracleManager: configurable via setMaxPerformanceBound (OPERATOR_ROLE). Code4rena README notes 'set-performance-bound BOUND=10000' (10,000 basis points = 100%). This bounds validator performance score inputs, not the exchange rate output. No exchange rate deviation threshold or bps cap on kHYPE:HYPE movement per update. Yellow: deviation controls exist for performance scores but not for the critical exchange rate. RD-F-059 yellow Oracle staleness check present OracleManager implements MAX_ORACLE_STALENESS (3,600s / 1hr, adjustable by MANAGER_ROLE via setMaxOracleStaleness). Data from adapters older than this threshold is skipped with OracleDataStale event. Partial credit: staleness check exists for adapter data input layer. However: (a) applies to validator performance data, not to exchange rate freshness; (b) if all adapters are stale, generatePerformance silently skips — no revert, no protocol pause; (c) StakingAccountant has no independent staleness guard on the rate itself. Yellow: staleness check present but incomplete (no rate-level guard, no auto-pause on full staleness). RD-F-062 yellow External keeper/relayer not redundant Single Operator contract (0x23A4604cDFe8e9e2e9Cf7C10D7492B0F3f4B4038) serves as sole keeper: calls GeneratePerformance on OracleManager and CompleteReward on StakingManager daily. No documented redundant keeper, Gelato automation backup, or Chainlink Automation redundancy found in docs or source. 11,663 transactions indicates continuous operation historically, but single-point-of-failure design. If Operator key is compromised or the contract halts, validator performance updates and reward accrual stop with no alternative keeper. RD-F-054 n/a TWAP window duration No TWAP oracle used anywhere in Kinetiq kHYPE. Exchange rate is on-chain accounting; validator performance is operator-push. TWAP window concept does not apply. RD-F-055 n/a Oracle pool depth (USD) No DEX pool feeds the oracle. Exchange rate derives from staking balances, not pool liquidity. Pool depth is irrelevant. RD-F-060 n/a Chainlink aggregator min/max bound misconfig No Chainlink aggregator feed used. Data cache oracle_feeds: [] confirms absence. Source inspection found no Chainlink AggregatorV3Interface import or latestRoundData() call. RD-F-061 n/a LP token balanceOf used for pricing kHYPE exchange rate uses totalStaked + totalRewards() - totalClaimed - totalSlashing() — on-chain accounting variables, not LP token balanceOf. No donation-manipulation vector via direct transfer to pool. RD-F-181 n/a Permissionless-pool lending oracle Kinetiq is an LST protocol, not a lending/borrowing protocol. No permissionless pool listing exists. The kHYPE exchange rate mechanism has no borrow markets where permissionlessly-created fake token pools could be accepted as collateral. Data cache borrow.present: false confirms no lending market.
RD-F-048 green Oracle providers used Kinetiq uses a proprietary internal oracle pipeline only. No Chainlink, Pyth, Redstone, or UniswapV3 TWAP feed used. kHYPE exchange rate is computed from on-chain staking accounting in StakingAccountant. Validator performance metrics pushed by an authorized Operator to DefaultOracle/OracleManager. Data cache confirms oracle_feeds: [], oracle: null.
RD-F-049 green Oracle role per asset kHYPE exchange rate: primary role served by StakingAccountant on-chain accounting (no secondary). Validator performance: primary role served by DefaultOracle (operator-push, no secondary). HYPE/USD price: not used — redemption is always HYPE-for-kHYPE, no USD price oracle needed. No fallback oracle for any role.
RD-F-053 green Oracle source = spot DEX pool (no TWAP) [★ CRITICAL — GREEN] kHYPE exchange rate is computed as (totalStaked + rewardsAmount - totalClaimed - slashingAmount) * 1e18 / totalKHYPESupply in StakingAccountant._getExchangeRatio(). This is on-chain accounting from staking balances — no DEX spot price, no AMM price oracle, no LP token balanceOf. Validator performance scores are operator-pushed from L1 reads, not from any DEX. F053 does not fire.
RD-F-180 green Immutable oracle address [★ F180 COMPOSE-COUNTED — GREEN] Oracle adapters in OracleManager are admin-replaceable: authorizeOracleAdapter(address adapter) (MANAGER_ROLE) and deauthorizeOracle(address) (MANAGER_ROLE) allow adding/removing adapters without contract upgrade. DefaultOracle's OPERATOR_ROLE is revocable/regrantable by DEFAULT_ADMIN_ROLE via OpenZeppelin AccessControl — operator address not immutable. No 'immutable' keyword for oracle addresses found in source. F180 does not fire. NOTE: This is a ★ critical factor per PD-017 (compose-counted) — flagged for orchestrator T-14 post-launch promotion tracking.
Economic risk Yellow 33 13 of 13
RD-F-063 yellow TVL (current + 30d trend) TVL $839.9M current (DefiLlama, 2026-05-17). 30d change -11.3% (declining trend). 90d CoV 0.082 (stable within window, mean $833.8M). 12-month peak ~$2.65B (Sep 2025); current is 68% below peak but stabilised in $700M-$950M band over last 90 days. Yellow: TVL above $100M threshold but 30d trend is declining at -11.3% (approaching -20% red boundary). Single-asset (HYPE) underlying amplifies volatility sensitivity. RD-F-065 yellow Liquidity depth per major asset kHYPE secondary-market liquidity is thin. CoinMarketCap (2026-05-17): 24h trading volume $24,608, market cap $773.1M, Vol/Mkt Cap 0.003183%, Liq/Mkt Cap 1.04%. kHYPE price $44.20 vs HYPE ~$43.51 (1.6% premium — not a depeg). The 'swap via DEX' exit path offered by Kinetiq docs is not practically viable for holders with >~$50K positions during stress; actual exit for large positions requires the 8-9 day unstaking queue (1-day lock + 7-day queue per docs FAQ). Yellow: below 2%-of-TVL liquidity depth threshold, but protocol is functional via queue. Comparable to other young ecosystem LSTs. RD-F-064 gray TVL concentration (top-10 wallet share) Top-10 depositor wallet share not computable from available public sources. HyperEVM does not expose a public subgraph for staking deposit events; no Dune Analytics adapter for Hyperliquid L1 staking exists. Data cache coverage_flags.non_evm_substrate=true reflects this. Whale activity documented (>$40M HYPE repositioning at launch per crynet.io analysis) but individual depositor shares unquantifiable. Gray pending custom HyperEVM indexer. RD-F-066 n/a Utilization rate (lending protocols) Kinetiq is not a lending protocol. No borrow markets exist. Data cache borrow.present=false. PD-024 lending-specific N/A pattern applies. RD-F-067 n/a Historical bad-debt events Kinetiq is not a lending protocol. No collateralized borrow markets where bad debt can be socialized. LST rate reduction from slashing would uniformly reduce kHYPE redemption value but is not 'bad debt' in the lending sense. No historical bad-debt events found. PD-024 N/A applies. RD-F-068 n/a Collateralization under stress Not a lending/CDP protocol. No collateralization ratio to stress-test. PD-024 lending-specific N/A applies. RD-F-069 n/a Algorithmic / under-collateralized stablecoin kHYPE is not a stablecoin (algorithmic or otherwise). It is a yield-bearing LST token backed by staked HYPE. The StakingAccountant formula (totalHYPE/totalKHYPESupply) ensures the token is fully backed at all times. PD-024 stablecoin classification not applicable. RD-F-070 n/a Empty cToken-style market (zero supply/borrow) [CRITICAL FACTOR — not_applicable] Kinetiq is an original-design LST protocol, not a Compound V2 fork. Code4rena README explicitly states: 'No indication this protocol forks from another existing protocol.' No cToken-style market architecture exists. The StakingAccountant uses a rate-based accounting model (totalHYPE/totalKHYPESupply * 1e18), not a cToken share/borrow market. PD-024 Compound-fork-only N/A applies. The bootstrap guard (if totalKHYPESupply==0 return 1e18) is an LST rate initialization guard, not a cToken-market guard. RD-F-071 n/a Seed-deposit requirement for new market listing Kinetiq does not have a market-listing process with seed-deposit requirements. Single LST product (kHYPE) with institutional whitelabel deployments managed by the team. No permissionless market listing. PD-024 lending-specific N/A applies. RD-F-072 n/a Market-listing governance threshold No market-listing governance threshold applicable. Kinetiq does not operate a permissionless or threshold-governed market-listing system. Institutional LST deployments (flowHYPE, HiHYPE, etc.) are managed by the Kinetiq team under their Launch product, not via on-chain governance listing. PD-024 N/A. RD-F-073 n/a Oracle-manipulation-proof borrow cap No borrow caps applicable. Kinetiq has no borrow/lending functionality. The kHYPE exchange rate is set by internal StakingAccountant formula, not a DEX-TWAP oracle used for borrow pricing. PD-024 lending-specific N/A applies. RD-F-074 n/a ERC-4626 virtual-share offset (OZ ≥4.9) kHYPE is not an ERC-4626 vault. It is a custom LST ERC-20 token with exchange rate determined by StakingAccountant (totalHYPE/totalKHYPESupply * 1e18). No convertToShares/convertToAssets ERC-4626 interface. Process-learnings LST template: F074 N/A for non-ERC-4626 LSTs (liquid-collective precedent). ERC-4626 virtual-share offset pattern not applicable. RD-F-075 n/a First-depositor / share-inflation guard kHYPE is not an ERC-4626 vault — primary ERC-4626 first-depositor framing does not apply. On the custom StakingAccountant model: _getExchangeRatio() explicitly returns 1e18 (1:1 ratio) when totalKHYPESupply==0, preventing division-by-zero and establishing safe initialization. First depositor mints at 1:1 and cannot inflate the rate via donation — the rate is admin-controlled via Operator pushes (rewardsAmount, slashingAmount), not donation-manipulable. The share-inflation attack vector is structurally absent in this architecture. Process-learnings LST template (liquid-collective): F075 N/A for non-ERC-4626 LSTs. Not_applicable is the correct verdict.
Operational history Green 12 15 of 15
RD-F-089 red Insurance coverage active No active third-party smart contract coverage found. Nexus Mutual's 20+ new cover listings blog post (their most recent coverage expansion) does not include Kinetiq or any Hyperliquid-native protocol; Nexus Mutual noted Q1 2026 intent to support non-EVM protocols but has not listed Kinetiq. No Sherlock or Unslashed cover found. The Cantina bug bounty ($5M critical max) is a vulnerability discovery incentive — NOT user-fund insurance. $840M TVL with zero third-party cover is a structural red for this factor. RD-F-076 yellow Protocol age (days) StakingManager deploy block 7635341 on 2025-07-05; mainnet public open 2025-07-15. Age at 2026-05-17 = ~316 days from first deploy. Threshold: yellow = 90-364 days. Novel substrate (HyperEVM), $840M TVL — limited track record for this asset size. RD-F-081 n/a Post-exploit response score No incidents have occurred. Post-exploit response score is only meaningful when at least one incident exists. Zero incidents → not_applicable. RD-F-082 n/a Post-mortem published within 30 days No incidents have occurred. Post-mortem timeliness is only assessable when an incident exists. Zero incidents → not_applicable. RD-F-083 n/a Auditor re-engaged after last exploit No incidents have occurred. Auditor re-engagement after exploit is only assessable when an exploit exists. Zero incidents → not_applicable. RD-F-085 n/a Incident response time (minutes) No incidents have occurred. Incident response time (minutes to first statement) is only measurable when an incident exists. Zero incidents → not_applicable.
RD-F-077 green Prior exploit count Zero distinct incidents found. Searched: proprietary hacks database (0 matches for 'kinetiq' or 'khype' case-insensitive across all 23 batches), data cache rekt.incidents=[], DefiLlama hacks=[], web search for Kinetiq exploit/hack (no results). Hyperliquid JELLY/HLP March 2025 episode excluded: Kinetiq contracts were not deployed until July 2025 and that was a Hyperliquid-platform event, not a Kinetiq-contract incident.
RD-F-078 green Chronic-exploit flag (≥3 incidents) Derived from F077: 0 incidents, well below the 3-incident chronic threshold. Boolean: green = <3 incidents.
RD-F-079 green Same-root-cause repeat exploit Zero incidents means no root-cause clustering is possible. No repeat exploit of any root-cause class.
RD-F-080 green Days since last exploit No incidents; methodology states green = >365 days or no incidents. Zero incidents → green.
RD-F-084 green TVL stability (CoV over 90d) 90-day TVL CoV from data cache: 0.0817 (8.17%), mean $833.8M, std $68.2M, window 2026-02-18 to 2026-05-17, 90 samples. Threshold: green = CoV < 0.15. The 8.17% CoV indicates stable TVL. The 30-day decline (-11.3%) reflects HYPE token price, not protocol abandonment.
RD-F-086 green Pause activations (trailing 12 months) No pause events or emergency stop activations visible in StakingManager transaction history on hyperevmscan.io. The protocol has a PauserRegistry (0xac03CABA51e17c86c921E1f6CBFBdC91F8BB2E6b) with SENTINEL_ROLE for emergency pause. Zero deliberate pause activations in ~316 days of operation (trailing 12 months).
RD-F-087 green Pause > 7 consecutive days Derived from F086: zero pause activations found. Cannot have paused >7 consecutive days if no pause has occurred.
RD-F-088 green Re-deployed to new addresses in last year No full re-deployment to new contract addresses. All core proxy addresses (kHYPE 0xfD739d4e423301CE9385c1fb8850539D657C296D, StakingManager 0x393D0B87Ed38fc779FD9611144aE649BA6082109, etc.) are original July 2025 deploy addresses, still active. Proxy implementation upgrades (OracleManager and StakingAccountant upgraded April 2026) are in-place upgrades at the same proxy address — not re-deployments to a new address set.
RD-F-166 green Deprecated contracts still holding value Single-version protocol launched July 2025. No contract set announced as deprecated or sunset. Markets product (kmHYPE) and institutional deployments (flowHYPE, HiHYPE, asxnHYPE, hylqHYPE) are live parallel products — not deprecated versions. Data cache coverage_flags.has_legacy_v1 = false. No deprecated contract holds any value.
Real-time signals Green 17 22 of 22
RD-F-109 yellow Social-media impersonation scam spike Applicable: yes. Kinetiq is the #1 Hyperliquid LST at $840M TVL — a high-attention impersonation target. Observed in routine Google searches (2026-05-17): at minimum 5 active impersonating domains: kinietiq.io (letter transposition), kinietiq.co (same transposition, different TLD), kineitiq.cc (letter insertion, branding themselves 'Premier Liquid Staking | Hyperliquid Staking Solutions'), klnetiq.xyz (l substituted for first i, SAME TLD as official kinetiq.xyz), kinetiq-hyperliquid.com (descriptive append). Additionally kinetiqai.xyz appeared. Active Hyperliquid phishing landscape documented by OneKey (2026). No confirmed user-loss events attributed to Kinetiq-specific impersonation in public sources as of assessment date. Yellow (not red) because no confirmed active user-loss from Kinetiq-specific impersonation is documented; if confirmed user-losses emerge, upgrade to red. The concurrent existence of 5+ impersonator domains for the same $840M LST is a materially elevated impersonati RD-F-090 gray Mixer withdrawal → protocol interaction T-09 phase-2 signal (tier-C advisory). Applicable: yes — any protocol accepting deposits should monitor mixer-funded wallets. Detection requires licensed wallet-clustering feed (Chainalysis/TRM) plus HyperEVM on-chain interaction scan. No licensed feed available for this T-10 static assessment. Public-proxy observation: no publicly labeled mixer-withdrawal address found interacting with kHYPE or StakingManager on HyperEVMScan. Would not fire today given data availability. Threshold: wallet withdrew from Tornado/Railgun within 30 days AND interacted with protocol with >$100k value. RD-F-091 gray Partial-drain test transactions Post-v1 signal infrastructure. Applicable: yes. Definition: small-value drains prior to larger drain fitting known pre-strike pattern. No such pattern observed in publicly accessible HyperEVMScan transaction history for StakingManager or kHYPE contract. Signal requires automated pattern-matching against HyperEVM block data, not yet deployed. T-09 v2/deferred shortlist. RD-F-092 gray Unusual mempool pattern from deployer wallet Post-v1 signal infrastructure. Applicable: limited — deployer EOA 0xb05cb1a8 is no longer the admin (ProxyAdmin transferred to 4-of-7 Safe 2026-04-21). Operator contract 0x23A4604c generates 11,663+ automated txs; separating unusual from baseline requires configured monitoring. No unusual mempool pattern from deployer or Operator observed in publicly accessible data. RD-F-093 gray Abnormal gas-price willingness from attacker wallet Post-v1 signal infrastructure. Applicable: yes in principle. HyperEVM gas market baseline differs from Ethereum mainnet; the 5x EMA threshold must be calibrated for HyperEVM fee market. No attacker wallet identified to monitor. No abnormal gas-price willingness observed. RD-F-094 gray New contract with similar bytecode to exploit template Post-v1 signal infrastructure. Applicable: yes. Monitoring for exploit-template bytecode deployment on HyperEVM (chainId 999) feasible but requires HyperEVM-specific deployment scanner. No confirmed exploit-template deployment targeting Kinetiq contract patterns found via public searches. Protocol has no prior exploit from which a template would be derived. RD-F-095 gray Known-exploit function-selector replay Post-v1 signal infrastructure. Applicable: yes. No prior Kinetiq exploit exists from which a known selector replay template could be built. Would score green if assessed (no prior exploit template), but cannot grade without the pattern-match infrastructure and curated exploit-template database. RD-F-096 gray New ERC-20 approval to unverified contract from whale Post-v1 signal infrastructure. Applicable: yes — kHYPE is an ERC-20 token; approvals to unverified contracts are monitorable on HyperEVMScan. No active monitoring of this approval pattern for kHYPE holders deployed. Signal requires continuous ERC-20 Approval event monitoring on kHYPE contract. RD-F-097 gray Sybil surge of identical-pattern transactions Post-v1 signal infrastructure. Applicable: yes — StakingManager accepts deposits; sybil surge would appear as many new EOAs making identical small deposits in a short window. Not observed in publicly accessible StakingManager transaction history. Requires automated clustering detection. RD-F-099 gray Oracle price deviation >X% from secondary T-09 phase-2 signal. Applicable in principle: yes. Kinetiq uses a proprietary push-oracle (Operator→OracleManager→StakingAccountant) for the kHYPE/HYPE exchange rate — not a Chainlink/Pyth primary feed. No independent secondary feed exists for this rate. The T-09 standard detection rule (primary vs secondary feed comparison) cannot be applied as-is. A custom rule comparing the daily pushed rate against an independently computed NAV would be needed. Pipeline unimplemented. Data cache oracle_feeds: [] confirms no standard feed mapping. RD-F-100 n/a Flash loan >$10M targeting protocol tokens Kinetiq is a single-function LST with no Aave/Balancer/Uniswap flash-loan pool for kHYPE at scale. No protocol-controlled lending market or oracle that a flash-loan could manipulate via the T-09 attack pattern. No governance token voting that is flash-loanable (no on-chain governor). T-09 phase-2 signal in any case. Not applicable to this protocol architecture. Source: data cache borrow.present=false; profile §7 confirms no flash-loan venue for kHYPE; no on-chain governor contract. RD-F-101 n/a Large governance proposal queued No on-chain governor contract (governor_address=null in data cache; snapshot_space=null). Kinetiq governance is currently a 4-of-7 Safe with no proposal queue and no ProposalCreated events to monitor. KNTQ governance token launched November 2025 but formal on-chain governance mechanics not deployed as of 2026-05-17. Signal trigger condition cannot fire. Source: data cache governance.governor_address=null, snapshot_space=null; profile §6. RD-F-102 gray Admin/upgrade transaction in mempool T-09 phase-2 signal. Applicable: yes — 4-of-7 Safe 0x18A82c96 executes admin and upgrade transactions. Mempool monitoring of Safe execTransaction targeting Kinetiq proxy contracts is the correct signal configuration. Most recent Safe execTx was 2026-05-14 (routine $0.00 value execTransaction). No pending mempool upgrade tx observed via public sources. High-value signal for Kinetiq given the absence of a timelock — Safe upgrades are instantaneous once 4-of-7 approve; mempool is the ONLY pre-execution warning window. RD-F-103 n/a Bridge signer-set change proposed/executed kHYPE is single-chain Hyperliquid-native. No Kinetiq-operated bridge. layerzero.present=false in data cache. has_bridge_surface=false per profile §7. No bridge signer set to monitor. Source: data cache layerzero.present=false; profile §7. RD-F-104 n/a Stablecoin depeg >2% on shared-LP venue Kinetiq protocol does not hold stablecoin reserves or accept stablecoins as collateral. Protocol TVL is 100% Hyperliquid L1 HYPE staking. No stablecoin dependency meets the >5% TVL exposure threshold defined in T-09 §4.2 suppression rule. kHYPE being held as collateral in third-party protocols (e.g. Purrlend) represents downstream integration risk, not Kinetiq's own stablecoin dependency. Signal trigger condition does not apply. Source: data cache borrow.present=false; chains[0].name=Hyperliquid L1 TVL 100%. RD-F-105 gray DNS/CDN/frontend hash drift T-09 phase-2 signal. Applicable: yes — kinetiq.xyz is the production frontend. No DNS change or TLS cert change detected via manual check in this assessment. Elevated context: at least 5 active impersonating domains exist (see Cat 11 F161 red finding), making this signal particularly high-value for Kinetiq. External hash monitor not yet deployed. If the official frontend were compromised, user traffic might be redirected to one of the identified impersonator domains — RD-F-105 is the only on-chain-observable warning signal for this attack vector. RD-F-106 n/a Cross-chain bridge unverified mint pattern No Kinetiq-operated bridge. kHYPE is single-chain Hyperliquid-native. No cross-chain bridge tx pattern is possible for Kinetiq's own contracts. Source: profile §7; data cache layerzero.present=false. RD-F-107 gray Admin EOA signing from new geography/device Post-v1 signal infrastructure. Admin is a 4-of-7 Safe, not a single EOA — the individual-signer geography monitoring signal is less targeted. The 7 Safe signers' geographies are unknown; no off-chain signing telemetry is available. Signal requires MPC/session-key provider data or signing-time distribution analysis per signer address. RD-F-108 gray GitHub force-push to sensitive branch Post-v1 signal infrastructure. Applicable: yes in principle. Kinetiq GitHub org (github.com/kinetiq-research) has only 2 public repos (hl-rs, f1rewall); core contracts repo is private. GitHub API monitoring of a private repo requires protocol opt-in. No force-push or sensitive-branch push observed in public repos. RD-F-110 n/a Unusual pending/executed proposal ratio No on-chain governor contract. No proposal queue to monitor. Governance is a 4-of-7 Safe with no formal proposal-to-execution pipeline emitting ProposalCreated or ProposalQueued events. Source: data cache governance.governor_address=null; profile §6 confirms no on-chain governor deployed. RD-F-182 n/a Security-Council threshold reduction (RT) Batch-24 signal: Security-Council threshold reduction event (RT signal). Applicable context: the 4-of-7 Gnosis Safe is Kinetiq's admin (ProxyAdmin transferred 2026-04-21 per governance-admin-analyst). The F182 dual-trigger (threshold reduction AND timelock removal within ≤14 days) cannot fully fire for Kinetiq because there is NO timelock anywhere in the protocol — the timelock-removal component of the Drift pattern has nothing to remove. The threshold-reduction-only sub-condition is monitorable, but since there is already no timelock, the risk captured by F182's combined trigger (Drift pattern = threshold reduction PLUS timelock removal) is partially inapplicable. The Safe has executed 77 transactions with the most recent on 2026-05-14 — all routine execTransactions with near-zero HYPE value. No threshold reduction event observed. The absence of a timelock is already captured as a static red in Cat 2 (F032/F033). Scoring not_applicable because the defining dual-trigger condition of F1
RD-F-098 green TVL anomaly — % drop in <1h T-09 v1 launch signal, tier-A. TVL current: $839,855,333 (2026-05-17). 90d mean: $833,765,153; 90d CoV: 0.082 (8.2% volatility — stable relative to ATH of $2.65B). 1d change: +2.18%; 30d change: -11.3% (gradual HYPE-price-driven decline spread across 30 days, not a sudden hour-level event). Threshold: TVL_now/baseline_30d < 0.70 within 60-minute trailing window. The 30d -11.3% decline is market-driven and sector-correlated (HYPE price movement) — suppression rule (sector-wide correlation) would apply. No single-hour event approaching the 30% drop threshold observed in the 90-day data series. Signal would not fire today.
Dev identity & insider risk Green 15 16 of 16
RD-F-111 yellow Team doxx status Mixed doxx status. CTO Justin Greenberg uses real name (confirmed via GitHub commit SHA f1bd992 in code-423n4/2025-04-kinetiq and press release attribution). Founder 0xOmnia (Omnia.hl) operates under consistent pseudonym with 12+ month public track record including personal website, active X account, and podcast appearances, but no real-name binding found. Three additional LinkedIn-listed employees (Magnus Lai, Dalton Weeks, Angel Sanchez) not confirmed as core protocol contributors. Overall: consistent-pseudonym with partial named-CTO — between 'real-name' and 'pseudonym-no-track-record' tiers. RD-F-112 yellow Team public accountability surface 0xOmnia has @0xOmnia X (active 12+ months), personal website 0xomnia.com, podcast appearance on Seed Club 11AM (Aug 2025), YouTube interview (June 2025). Justin Greenberg has @greenbergz X, @justingreenberg GitHub, and multiple press release attributions. Neither has confirmed LinkedIn profile with employment history, conference talk recordings, or prior employer references. Approximately 2–3 verifiable public trails per named member — above anonymous but below institutional standard. RD-F-116 yellow Contributor tenure at admin-permissioned PR Core contracts repository is private (not publicly accessible on kinetiq-research GitHub). Code4rena audit repo (2025-04-kinetiq) shows justingreenberg contributed on Apr 7 2025 — approximately 3+ months into protocol development since late 2024 founding, which is within a reasonable early-contributor window. However, we cannot assess the most recent admin-permissioned code change in the private production repo. Scoring yellow due to inability to verify full contributor tenure for recent admin-permissioned changes. RD-F-121 yellow Contributor OSINT depth score OSINT depth scored approximately 2–3/5 for named team members. 0xOmnia: personal website, consistent X handle (12+ months), personal email, podcast appearances — pseudonymous with no LinkedIn or real-name confirmation, depth ~2/5. Justin Greenberg: named CTO, @greenbergz X, @justingreenberg GitHub (private activity), multiple press release attributions — no LinkedIn depth or prior employer confirmation, depth ~3/5. Below institutional due-diligence standard for a protocol holding $840M TVL. RD-F-123 yellow Sudden admin-rescue/ACL change without discussion ProxyAdmin ownership was transferred from deployer EOA to 4-of-7 Gnosis Safe (0x18A82c968b992D28D4D812920eB7b4305306f8F1) via tx 0x708e772d on 2026-04-21. This is a security improvement (EOA to multisig), not a covert deterioration. The April 2026 kHYPE v2 upgrade (KIP-2) was publicly announced on the @Kinetiq_xyz X account prior to execution. However, Kinetiq has no dedicated governance forum (no Snapshot space, no Tally governor, no dedicated forum) — there is no formal discussion thread with community pre-announcement. The KNTQ tokenomics announcement (October 2025) publicly stated 'multisig safeguards.' Assessed as disclosed-but-centralized: no covert insider-implant signal, but absence of formal governance forum means admin changes execute through team announcement only. Yellow, not red. RD-F-117 n/a ENS/NameStone identity bound to deployer Deployer EOA 0xb05cb1a8188110ac2cb062996526b43179162509 is HyperEVM-native (chainId 999). ENS (Ethereum Name Service) is an Ethereum L1 infrastructure. The deployer has no confirmed Ethereum L1 presence — it is a HyperEVM-native wallet. While the ENS app shows some interaction when queried with this address, the specific ENS name is not surfaced, and critically, an ENS name bound on Ethereum L1 resolves to an Ethereum L1 address which is a different address space from HyperEVM. This is not the hard TRON/Solana substrate-N/A case, but ENS identity binding genuinely does not apply to a HyperEVM-only deployer in the same way it applies to an Ethereum L1 deployer. Score: not_applicable with rationale. RD-F-119 gray Commit timezone consistent with stated geography Core contracts repository is private. kinetiq-research GitHub org lists Singapore as location but has no public members. Code4rena audit repo shows commits Apr 5–7 2025 but no timezone metadata is accessible in page content. Commit-time geography consistency analysis is not feasible without access to the private production repo commit history. RD-F-120 gray Video-off/voice-consistency flag 0xOmnia appeared in video/podcast interviews (Seed Club 11AM Aug 2025; YouTube 'Liquid Staking Unlocked' June 2025). Existence of video content confirmed via search result listings. Curator screening of interview content for video-off refusals or voice/timezone inconsistencies is required but not feasible via available tool access. No reports of such inconsistencies found in public commentary. RD-F-122 gray Contributor paid to DPRK-cluster wallet Team compensation appears to be off-chain (no on-chain payroll streams identified for named contributors). Deployer EOA funding trace 1–2 hops shows no DPRK cluster labels, but contributor wallet addresses are not publicly mapped. Per standard process-learning for F122: mark gray for protocols with off-chain payroll and no identifiable contributor payment streams. RD-F-184 gray Real-capital social-engineering persona No curator flag or public evidence of a real-capital social-engineering persona (Drift Protocol / UNC4736 comparator) involving Kinetiq team or external integrators. Kinetiq is 10 months old; seed investors are institutional (Maven 11, Chorus One, Flowdesk, SIG/Susquehanna, Pier Two, IMC) with verifiable track records, reducing the likelihood of an unvetted persona gaining deep access. Factor definition requires curator confidence above on-chain trail — not assessable at OSINT tier without positive evidence trigger. Marked gray per process-learnings guidance for F184.
RD-F-113 green Team other-protocol involvement history No prior protocol role found for 0xOmnia or Justin Greenberg via OSINT. Both are first publicly attributed to Kinetiq (founded late 2024). No rug, failed project, or conflict-of-interest link found via web search and X history review. Clean by OSINT evidence: no negative prior history, but also limited accountability from track-record absence.
RD-F-114 green Deployer address prior on-chain history Deployer EOA 0xb05cb1a8188110ac2cb062996526b43179162509 has 717 total transactions on HyperEVM, all within the Kinetiq protocol ecosystem. First transaction ~316 days ago (consistent with July 2025 Kinetiq launch). No pre-Kinetiq contract deployments detected on HyperEVM or Ethereum mainnet. HyperEVMScan label is 'Kinetiq: Deployer.' Normal dev history with no prior-rug linked deployments.
RD-F-115 green Prior rug/exit-scam affiliation No rug pull, exit-scam, or prior-fraud association found for 0xOmnia, Justin Greenberg, or any identified Kinetiq team member. Data cache shows no Rekt incidents. Web search for 'Kinetiq 0xOmnia rug scam exit' returned no positive result. Hacksdatabase grep returned no Kinetiq entry.
RD-F-118 green Handle reuse across failed/rugged projects No evidence found of @0xOmnia or @greenbergz being previously associated with rugged or failed projects under different aliases. Extensive OSINT search found no prior handle aliases associated with fraud or failure. Both handles appear as Kinetiq-first public identities.
RD-F-124 green Deployer wallet mixer-funded within 30 days Deployer EOA 0xb05cb1a8188110ac2cb062996526b43179162509 was funded approximately 316 days ago (aligned with July 2025 deploy) from 0xd0A8fc7f6e08691b39bea04ac01538d4c9eaaa91. That intermediate address shows KuCoin exchange interactions (KuCoin:Wallet label visible in HyperEVMScan), consistent with a personal/team trading wallet. HyperEVM is chainId 999 — Tornado Cash operates on Ethereum L1 and cannot directly fund a HyperEVM-native EOA. No mixer label detected at any confirmed hop within the 30-day pre-deploy window. Critical factor: GREEN.
RD-F-125 green Deployer linked within 3 hops to DPRK/Lazarus No OFAC SDN match found for deployer EOA 0xb05cb1a8188110ac2cb062996526b43179162509 or its 1-hop funding source 0xd0A8fc7f…. No Chainalysis, TRM Labs, or Elliptic public cluster label linking Kinetiq addresses to DPRK/Lazarus cluster found. The December 2024 Hyperliquid DPRK episode (DPRK-linked trading wallets on the Hyperliquid exchange) is a venue-use event by an external attacker — NOT a Kinetiq team or deployer nexus per the U4 disambiguation rule. No Kinetiq team member named in any DPRK attribution report. Critical factor: GREEN.
Fork / dependency lineage Green 11 10 of 10
RD-F-133 yellow Dependency manifest uses unpinned versions .gitmodules shows openzeppelin-contracts-upgradeable, openzeppelin-contracts, and forge-std without pinned commit SHAs. OZ v5.1.0 is in use (confirmed via HyperEVMScan metadata) but unpinned gitmodules allow resolution to a different commit on clean builds. RD-F-126 n/a Is-a-fork-of Kinetiq is an original protocol — not a fork of any upstream. Code4rena README explicitly states no fork lineage. Architecture is purpose-built for Hyperliquid EVM. RD-F-127 n/a Upstream patch not merged No upstream fork exists; upstream patch merge factor is structurally inapplicable. RD-F-128 n/a Upstream vulnerability disclosure (last 90d) No upstream fork exists; upstream vulnerability disclosure factor is structurally inapplicable. RD-F-129 n/a Code divergence from upstream (%) No upstream fork exists; code divergence percentage is undefined and inapplicable. RD-F-130 n/a Fork depth (generations from original audit) No fork lineage; fork depth is 0/undefined. Factor inapplicable. RD-F-131 n/a Fork retains upstream audit coverage No upstream exists; question of fork retaining upstream audit coverage is moot. RD-F-132 n/a Fork has different economic parameters than upstream No upstream exists; fork economic parameter comparison is inapplicable.
RD-F-134 green Dependency had malicious-release incident (last 90d) OZ v5.1.0 (openzeppelin/contracts + openzeppelin/contracts-upgradeable): no confirmed malicious release in trailing 90 days from 2026-05-17. No active GHSA advisory for the OZ 5.1.0 components in use.
RD-F-135 green Shared-library version with known-vuln status OZ 5.1.0 — no active high/critical advisories as of 2026-05-17. Known OZ vulnerabilities (Base64.encode fixed in 5.0.2+; Multicall duplicate in 4.9.4 only; Merkle multiproof pre-4.9.2) do not affect 5.1.0. No CVE/GHSA for OZ 5.1.0 found.
Post-deploy hygiene & change mgmt Yellow 30 13 of 13
RD-F-138 red Hot-patch deploys without timelock (last 30 days) The April 7 2026 upgrade of 5 contracts was executed via Safe execTransaction with no timelock route. This is a hot-patch pattern — the entire upgrade from signing to execution was a single Safe tx with no declared delay. No OZ TimelockController exists in the protocol. All upgrades in the last 30 days (the batch) bypassed a timelock by construction. RD-F-137 yellow Upgrade frequency (per 90 days) 5 upgrades in last 90 days (April 7 2026 batch of 5 contracts). Rate: ~1.7 upgrades/month for a $840M production LST. Elevated but not extreme; all via Safe with 4-of-7 approval. Prior upgrade was at launch (July 2025). RD-F-139 yellow Post-audit code changes without re-audit April 7 2026 batch upgrade deployed new implementations for 5 core contracts. Most recent kHYPE-core audit covering these contracts: Spearbit June 2025 (~10 months prior). November 2025 Pashov audit covered instant-unstake feature only. No audit found specifically covering the April 2026 implementation changes. Changes appear operational rather than architectural based on tx context, and Cantina bug bounty ($5M max) is running. Scored yellow not red based on (a) operational change context and (b) continuous bug bounty program. However, the deployed bytecode is unaudited relative to any recent audit engagement. RD-F-140 yellow Fix-merged-but-not-deployed gap Code4rena April 2025 findings: H-01 (buffer lock) disputed, H-02 (slashing order) disputed, H-03 (receive() auto-stake) acknowledged but not fully fixed, M-01 through M-05 mostly disputed/acknowledged. Some medium findings disputed without clear on-chain remediation evidence. No confirmed merged-but-undeployed critical fix gap found. RD-F-146 yellow New contract deploys in last 30 days Multiple new contract deployments in the last 30-42 days: ValidatorSanityChecker (9 days ago), SKNTQHarvestAdapter, DeployerAdapter — new attack surfaces expanding protocol footprint. Active deployment cadence indicates ongoing development. RD-F-185 yellow Bridge rate-limiter / chain-pause as positive mitigant PauserRegistry (0xac03CABA...) provides emergency pause for EVM contract operations — a positive mitigant. FAQ confirms 'Emergency pause functionality' as a security feature. However, no per-window outflow rate-limiter at protocol level ('None at the protocol level' per FAQ). Hyperliquid L1 chain-pause exists as a theoretical control but is not under Kinetiq's control — it is a platform-governance mechanism. Partial positive mitigant: protocol-level pause exists, but no rate-limiter and L1 pause is not protocol-controlled. RD-F-136 gray Deployed bytecode matches signed release tag No public contracts repository with signed release tags. kinetiq-research GitHub org has no contracts repo. Code4rena competition repo (audit base) may not match the April 2026 deployed implementations. Cannot confirm bytecode-to-commit match. RD-F-142 gray Storage-layout collision risk across upgrades OpenZeppelin transparent proxy upgrades used. April 2026 batch upgraded 5 contracts simultaneously. No OZ upgrades-plugin validation evidence found in public CI/CD or audit reports. Storage layout collision risk cannot be ruled out without seeing the implementation diffs. RD-F-145 gray Deployed bytecode reproducibility No public contracts repo with build artifacts or release tags. Code4rena repo is audit-time snapshot and may not match deployed implementations (especially post-April 2026 upgrades). Bytecode reproducibility cannot be confirmed. RD-F-168 n/a Stale-approval exposure on deprecated router No deprecated routers or contracts found. Protocol is 10 months old with no documented contract deprecations. Stale-approval risk inapplicable.
RD-F-141 green Test-mode parameters in deploy No test-mode parameters found in production deployment. Oracle intervals at production values (24h update interval, 1h staleness threshold). Admin is 4-of-7 Safe, not deployer EOA. No infinite allowances or test oracle addresses identified.
RD-F-143 green Reinitializable implementation (no _disableInitializers) All confirmed implementation contracts call _disableInitializers() in their constructors. KHYPE.sol: constructor calls _disableInitializers(). StakingManager.sol: constructor() { _disableInitializers(); }. OracleManager.sol: same pattern. StakingAccountant.sol: same pattern. Source confirmed via Code4rena audit repo raw files.
RD-F-144 green CREATE2 factory permits same-address redeploy No CREATE2 factory deployment pattern identified. Contracts deployed via standard deployer EOA with CREATE opcode. No CREATE2 factory references in Code4rena repo or deployer transaction history.
Cross-chain & bridge Gray 0 12 of 12
RD-F-147 n/a Protocol has bridge surface No Kinetiq-operated cross-chain bridge exists. kHYPE is single-chain Hyperliquid-native. Profile has_bridge_surface: false, is_a_bridge: false. Data cache layerzero.present: false, layerzero_bridge: false, cross_chain: false. Enso front-end routing is not a Kinetiq bridge contract. No LayerZero OApp, deBridge, Wormhole, CCIP, or equivalent endpoint found in docs, source, or hyperevmscan.io. RD-F-148 n/a Bridge validator count (M) No bridge exists. Cat 10 fully N/A — kHYPE is single-chain Hyperliquid-native with no Kinetiq-operated cross-chain bridge surface. RD-F-149 n/a Bridge validator threshold (k-of-M) No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-150 n/a Bridge validator co-hosting No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-151 n/a Bridge ecrecover checks result ≠ address(0) No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. F151 (ecrecover check) does not apply. RD-F-152 n/a Bridge binds message to srcChainId No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-153 n/a Bridge tracks nonce-consumed mapping No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-154 n/a Default bytes32(0) acceptable as valid root No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. F154 (bytes32(0) root) does not apply. RD-F-155 n/a Bridge validator-set rotation recency No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-156 n/a Bridge uses same key custody for >30% validators No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-157 n/a Bridge TVL per validator ratio No bridge exists. Cat 10 fully N/A — no Kinetiq-operated cross-chain bridge surface. RD-F-179 n/a LayerZero OFT DVN config (count, threshold, diversity) No LayerZero OFT adapter exists for Kinetiq. kHYPE is single-chain Hyperliquid-native. Data cache layerzero.present: false, layerzero_bridge: false. No DVN configuration to assess. F179 is not a LayerZero OApp. Cat 10 fully N/A.
Threat intelligence & recon Red 100 8 of 8
RD-F-161 red Protocol-impersonator domain registered (typosquat) RED. Threshold: a typosquat of the official domain registered within last 90 days. Finding: at minimum 5 simultaneously active impersonating domains found in standard Google searches (2026-05-17): (1) kinietiq.io — letter transposition (ki-nie-tiq vs ki-ne-tiq); (2) kinietiq.co — same transposition, different TLD; (3) kineitiq.cc — letter insertion, Google snippet 'Premier Liquid Staking | Hyperliquid Staking Solutions' — actively imitating Kinetiq's core product value prop; (4) klnetiq.xyz — l substituted for first i, SAME .xyz TLD as official kinetiq.xyz — highest deception potential; (5) kinetiq-hyperliquid.com — descriptive append impersonator. Additionally kinetiqai.xyz observed. Registration date of specific domains not confirmed without WHOIS API access, but active presence in search results contemporaneous with Kinetiq's high-attention period strongly implies recent registration. At least kinietiq.cc/kineitiq.cc and klnetiq.xyz present themselves as liquid staking protocol UIs. RD-F-158 gray Known-threat-actor cluster has touched protocol T-09 phase-2 signal (tier-C advisory). Applicable: yes. Requires curated threat-actor wallet cluster list plus on-chain interaction scan against Kinetiq's core contracts on HyperEVM. No licensed Chainalysis/TRM feed available for this T-10 static assessment. Public-proxy observation: no wallets in OFAC SDN list or publicly labeled as Lazarus/UNC4736 found interacting with Kinetiq contracts in publicly accessible HyperEVMScan data. Web searches for 'Kinetiq DPRK Lazarus' return no protocol-specific hits. Requires licensed feed for definitive assessment. RD-F-159 gray Attacker wallet pre-strike probe (low-gas failing txs) Post-v1 signal infrastructure. Applicable: yes. Requires curated threat-actor cluster list plus HyperEVM mempool monitoring for failing low-gas probe transactions. No failing probe-pattern transactions found in publicly accessible HyperEVMScan pages for core Kinetiq contracts (StakingManager, kHYPE, StakingAccountant, OracleManager). RD-F-160 gray GitHub malicious-dependency incident touching protocol deps Post-v1 signal infrastructure. Applicable: yes — Kinetiq uses OpenZeppelin contracts and Hyperliquid HyperEVM precompiles. No GitHub security advisory or npm/crates.io malicious-release incident found in public searches affecting Kinetiq dependencies in the trailing 90 days as of 2026-05-17. Core contracts repo is private — GitHub advisory monitoring not possible without opt-in. RD-F-162 gray Known-exploit-template selector deployed by any address Post-v1 signal infrastructure. Applicable: yes. Requires maintained exploit-template database and HyperEVM deploy-scan monitoring for Kinetiq function-selector patterns. No prior Kinetiq exploit exists from which a template would be derived. No evidence of exploit-template deployment targeting Kinetiq found via public searches. RD-F-163 gray Avg attacker reconnaissance time for peer-class protocols Analytic benchmark factor. Requires curator-maintained data on reconnaissance time distributions for peer-class LST protocols. The LST-class DPRK reconnaissance pattern (Drift Protocol = 6-month pre-strike social engineering) suggests 30–278 day reconnaissance windows. No Kinetiq-specific reconnaissance activity detected in publicly accessible HyperEVMScan data for core contracts. Score gray pending curator benchmark table for LST-class protocols. RD-F-164 gray Leaked credential on paste/sentry site Applicable: yes. Monitoring paste sites and Sentry-alt for Kinetiq infra endpoints and API keys is a manual curator function. No public paste-site leak for Kinetiq infrastructure found via web search as of 2026-05-17. Requires a dedicated paste-monitoring feed. Post-v1 signal infrastructure. RD-F-165 gray Protocol social channel has scam-coordinator flag Applicable: yes. Kinetiq has a Discord community (referenced via f1rewall Discord gateway app in GitHub org). Discord URL not confirmed in public sources as of 2026-05-17. No specific Discord scam-coordinator flag found. Requires curator social watchlist maintenance. Post-v1 signal infrastructure.
Tooling / compiler / AI Green 0 5 of 5
RD-F-171 n/a Bytecode similarity to audited upstream with behavior deviation Kinetiq is an original protocol with no audited upstream codebase to compare against. Bytecode similarity to audited-upstream factor requires a reference upstream; factor is structurally inapplicable.
RD-F-170 green Solc version used (known-bug versions flagged) All deployed contracts use solc v0.8.26+commit.8a97fa7a (confirmed via HyperEVMScan). Only low-severity LostStorageArrayWriteOnSlotOverflow affects 0.8.26. High-severity TransientStorageClearingHelperCollision bug affects 0.8.28-0.8.33 only — not applicable.
RD-F-172 green Repo shows AI-tool co-authorship in critical files No Co-authored-by: GitHub Copilot or ChatGPT Code Interpreter commit signatures found in 11 visible commits in Code4rena repo. Production org github.com/kinetiq-research contains only non-contract repos. No AI co-authorship trailer detected.
RD-F-173 green Team self-disclosure of AI-generated Solidity No public disclosure in Kinetiq docs, X/Twitter, blog, or audit materials indicating AI-generated Solidity in security-critical paths. Code4rena README makes no mention of AI tool usage. No self-disclosure found.
RD-F-174 green Dependency tree uses EOL Solidity version All deployed contracts use solc 0.8.26 — a supported non-EOL version (Solidity 0.8.x series actively maintained as of May 2026). OZ v5.1.0 is compatible with Solidity 0.8.20+. viaIR=true compile mode is supported for 0.8.26.
Response & disclosure hygiene Green 8 4 of 4
RD-F-176 yellow Disclosure SLA public Policy.txt states Kinetiq 'will investigate legitimate reports and make every effort to quickly resolve any vulnerability' — best-effort language with no specific acknowledgment-time SLA. Cantina bounty page states reports should be submitted 'as soon as possible — ideally within 24 hours of discovery' (researcher-side guidance, not an issuer acknowledgment SLA). No formal 'we acknowledge within X hours' commitment published. Yellow = SLA stated as best-effort but no specific timeframe.
RD-F-175 green Disclosure channel exists Multiple confirmed disclosure channels: (1) security@kinetiq.xyz published in PGP-signed security.txt (expires 2027-07-01); (2) Discord at https://discord.kinetiq.xyz as alternate; (3) PGP encryption key at https://kinetiq.xyz/.well-known/pubkey.asc; (4) Cantina bug bounty program live since 2025-09-15 with Critical: $5M / High: $50K / Medium: $5K / Low: $500 tiers; (5) policy.txt at /.well-known/policy.txt. This exceeds the baseline 'publishes a public security-disclosure channel' threshold.
RD-F-177 green Prior known-ignored disclosure No incidents have occurred (F077 = green, 0 incidents). No post-mortems exist to analyze for ignored disclosures. Web search for 'Kinetiq vulnerability disclosure ignored' returned no results. No evidence of any pre-exploit disclosure that was deferred or ignored.
RD-F-178 green CVE/GHSA advisory issued against protocol No CVE or GHSA advisory found against Kinetiq contracts. Web search for 'Kinetiq CVE GHSA advisory vulnerability 2025 2026' returned no relevant results. GitHub Advisory Database search returned nothing for Kinetiq. The protocol has 8 audits (Spearbit x3, Code4rena, Zenith x2, Pashov x2) but none resulted in a public CVE or GHSA advisory.
rubric_version v1.7.0 graded_at 2026-05-17 18:25:48 factors 184 protocol kinetiq