Kintsu
Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.
Kintsu issues sMON on Monad and sHYPE on Hyperliquid, with each receipt redeemable only through staking contracts and native unbonding on its respective chain. Both observed settlement perimeters are outside the approved-chain set, so the version-1 rejected-chain dossier is dispositive regardless of the approximately $2.03M observed across Monad and Hyperliquid L1 on 2026-08-15.
- The relevant Monad or Hyperliquid L1 chain verdict changes, or an economically separate Kintsu product deploys on an approved chain
- The reopened product supplies realized validator concentration, authority, slashing, audit, incident and proposed-size primary and secondary exit evidence
The research file
Mechanism and chain applicability
Kintsu pools native gas tokens and issues chain-specific liquid-staking receipts: sMON for MON and sHYPE for HYPE. Its Monad StakedMonad contract delegates pooled MON among registered validators, while the Hyperliquid StakedHype contract batches HYPE through the CoreWriter precompile into HyperCore staking. Both products therefore depend directly on their native settlement chains and meet the shared v1 rejected-chain dossier.
Current observation and perimeter
The DefiLlama protocol API read on 2026-08-15 classified Kintsu as Liquid Staking and reported approximately $2.03M: about $1.99M on Monad and $0.05M on Hyperliquid L1. The registry now includes both current perimeters rather than the stale Monad-only scope. Kintsu’s current documentation publishes separate Monad and Hyperliquid architectures and redemption workflows, supporting an active two-product record.
Control, slashing and exit applicability
Kintsu governance maintains validator target weights and contracts batch delegation and unbonding. Receipt holders inherit validator performance and slashing, contract and governance authority, native cooldown and batch timing. Hyperliquid exits additionally require unbonded HYPE to move from HyperCore back to the HyperEVM vault; Monad redemption depends on nodes returning unbonded MON. Secondary DEX liquidity does not remove those settlement dependencies.
Why the class rule decides
Every observed sMON and sHYPE mint, stake accounting and protocol redemption settles on Monad or Hyperliquid L1. The shared v1 rejected-chain dossier therefore controls before validator diversification, audit or size. Reopen only if the relevant chain verdict changes or an economically separate Kintsu product deploys on an approved chain, then test validators, realized concentration, authorities, slashing, audits, incidents and proposed-size exits.
Sources
The claims above trace to these. Where a number could not be independently verified, the thesis says so.
- Kintsu — protocol and chain-specific receipts · primary · accessed 2026-08-15
Supports: liquid staking, sMON, Monad, validator delegation, redemption - Kintsu — Monad staking architecture · primary · accessed 2026-08-15
Supports: StakedMonad, sMON, validator registry, target weights, redemption - Kintsu — Hyperliquid staking and unbonding · primary · accessed 2026-08-15
Supports: sHYPE, HyperCore, HyperEVM, CoreWriter, cooldown, batch redemption - Kintsu — staking and unstaking user lifecycle · primary · accessed 2026-08-15
Supports: MON and HYPE, receipt tokens, native cooldown, secondary liquidity, redemption - DefiLlama — Kintsu survey record · secondary · accessed 2026-08-15
Supports: current TVL, Monad, Hyperliquid L1, Liquid Staking category
Inherited controls
The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.
| Chain | Verdict | Grade | Control constraint |
|---|---|---|---|
| Hyperliquid / HyperEVM | Rejected | freezable | a 21-validator permissioned set operates both the chain and its bridge — one compromise reaches both. |
| Monad | Approved · limits | crypto-backed | the L1 has a public validator path, but its short production record, single initial client lineage, and Foundation-directed delegation keep stake and operations concentrated. |