Collateral underwriting

Listing a market costs 500k HYPE locked for 183 days, slashable and burned if it goes wrong. The market must then be settled correctly for its whole life. HIP-3 and HIP-4 stakes stack: an operator running both posts 1 million HYPE.

Deployers have fee revenue but not the capital up front. The track tested selling that gap as a service: somebody else posts the stake and watches the covenants, paid from the fee share. It found a two-of-two quorum can run the deployer instead, and nobody, not even that quorum, can take the bonded portion.

Slashing burns the stake, whatever the intent

Three rules from the HIP-3 docs shape the risk:

• Slashed stake is burned, not paid to affected users: nothing is recovered.
• Slashing is technical, not moral. It does not distinguish deviating from a good specification, following a bad one, or having keys compromised.
• Stake stays slashable through the 7-day unstaking queue.

The protocol refuses somebody else’s stake by name

If a deployer’s stake could be somebody else’s, a pooled vault could back deployers with tranching enforced in code. If not, underwriting becomes custody and counterparty risk. The docs leave it open: the HIP-3 page tells liquid staking operators to diligence deployers, since slashing ignores who funded the stake, and muses that a self-bond “could make sense”.

The fourth line of evidence settles it:

Evidence	Result
No wire format	Delegation attaches HYPE to a validator, not a user; HYPE enters a staking account only by a cDeposit from that address’s own spot balance. A third party can only send HYPE to the deployer (then it is the deployer’s) or delegate to a validator
Nobody does it	All 12 mainnet deployers funded the requirement from their own account; across 268 deployer accounts (12 mainnet, 256 testnet) none did otherwise. On testnet (requirement 100 HYPE), 68 accounts hold exactly 100.00000000 HYPE, the signature of funding to a threshold
The threshold is the account’s own balance	A fresh testnet account was refused activation with Insufficient stake at 0 and at 99.5 HYPE, then accepted at 100.5 HYPE, with nothing else on the network changed
The one route that could work is closed by name	A staking link attributes a staking account’s HYPE to a separate trading account. An empty trading account linked to a staking account holding 100 HYPE was refused with Deployer cannot have staking link

The balance test alone cannot decide, since “own balance plus anything attributed to it” predicts the same results. The named refusal can: it is a categorical rejection, not Insufficient stake, so the protocol considered the case and excluded it.

Two details shaped the design:

• The whole staking balance counts, delegated + undelegated: the accepted 100.5 HYPE was delegated to no validator.
• An API wallet cannot reach the bond. An agent could place and cancel orders for its master, but a HIP-4 deployer action or cWithdraw it signed was refused with an error naming the agent’s own address.

A quorum can run a deployer

Two mutually distrusting parties can run one bonded deployer as a native multi-sig, through which every action must then go. 8 of the 12 mainnet deployer accounts already are, at thresholds from 2-of-3 to 4-of-8. The track ran a facility’s sequence on a fresh testnet account:

Step	Operator alone	Operator and underwriter
Convert to 2-of-2 while holding nothing		accepted
Bond 100 HYPE into the staking account	Multi-sig threshold not met	accepted
Activate the outcome venue	Multi-sig threshold not met	accepted; outcomeMeta shows the venue
Withdraw headroom above the requirement	Multi-sig threshold not met	accepted, into the unstaking queue

On a separate account, the original single key was refused after conversion with Multi-sig required: conversion retires it.

Day-to-day operation can be delegated. A quorum setSubDeployers action granted registration and settlement to the operator alone, and the grants read back on chain; everything else needs both signatures. Revocation is itself a deployer action, so the underwriter cannot take a grant back alone.

Nobody can take the bonded portion

While the role is live, the protocol escrows the requirement against everyone, including the full quorum. Bonded at 102.0 HYPE against 100.0 required, a quorum withdrawal of 1.5 was accepted and the next, of 1.0, refused with Insufficient balance to withdraw from CStaking, with the same two signatures. The quorum governs only the headroom and, once releasable, the exit.

The numbers

Quantity	Value	Basis
HIP-3 stake	500k HYPE, held at least 183 days after the dex is deployed	docs
HIP-4 stake	500k HYPE on mainnet, stacking with any HIP-3 stake	digest 02; docs
Testnet requirement	100 HYPE	spec 03
Unstaking queue	7 days on mainnet, confirmed to the second; about 5 minutes on testnet	docs; spec 03
Release condition	once all assets are settled, the required stake is free to be unstaked	docs
Slashing guidance	up to 100% for irregular inputs causing invalid state transitions or prolonged downtime, 50% for brief downtime, 20% for degradation; a stake-weighted median of validator votes; slashed stake burned	docs
Multi-sig signers	up to 10 authorised users	docs
Mainnet deployer accounts, multi-sig	8 of 12	spec 03
Deployer accounts examined	268 (12 mainnet, 256 testnet); none bonded any other way	spec 03
Escrow test	102.0 bonded, 100.0 required: 1.5 withdrawn, next 1.0 refused	spec 03
Deployer fee share	HIP-3 0 to 300%; HIP-4 deployerFeeScale 0 to 10	docs

