TGTGInsighttelegram intelligenceLIVE / telegram public index
← Hyperliquid Announcements
Hyperliquid Announcements avatar

TGINSIGHT POST

Post #441

@hyperliquid_announcements

Hyperliquid Announcements

Views7,920Post view count
PostedSep 2509/25/2025, 07:24 AM
Post content

Post content

HIP-3 on testnet is now available for mainnet level bug bounties. There are several medium severity "Easter egg" bugs intentionally left for people to find on testnet, as an added incentive for detectives to investigate. These "bugs" have simple fixes and will be resolved for mainnet launch regardless of whether someone finds them. As always, the first complete report of each bug is the only eligible one for the bug bounty program. Initial HIP-3 spec for mainnet (live on testnet) 1. The staking requirement for mainnet will be 500k HYPE. This requirement is expected to decrease over time as the infrastructure matures. Any amount staked above the most recent requirement can be unstaked. The staking requirement is maintained for 30 days even after all of the deployer's perps have been halted. 2. Any deployer that meets the staking requirement can deploy one perp dex. As a reminder, each perp dex features independent margining, order books, and deployer settings. A future upgrade may support multiple dex deployments sharing the same deployer and staking requirement. 3. Any quote asset can be used as the collateral asset for a dex. As a reminder, assets that fail to meet the permissionless quote asset requirements will lose quote asset status based on onchain validator vote. Such a vote would also disable perp dexs that use this asset as collateral. 4. HIP-3 deployers are not subject to slashing related to quote assets. On a future upgrade, dexs with disabled quote assets would support migration to a new collateral token. This is not expected to happen on mainnet, as quote token deployers have their separate staking and slashing conditions. In summary, the quote asset choice is important for trading fee and product considerations, but is not an existential risk for HIP-3 deployers. 5. The first 3 assets deployed in any perp dex do not require auction participation. Additional assets go through a Dutch auction with the same hyperparameters (including frequency and minimum price) as the HIP-1 auction. The HIP-3 auction for additional perps is shared across all perp dexs. Future upgrades will support improved ergonomics around reserving assets for time-sensitive future deployments. 6. Isolated-only margin mode is required. Cross margin will be supported in a future upgrade. 7. HIP-3 markets incorporate the usual sources of trading fee discounts, including staking discounts, referral rewards, and aligned collateral discount. From the deployer perspective, the fee share is fixed at 50%. From the user perspective, fees are 2x the usual fees on validator-operated perp markets. The net effect is that the protocol collects the same fee regardless of whether the trade is on an HIP-3 or a validator-operated perp. User rebates are unaffected, and do not interact with the deployer. Deployer configurability of fees will be supported in a future upgrade. 8. Aligned stablecoin collateral will automatically receive reduced fees once the alignment condition (which is being updated based on user and deployer feedback) is implemented. HIP-3 Slashing (note: in all usages below, "slashing" is only in the context of HIP-3) While slashing is ultimately by validator quorum, the protocol guidelines have been distilled from careful testnet analysis, user feedback, and deployer feedback. The guiding principle is that slashing is to prevent behavior that jeopardizes protocol correctness, uptime, or performance. A useful rule of thumb is that any slashable behavior should be accompanied by a bug fix in the protocol implementation. Therefore, HIP-3 should not require slashing in its final state. However, slashing is an important safety mechanism for a practical rollout of this large feature set. Slashing is technical and does not distinguish between malicious and incompetent behavior. Relatedly, slashing does not distinguish between 1. A deployer that deviates from a well-designed contract spec 2. A deployer that faithfully follows a poorly designed contract spec 3. A deployer whose private keys are compromised