How HyperLeaf Works

HyperLeaf is organized around a simple pipeline:

Source asset / position
        ↓
 verified custody or lock
        ↓
  Leaf representation
        ↓
HyperEVM liquidity
        ↓
 trade / collateral / LP / integration

Step 1 — Identify the economic claim

Before a Leaf exists, HyperLeaf defines what the underlying claim actually is.

Examples include:

• a transferable staking receipt;
• a vault share;
• a locked farm position;
• a vote-escrow position;
• a queued withdrawal claim.

The first rule is that a token balance alone is not sufficient evidence of economic backing.

The system distinguishes authorization, accounting, and solvency:

authorized message
      ≠
accounting truth
      ≠
solvency proof

Step 2 — Lock or custody the canonical backing

The canonical backing is held or controlled by the relevant HyperLeaf contract or the native protocol integration.

Donations do not automatically create new Leaf supply.

A Leaf is minted against an explicitly defined backing relationship.

Step 3 — Mint the Leaf

Once the backing condition is satisfied, HyperLeaf issues the corresponding Leaf token on HyperEVM.

The Leaf has a fixed meaning for that listing.

For example:

1 hNEST
= one unit of the HyperLeaf hNEST claim

The exact accounting unit depends on the asset. For rate-bearing positions, the unit may be shares rather than raw token balance.

Step 4 — Make the claim useful

A Leaf can then be:

• held;
• transferred;
• traded;
• used in an integrated protocol;
• supplied as liquidity;
• used as collateral where a venue supports it.

HyperLeaf does not require every listing to have the same secondary behavior.

Step 5 — Exit according to the underlying topology

The exit path is a property of the listing.

L — Liquid

The underlying is a transferable receipt with an immediate protocol exit.

Leaf → burn → return same receipt

C1 — Closed

The underlying is a long-duration or otherwise non-redeemable position.

Leaf → secondary market

The Leaf can be backed and tradeable without the protocol promising an immediate peg-out.

C2 — Queued

The underlying has a defined unstaking or withdrawal process.

Leaf → burn → queue → wait → claim

Why the distinction matters

The most dangerous product design is pretending that all three are the same.

HyperLeaf makes the difference explicit in the product taxonomy, token name, UI, and risk disclosures.

A ticker should tell users what kind of claim they are buying.

Source rewards

Rewards are handled according to the economic model of the underlying.

Some rewards belong inside the Leaf’s intrinsic value.

Other rewards are side assets that can be converted into HYPE.

The system does not assume that every reward should increase token NAV or that every reward should be distributed as HYPE.

The accounting decision comes first. The interface follows it.