HyperLeaf Whitepaper

A liquidity layer for productive assets on HyperEVM

Abstract

Crypto assets increasingly represent productive positions rather than static balances. Staking receipts accrue rewards. Vault shares encode claims on managed strategies. Vote-escrow positions control long-duration capital. Farm locks can carry substantial economic value while remaining difficult to transfer or use.

Yet most of the liquidity stack is still organized around immediately transferable spot tokens.

HyperLeaf proposes a different approach: represent the economic form of productive positions as standardized HyperEVM assets called Leaf assets.

A Leaf asset is designed to preserve the essential properties of the underlying claim — principal, yield, lock state, and exit topology — while making the position transferable, tradable, and composable on HyperEVM.

The protocol does not attempt to erase source-level risk or guarantee a universal 1:1 peg. Instead, it provides an explicit taxonomy for different exit conditions and an accounting framework that prevents outstanding claims from exceeding recognized economically realizable backing.

The business model is designed around real yield: a target protocol fee of 1% on supported realized yield, rather than broad entry and exit tolls.

The first native product is hNEST. The architecture is designed to expand from native HyperEVM positions into cross-chain liquid receipts, long-duration closed claims, and queued withdrawal positions.

HyperLeaf is an AI-native liquidity protocol for productive assets: AI writes the code; the chain proves the economics.

1. The problem

Modern crypto has a growing class of assets whose value comes from being productive rather than merely transferable.

A user may own:

• a liquid staking receipt;
• a vault share;
• a vote-escrow position;
• a locked farm claim;
• a queued withdrawal ticket;
• or a reward-bearing receipt with value that changes over time.

These positions often fail to compose cleanly with trading networks.

The problem is not simply cross-chain messaging. A bridge can move a static token while completely ignoring the economic structure of the position it represents.

HyperLeaf treats that economic structure as part of the product.

2. The thesis

HyperLeaf’s thesis is:

Productive assets should not become useless merely because their underlying strategy is locked somewhere else.

And more sharply:

HyperLeaf does not make illiquid positions liquid by changing their underlying risk. It makes the ownership of that risk transferable.

Instead, the economic claim should become a transferable HyperEVM instrument.

The resulting Leaf asset gives the user a choice:

• hold the productive position;
• trade it for liquidity;
• use it in another protocol;
• supply it as collateral where supported;
• or follow the defined underlying exit process.

The protocol therefore targets capital efficiency, not merely asset transport.

3. Product architecture

The generic architecture is:

Source protocol / chain
        ↓
Canonical backing
        ↓
Verification + accounting
        ↓
Leaf asset on HyperEVM
        ↓
Market + integrations

There are two primary product families.

Native

The underlying position already lives on HyperEVM. HyperLeaf integrates with the source protocol directly and issues a native Leaf.

Cross-chain

The underlying position lives elsewhere. HyperLeaf uses source-side custody or locking and cross-chain messaging to represent the claim on HyperEVM.

LayerZero or another transport system is an infrastructure component. It is not the economic product.

4. Leaf asset taxonomy

HyperLeaf defines three primary exit topologies.

L — Liquid

The underlying is an immediately transferable receipt.

The Leaf can be burned and the same receipt can be returned.

C1 — Closed

The underlying position is long-duration, locked, or otherwise inappropriate for instant protocol redemption.

The Leaf is backed and transferable, but the primary exit is the secondary market.

C2 — Queued

The underlying protocol exposes a known withdrawal path with a finite delay.

The Leaf can be burned into a withdrawal ticket and claimed after the source-defined wait.

This taxonomy prevents the protocol from pretending that all assets are economically identical.

5. The core accounting invariant

The central safety rule is:

Outstanding Leaf claims
≤
Economically realizable underlying

A more complete representation is:

outstanding claims
≤
principal
+ explicitly recognized yield
− pending redemptions
− applicable fees

The protocol deliberately avoids using raw token balances as the sole proof of backing.

A balance may be:

• a donation;
• a reward balance;
• an intermediate custody amount;
• an asset with a different economic unit;
• or an asset subject to upstream restrictions.

Therefore every listing defines its own accounting source and invariant.

6. Authorization, accounting, and solvency

HyperLeaf separates three concepts that are frequently conflated in bridge designs.

Authorization

Did an approved actor or message authorize the action?

Accounting

What amount did the event economically create or move?

Solvency

Can the recognized claim actually be paid from the underlying system?

A valid message is not automatically economic truth.

This principle is especially important in cross-chain environments, where a message may be authentic while the source state is still economically wrong or compromised.

7. Yield model

HyperLeaf classifies yield into distinct economic categories.

Intrinsic yield

For rate-bearing positions, the underlying receipt may become worth more over time without changing the number of shares.

This value naturally remains inside the Leaf.

Side-token yield

