聊天记录
共 15 条，显示第 1-15 条
ALO priority and the full range of IOC priority fees are live on mainnet. Both are additive features, and neither includes breaking changes for API users.
Thank you to all users who have provided feedback. The docs have been updated with further details and examples. The page https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/optimizing-latency is now the docs entry point for technical details about latency. It includes links to other pages, e.g. https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees.
ALO priority and the full range of IOC priority fees are live on mainnet. Both are additive features, and neither includes breaking changes for API users.
Thank you to all users who have provided feedback. The docs have been updated with further details and examples. The page https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/optimizing-latency is now the docs entry point for technical details about latency. It includes links to other pages, e.g. https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees.
IOC priority fees on testnet now support the range 8bps -> 100%. This range has identical prioritization effect in the mempool, so there is no breaking change compared to mainnet. In the range 8-100bps, priority fee is only used as a sorting mechanism for such orders received at a similar time. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details and examples.
IOC priority fees on testnet now support the range 8bps -> 100%. This range has identical prioritization effect in the mempool, so there is no breaking change compared to mainnet. In the range 8-100bps, priority fee is only used as a sorting mechanism for such orders received at a similar time. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details and examples.
ALO orders now support priority fees on testnet. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details. As always, feedback is much appreciated.
ALO orders now support priority fees on testnet. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details. As always, feedback is much appreciated.
As previously announced https://discord.com/channels/1029781241702129716/1208476333089497189/1501068827801423912, DEX abstraction will be fully discontinued on the next network upgrade. Builders and automated traders should migrate to unified account and disabled abstraction, respectively.
As previously announced https://discord.com/channels/1029781241702129716/1208476333089497189/1501068827801423912, DEX abstraction will be fully discontinued on the next network upgrade. Builders and automated traders should migrate to unified account and disabled abstraction, respectively.
Based on deployer feedback, on the next network upgrade, the reserve deployment allocation for HIP-3 deployers will increase from `7` to `7 + 0.2 * n_auction_deployments`. The scale factor may increase over time as the protocol scales.
Based on deployer feedback, on the next network upgrade, the reserve deployment allocation for HIP-3 deployers will increase from `7` to `7 + 0.2 * n_auction_deployments`. The scale factor may increase over time as the protocol scales.
Three network upgrades from now, the `webData2` websocket subscription will be discontinued. As a reminder, builders should migrate to `webData3` for up-to-date data
Three network upgrades from now, the `webData2` websocket subscription will be discontinued. As a reminder, builders should migrate to `webData3` for up-to-date data
Two network upgrades from now, the maximum batch size for batched trading actions (order, modify, cancel, cancelByCloid) will be set to 100. This only affects a very small percentage of transactions, but automated traders who depend on large batch sizes should chunk their requests accordingly.
Two network upgrades from now, the maximum batch size for batched trading actions (order, modify, cancel, cancelByCloid) will be set to 100. This only affects a very small percentage of transactions, but automated traders who depend on large batch sizes should chunk their requests accordingly.
On the next network upgrade, order priority fees will be extended to IOC orders on all non-outcome assets. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details
On the next network upgrade, order priority fees will be extended to IOC orders on all non-outcome assets. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/priority-fees for more details
Thank you for the feedback. This has been raised before, and the point is well taken. The complication is that HyperEVM is atomically composable with HyperCore via precompiles and system transactions, and also generates HyperCore traffic via CoreWriter. The execution of a single HyperEVM block must fit within the execution of a single L1 block. I believe this is an order of magnitude faster than most general purpose chains, and the composability with HyperCore is a unique constraint that other chains do not build around. The most important property to maintain is that HyperEVM composes natively with HyperCore. At least how I think about it, HyperEVM excels in applications where programmability is added to HyperCore, rather than standalone EVM applications. Examples include liquid staking, tokenized vaults, native RWA issuance (e.g. USDC).
It is of course possible to build a general purpose EVM side chain with no direct composability with HyperCore, but that defeats most of the purpose and those applications can be built on existing chains anyway. It would be helpful to flag any general purpose EVM applications that do not benefit from direct HyperCore native implementation that you think HyperEVM ought to support.
Thank you for the feedback. This has been raised before, and the point is well taken. The complication is that HyperEVM is atomically composable with HyperCore via precompiles and system transactions, and also generates HyperCore traffic via CoreWriter. The execution of a single HyperEVM block must fit within the execution of a single L1 block. I believe this is an order of magnitude faster than most general purpose chains, and the composability with HyperCore is a unique constraint that other chains do not build around. The most important property to maintain is that HyperEVM composes natively with HyperCore. At least how I think about it, HyperEVM excels in applications where programmability is added to HyperCore, rather than standalone EVM applications. Examples include liquid staking, tokenized vaults, native RWA issuance (e.g. USDC).
It is of course possible to build a general purpose EVM side chain with no direct composability with HyperCore, but that defeats most of the purpose and those applications can be built on existing chains anyway. It would be helpful to flag any general purpose EVM applications that do not benefit from direct HyperCore native implementation that you think HyperEVM ought to support.
1. As a reminder, read and write priority fees are in scope for the bug bounty program, like all features live on mainnet. Several users have responsibly disclosed edge cases and received bounties, for example by identifying ways ALO prioritization could be obtained for non-ALO orders. All known effects have been patched, so latency-sensitive users may wish to re-benchmark order and gossip priority fees for their use cases. Bug bounty reports on priority fees and any other mainnet feature are always welcome, and feedback is greatly appreciated.
2. As a clarification for fast cancels, there is no disadvantage for setting `f: true`on cancels. The only difference is that the cancels will not work for trigger orders.
3. On the next network upgrade, the minimum order notional formula will be made more predictable based on user feedback. Instead of being based on mark price, it will be based on limit price for resting orders and first execution price for executable orders.
1. As a reminder, read and write priority fees are in scope for the bug bounty program, like all features live on mainnet. Several users have responsibly disclosed edge cases and received bounties, for example by identifying ways ALO prioritization could be obtained for non-ALO orders. All known effects have been patched, so latency-sensitive users may wish to re-benchmark order and gossip priority fees for their use cases. Bug bounty reports on priority fees and any other mainnet feature are always welcome, and feedback is greatly appreciated.
2. As a clarification for fast cancels, there is no disadvantage for setting `f: true`on cancels. The only difference is that the cancels will not work for trigger orders.
3. On the next network upgrade, the minimum order notional formula will be made more predictable based on user feedback. Instead of being based on mark price, it will be based on limit price for resting orders and first execution price for executable orders.
On the next network upgrade:
1. As previously announced, `webData2` will push every 15 seconds. As a reminder, `webData2` will eventually be discontinued, so builders should use `webData3` and other component subscriptions.
2. As previously announced, `l2Book` without `fast: true` will push 20 levels every 5 seconds.
3. For latency-sensitive users: `cancel` and `cancelByCloid` actions have a new `fast` flag, represented by `f: true` in the action payload. Fast cancels will be rejected for trigger orders, but are otherwise equivalent to normal cancels. This optional field is already live and documented at https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint#cancel-order-s, though it currently has no effect. On the next network upgrade, mempool prioritization will only apply to cancel actions with `f: true`.
On the next network upgrade:
1. As previously announced, `webData2` will push every 15 seconds. As a reminder, `webData2` will eventually be discontinued, so builders should use `webData3` and other component subscriptions.
2. As previously announced, `l2Book` without `fast: true` will push 20 levels every 5 seconds.
3. For latency-sensitive users: `cancel` and `cancelByCloid` actions have a new `fast` flag, represented by `f: true` in the action payload. Fast cancels will be rejected for trigger orders, but are otherwise equivalent to normal cancels. This optional field is already live and documented at https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint#cancel-order-s, though it currently has no effect. On the next network upgrade, mempool prioritization will only apply to cancel actions with `f: true`.
Based on user feedback on the API changes above:
1. `webData2` will remain unchanged (the current 5 second instead of 15 second push interval) for one more network upgrade to give builders more time to migrate.
2. `l2Book`without `fast: true` will push 20 levels every 2 seconds, instead of every 5 seconds. The following upgrade will push every 5 seconds instead.
3. `fastAssetCtxs` websocket endpoint has been added to push mark price diffs at the original 5 second interval. This can be used to preserve previous behavior on interfaces. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions for details.
4. `modify` and `batchModify` actions now support an optional "always place" field that allows modifying orders into executable or trigger orders. Frontend integrations can use this to support the less common user flows where modifies are expected to execute instead of rest in the book. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint#modify-an-order for details
Based on user feedback on the API changes above:
1. `webData2` will remain unchanged (the current 5 second instead of 15 second push interval) for one more network upgrade to give builders more time to migrate.
2. `l2Book`without `fast: true` will push 20 levels every 2 seconds, instead of every 5 seconds. The following upgrade will push every 5 seconds instead.
3. `fastAssetCtxs` websocket endpoint has been added to push mark price diffs at the original 5 second interval. This can be used to preserve previous behavior on interfaces. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/websocket/subscriptions for details.
4. `modify` and `batchModify` actions now support an optional "always place" field that allows modifying orders into executable or trigger orders. Frontend integrations can use this to support the less common user flows where modifies are expected to execute instead of rest in the book. See https://hyperliquid.gitbook.io/hyperliquid-docs/for-developers/api/exchange-endpoint#modify-an-order for details
Hyperliquid now supports recurring daily ETH, HYPE, and SOL binary outcomes. Like BTC daily outcomes, these are automatically deployed and settled daily at 06:00 UTC to the Hyperliquid mark price of the underlying perp asset, e.g., ETH-USDC
See Docs: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/contract-specifications#recurring-outcomes
Hyperliquid now supports recurring daily ETH, HYPE, and SOL binary outcomes. Like BTC daily outcomes, these are automatically deployed and settled daily at 06:00 UTC to the Hyperliquid mark price of the underlying perp asset, e.g., ETH-USDC
See Docs: https://hyperliquid.gitbook.io/hyperliquid-docs/trading/contract-specifications#recurring-outcomes
On the next network upgrade, several snapshot-based websocket API endpoints will have updated push frequencies:
1. `webData2` will push 15 seconds. As a reminder, `webData2` will eventually be discontinued, so builders should use `webData3` and other component subscriptions as previously announced.
2. `l2Book` subscription will include an optional `fast: true` field. When set, the book will push 5 levels every 0.5 seconds. The subscription without the flag will push 20 levels every 5 seconds. Builders should merge the two books on their UI. Automated traders should run a non-validating node for more levels or real time update streams.
3. `allMids` will push every 5 seconds. Builders can use other feeds if faster price updates are needed for specific coins.
4. `spotAssetCtxs` and `allDexsAssetCtxs` will push every 15 seconds. There will be a compressed feed of all mark prices to be announced.
On the next network upgrade, several snapshot-based websocket API endpoints will have updated push frequencies:
1. `webData2` will push 15 seconds. As a reminder, `webData2` will eventually be discontinued, so builders should use `webData3` and other component subscriptions as previously announced.
2. `l2Book` subscription will include an optional `fast: true` field. When set, the book will push 5 levels every 0.5 seconds. The subscription without the flag will push 20 levels every 5 seconds. Builders should merge the two books on their UI. Automated traders should run a non-validating node for more levels or real time update streams.
3. `allMids` will push every 5 seconds. Builders can use other feeds if faster price updates are needed for specific coins.
4. `spotAssetCtxs` and `allDexsAssetCtxs` will push every 15 seconds. There will be a compressed feed of all mark prices to be announced.
On the next network upgrade, order modifies will not support modifying into immediate execution. If the new order TIF does not rest on the book (e.g. IOC), the modify will be rejected. If the new order TIF is GTC, it will modify into an ALO order instead.
On the next network upgrade, order modifies will not support modifying into immediate execution. If the new order TIF does not rest on the book (e.g. IOC), the modify will be rejected. If the new order TIF is GTC, it will modify into an ALO order instead.
Hyperliquid