Hyperdrive

Hyperdrive is where an open-long quote becomes fixed-rate position tokens

Hyperdrive is a fixed-rate AMM interface where you choose a yield pool and deposit amount, approve the selected asset when required and confirm an open-long call that mints a maturity-specific position balance. Before signing, the screen resolves the pool's fixed APR, duration, estimated long-token output and settlement asset into contract parameters. After execution, the receipt and OpenLong event provide the on-chain evidence needed to match the quote with the new position.

Terms on demand make the selected pool actionable

Even so, Hyperdrive's terms-on-demand mechanism turns the selected yield pool into a fresh long position with a maturity derived from that pool's checkpoint schedule.

That feature matters at decision time because the interface doesn't ask you to find an already-issued bond series. A pool built around an ERC-4626 vault, an Aave market, Lido stETH, a Morpho vault or Sky savings asset supplies the yield source and its configured term. The quote then prices a new long against the pool's reserves. One selection therefore fixes one pool contract, one deposit route and one maturity calculation; switching pools changes all three, even when the wallet displays the same base ticker.

The remaining detail is recorded in Hyperdrive about networks. Maturity equals a checkpoint boundary plus the pool's position duration, not the moment when the button is pressed. Hyperdrive annualizes APR on a 365-day basis and its fixed-point calculations use 18 decimal places. Those are durable calculation rules; the displayed APR and token output move with reserves. Read the refreshed quote immediately before confirmation because a new checkpoint or reserve change alters the executable values.

The pre-confirmation quote turns three choices into contract limits

Hyperdrive's open-long preview maps the pool, payment asset and amount into contract limits that the wallet must accept for execution.

Pool and payment asset

The pool choice determines the Hyperdrive contract and maturity logic. The payment selector then chooses base units or vault-share units, and the Boolean asBase option records that choice. That gives the core call two settlement modes, while the options structure also carries destination and extraData. A deposit labeled DAI differs from sDAI; USDC differs from an ERC-4626 share that represents USDC. Match the wallet balance, token contract and unit shown in the preview.

Amount and output floor

Amount is the supplied capital; bond output is the fixed-rate claim amount minted to the destination. openLong has 4 top-level inputs: amount, minimum output, minimum vault-share price and an options object. The output floor converts the interface's slippage setting into a hard contract boundary. If the calculated bond amount falls below it, execution reverts rather than minting a smaller balance.

Worked example, with hypothetical inputs throughout: a 1,000-unit deposit, a 1,030-token quote, a 0.5% tolerance and a 182-day pool duration. The minimum output is 1,030 × (1 − 0.005) = 1,024.85 long tokens. A receipt showing 1,026 tokens clears that boundary, so the concrete minted result is 1,026 maturity-specific units. The 182-day duration identifies when the position matures; it doesn't change the 1,024.85 execution floor. Fees and reserve movement already appear in the refreshed quote rather than entering this arithmetic afterward.

Recipient and signing account

The destination field receives the long balance, while the connected wallet pays and signs. Keeping both addresses identical removes an extra reconciliation step. MetaMask and Rabby show the call target and value; WalletConnect transports the same request to a separate wallet. Review three objects before signing: the pool contract, selected token and destination address. A change to any one requires a new quote.

Which wallet prompts belong to an open long?

A Hyperdrive ERC-20 open long normally presents two wallet confirmations when allowance is missing: one approval followed by one Hyperdrive trade.

The approval changes allowance only

Approval authorizes a spender to transfer a stated ERC-20 amount from the owner. It doesn't open the long or mint position tokens. If the allowance is already sufficient, the interface skips this prompt. A route that deposits native ETH doesn't use ERC-20 approval, although the contract call still needs gas. An approval receipt changes one owner - token - spender allowance record; the long receipt changes Hyperdrive position and reserve state.

The execution calls the pool