Some positions receive separate reward tokens. Eligible surplus can be converted into WHYPE and distributed according to the listing’s reward design.

Locked reward entitlement

Some source protocols expose rewards that remain locked or internal. These are not automatically treated as liquid HYPE.

Market price

Secondary market price is independent from protocol accounting value.

The three should never be merged into one generic “APR.”

8. Protocol economics

HyperLeaf is designed to earn from real productive activity.

The target protocol fee is:

1% of real yield, not principal.

The system is not designed around large deposit or redemption taxes.

This model aligns the protocol with users because HyperLeaf earns more when productive positions generate more realized value.

The protocol does not depend on guaranteeing a market price or maintaining permanent treasury inventory.

9. Leaf Market

A major use case is the trading of claims that cannot be redeemed immediately.

A conventional model attempts to force every token toward a protocol-controlled peg.

HyperLeaf instead accepts that time has value.

If a claim has a long exit period, a market participant may rationally buy it below the accounting value in exchange for receiving immediate transferability.

Leaf Market therefore acts as core Protocol liquidity — an exit venue without turning HyperLeaf into the permanent counterparty.

HyperLeaf does not remove lock risk; it makes ownership of that risk transferable.

The protocol can remain neutral while market participants exchange time preference.

On HyperEVM, the hNEST↔NEST same-chain board is LIVE. Cross-chain Leaf markets remain subject to the same LIVE / CANARY / PLANNED discipline as other listings.

10. Composability

Leaf assets are intended to become useful outside HyperLeaf.

Potential integrations include:

• lending markets;
• liquidity pools;
• yield vaults;
• trading and margin systems;
• treasury management;
• structured products.

However, composability is not assumed to be automatic.

Some reward designs do not distribute cleanly through AMM or lending contracts. Therefore the protocol distinguishes between:

• a token being composable as an ERC-20;
• its underlying value being retained in the token;
• and its side rewards being distributable to a contract address.

This distinction is essential when designing future reward gauges.

11. hNEST as the first implementation

hNEST demonstrates the native product model.

Its economic path is:

NEST
  ↓
NestVault
  ↓
veNEST / HEV managed position
  ↓
hNEST

The hNEST thesis is not instant redemption.

It is that a user can gain a liquid HyperEVM representation of a long-duration NEST position.

The live hNEST token is transferable immediately. A ~8-day circulation delay applies only to deposits routed through the optional EpochHNestGate used by the public app.

The product keeps the secondary market — including Leaf Market — as the main liquidity rail while retaining a protocol-level backstop for manual or emergency redemption.

The integration also demonstrates a key HyperLeaf principle: upstream economic activity should not become new hNEST liability unless the accounting transition is verifiable.

12. Security model

HyperLeaf considers five major risk classes:

1. HyperLeaf smart-contract risk;
2. upstream protocol risk;
3. cross-chain transport risk;
4. liquidity risk;
5. operational key risk.

The system therefore uses:

• listing-specific caps;
• guardian pause controls;
• separated operational roles;
• explicit health states;
• source-specific accounting invariants;
• defined emergency behavior.

When an underlying system becomes suspicious, minting should stop before uncertainty is amplified into additional Leaf liabilities.

13. Liquidity philosophy

HyperLeaf does not define “liquid” as “the protocol promises to buy it.”

Liquidity is a property of the market.

The protocol provides the asset standard and the rails.

The market provides price discovery.

This creates healthier incentives for long-duration positions because liquidity can emerge without requiring HyperLeaf itself to warehouse all maturity risk.

14. Growth model

HyperLeaf expects network value to come from integrations rather than ticker count.

The flywheel is:

more productive assets
        ↓
more Leaf supply
        ↓
more useful integrations
        ↓
more demand for Leaf exposure
        ↓
more productive positions worth bringing to HyperEVM

Success should therefore be measured through:

• non-incentivized TVL;
• integrations;
• utilization;
• realized yield;
• fee revenue;
• market quality;
• and the reliability of accounting.

15. Roadmap principles

HyperLeaf expands by proof.

Each new listing must answer four questions:

1. What exactly is the backing?
2. What is the accounting unit?
3. What is the exit path?
4. What happens when the source system fails?

Only after those answers are precise should the implementation be deployed.

The roadmap therefore moves from simpler liquid receipts toward increasingly complex locked and cross-chain claims.

16. Conclusion

HyperLeaf is building a financial representation layer for productive crypto assets.

The goal is not to make every asset look like a stablecoin.

The goal is to make productive positions understandable and usable on HyperEVM without lying about their backing, yield, or exit constraints.

A Leaf asset is the result:

a transferable HyperEVM claim on productive value that would otherwise remain fragmented, locked, or difficult to compose.

The long-term opportunity is a HyperEVM where productive capital from many chains can become part of one composable liquidity layer.