Trust, Solvency & Risk
The core safety rule
HyperLeaf is designed around one invariant:
Outstanding Leaf claims must not exceed economically realizable backing recognized by the protocol.
This is stronger than checking a token balance.
A contract can hold tokens that are not economically equivalent to the claim it has issued.
Three checks
HyperLeaf separates three questions:
Authorization
Who is allowed to say that an event occurred?
Accounting
What quantity should the protocol recognize?
Solvency
Can the recognized claim actually be paid from the underlying system?
A valid cross-chain message can prove authorization without proving economic backing.
What can go wrong
Smart-contract risk
Bugs in HyperLeaf contracts or upstream integrations can affect minting, accounting, custody, or exit.
Upstream protocol risk
A Leaf inherits important assumptions from the protocol that creates the underlying yield-bearing position.
Cross-chain risk
Cross-chain listings depend on message delivery, verification infrastructure, source-chain availability, and destination-chain execution.
Liquidity risk
A backed Leaf may still trade at a discount if the market is thin.
Oracle / rate risk
Rate-bearing assets depend on the correctness of their source accounting or exchange-rate mechanism.
Operational risk
Routine weekly operations (harvesting, booking and distributing rewards) run from a separate keeper wallet. The keeper cannot withdraw user funds, change settings or upgrade contracts, but it does control when and how rewards are booked into each weekly epoch. Admin authority over the vault, deposit gate, staking adapter and Leaf Market sits with a single owner wallet, not a multisig (see Admin key).
Admin key: The vault, deposit gate, staking adapter and Leaf Market are controlled by a single wallet, not a multisig. That key can change settings and upgrade the deposit gate contract. If it were lost or compromised, user funds could be at risk.
No deposit cap: There is currently no limit on total deposits.
Failure policy
When an underlying system becomes suspicious, HyperLeaf prefers to stop minting before attempting to preserve a misleading peg.
The intended state model is:
| State | Mint | Redeem / exit |
|---|---|---|
| Normal | Yes | According to listing rules |
| Degraded | No | Continue only where safe and backed |
| Halted | No | Paused according to incident policy |
| Insolvent | No | No automatic 1:1 payout against disputed claims |
The principle is simple:
When backing becomes uncertain, stop amplifying the uncertainty.
What HyperLeaf does not promise
HyperLeaf does not guarantee:
- a 1:1 market price;
- a buyer at any time;
- instant redemption for every Leaf;
- uninterrupted source protocol availability;
- immunity from upstream governance or upgrade risk.
Those are deliberately not part of the protocol promise.
Transparency
Each listing should be understandable from four pieces of information:
- what the canonical backing is;
- how the Leaf supply is accounted for;
- how yield is generated and attributed;
- how the user can exit.
A listing should not ship merely because the adapter compiles.
The economic story must be auditable first.