H10X: a fully backed index of the Hedera ecosystem

01Abstract

H10X is a token on the Hedera Token Service (HTS) that represents a weighted basket of ten tokens from the Hedera ecosystem: HBAR, Bitcoin and Ether bridged to Hedera, and seven native projects covering trading, lending, liquid staking, carbon credits, real-world assets, wallets and community.

Every H10X is backed by the basket itself. The tokens are held by H10XVault, an immutable smart contract with no proxy and no admin key. Anyone can issue H10X by depositing the basket in the vault's current proportions, and any holder can redeem H10X for their share of every token, at any time. Issue and redeem need no price oracle and no custodian, and redemptions can never be paused.

Day to day, people buy and sell H10X with HBAR on SaucerSwap. A keeper keeps the pool price close to the net asset value (NAV) by arbitraging between the pools and the vault, so buying pressure turns into new deposits in the vault. A 2-of-3 multisig reviews the basket every quarter under published rules. It can change weights and rebalance within limits set in the contract, but the contract has no function to withdraw the basket.

02The problem

Hedera has a growing ecosystem of tokens, but holding a broad, balanced position in it is hard work:

• Many tokens, many steps. Each token needs its own association, its own swap and its own price impact. Ten positions mean ten trades to enter, ten to exit and constant manual rebalancing.
• Thin markets. Many ecosystem tokens have shallow pools. A small buyer can lose more to slippage than to fees, and a single position can move far from its target weight.
• Issuer controls. On Hedera, a token can carry keys that let its issuer freeze accounts, pause transfers, require KYC or charge custom fees. A basket that ignores these keys can be blocked by any one of its issuers.
• Trust in custodians. An index held off-chain by a company asks holders to trust that company's books. An on-chain index that cannot be redeemed is only a price tracker.

H10X answers each point: one token and one association, a basket that follows published rules, admission checks enforced by the contract itself, and backing that anyone can verify on-chain and take out in kind.

03How H10X works

Properties

• Fully backed. The vault is the H10X token's treasury and its only supply key. H10X can only be minted when the proportional basket goes in, and it is burned when the basket comes out.
• Redeemable in kind. Any holder can burn H10X and receive their share of each token directly from the contract. Redemptions cannot be paused by anyone.
• No oracle in issue and redeem. Both use the vault's actual balances. Prices only matter off-chain: for the NAV shown in the dapp, the keeper and rebalancing.
• Immutable. No proxy and no admin key: the code on mainnet can't be changed or replaced. The source is verified on Sourcify (exact match).
• Bounded governance. Every power of the multisig is limited in the code: at most ten components, fees capped at 1%, swaps only between components through fixed routers, a cap per trade and a mandatory minimum output.

04The basket and its methodology

The official basket (version 3, October 2026) and its target weights:

4.1 Selection rules

1. A Hedera (HTS) token with a SaucerSwap pool against HBAR.
2. Its issuer cannot block the vault: no freeze, pause, KYC or fee-schedule key and no custom fees. The contract checks this itself when a token is added (section 4.3).
3. SaucerSwap liquidity in line with its weight: at least $50k for a 5% weight, $250k for 10% and $1M for 15–20%, plus at least $500 of average daily volume.
4. An active project with at least 12 months of history. For BTC and ETH, the original asset's history counts.
5. Reviewed every quarter. Changes are signed by the 2-of-3 multisig and announced beforehand.

4.2 Weighting

Weights are fixed tiers, not market-cap weights: market caps on Hedera are dominated by HBAR, and a cap-weighted basket would be little more than HBAR. The tiers give the network token the largest single weight (20%), anchor the basket with Bitcoin (15%) and Ether (10%), and give each ecosystem sector a meaningful share. The 5% tier is for tokens that meet every rule but whose liquidity does not yet support 10%. The largest single weight is 20%.

Weights are targets. Between rebalances the actual weights drift with prices; the dapp shows both the target and the live weight of every token in the vault.

4.3 Admission checks in the contract

When the multisig adds a token, the vault reads its keys and custom fees from the Hedera Token Service and rejects it if it has a KYC, freeze, fee-schedule or pause key, or any custom fee. On Hedera such keys cannot be added to a token after it is created, so a token that passes once stays safe from them. Other keys are allowed but disclosed:

