Risks & security

What is actually guaranteed, what is not, and what can still go wrong. Written as we would want to read it.

What cannot happen

The liquidity cannot be withdrawn. Not by the creator, not by us, not by a compromised key. The launchpad has no function that removes a position except the bond, which puts it straight back — see Locked liquidity. This holds once the launchpad's full-access keys are deleted, the deployment's final step; nothing is deployed yet.

The supply cannot grow. Minted once, when the coin is created. There is no mint function.

Your sells cannot be blocked by the token. No branch of the coin's code gates a transfer, at any moment, under any condition. There is no launch window restricting anything. (USDC's own blocklist is a separate matter — see below.)

Your fees cannot be redirected. The creator is written in the coin's launch record and has no setter; the treasury is fixed when the launchpad is deployed.

A bond cannot strand liquidity. Every step is recorded; a step that fails leaves everything inside the launchpad, and anyone can resume it. The coin has no path out of the launchpad except back into its pool.

A tracker's vault cannot pay anyone but its hedge contract. The one path by which margin leaves a vault, fund_hedge, sends only to the vault's hedge_funder, only out of idle USDC above the buffer floor, never before the tracker bonds and never while the vault is paused. The caller picks an amount, never a destination.

The hedge account cannot be emptied by a key on the keeper machine. The Hyperliquid master account can only be signed for by the hedge contract, through NEAR's Chain Signatures, and the contract only signs transfers to deposit addresses, capped per transfer and per day. The keeper's trading key cannot withdraw at all.

A tracker cannot promise more leverage than its hedge can hold. The factory caps every tracker at the lower of 5× and 90% of the venue's own cap for the market, on chain.

What you are exposed to

The tracker is leveraged, and leverage decays. A bonded coin's floor is a leveraged position — up to 5×. It loses ground on a round trip in the underlying, it pays funding every hour, and it can be liquidated. See NAV, decay & funding. This is the single most important thing on this page.

The venue. The perpetual position backing a tracker lives on Hyperliquid, on trade.xyz's xyz market. We do not control either and cannot insure them. If Hyperliquid or trade.xyz pauses or halts a market, misprices it (trade.xyz runs the oracle), changes its rules or fees, or stops answering, the backing behind every coin on that tracker is affected. Hyperliquid liquidates an account when its equity falls below its maintenance margin — at 5× on a 20× market like Nvidia, about 17.9% against a long or 17.1% against a short from the averaged entry, for the first margin tier (see The hedge book for every market).

Stock hours on a venue that never closes. Hyperliquid keeps the xyz markets trading around the clock. The backing keeps moving at any hour, the price outside an underlying's home hours comes from trade.xyz's oracle and Hyperliquid's own trading, and it can gap when the home market reopens. A market that is halted cannot be resized until it resumes.

One account for every tracker. All trackers are hedged inside one Hyperliquid master account, on one cross-margin xyz balance. The hedge contract and the keeper keep per-vault books that attribute each tracker its share; on the venue, the positions share one margin balance. A liquidation of the account would hit every tracker, not only the one that lost. The keeper sizes every tracker well under the venue's cap, and a long and a short tracker on the same market net against each other on the venue.

Funding. Settled every hour on Hyperliquid, at a rate the venue computes. It can run against a tracker for long stretches.

The keeper and the NAV. NAV is computed and signed by the protocol's keeper and posted on chain; NEAR cannot check it against the venue, because the venue is another chain. If the keeper stalls, NAV goes stale; after the vault's staleness window (one hour in the deployment defaults) minting and redeeming that tracker stop rather than act on an old price, which fails closed but still means a tracker can be temporarily unredeemable. If the keeper's books disagree with what the venue and NEAR show, it posts no NAV until the difference is repaired — the same fail-closed outcome. A keeper that stops also stops rebalancing, and a leveraged position that is not de-levered on the way down runs into the venue's liquidation threshold.

