The hedge book

Every backed coin's pool is margin on a real market. The hedge book is that, added up — every tracker, what its vault holds, what it has sent to the venue and had back — and, underneath it, who actually holds the positions and what the chains can prove about them.

It is public, at /hedge.

Nothing here has carried money yet. The hedge contract is tested in a sandbox against a stand-in for NEAR's signer network, and the Hyperliquid signatures it produces are checked byte for byte against Hyperliquid's official SDK. No transfer to or from Hyperliquid has been made on NEAR; the first planned live test is a 10 USDC round trip. Latencies and fees on this page are from dry quotes and single samples taken on 2026-09-25, and are marked as such.

Where the hedge lives, in plain words

The positions are held on Hyperliquid, a perpetuals exchange that runs on its own chain (HyperCore), on the xyz market deployed there by trade.xyz under Hyperliquid's HIP-3 — the market that lists stocks, indices and commodities, margined in USDC.

Hyperliquid identifies an account by an Ethereum-style address, and only a signature from that address can move its money. In the Avalanche version, the hedge account (on another exchange) belonged to an ordinary wallet whose key sat online on the keeper's machine and could have withdrawn everything. On NEAR it does not:

• the positions sit in one Hyperliquid master account whose address is derived by NEAR Chain Signatures from the protocol's hedge contract (its NEAR account plus a fixed path). Only that contract can ask NEAR's signer network (v1.signer, a threshold network of signers) to sign as the master account;
• the hedge contract's code asks for exactly two kinds of signature: approving the keeper's trading key (only when the owner calls it, for an address the owner names), and sending USDC from the master account to a NEAR Intents deposit address, for no more than a vault has on the venue, under a per-transfer and a per-day cap. It has no code that signs Hyperliquid's Withdraw, or any other transfer;
• the keeper trades with a Hyperliquid agent key — an API key the master account approved — which can place orders and move collateral between the master account's own balances, and cannot withdraw or send to anyone else;
• every tracker's vault stores the hedge contract as its hedge_funder, the only account the vault can ever send hedge money to;
• dollars cross between NEAR and Hyperliquid through NEAR Intents 1Click — a network of solvers that deliver an asset on one chain against a deposit on another — in one hop each way: NEAR USDC to Hyperliquid USDC in about 30 seconds, and back in about 35 (dry quotes, 2026-09-25).

That is the honest shape of it: the dollars behind a bonded coin leave NEAR for an exchange account that a contract, not a person, controls, travel both ways through 1Click's solvers, and are traded by a key that cannot take them. The rest of this page is what bounds that, and what you still have to trust.

How the money moves

 out    vault ──fund_hedge──▶ hedge contract                                    on NEAR
        hedge contract ──USDC──▶ 1Click deposit address (recipient: master)     on NEAR
        1Click credits USDC to the master account                  ~30 s        on Hyperliquid
        keeper (agent key) moves it to the xyz balance and trades                on Hyperliquid

 back   keeper (agent key) moves USDC back from xyz
        hedge contract has v1.signer sign SendAsset ──▶ 1Click address  ~5 s     NEAR → Hyperliquid
        1Click delivers NEAR USDC to the hedge contract            ~35 s        on NEAR
        hedge contract ──settle_return──▶ vault                                  on NEAR

