Becoming an outcome deployer (HIP-4)

Activation is a one-way door. It claims a venue name that is never released and binds the stake for at least 183 days, and only a deactivation, itself permanent, ends it. So get account mode, custody and stake right first. Standard: HIP-4.

7 steps to a live venue

Everything before activation can be changed. Activation claims the venue name for good, so account mode, custody and stake come first.

1. Fund the master wallet. Until it exists on HyperCore, every action fails with User or API Wallet ... does not exist or Must deposit before performing actions, before any stake check.

2. Set Standard mode (account modes), as the docs require: Manual in the app, disabled in userAbstraction and userSetAbstraction, i via agentSetAbstraction.

3. Optionally go multi-sig, before the stake arrives. The quorum then signs everything, withdrawals and activation included, and CoreWriter stops working (multi-sig accounts).

4. Stake in the deployer’s own staking account; undelegated HYPE counts (testnet: 99.5 refused with Insufficient stake, 100.5 all undelegated accepted). It stacks with any HIP-3 requirement.

5. Activate, irreversibly:

   { "type": "activateOutcomeDeployer", "activate": { "venueName": "ab" } }

   Master key or quorum only: an agent-signed activation was refused, naming the agent’s address. Browser wallets refuse the chain-1337 L1 domain, so add a placeholder chain-1337 network or sign from a raw key. venueName is camelCase; venue_name signed a different action and recovered a different address.

6. Delegate. A single-key deployer approves an API wallet to register and settle; a multi-sig grants a sub-deployer from the quorum (measured), which then acts with one signature.

7. Deploy from templates.

Venue names are global

Venue names follow HIP-3 dex name rules and are unique across all venues, deactivated ones included. A venue cannot match a perp dex name or spot, and no later dex can claim it. Every outcomeDeploy carries it at top level, keys in exactly this order:

{ "type": "outcomeDeploy", "venue": "ab", "operation": { "<variant>": { } } }

Rejected: the older {"type": "spotDeploy", "outcome": {...}}, and outcomeDeploy with the variant outside operation.

Sub-deployers

{ "type": "outcomeDeploy", "venue": "ab", "operation": { "setSubDeployers": [
  { "variant": "registerStandaloneOutcomeFromTemplate", "user": "0x...", "allowed": true },
  { "variant": "settleOutcome", "user": "0x...", "allowed": true } ] } }

variant is registerStandaloneOutcomeFromTemplate, registerQuestionFromTemplate, registerAndAssociateNamedOutcomeFromTemplate, settleOutcome or settleQuestion (which authorises settleQuestion2).

A sub-deployer acts under the deployer’s venue: its registrations count toward the deployer’s limits, and it settles only the deployer’s outcomes. Grants read back in outcomeMeta as subDeployers, a list of [variant, [addresses]]; revoking one is a deployer action.

Limits per venue

	Mainnet	Testnet
Stake	500k HYPE	100 HYPE
Active outcomes	100	10
New outcomes per day	500	50
Minimum stake period	183 days	183 days
Deployment gas	none	none

Only the chain knows remaining capacity:

{ "type": "outcomeDeployerLimits", "venue": "ab" }

{ "nDailyOutcomesRemaining": 50, "nActiveOutcomesRemaining": 14 }

• Settling an outcome frees an active slot. At 100 active on mainnet, nothing more lists until one settles.
• registerAndAssociateNamedOutcomeFromTemplate counts toward both caps.
• A rejected deploy still uses one of the day’s slots.
• Per the docs a question of N outcomes registers N + 1, all against the active cap; unmeasured, and the fallback’s daily-cap treatment is undocumented.

Deactivation

{ "type": "activateOutcomeDeployer", "deactivate": null }

Deactivation needs 183 days elapsed and no active outcomes. It is permanent: the account can never reactivate, and its venue name stays reserved.

The numbers

Parameter	Value
Venue name	2 to 4 lowercase ASCII letters, never released
Mainnet stake, limits	500k HYPE; 100 active; 500 per day; 183 days
Testnet stake, limits	100 HYPE; 10 active; 50 per day; 183 days
Questions	at most 100 question outcomes each
Unstaking queue	7 days on mainnet; about 5 minutes on testnet
Signing domain for deployer actions	Exchange, chainId 1337, source “a” mainnet, “b” testnet

Deploying from code

• Deploys return no outcome id. Find it in outcomeMeta (entries template:<id>, sorted key:value description). Record the intent first; on a timeout, 5xx or 429, check outcomeMeta before sending again. Nonces are single-use, so an identical resend cannot execute twice, but re-signing with a new nonce can.
• Signing. L1 actions: MessagePack of the action in key order, nonce and vault marker, hashed and signed through the Agent type. Tuples sorted, addresses lowercase, no trailing zeros (signing, multi-sig).
• Some tooling checks only delegatorSummary.delegated, stricter than the chain.

Common traps

• A staking link disqualifies the account: activation was refused with Deployer cannot have staking link (deployer economics).
• The requirement is escrowed. While the role is live, any staking withdrawal below it is refused, whoever signs.
• Testnet unstakes in about 5 minutes, mainnet in 7 days: exit logic tested on testnet is wrong in production.
• The docs page is headed “Testnet-only”, but HIP-4 deployment is live on mainnet.

Next, choose what to list in outcome templates and keywords, then see settling outcomes for your obligation.