The second prompt calls openLong on the selected pool. Hyperdrive receives 4 inputs plus the 3-field options object and returns 2 values: maturityTime and bondProceeds. Wallet simulation should show the contract destination and requested asset movement. The wallet should also show whether the call sends native value; most ERC-20 routes send zero. An EVM address occupies 20 bytes and displays as 40 hexadecimal characters after 0x, so compare the complete address rather than a shortened label.

Gas belongs to each state-changing transaction. Missing allowance therefore creates 2 transactions, while sufficient allowance leaves 1 open-long transaction. The gas price and estimated gas units come from current chain conditions and call simulation, so they aren't durable page values. Keep enough native currency for every prompt the interface actually presents. The sequence changes when allowance already exists or the route accepts native value.

A completed trade mints a maturity-specific long balance

Successful Hyperdrive execution creates a maturity-specific long balance, updates pool accounting and emits an OpenLong event containing the trade's identifying values.

The protocol doesn't mint a generic wallet ticker. Its 256-bit asset ID combines the position type and maturity, allowing one contract to account for many long series. That identifier separates a long at one maturity from another long at a later maturity. A wallet may omit the balance from its default token list, yet the contract's balance query still records it. The openLong call also returns exactly 2 values - the maturity timestamp and bond proceeds - so an integration can reconcile the user-visible quote without reading display metadata.

The OpenLong event records 8 parameters, including 2 indexed identifiers: trader and assetId. The other 6 values state maturityTime, input amount, vaultSharePrice, asBase, bondAmount and extraData. Together they describe the executed trade, not merely the intended one. The event's assetId and maturityTime should agree with the new balance.

On those terms, Hyperdrive's options structure contains 3 fields, and by convention the last 32 bytes of extraData pass through to the event. Most interface users don't set that metadata directly. The destination can differ from the signing account, so check the receiving address before deciding a position is missing. The apparent result changes when the quote deliberately sends the long balance elsewhere.

How do you verify the minted position on-chain?

A Hyperdrive long is verified by matching the successful transaction receipt, OpenLong event and wallet balance against the quote you approved.

Start with receipt status. EIP-658 receipts use status 1 for success and status 0 for reversion. A transaction hash is 32 bytes, and wallets normally display it as 64 hexadecimal characters after 0x; use that single identifier to open the exact record. Confirm the to address matches the selected Hyperdrive pool contract, then inspect OpenLong. The logged bondAmount is the executed token quantity, while maturityTime identifies the series. Don't substitute the wallet's submitted amount for bondAmount because they represent capital in and claim units out.

Next query the long balance for the destination and the event's assetId. The increase should equal bondAmount unless the same transaction includes a related transfer, which the event log also exposes. Record 4 items together: transaction hash, pool address, assetId and maturityTime. That compact record survives interface cache resets and wallet display omissions. The final balance calculation changes when the same receipt contains an additional position-token transfer.

An allowance mismatch has a deterministic recovery path

A repeated approval prompt usually means the selected token, spender or confirmed allowance no longer matches the freshly generated Hyperdrive call.

Match the exact payment token

Start with the token contract currently selected in the payment field. DAI allowance can't fund an sDAI route, and USDC allowance can't fund a vault-share route even when both represent the same accounting currency. ERC-20 allowance binds one owner, one spender and one token contract. Check all 3 against the new request, then ignore any approval attached to a previous pool or asset.

Read the requested spender

The spender must match the contract that will pull the token in the present call. A direct pool call and a routed call need not expose the same spender, so read the wallet request rather than assuming an earlier address. A spender from a previous approval screen doesn't govern the new request. If the confirmed allowance is smaller than the new amount, submit a fresh approval. An approval with status 1 establishes the allowance; a queued or status-0 receipt doesn't.

Refresh state and rebuild the quote

After the approval receipt confirms, reconnect or refresh the account state and request a new open-long quote. This matters because the prior preview was computed before one on-chain state change and its minimum output may no longer describe the latest reserves. Confirm the payment unit again, then sign only the openLong call. If the approval button persists, the mismatch remains among the token, owner, spender or amount.

Practical questions about Hyperdrive