• Out of the vault. fund_hedge(amount) on a tracker's vault sends USDC to the hedge contract and nowhere else. It is capped on chain at fundable_usdc() — the vault's idle USDC above its buffer floor, fees and parked payouts excluded — it refuses before the tracker has bonded, and it refuses while the vault is paused. Only the vault owner or the hedge contract can call it, and neither chooses the destination. The hedge contract books the USDC as that vault's idle.
• Into Hyperliquid. The keeper asks 1Click for a quote from NEAR USDC to Hyperliquid USDC whose recipient is the master account, and calls deposit_to_venue(vault, amount, deposit_address, quote_id) with its operator key. The hedge contract checks the address has the form 1Click issues (a 64-hex NEAR implicit account), charges the transfer against its caps, moves the amount from the vault's idle to on_venue, logs the quote id, and sends the USDC. 1Click credits the master account's balance on Hyperliquid (about 30 seconds in the dry quote). The keeper then moves it, with the agent key, to the master account's xyz balance and books it to the tracker it came from.
• Back. To return money, the keeper first shrinks the tracker's share of the position so the equity left keeps the stated multiple, moves the USDC out of xyz with the agent key, and asks 1Click for a quote from Hyperliquid USDC to NEAR USDC whose recipient is the hedge contract. It then calls request_return(vault, amount, destination, nonce, quote_id): the hedge contract checks the vault has at least that much on the venue, charges the caps, moves it to returning, builds Hyperliquid's SendAsset message itself, and has v1.signer sign it as the master account (one sample on mainnet: about 8 blocks, 4.7 seconds). The keeper posts the signed message to Hyperliquid; 1Click delivers NEAR USDC to the hedge contract (about 35 seconds in the dry quote); sync_balance — anyone may call it — measures what arrived, and the keeper's settle_return pays it into the vault, never more than has arrived and never more than that vault has returning.
• What 1Click costs. On 2026-09-25 a dry quote turned 100 USDC into 99.68 on the way out and 99.78 on the way back. That includes a 0.25% platform fee 1Click charges quotes made without a partner key; a partner key is meant to bring stablecoin routes near 0.01%, and has not been requested yet. The way back also carries Hyperliquid's flat 0.2 USDC transfer fee (minimum 0.5 USDC). None of this has been measured with money. Whatever a leg costs reduces what arrives, so it is a cost of the tracker, visible in its NAV.
• Nothing counted twice, nothing lost. While a leg is open, the dollars are in none of the obvious places — not in the vault, not yet in the account. The hedge contract books every dollar per vault as idle (received, not yet sent), on_venue (sent to Hyperliquid) or returning (a signed transfer back exists, not yet delivered), in public state anyone can read with book(vault). A transfer that fails on NEAR puts its books back; a signature that fails puts them back; a return Hyperliquid refuses is put back with cancel_return. The keeper counts each dollar exactly once in NAV, and if its books ever disagree with what the venue and NEAR show, it posts no NAV until the difference is explained.

The keys

What changed from Avalanche is the first row. There, the account belonged to a wallet key that had to sit online and could, if stolen, withdraw everything anywhere. Here nothing on the keeper machine can sign for the master account: the only signer is a contract, and its code only sends USDC to deposit addresses, for no more than a vault has on the venue, capped. A stolen keeper machine can still do harm — misdirect transfers up to those caps, trade badly, or sign a false NAV (below) — but it cannot empty the account.

The switches

• Kill switch. The vault owner calls set_hedge_funder(None): from that moment, fund_hedge fails for everyone. No further dollar can leave that vault for the venue.
• Pause. set_paused(true) on a vault stops fund_hedge too, along with minting and redeeming. set_paused(true) on the hedge contract stops every deposit and return request.
• Caps. The hedge contract refuses any single transfer above max_transfer_usdc, and more than daily_cap_usdc in a UTC day, in either direction. The deployment defaults are $50,000 and $250,000, and are still to be confirmed.

Neither the kill switch nor a pause can reach money already on Hyperliquid or in 1Click's hands, and neither closes a position: open positions stay open under the venue's rules until the keeper manages them.

What you are trusting

• The operator key, within the caps. A contract cannot check that an address really belongs to 1Click, or that a 1Click quote really pays the hedge contract: quotes are made off chain. So the operator chooses those addresses, and a thief holding the operator key could send up to one transfer's cap per call, and a day's cap per day, somewhere else — idle USDC on NEAR on the way out, or USDC from the master account on the way back. Every transfer is a public event with its quote id, and the owner can pause the contract or change the operator. How to have the contract verify a 1Click address is an open design question.
• The hedge contract's account. The master account is whatever the hedge contract's code says it is. The vault, coin and reference-pool code is published on NEAR by hash and can never change, but the hedge contract and the tracker factory are ordinary accounts: whoever holds a full-access key to the hedge contract's account could deploy different code, and that code would control the master account. Whether those keys are removed or held by a multisig after deployment is not settled yet; check the account's keys on NearBlocks.
• NEAR's signer network. v1.signer is a threshold network: a signature needs a threshold of its nodes (11 on 2026-09-25). If it stops answering, no return can be signed until it does; if a threshold of its nodes colluded, they could sign as the master account.
• 1Click's solvers. For about 30 seconds each way, the dollars are with 1Click: a deposit address issued for the quote, a solver that delivers on the other side. Quotes carry a refund address. The fees and latencies here are dry quotes, not measured transfers.
• Hyperliquid and trade.xyz. Deposits sit with Hyperliquid, on its own chain, under its validators and its rules. The xyz markets belong to trade.xyz, which runs their oracle and sets their fees and can halt them. We control neither.
• One shared account. Every tracker is hedged inside the master account's one xyz balance. That nets a long and a short tracker on the same market, which uses less margin; the cost is that losses are no longer isolated per tracker — a liquidation of the account hits every tracker. The keeper sizes every tracker well under the venue's leverage cap.
• The keeper. It trades the account and signs NAV. A keeper that stops rebalancing, or trades badly, costs the trackers; the agent key cannot move money out of the account, but it can lose it in the market. A stolen NAV key could post a false NAV — the vault checks the signature, not the number — and mint or redeem against it until the owner changes the signer or pauses the vault; what it could take is bounded by the vault's idle USDC.