The underwriter is a co-custodian, not a lender

The underwriter signs on the stake rather than handing it over, the protocol protects the principal from the operator, and slashing is the only path to loss. That is a risk you can price. The original structure was not.

The bond never leaves the deployer's own account. What the underwriter holds is a signature, and the protocol holds the floor.

• The pool cannot hold the bond. It is a staking balance in the deployer’s own account, and CoreWriter does not work for multi-sig users, so no contract can hold, stake or claw it back. A HyperEVM pool holds deposits and a fee waterfall, tranched on the deposit side only; a token implying otherwise is mis-sold.
• The underwriter co-signs slashable actions, so it can decline to list a market whose oracle it will not stand behind.
• The grant set is the key term. Each grant is a slashable action the underwriter no longer sees and cannot revoke alone, so it is negotiated before funding.
• The self-bond has a narrower job: alignment against the one failure no signature sees, faithfully operating a bad specification.
• The term is a bullet with a slashable tail: 183 days, then the 7-day queue. Release is the later of the lock and every asset settled, so a book that cannot wind down extends the facility indefinitely.
• A funded deployer must never carry a staking link. Activation is refused with one; adding one later is undefined, so the monitor treats it as a breach.

The monitor found no slashing on mainnet

The monitor is read-only and uses only the info API. Across every mainnet HIP-3 and HIP-4 deployer it checks bond adequacy and headroom from delegatorSummary (delegated + undelegated), pending withdrawals, signer set and threshold, staking links, sub-deployer grants, cross margin and oracle settings, and a slashing reconciliation. It alerts on transitions, not levels, and treats a failed fetch as silence, not health.

Finding	Detail
Stake and activity line up exactly	Every deployer with non-zero volume or open interest held at least 500k HYPE in its own staking account; every one holding less had zero open interest and zero volume
Low balances are completed terms, not breaches	Each had held the full requirement and released it after the lock, between day 189 and about day 418. One undelegated its whole stake on day 181 and kept its dex: undelegating does not breach the requirement, leaving the staking account does
No mainnet deployer has lost stake it did not ask to withdraw	Stake rises only by deposits and rewards and falls only by requested withdrawals, so delegated + undelegated + pending must be at least deposits minus finalised withdrawals. All 12 reconcile, with surpluses of 0.0029 to 17,562 HYPE in staking rewards: absence of slashing checked arithmetically
Two accounts carry impossible deposit amounts	Deposits with ten decimal places on an eight-decimal token, always their largest, the mark of a float. The reconciliation rounds them to the wei and reports how often
Stake attaches to the deployer of record only	None of the 37 sub-deployer and fee-recipient addresses held any stake
The only early warning is the queue	A non-zero totalPendingWithdrawal means the bond has started to leave, with 7 days’ notice

Two limits. The info API does not expose HIP-4 venue volume, so a facility can be monitored but not priced, and only counterparties who agree to publish can be underwritten. And the monitor flags the track’s own testnet deployer: 205 HYPE against 100 required on a single signer, movable unilaterally; meeting the covenant is the precondition for enforcing it on others.

Five open questions

Open question	Detail
A pilot	Works end to end on testnet; needs a counterparty, a term sheet, an agreed grant set, a co-signing service that applies policy before signing, and a full 183-day lock completed without loss
Slashing frequency	No mainnet deployer has been slashed, so frequency is a documented prior, not a fit. The counterparty multiplier spans 1,948x from best to worst, the model’s largest single risk
Shared bonds	One mainnet deployer carries two perp dexes on 586,072 HYPE, well under two requirements; one has zero open interest and may have been released, so sharing is suggested, not established
Queue behaviour	The testnet queue drains in about five minutes against seven days on mainnet, so redemption logic that passes there will be wrong in production
Late settlement	HIP-4 slashing for late settlement was specified, disclaimed for testnet, and not observed on mainnet

For the native primitive the co-custody model rests on, see Multi-sig accounts. For fee shares, stake cost and slashing, see Deployer economics and risk.