Redemptions can wait. A vault keeps part of its dollars idle (20% of what its supply is worth, in the deployment defaults) and the rest on Hyperliquid. A redeem the vault cannot pay at once joins a first-in-first-out queue the keeper fills by bringing USDC back through 1Click. That has not been timed on NEAR yet: the transfer itself was quoted at about 35 seconds, and a signature from NEAR's signer network took about 5 seconds in one sample, so minutes rather than seconds — longer if 1Click, the signer network or the venue is slow. A queued redeem can be cancelled until it executes. Selling a bonded coin is different: it is paid at once out of the tracker's USDC pool, at whatever that pool's depth allows.

Concentration. Many coins can bond onto the same tracker, and they share one position. A bad day on one stock is a bad day for every coin behind it. The hedge book publishes how concentrated the book is, because you should be able to see it.

Price impact on a thin coin. A fresh launch has very little behind it. Early buys move the price hard, and selling into that pool moves it hard the other way. This is not a hidden cost — the backing figure on every coin page is exactly how much is there.

A coin between two pools. During a bond, for a few seconds — longer if a step stalls until someone resumes it — the coin is in neither pool and cannot be traded.

Custody and trust: who holds the hedge

This is the part that is not trustless, stated plainly.

The positions sit in a Hyperliquid master account that belongs to no person: its address is derived by NEAR's Chain Signatures from the protocol's hedge contract, and only that contract can have NEAR's signer network sign for it. The vault sends the hedge contract money only through fund_hedge. The hedge contract sends it to Hyperliquid through NEAR Intents 1Click, and on the way back has the master account sign a transfer to a 1Click deposit address whose delivery comes back to the hedge contract, which pays the vault. Orders are signed by a separate agent key that can only trade.

What that leaves you trusting:

The operator key, within the caps. The keeper's NEAR key chooses the 1Click deposit addresses, and a contract cannot verify that an address belongs to 1Click or that a quote pays back the hedge contract: quotes are made off chain. A thief holding that key could therefore misroute up to one transfer's cap per call and a day's cap per day (deployment defaults: $50,000 and $250,000, still to be confirmed) — idle USDC held by the hedge contract, or USDC from the master account. Every transfer is a public event carrying its quote id, and the owner can pause the hedge contract or replace the operator. On the keeper machine the key is a function-call key limited to the hedge contract and the vaults.
The hedge contract's account. Whoever holds a full-access key to the hedge contract's NEAR account could deploy different code, and that code would control the master account. The same goes for the tracker factory. Unlike the launchpad, the runbook does not yet remove those keys; whether they are removed or held by a multisig is not settled. Check the account's keys on NearBlocks.
NEAR's signer network (v1.signer). 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; a threshold of colluding nodes could sign as the master account. It has not yet signed for the hedge contract on mainnet — the sandbox tests use a stand-in, and a mainnet dry run is still to do.
1Click's solvers. For about 30 seconds each way the dollars are with 1Click: at a deposit address issued for the quote, delivered by a solver on the other side. Quotes carry a refund address. The fees (a dry quote cost 0.32% out and 0.22% back) and latencies have not been measured with money.
Hyperliquid's custody. Money on Hyperliquid is held on Hyperliquid's own chain, under its validators and its rules. There is no route back to NEAR that does not pass through Hyperliquid and a bridge.
trade.xyz. It deployed the xyz markets: it runs their oracle, sets their fees and can halt them.
The agent key. It cannot move money out of the account, but it can trade — badly, if compromised. It is valid for at most 180 days and is renewed with a new address each time.
The keeper's NAV. Signed, not proven. The vault checks the signature, not the number: a stolen NAV key could post a false NAV and mint or redeem against it, reaching the vault's idle USDC, until the owner changes the signer or pauses the vault. What the chains do prove is every dollar that left each vault (hedge_funded), every deposit and return the hedge contract made (flake-hedge events), every dollar paid back into a vault (hedge_returned), and — because Hyperliquid accounts are public — the master account's balance and positions. What is not proven anywhere is how that account splits between trackers.