One position per tracker, not per coin

A tracker carries a single position, on one market, inside the master account. Every coin bonded onto NVDAx5 puts its backing behind the same Nvidia exposure, so the arithmetic is per tracker, never per coin:

margin(u)   = what tracker u's backing is worth: its supply × NAV
size(u)     = margin(u) · leverage / entry
notional(u) = size(u) · mark
PnL(u)      = size(u) · (mark − entry) · (+1 long, −1 short)

A coin's share of a tracker is its share of the tracker's supply — split pro rata, because a pooled position carrying one averaged entry has no other honest way to attribute itself.

What each column means

Above the table, the hedge contract itself: its account, the master account's address on Hyperliquid, the operator, the caps and what has moved today.

The account behind each row

The master account's xyz balance is cross-margined: one USDC balance backs every position in it, and a tracker's leverage is its notional divided by its share of the equity. Keeping the multiple is therefore a matter of trading the difference — when the position gains, the keeper buys a little more; when it loses, it sells a little down — rather than closing and reopening anything.

The keeper never sizes past 90% of the leverage Hyperliquid allows on the market, and lets a tracker's leverage drift within a band (20% either side of target, leverage_band_bps on the vault) before trading back.

Liquidation

Hyperliquid liquidates when an account's equity falls below its maintenance margin: the position's notional times the market's maintenance fraction m. For the first margin tier, m is half the initial margin at maximum leverage, 1 / (2 · max leverage): 2.5% on 20× markets, 5% on 10× markets, 2% on gold and silver, about 1.67% on QQQ, 1% on SPY. Larger positions fall into higher tiers with more margin; we have not read every market's tiers. With E the entry and L the leverage, a single position reaches that point at:

long    P_liq = E · (1 − 1/L) / (1 − m)
short   P_liq = E · (1 + 1/L) / (1 + m)

The size cancels out entirely, which is why a leg's liquidation depends only on its entry, its leverage and its market — and why adding backing at a new mark moves it, through the averaged entry.

These are moves from entry before funding, for a position nobody rebalances, and for a tracker alone in the account: because the account is shared, another tracker's losses can bring the liquidation closer, and another's gains push it further. The keeper de-levers long before that point. Hyperliquid's own liquidation logic is the authoritative one.

Why the account leverage is not exactly the stated multiple

Notional is divided by equity, and equity moves with unrealised PnL. A book losing money carries more leverage than it opened with, and the number goes up — which is precisely the thing worth seeing. A book showing a flat 5× through a drawdown would be hiding it.

Checking it yourself

What NEAR proves — every dollar that left for the venue and every dollar that came back:

factory.get_lt(lt)            → {underlying, is_short, leverage, market_id, live, bonded}
vault.state()                 → usdc_held, hedge_outstanding, hedge_funder, buffer_bps, paused, …
vault.fundable_usdc()         → what the vault could send right now
vault.peek_nav()              → {nav, hedge_equity_usd, updated_at_secs, stale, bond_gated, bonded}
hedge.book(vault)             → {managed, idle, on_venue, returning}
hedge.state()                 → master address, operator, caps, moved_today, transfers in flight
hedge.master_address()        → the Hyperliquid master account, derived from v1.signer

Every leg is an event (NEP-297): hedge_funded on the vault; funded, deposit_to_venue (with the 1Click quote id), return_requested, signed, return_settled on the hedge contract (standard flake-hedge); hedge_returned on the vault. The master address can be re-derived by anyone from the hedge contract's account and path with v1.signer.derived_public_key.

The venue side is public too. Unlike the Avalanche venue, Hyperliquid account state is public: anyone can read the master account's balances and positions through Hyperliquid's info API (clearinghouseState with dex: "xyz"), or on its explorer. What stays off chain is the split of that account between trackers — that rests on the keeper's ledger and its signed NAV, whose hedge_equity_usd field states each tracker's share at every post.

Live, and honestly so

Marks are Hyperliquid's, read live, so the book moves as the market moves. The vault and hedge-contract figures are re-read from NEAR. Funding is settled on Hyperliquid every hour and shows up in the account's equity, not in the table.

Hyperliquid does not close, so the book keeps marking through nights and weekends; the price can still gap when an underlying's home market reopens. A market the venue halts cannot be resized until it resumes. When a market the venue cannot quote appears, its row says so and is left out of the totals rather than counted as flat. An unknown price is not a zero.