Anatomy of a Distribution: Ethena Liquid Leverage

Merkl is usually read as a rail: hand it a list of addresses and amounts, and it pays them out. That misses where the value sits. The hard part, and the real product, is computing who is owed what, under rules that can fold dozens of parameters into a single payout. Traditional finance has a name for the party that does exactly this. The paying agent calculates and administers what each holder is due, and Merkl is the programmable, onchain version of it.

What that allocation computation involves is invisible from the outside, and making it visible is the whole point of this series, Anatomy of a Distribution. The method is the same each time: take one real, live distribution and look under the hood at the machinery that turns a single onchain action into a fair payout. We stay on mechanics. No budgets, no amounts distributed, no daily figures.

We are opening with what is, to date, the most intricate shape Ethena has run with Merkl: the Liquid Leverage program on the Aave markets on Ethereum. As intricate as this distribution is, none of it was custom-built. Every parameter is an existing building block, and it is the way they combine that makes this program bespoke.

What the user sees, and what runs underneath

From the user's seat, the instruction reads as a single line: lend USDe and sUSDe on Aave, and loop the position. Everything else is invisible. That asymmetry is the entire point. A naive distribution would treat "supply the asset" as the rule, take a balance snapshot, and pay everyone holding it. Ethena wanted something far narrower and considerably harder to fake, and the distance between those two outcomes is the distance between a rail and a programmable layer.

So before anything pays out, the live configuration runs a stack of conditions, and on Ethereum that stack is deeper than usual because the program spans two markets at once. The opportunity is named for the behavior it rewards: lend on Aave with looping required. Looping is the thing being rewarded, not the deposit. Let us walk the stack one brick at a time, and for each, name what a simpler system would get wrong.

1. Eligibility is a stack, not a balance check

The first brick gates who is even considered. A wallet does not qualify by holding the asset. It has to satisfy a set of hooks, all of them, at the same time.

It must lend on the Aave USDe and sUSDe markets. It must also borrow against that position, in USDC, USDT, or USDS. And it must keep its health factor below a configured ceiling, set here to 2.5.

Read that last condition twice, because it inverts a reflex. In a lending market a low health factor is a warning light: it means a position sits closer to liquidation, and most of the time you want it higher, not lower. Here the logic runs the other way. A wallet that lends USDe and borrows nothing keeps a high health factor precisely because it is taking no leverage, which means it is parking the asset rather than working it. By requiring the health factor to stay below a ceiling, the configuration is checking for genuine looping. The low health factor is the onchain evidence that the wallet actually borrowed and recycled, instead of sitting still.

A balance check cannot express any of this. It sees an amount and stops. The hook stack sees a behavior, and it is already several conditions deep before scoring even begins.

2. Scoring takes the minimum across two markets

This is the brick that makes the Ethereum shape stand out, and it is the one a rail could never do.

The program does not reward one market. It rewards a paired position across two: the USDe market and the sUSDe market. Internally, the distribution is composed of two linked sub-distributions, one per market, joined under a single opportunity. The way they are joined is the interesting part. The scoring rule is literally a minimum: a wallet is credited on the smaller of its two positions, the lesser of what it lent on the USDe side and what it lent on the sUSDe side.

Think about what that defeats. If the rule simply added the two positions, a wallet could load one market heavily, touch the other with a token amount, and collect as if it were balanced across both. Scoring on the minimum closes that door completely. To earn on a given size, a wallet has to actually hold that size on both sides. The reward tracks the paired exposure Ethena wants to see, not the larger leg a farmer would rather show. One simple instruction for the user, a two-market minimum resolved underneath.

3. The reward is a receipt token

The third brick is what the user receives. It is not a separate governance token dropped in alongside the position. The reward is aEthUSDe, the Aave receipt token that represents the supplied USDe position itself.

This is deliberate. Most distributions pay in an unrelated asset that lands in the wallet as something you then have to decide what to do with, and the rational move is often to sell it, which quietly pulls capital out of the very behavior being rewarded. Paying in the receipt token keeps the reward inside the position. It compounds straight back into the Aave supply rather than sitting loose next to it. The behavior being rewarded and the form of the reward are the same shape, which means the wallet that looped harder ends up holding more of the exact asset it was looping. Alignment here is not a slogan, it is the token address.

4. The reward amount tracks a target rate, and it is capped

