聊天记录
共 24 条，显示第 1-24 条
An /info request to`allPerpMetas` will return that - a market that is in a halted state it will have the `isDelisted` flag set to `true`:
```json
{
"szDecimals": 4,
"name": "xyz:ALUMINIUM",
"maxLeverage": 20,
"marginTableId": 20,
"onlyIsolated": true,
"isDelisted": true,
"marginMode": "strictIsolated",
"growthMode": "enabled",
"lastGrowthModeChangeTime": "2026-01-21T21:02:05.395415841"
},
```
An /info request to`allPerpMetas` will return that - a market that is in a halted state it will have the `isDelisted` flag set to `true`:
```json
{
"szDecimals": 4,
"name": "xyz:ALUMINIUM",
"maxLeverage": 20,
"marginTableId": 20,
"onlyIsolated": true,
"isDelisted": true,
"marginMode": "strictIsolated",
"growthMode": "enabled",
"lastGrowthModeChangeTime": "2026-01-21T21:02:05.395415841"
},
```
Yes it can
Yes it can
You could also send a `subAccounts2` request with the master address and all the subaccounts will be listed.
You could also send a `subAccounts2` request with the master address and all the subaccounts will be listed.
If you send a `userRole` info request with the subaccount address, the master account it belongs to will be returned like `{ "role": "subAccount", "data": { "master": "0x1234...abcd" } }`
If you send a `userRole` info request with the subaccount address, the master account it belongs to will be returned like `{ "role": "subAccount", "data": { "master": "0x1234...abcd" } }`
Yes it is, all `/exchange` endpoint API calls are actions: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint
Yes it is, all `/exchange` endpoint API calls are actions: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint
`userRateLimit` returns API usage data for a user, which you can then query at a regular interval to track usage: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint#request-body-5
`userRateLimit` returns API usage data for a user, which you can then query at a regular interval to track usage: https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/info-endpoint#request-body-5
There is a much written about latency optimisation in this channel and others, just search “latency”. Besides that latency optimisation is outside the scope of the API.
There is a much written about latency optimisation in this channel and others, just search “latency”. Besides that latency optimisation is outside the scope of the API.
HyperCore block times are 70ms anyway.
There is a speedbump on taker (spread crossing GTC/IOC) orders that is an intentional design of Hyperliquid.
HyperCore block times are 70ms anyway.
There is a speedbump on taker (spread crossing GTC/IOC) orders that is an intentional design of Hyperliquid.
You would have to download the replica_cmds from s3 historical archive
You would have to download the replica_cmds from s3 historical archive
An /info request to the `allPerpMetas` will return that
An /info request to the `allPerpMetas` will return that
You can do that by tailing the current hour’s node_fills file and parsing each fill.
You can do that by tailing the current hour’s node_fills file and parsing each fill.
There aren’t any ways to easily do this from the API. One way could be by downloading the node_fills from the s3, which get uploaded every hour. If you need more real-time than that you would need to run your own node and tail the node fills.
There aren’t any ways to easily do this from the API. One way could be by downloading the node_fills from the s3, which get uploaded every hour. If you need more real-time than that you would need to run your own node and tail the node fills.
<@561226480189964298> Explanation here for SetGlobalAction
<@561226480189964298> Explanation here for SetGlobalAction
A more direct way is to send an initial `allPerpMetas` info request to get all perp pairs, filter out delisted ones, and then subscribe `trades` for each pair. This gives you a real-time liquidations feed.
A more direct way is to send an initial `allPerpMetas` info request to get all perp pairs, filter out delisted ones, and then subscribe `trades` for each pair. This gives you a real-time liquidations feed.
In any case, this is unrelated to the API
In any case, this is unrelated to the API
This is comparing apples to oranges, tradexyz listings are onchain perp contracts, your brokerage is almost certainly offering leveraged exposure to equities via CFDs which are a completely different product. The closest comparison may be other CeX equity perps listings such as those offered by Bybit, but even they don’t have long tail listings like NFLX, URNM, EBAY etc. Equity perps are also an unusually new product, less than 1 year old.
This is comparing apples to oranges, tradexyz listings are onchain perp contracts, your brokerage is almost certainly offering leveraged exposure to equities via CFDs which are a completely different product. The closest comparison may be other CeX equity perps listings such as those offered by Bybit, but even they don’t have long tail listings like NFLX, URNM, EBAY etc. Equity perps are also an unusually new product, less than 1 year old.
You can charge users a builder fee of up to 0.1% of the notional value of the order or 1% for spot. If users onboard to Hyperliquid through your app you can also set their referral code to your one, many builder code apps do this.
You can charge users a builder fee of up to 0.1% of the notional value of the order or 1% for spot. If users onboard to Hyperliquid through your app you can also set their referral code to your one, many builder code apps do this.
No you have to build that yourself
No you have to build that yourself
Any previously unseen timestamp parsed from newly written data represents a new block
Any previously unseen timestamp parsed from newly written data represents a new block
The latency of bbo messages should be the same as any other per-block cadence subscription channel, such as trades or a users orderUpdates.
Running and fine tuning a non-validating node for latency is quite involved compared to using the websockets api.
The latency of bbo messages should be the same as any other per-block cadence subscription channel, such as trades or a users orderUpdates.
Running and fine tuning a non-validating node for latency is quite involved compared to using the websockets api.
Bbo is pushed per-block when the best bid or ask changes. Unlike l2book, no initial bbo snapshot is pushed immediately upon connection, so the first bbo message can take time to arrive on less active markets.
Bbo is pushed per-block when the best bid or ask changes. Unlike l2book, no initial bbo snapshot is pushed immediately upon connection, so the first bbo message can take time to arrive on less active markets.
Unlikely to be an option at the data egress rates HL is clocking.
Unlikely to be an option at the data egress rates HL is clocking.
It may also be a way to save on their (presumably) enormous AWS costs, whilst further incentivising users that need real-time feeds to run nodes.
It may also be a way to save on their (presumably) enormous AWS costs, whilst further incentivising users that need real-time feeds to run nodes.
It’s better to subscribe to `openOrders` and `orderUpdates`, and use the `orderUpdates` feed (which is per-block) to keep a local open orders state updated by merging those updates with open orders.
It’s better to subscribe to `openOrders` and `orderUpdates`, and use the `orderUpdates` feed (which is per-block) to keep a local open orders state updated by merging those updates with open orders.
Hyperliquid