What this removes compared with the Avalanche version: a hot wallet key that could withdraw the whole hedge account anywhere, the hop through Arbitrum and the gas float kept there, and Circle's bridge in the return path.

The switches the vault owner holds, which need nothing from the keeper:

set_hedge_funder(None) — the kill switch. From that moment, no dollar can leave the vault for the venue, whoever asks.
set_paused(true) — stops fund_hedge, minting and redeeming together.

And on the hedge contract, its owner can pause every deposit and return request, lower the caps, or replace the operator. None of these reaches money already on Hyperliquid or with 1Click, and none closes a position: open positions stay open under the venue's rules until the keeper manages them.

What the protocol owner can do

On the launchpad: pause new launches. Nothing else — no fee book, no position, no coin.

On the factory: list or delist the markets the launch form offers (set_underlying), set the defaults new trackers are created with (fees, staleness, buffer, NAV floor, hedge contract), change the NAV signer for new trackers, authorise launchers, create trackers and their reference pools, change the reference-pool depth at which a tracker bonds, and bond a tracker directly.

On each tracker's vault: change or cut off its hedge contract, pause it, change its NAV signer, staleness window and oracle pause, its target leverage and rebalancing band, its NAV floor for minting, its idle buffer, and its fees within hard caps (5% per mint or redeem, 5% a year management — the runbook's defaults are 0.1%, 0.1% and 0), withdraw the protocol's accrued mint and redeem fees (never holders' USDC), and move USDC someone sent the vault outside its books.

On the hedge contract: set the operator, the caps and the managed vaults, approve a Hyperliquid trading key for an address it names, and pause.

On each reference pool: force a re-centre and withdraw the pool's idle inventory — the protocol's own liquidity, not users'.

Every one of these is an on-chain transaction anyone can see. None of them touches a coin that already exists: its pool, its lock, its split and its creator are fixed at launch and no owner action reaches them. The runbook makes the owner a ledger or a multisig, never a key on the keeper machine.

Dependencies outside our contracts

NEAR. The chain itself and its validators. Gas and storage are paid in NEAR.
USDC. Circle's native dollar on NEAR. Circle's USDC has a blocklist: an address on it cannot move USDC, so it cannot buy, sell, redeem or claim in USDC here. If a vault, the hedge contract or the treasury were ever blocklisted, every USDC transfer involving it would fail.
Rhea Finance DCL. The pools live in Rhea's DCL contract, owned by Rhea's DAO, which can pause a pool and upgrade DCL's code. Its 20% share of every swap fee is its own setting.
NEAR Intents 1Click, NEAR's signer network, Hyperliquid and trade.xyz, as above.

Verify rather than trust

Every claim about our contracts is a public view or a source-code read. The account ids will be in Architecture; nothing is deployed yet, so any account presented as ours today is unverified. Once deployed, check that the launchpad has no full-access key, and compare the coin, vault and reference-pool code hashes with a build of the published source (whether that build is reproducible byte for byte on another machine has not been checked yet). If a statement on this page and the chain disagree, the chain is right and we want to hear about it.

Audit status

The contracts have not been audited by a third party. They are unit-tested and tested in a NEAR sandbox running the real Rhea DCL code (version 2.3.13): a launch, a bond, fees, the vault's mint, redeem and queue, the factory and the reference pools. The hedge contract is tested against a stand-in for NEAR's signer network, and the Hyperliquid messages it has signed match Hyperliquid's official SDK byte for byte. Nothing has run on testnet or mainnet yet, and no dollar has crossed to Hyperliquid from NEAR: the planned first live test is a 10 USDC round trip — vault to Hyperliquid through 1Click, back to the hedge contract, into the vault — measuring 1Click's fees and latency both ways. The live tests of the earlier Avalanche version exercised a different venue and bridge, and prove nothing about this one.