An admin key can delete its token. The vault handles that case: a deleted component can be removed by the multisig, and redemptions can skip it so holders always get the rest of the basket. A wipe key, held here only by the LayerZero bridge connector for WBTC and WETH, is part of the bridge's trust model and is listed as a risk in section 12.

4.4 How a basket change is made

1. Exit: the multisig sets the leaving token's target weight to 0, then sells its whole balance in a single swap. The swap that empties the token also removes it from the basket, in the same transaction.
2. Entry: the multisig adds the new token together with the new target weights (the new token's weight must be above 0), and buys it through rebalancing swaps.
3. Weights: the exact target weights are set, and the remaining differences are rebalanced.

Each step is a separate multisig transaction signed by two of the three members, and each one is visible on HashScan. Holders can redeem at any point during a change.

4.5 Changes to the basket

4.6 Backtest of the launch basket

Before launch, the launch basket was simulated over three years of real prices (October 2023 to September 2026, weekly data from Binance and SaucerSwap, monthly rebalancing, 0.3% cost on every rebalancing trade). Tokens that did not exist yet were left out and their weight was shared among the rest until they appeared.

A backtest is a simulation, not a track record, and the past says nothing reliable about the future. The basket fell 66% from its peak in September 2025 to July 2026. The backtest will be regenerated with the current basket; the full study is at h10xindex.xyz/backtest.

06Governance

The vault's owner, guardian and rebalancer are the same account: a Hedera multisig, 0.0.10907480, that needs two of its three members' signatures for every action. Members' keys are never stored on the servers that run the keeper and the website.

6.1 Limits on rebalancing

• Both ends of a swap must be basket components; value can only move between components.
• Only through the SaucerSwap V1 and V2 routers fixed when the vault was deployed.
• At most 20% of the sold token's balance per swap. The exception is a token whose weight is already 0, which can be sold in full so it can leave.
• Every swap needs a non-zero minimum output and a deadline, and the vault measures the balances before and after to check what was really spent and received.

6.2 Process

Proposals are created as Hedera scheduled transactions and signed one at a time from the governance panel of the dapp; each one must execute before the next is built, because it is tied to the configuration version. The team's tooling quotes every swap against on-chain prices before proposing it, and the minimum output is set from that quote. Before signing, the panel decodes the real transaction from the network and warns if it does not target the official vault, if a swap routes through tokens outside the basket, or if its minimum output is more than 5% below the current price. Basket changes are announced before they are signed.

07Market and keeper

7.1 Where H10X trades

Holders buy and sell H10X with HBAR on SaucerSwap, in one swap, from any Hedera wallet or from the H10X dapp. Two pools are planned: an H10X/HBAR pool on SaucerSwap V2 (concentrated liquidity, 0.3% fee tier), which has been proposed to the SaucerSwap DAO because V2 pools are approved by its vote, and optionally a SaucerSwap V1 pool, which is permissionless. Buying and selling in the dapp opens when the pools are live.

7.2 The keeper

The keeper is a service run by the team with its own operating account, which has no role in the vault. In every cycle it computes the NAV, reads both pools and picks the most profitable correction:

• Premium (pool price above NAV): issue H10X with basket tokens from its inventory and sell them in the pool.
• Discount (pool price below NAV): buy H10X in the pool and redeem it for the basket.
• Between pools: buy in the cheaper pool and sell in the dearer one, without touching the vault.

Each trade is sized up to the point where the next H10X stops being profitable. After arbitrage the price settles within about ±0.8% of the NAV: the 0.3% pool fee plus the 0.5% vault fee.

7.3 How the vault grows

Buying H10X in the pool only moves existing H10X from the pool to the buyer. When buying pushes the price above the NAV, the keeper issues new H10X, which means depositing the basket in the vault, and sells them into the pool. The vault therefore grows with net demand, while the NAV per H10X only moves with the prices of the ten tokens. When holders sell, the keeper buys and redeems, and the vault shrinks. Issue and redeem are open to anyone, so any other arbitrageur can do the same.

7.4 Liquidity that follows the NAV

The protocol's own V2 liquidity is a concentrated position of ±20% around the NAV. When the NAV enters the outer 20% of the range, or leaves it, and stays there for 10 minutes, the keeper recentres the position on the NAV in a single transaction, keeping its value. It decides by the NAV and never by the pool price, so a large trade cannot force a recentring. Recentring is limited to once every 6 hours and three times a day.

These defaults come from a range laboratory that replays three years of real NAV moves and stress paths (double volatility, a 35% drop in an hour, swings at the range edge) through the same code the keeper runs.

7.5 Keeper safety limits

• Caps on the size of every trade, a minimum profit per trade, and an automatic stop if it loses more than a set amount in 24 hours.
• It does nothing while a price source is in dispute, or while a pool is more than 20% away from the NAV: a jump that large is reviewed by a person.
• Token allowances are always revoked after use, and the account keeps an HBAR reserve for fees.
• If the keeper stops, nothing is at risk in the vault: the pool price may drift from the NAV until it is back, and holders can always redeem directly.

08Security

• Tests: 124 Foundry tests, including unit, fuzz and invariant tests and economic simulations. Adversarial campaigns of millions of random calls found no violation, and mutation testing caught 35 of 36 deliberately planted bugs (the survivor changes nothing).
• Static analysis: Slither 0.11.6 and Aderyn 0.6.8; every result was checked by hand and none was exploitable.
• Manual review: two rounds with proofs of concept. Version 1.3.0 fixes every finding except F-1 (trust in the multisig, by design; section 6) and F-5 (dust sent to a token that never held a balance can block its removal; buying some and exiting works around it, and nothing is at risk).
• Testnet rehearsal: the full life cycle of 1.3.0 ran on Hedera testnet, including a basket token deleted by its issuer.
• Off-chain tools: the keeper, rebalancing and basket changes are rehearsed in a simulator of the vault and SaucerSwap before any mainnet action.

To report a vulnerability, email h10xindex@gmail.com with the details and, if possible, a proof of concept, and please don't disclose it publicly until we have answered.

09Transparency

• Verified source: exact match on Sourcify, and the public GitHub repository rebuilds the same bytecode (solc 0.8.28, Cancun, 200 runs) with its tests running in CI.
• Everything on-chain: every issue, redeem, swap, weight change and fee claim is an event of the vault, visible on HashScan.
• Live composition: the dapp shows the vault's balances, the live weight of each token, the NAV and its history. The same data is served as a public JSON API.
• Public metrics: value in the vault, holders, active accounts, transactions and pool liquidity, with their daily history, for grant programmes and anyone else who wants to follow the project.
• Published rules: the selection rules, the basket and its change history are on the website and in this paper.

11Roadmap

12Risks

• Market risk. All ten tokens are volatile and closely correlated with HBAR. The value of H10X can fall sharply; the launch basket's backtest lost 66% from peak to trough.
• Smart-contract risk. The vault has had a self-review, not an independent audit, and is immutable: a bug could not be patched, only worked around by migrating to a new vault.
• Governance risk. The multisig is trusted with the quality of rebalancing (F-1). If two of three member keys were compromised, value could be lost through bad swaps, a little at a time within the per-trade cap.
• Component risk. A component can lose its value, be exploited (as Bonzo's lending market was in July 2026) or be deleted by its issuer. WBTC and WETH depend on the LayerZero bridge, whose connector holds their supply and wipe keys.
• Liquidity risk. Pools for some components are small, and the H10X pools will be small at first. Large trades move prices, rebalancing costs grow, and the H10X price can drift from the NAV if the keeper is stopped or short of inventory.
• Price-data risk. The NAV, the keeper and rebalancing quotes use on-chain SaucerSwap prices, which can be moved in thin pools. Guards exist, but no price source is perfect.
• Platform risk. H10X depends on Hedera, the Hedera Token Service and SaucerSwap working as they do today.
• Regulatory risk. Rules for crypto-asset products, including MiCA in the EU, may affect how H10X can be offered in some places.

13Team and contact

Website h10xindex.xyz · X @H10Xtoken · email h10xindex@gmail.com · code github.com/burnbytes26/H10X-index

14Appendix: addresses