The fourth brick is how much each wallet gets. It is not a fixed amount per wallet, and not a pool split among whoever shows up. Instead the engine targets a rate: it sizes each wallet's reward to deliver a set annual return on its position, like a target APR, and caps it so the rate cannot run too high. Here the target roughly matches the native sUSDe rate, and it is a dial the issuer can turn, not a fixed number.

Why this way? A fixed amount per wallet ignores position size, so it pays the wrong rate to almost everyone. A pool split makes each wallet's reward depend on how many others joined, which no issuer can predict. Targeting a rate fixes the one thing the issuer wants to offer, the return, and the engine works backward to each amount, recomputing as positions and prices move. The cap is the safety rail: on a quiet day, it stops the rate from ballooning.

5. Scoring is weighted by time, not a snapshot

The fifth brick is the one most distributions get laziest about. Scoring is weighted by time. A wallet is credited in proportion to the position it actually held, across the duration it held it, and then the cross-market minimum is taken on that time-weighted basis.

The contrast is a single snapshot, which is trivially gameable: deposit the moment before, withdraw the moment after, collect as if you had been present throughout. Time-weighting closes that door. An hour of holding earns an hour. Holding throughout earns throughout. Combined with the eligibility stack, a wallet is only ever scored for the windows in which it was simultaneously lending on both markets, borrowing, and sitting below the health factor ceiling. The conditions are not checked once. They are checked continuously.

6. Reaching the real owner: forwarders and exclusions

The sixth brick looks like an edge case and is actually the hardest problem in onchain distribution. The lent position is represented by a receipt token, and a receipt token can move. It can be deposited into a vault, wrapped, or routed through another contract. When that happens, the address technically holding the token is not the wallet that is actually exposed to the position.

Pay the holder and you pay the contract, not the person. The reward lands in an intermediary that has no way to pass it on, and the user who took the leverage gets nothing. This is where Merkl's reward forwarders do the work. Forwarding is enabled on this distribution, so the engine traces ownership through nested contracts, layer by layer, until it reaches the wallet genuinely exposed, and pays there instead of stopping at the intermediary. Alongside it sits a blacklist: an explicit list of excluded addresses, contracts that should not earn, removed from the calculation entirely.

The whole thing, as a configuration

Every brick above lives in a single configuration object, stored and computed by the platform. Here is that configuration (minus the 32 excluded addresses, trimmed for readability). None of it is custom code. These modules already exist, and this distribution is simply a particular way of combining them.

{
  "type": "MULTILOG_DUTCH",
  "computeScoreParameters": { "computeMethod": "genericTimeWeighted" },
  "composedCampaignsCompute": "min(1,2)",
  "forwardingEnabled": true,
  "hooks": [
    { "hookType": 17, "healthFactorThreshold": "2.5", "targetBytesLike": "0x87870Bca...4E2 (Aave pool)" },
    { "hookType": 14, "borrowBytesLike": ["0x015396E1...5145 (debt token)"] }
  ],
  "composedCampaigns": [
    {
      "composedIndex": 1,
      "symbolUnderlyingToken": "sUSDe",
      "symbolTargetToken": "aEthsUSDe",
      "symbolRewardToken": "aEthUSDe",
      "distributionMethodParameters": {
        "distributionMethod": "MAX_APR",
        "distributionSettings": { "apr": "0.035", "rewardTokenPricing": true, "targetTokenPricing": true }
      }
    },
    {
      "composedIndex": 2,
      "composedType": "MAIN",
      "symbolUnderlyingToken": "USDe",
      "symbolTargetToken": "aEthUSDe",
      "symbolRewardToken": "aEthUSDe",
      "distributionMethodParameters": {
        "distributionMethod": "MAX_APR",
        "distributionSettings": { "apr": "0.035", "rewardTokenPricing": true, "targetTokenPricing": true }
      }
    }
  ],
  "blacklist": ["0x90d443b3...E981", "0x2c4FB358...1c08", "... (32 addresses excluded)"]
}

What this distribution shows

For the user, this looks simple: deposit, loop, and keep the health factor in range. Behind that one action runs a whole stack of Merkl engineering, the six bricks we just walked through: the paired-market minimum, the inverted health-factor check, the receipt-token reward, the capped target rate, the time-weighting, and the ownership forwarding, all resolved inside a single configuration object.

That is where Merkl's value sits. Not in moving the tokens, but in combining dozens of parameters into a unique distribution without a line of custom code. The same set of bricks runs unchanged on other chains too, like Plasma, with only the tokens swapped. The complexity is real, and Merkl absorbs all of it: the issuer is left with a configuration, the user with a single click.