聊天记录
共 3 条，显示第 1-3 条
The official docs only document "type": "subAccounts", which returns clearinghouseState (singular object).
For accounts with unified account / portfolio margin enabled, app.hyperliquid.xyz actually calls a different, undocumented request type: "subAccounts2". Looks like this was added but never documented.
Request:
{"type":"subAccounts2","user":"0x..."}
Response:
[{
"name": "other",
"subAccountUser": "0x...",
"master": "0x...",
"dexToClearinghouseState": [],
"spotState": { "balances": [...] },
"tokenToAvailableAfterMaintenance": [[0, "929.412213"]],
"abstraction": "unifiedAccount"
}]
Would be great to get this added to the info endpoint docs
The official docs only document "type": "subAccounts", which returns clearinghouseState (singular object).
For accounts with unified account / portfolio margin enabled, app.hyperliquid.xyz actually calls a different, undocumented request type: "subAccounts2". Looks like this was added but never documented.
Request:
{"type":"subAccounts2","user":"0x..."}
Response:
[{
"name": "other",
"subAccountUser": "0x...",
"master": "0x...",
"dexToClearinghouseState": [],
"spotState": { "balances": [...] },
"tokenToAvailableAfterMaintenance": [[0, "929.412213"]],
"abstraction": "unifiedAccount"
}]
Would be great to get this added to the info endpoint docs
hm, ok thanks
hm, ok thanks
Hey, found what looks like a regression in modify order handling. We've been running a live chase/re-peg strategy on mainnet since early 2026 that periodically modifies resting GTC orders, and this used to work fine even when the new price crossed the spread (executed as taker). Recently we started seeing modify calls get rejected with a "Post only" error whenever the new price crosses, even though tif is explicitly set to "Gtc" — and worse, the original resting order gets canceled as a side effect of the failed modify, not just the replacement.
Reproduced this cleanly on testnet with a minimal script (attached, hl_modify_test.py), full writeup with repro steps and actual/expected behavior in hl_bug_report.txt. Wanted to check here whether this is intended (i.e. modify always enforces ALO regardless of tif) or a bug, since it's not documented either way.
Hey, found what looks like a regression in modify order handling. We've been running a live chase/re-peg strategy on mainnet since early 2026 that periodically modifies resting GTC orders, and this used to work fine even when the new price crossed the spread (executed as taker). Recently we started seeing modify calls get rejected with a "Post only" error whenever the new price crosses, even though tif is explicitly set to "Gtc" — and worse, the original resting order gets canceled as a side effect of the failed modify, not just the replacement.
Reproduced this cleanly on testnet with a minimal script (attached, hl_modify_test.py), full writeup with repro steps and actual/expected behavior in hl_bug_report.txt. Wanted to check here whether this is intended (i.e. modify always enforces ALO regardless of tif) or a bug, since it's not documented either way.
Hyperliquid