Split, merge, negate

Conversions mint and redeem outcome contracts without touching the order book. Without them, a new market’s first trade would need a seller of a contract that doesn’t exist yet, and a holder of both sides would wait for settlement to get 1 back.

Since each set converts at exactly 1, a gap between related books is an arbitrage. Say a question has outcomes A, B and fallback F, with best Yes asks 0.46, 0.31 and 0.17:

• Buy 100 Yes of each → you pay 94 USDC.
• mergeQuestion the 100 sets → you receive 100 USDC, a 6 USDC gain.

Four conversions, one action

All four are sub-actions of the L1 action userOutcome.

Conversion	You give	You get	Applies to
splitOutcome	X quote tokens	X Yes and X No of one outcome	any outcome
mergeOutcome	X Yes and X No of one outcome	X quote tokens	any outcome
mergeQuestion	X Yes of every outcome in a question	X quote tokens	questions
negateOutcome	X No of one outcome in a question	X Yes of every other outcome in that question, fallback included	questions

Each swaps positions with identical payoffs:

• Split and merge. One Yes plus one No pays f + (1 - f) = 1 in every case.
• Merge question. Exactly one outcome settles to 1, so one Yes of every outcome is certain to pay 1; the protocol pays it now.
• Negate. No on A pays 1 exactly when another outcome wins, as does one Yes on every other outcome.

Outcomes A, B and fallback F: split A, negate its No, and the resulting Yes of every outcome merges back into exactly 1 USDC.

The numbers

Item	Value
L1 amount	decimal string of whole contracts, such as "10"
amount: null	merge the maximum (mergeOutcome, mergeQuestion only)
mergeQuestion capacity	limited by your smallest Yes holding in the question
CoreWriter action id	17
CoreWriter ops	0 split, 1 merge, 2 merge question, 3 negate
CoreWriter wei	1e8 per contract, a whole multiple of it
CoreWriter wei = 0	merge the maximum
Measured CoreWriter latency	same block, 0.01 to 0.68 s after the block timestamp (testnet, n = 6)

Closing gaps across a question

Within one outcome there is no arbitrage, since the shared book enforces Yes plus No equals 1. Split and merge are inventory tools there: split to quote both sides of a new book, merge leftover pairs into 1 each without crossing the spread.

When	Trade	Fees and size
Yes asks across the question sum below 1	buy one Yes of each outcome, mergeQuestion the set for exactly 1	buys are opening trades, unbilled in the mainnet fee measurement (7,256 fills); the thinnest book caps size
Yes bids sum above 1	split 1 quote token on any outcome, negate the No, sell the set	sells are closing trades and pay the fee, so the gap must exceed it
No on A is offered below the sum of the other outcomes’ Yes bids	buy it, negate, sell the basket

Conversions from code

The four wire shapes, in exactly this key order: msgpack hashes keys in insertion order, so key order is part of the signature (signing).

{"type": "userOutcome", "splitOutcome": {"outcome": 1121, "amount": "10"}}
{"type": "userOutcome", "mergeOutcome": {"outcome": 1121, "amount": null}}
{"type": "userOutcome", "mergeQuestion": {"question": 3, "amount": "5"}}
{"type": "userOutcome", "negateOutcome": {"question": 3, "outcome": 11, "amount": "5"}}

Fills label conversions Split Outcome, Merge Outcome, Merge Question and Negate Outcome, alongside Settlement; only Buy and Sell cross the book. These structural fills carry a nominal 1/n price and were about a fifth of outcome fills measured. Datasets disagree on counting them, so exclude them from trading volume unless stated (measuring volume).

From a contract: CoreWriter action 17, encoded (uint8 op, uint32 question, uint32 outcome, uint64 wei). Split and merge ignore question, merge question ignores outcome, negate uses both; unused fields must be 0, or HyperCore drops the payload while the EVM transaction still succeeds.

The docs say only that wei must be a multiple of size. On testnet, wei = 100000000 minted exactly one of each side and moved 1 USDC, both legs in the transaction’s own block (CoreWriter).

payload = 0x01 000011 abi.encode(uint8 op, uint32 question, uint32 outcome, uint64 wei)
split 1 contract of outcome 1121:   op 0, question 0, outcome 1121, wei 100000000

Conversion pitfalls

Use negateOutcome

Earlier documentation and some SDK examples showed negateQuestion. The chain takes negateOutcome, as Hyperliquid’s own interface and the current exchange endpoint docs show.

Amounts are plain decimal strings

The docs’ split example writes "123.0"; send "123". Trailing zeros change the signed bytes, which the signing docs list as a common cause of a signature recovering the wrong address.

• Whether an API wallet may sign splits and merges is unresolved: two codebases sign them with an agent key, a third tool refuses. Test on your own account.
• A refused CoreWriter conversion (non-zero unused field, wei not a whole contract, short balance) leaves no EVM trace. Check the balance a block later.
• Adding an outcome to a live question keeps complete sets complete: fallback Yes holders are credited the same Yes in it.
• Negate runs one way. The reverse, Yes of every other outcome into No of A, is a split of A then merge question: the split’s Yes A completes the set, the merge returns the collateral, and No A remains.

For the alternative to merging, see Settlement; for split-and-quote in practice, Options on the borrow rate.