Introducing Leveraged Hooks.
Enabling pool-native borrowing.
Leveraged Hooks supercharge Uniswap LPs by turning trading liquidity into lending liquidity too.
We built Hookr.fun around a simple question:
How far can the Uniswap hook primitive actually be pushed?
The obvious uses for hooks are dynamic fees, access controls, automated buybacks, or logic that runs before and after a swap.
But that understates the design space.
A hook sits at the point where liquidity, price discovery, execution, settlement, and LP accounting meet. It can inspect a transaction before it executes, apply market-specific policy, reconcile the result afterward, and maintain persistent state around the market.
That lets us ask a more interesting question:
What if the same liquidity making a market could also extend credit inside that market?
That is the idea behind Leveraged Hooks.
Not a separate perp exchange.
Not a lending protocol placed next to the pool.
Not a second group of depositors funding an external credit vault.
Instead, a single
market where LP capital supports spot execution and secured leverage—and where LPs can potentially earn both swap fees and borrow interest.
The Power of the Hook
Leverage is not just a multiplier added to a trading interface.
A credible leverage market has to coordinate an entire state transition:
Verify that the market is healthy enough to originate new credit
Calculate how much additional exposure the liquidity can safely support
Execute the purchase through the canonical market
Lock the purchased asset as collateral
Record the resulting debt
Accrue interest over time
Restrict new borrowing when utilization or risk rises
Close or liquidate the position through the same market
A hook can coordinate those steps at the exact moment a swap occurs.
But the hook does not create free capital.
Its power is more precise:
The hook can turn a normal swap into a policy-constrained balance-sheet transaction.
That distinction is the core of the design.
One Economic Market, Not Two Liquidity Pools
The simplest leverage architecture would place a lending vault next to every token pool.
ETH lenders would deposit into the vault. Traders would borrow ETH from that vault. The borrowed ETH would then be swapped through the token’s Uniswap pool.
That architecture can work, but it creates two separate capital bases:
Trading liquidity
Lending liquidity
That is not the version we find most interesting.
With Leveraged Hooks, an LP deposits into one Hookr-managed market. That market uses its capital for both execution and secured credit.
There is no second user-facing lending pot and no separate class of lenders.
Technically, the system still requires more than one contract. The hook needs an associated position ledger, risk engine, oracle policy, and managed LP accounting layer.
But economically, there is:
One LP deposit
One LP claim
One market
One source of capital
The LP’s position is no longer just a claim on the tokens currently sitting on the AMM curve.
It becomes a claim on the complete Hookr market balance sheet:
AMM inventory
Performing credit receivables
Accrued swap and borrow fees
Market reserves
Realized bad debt
The underlying primitive is:
An AMM with a balance sheet.
A NODE/ETH Example
Imagine NODE launches through
against ETH.
After initial trading, suppose the market contains approximately:
20 ETH
500 million NODE
That market already provides:
NODE price discovery
ETH-to-NODE swaps
NODE-to-ETH swaps
Trading-fee revenue for LPs
Now Alice arrives with 2 ETH and wants to go 2× long NODE.
Without leverage, she simply swaps:
2 ETH → NODE
With a Leveraged Hook, the position becomes:
2 ETH of Alice’s equity
plus
2 ETH of market-financed credit
equals
approximately 4 ETH of gross NODE buying power
The complete order executes through the actual NODE/ETH market.
The amount of NODE Alice receives depends on the pool’s active liquidity, fees, slippage, and price impact.
The leveraged demand is still real demand.
ETH enters the market.
NODE leaves the available liquidity.
The NODE price moves.
There is no separate leverage price sitting beside the spot market.
The pool remains the market.
The Market Sells NODE on Margin
The cleanest way to understand the transaction is not that the pool physically sends Alice 2 ETH and waits for her to return it.
Instead:
The market effectively sells Alice NODE on margin.
Alice contributes 2 ETH.
The market gives her approximately 4 ETH worth of NODE exposure.
The remaining 2 ETH is financed by the market and recorded as debt owed by Alice.
Her purchased NODE remains locked inside the leveraged position.
She cannot withdraw the financed NODE and disappear.
At origination, the simplified accounting looks like this:
The market delivers
Approximately 4 ETH worth of NODE
The market receives
2 ETH of external cash from Alice
plus
A 2 ETH credit receivable
Alice receives
Approximately 4 ETH of NODE exposure
minus
2 ETH of debt plus interest
Alice’s initial equity
Approximately 2 ETH
No value is created at origination.
The transaction simply changes the form of the market’s assets.
Some liquid inventory becomes a secured credit receivable.
That is how trading liquidity becomes lending liquidity.
Avoiding Double Counting
The locked NODE collateral and Alice’s debt cannot both be counted as independent LP assets.
That would count the same economic value twice.
Alice remains the owner of the position’s residual equity.
The Hookr market has a senior claim against the collateral for principal and interest.
For LP accounting, the market counts the value of the performing receivable.
The NODE collateral matters because it secures that receivable. It determines whether the debt remains healthy and how much the market can recover during liquidation.
But it is not free additional value.
Alice’s equity is:
Locked collateral value minus debt owed
The market’s credit asset should never be valued above the amount realistically recoverable from that collateral.
If the recoverable collateral value falls below the debt, the difference becomes bad debt.
That loss has to reduce LP value or be absorbed by an explicitly funded reserve or backstop.
It cannot be hidden by continuing to mark the loan at face value.
Where Uniswap Ends and Hookr Begins
The persistent debt does not live inside Uniswap as an unsettled token balance.
Uniswap handles:
The pool
The swap
The execution price
The liquidity transition
Atomic settlement
Hookr handles:
Collateral ownership
Persistent debt
Accrued interest
Position equity
Health factors
Credit ceilings
Liquidation eligibility
Market-level bad debt
Put differently:
Uniswap settles the trade. Hookr carries the balance sheet.
The hook connects the two.
It can validate a position before execution, reconcile the actual swap output rather than relying on an estimate, lock the resulting collateral, and update the credit ledger as one coordinated transaction.
Why Managed LP Accounting Matters
A standard Uniswap LP position represents a claim on the liquidity inside the Uniswap pool.
It does not automatically represent a claim on a separate credit ledger.
That means a production version of Leveraged Hooks will likely require Hookr to manage or wrap the underlying LP position.
LPs would receive a Hookr market share representing their claim on:
The underlying Uniswap liquidity
Uncollected swap fees
Performing leverage debt
Accrued borrow interest
Liquidation proceeds
Market reserves
Realized bad debt
This is necessary for coherent accounting.
Otherwise, the system could remove NODE from the AMM inventory, create a receivable elsewhere, and leave the original LP position unaware of the asset that replaced it.
The hook is the policy boundary.
The Hookr market share is the accounting boundary.
Together, they let LPs deposit once while their capital performs multiple jobs.
Opening a Leveraged Position
Alice submits a position with:
2 ETH of equity
2× target leverage
A maximum acceptable entry price
A minimum amount of NODE received
A maximum acceptable borrow rate
Before allowing the trade, the hook checks:
Current market liquidity
Existing market debt
Remaining credit capacity
Utilization
Oracle health
Expected price impact
Liquidation depth
Minimum collateralization requirements
Whether the market is in a protected state
If the checks pass, the gross NODE purchase executes through Uniswap.
The hook reconciles the position using the actual NODE received, not an optimistic quote.
The NODE is then locked inside Alice’s collateral account.
Alice receives a position claim—not freely withdrawable financed NODE.
Hookr records:
Principal
Interest index
Collateral amount
Entry execution
Health factor
Liquidation conditions
The entire operation completes atomically or reverts.
Closing a Profitable Position
Suppose Alice’s locked NODE can later be sold for 6 ETH.
When she closes:
The NODE is sold through the NODE/ETH market
The market receives the ETH proceeds
The 2 ETH principal is extinguished
Accrued interest and fees are paid
The remaining ETH goes to Alice
For example:
Sale proceeds: 6 ETH
Principal repayment: 2 ETH
Interest and fees: 0.1 ETH
Remaining value to Alice: 3.9 ETH
Alice began with 2 ETH and exits with 3.9 ETH in this simplified example.
The market receives its financed capital back plus yield.
The credit receivable disappears from the balance sheet and becomes liquid market inventory again.
Liquidation and Bad Debt
If NODE declines, the hook continuously compares the recoverable collateral value with Alice’s debt.
Liquidation has to begin before the collateral merely equals the principal.
The system needs room for:
Swap fees
Liquidation incentives
Market impact
Accrued interest
Oracle delay
Adverse price movement during execution
When a position becomes unhealthy:
A liquidator or protocol keeper triggers the unwind
Some or all of the NODE collateral is sold through the same market
ETH proceeds repay principal and interest
The liquidator receives a bounded incentive
Any residual value returns to Alice
Any shortfall becomes explicit market bad debt
The most important invariant is simple:
A credit receivable must never be valued above what its collateral can realistically repay through the market that must liquidate it.
That is why credit capacity should be based on executable depth, not headline TVL.
A market might display a large nominal liquidity number while only being able to absorb a much smaller NODE sale before suffering severe price impact.
The second number is what matters for leverage.
Credit Cannot Grow Faster Than Liquidation Capacity
Suppose the NODE market has:
20 ETH of quote-side liquidity
5 ETH of maximum permitted credit
2 ETH of outstanding credit
The market therefore has:
3 ETH of remaining leverage capacity
That credit ceiling should change with market conditions.
It should consider:
Available liquidity
Executable liquidation depth
Volatility
Current utilization
Oracle health
HOOKR bonding
Protocol-level risk limits
The most conservative constraint wins.
As debt utilization rises, borrow rates increase.
As liquidity or liquidation depth falls, credit capacity contracts.
When the system reaches its risk limit, the hook rejects new leverage and leverage increases.
Existing users can still:
Repay debt
Add collateral
Reduce exposure
Close positions
When the system becomes constrained:
Liabilities should be able to shrink, but not grow.
LP Withdrawals Are Part of the Credit Design
No liquidity split does not mean every unit of market value remains instantly withdrawable while loans are outstanding.
Once part of the market’s balance sheet exists as credit receivables, some value remains illiquid until borrowers repay or positions are liquidated.
The LP redemption system therefore needs explicit withdrawal rules.
Depending on utilization, a withdrawal might:
Execute immediately from available liquidity
Be limited to a portion of liquid market assets
Enter a withdrawal queue
Receive a proportional claim on outstanding receivables
Include a utilization-sensitive exit fee
The system cannot let early LPs withdraw all liquid ETH while leaving the remaining LPs exposed to every outstanding loan.
This is not just a user-interface decision.
It is part of solvency.
The credit model and LP redemption model have to be designed together.
The Market as Its Own Oracle
For a newly launched token, the Hookr.fun market may be the only meaningful source of price discovery.
That makes the pool the natural price source.
But it does not mean the latest trade should always be trusted.
The hook can maintain observations around:
Spot price
Short-window average price
Long-window average price
Liquidity depth
Volatility
Spot-versus-average-price deviation
Trade size relative to active liquidity
If price quality deteriorates, the market can enter protected mode.
Protected mode disables
New leverage
Leverage increases
Risk-increasing collateral withdrawals
Protected mode still allows
Debt repayment
Collateral additions
Deleveraging
Position closure
Liquidation under the applicable oracle policy
The oracle does not need to pretend the market is always trustworthy.
It needs to recognize when it is not.
What LPs Are Being Paid For
Leveraged Hooks can expand LP revenue from one source to several:
Swap fees
Borrow interest
Liquidation fees
Hook fees
But the additional yield is not free.
LPs are taking additional risks:
Borrower default
Delayed liquidation
Oracle manipulation
Reflexive sell pressure
High utilization
Withdrawal delays
Smart-contract risk
Borrow interest is the price paid for that additional balance-sheet risk.
The objective is not simply to advertise higher LP yield.
It is to create a market where additional LP revenue is matched by explicit, measurable, and bounded exposure.
Where $HOOKR Fits
HOOKR can become the economic coordination asset around this market structure.
A creator enabling Leveraged Hooks could be required to bond the already-live HOOKR token.
That bond can help:
Gate advanced market functionality
Align the creator with long-term market operation
Support a market-specific safety buffer
Constrain credit capacity alongside real liquidity limits
Reward developers who build and maintain the module
Leveraged Hooks also create new fee streams:
Borrow interest
Opening and closing fees
Liquidation fees
Additional swap fees
Module fees
Another hook can route part of that revenue through a simple loop:
Market fees → buy HOOKR → bond HOOKR
This creates a compounding system:
More activity creates more fees.
More fees acquire more HOOKR.
More HOOKR becomes bonded behind the market.
That additional economic backing can become one input into how much safe credit the market can support.
But HOOKR cannot replace real liquidity.
A large HOOKR bond cannot make an illiquid NODE market safe.
Liquidity and liquidation depth remain the hard constraints.
HOOKR can coordinate access, incentives, and economic backing around those constraints.
Existing Tokens Can Opt In
An existing token would not need to change its token contract.
Instead, it could create a new leverage-enabled
market.
That new pool would be initialized near the token’s current market price and seeded with enough liquidity to avoid immediate divergence or manipulation.
The token remains the same.
The new pool introduces a different market structure around it.
The Actual Primitive
Leveraged Hooks are easy to describe as native 2× longs.
But the underlying primitive is more important:
A hook-controlled AMM with an expanded balance sheet.
The hook does not bypass accounting.
It makes more expressive accounting possible.
It connects:
Swaps
Collateral
Debt
LP claims
Interest
Liquidations
Oracle policy
Fee routing
into one market state machine.
Uniswap provides the settlement and liquidity substrate.
Hookr adds the credit ledger and risk policy that allow the market to do more than exchange one token for another.
That is the boundary we want to push.
Leveraged Hooks supercharge Uniswap LPs by turning trading liquidity into lending liquidity too.
Leveraged Hooks are currently in design and are not live.
We are working through the exact integration, managed LP accounting, credit ceilings, withdrawal model, oracle behavior, liquidation mechanics, and HOOKR bonding system.