该用户的聊天记录定位。
It’s an utterly different queuing mechanism, essentially similar to having an infinitesimal tick size and increasing prices to gain queue
It’s an utterly different queuing mechanism, essentially similar to having an infinitesimal tick size and increasing prices to gain queue
The 'concrete example' in the docs for ALO priority fees is as clear as mud. In a nutshell is it the case that ALO priority fees allow later orders to jump to the top of the queue by paying for it within a 400ms window?
The 'concrete example' in the docs for ALO priority fees is as clear as mud. In a nutshell is it the case that ALO priority fees allow later orders to jump to the top of the queue by paying for it within a 400ms window?
What’s lacking is a freely available way for node operators to stream realtime data themselves. This would decentralise the API further and bridge the gap between what HL offers by default and the paid 3rd party providers of real time data
What’s lacking is a freely available way for node operators to stream realtime data themselves. This would decentralise the API further and bridge the gap between what HL offers by default and the paid 3rd party providers of real time data
Surely a more cost effective way to do that is to just buy a bunch of dedicated servers
Surely a more cost effective way to do that is to just buy a bunch of dedicated servers
Add a fill timestamp to IOC orders in the placement response, we currently have ``` {"channel":"post","data":{"id":69,"response":{"type":"action","payload":{"status":"ok","response":{"type":"order","data":{"statuses":[{"filled":{"totalSz":"3.16","avgPx":"56.594","oid":465652557470}}]}}}}}} ``` totalSz, avgPx and oid only
Add a fill timestamp to IOC orders in the placement response, we currently have ``` {"channel":"post","data":{"id":69,"response":{"type":"action","payload":{"status":"ok","response":{"type":"order","data":{"statuses":[{"filled":{"totalSz":"3.16","avgPx":"56.594","oid":465652557470}}]}}}}}} ``` totalSz, avgPx and oid only
They’re obviously struggling with performance problems. You don’t throttle like that unless it’s a last resort. Probably need to move to a decentralised streaming system
They’re obviously struggling with performance problems. You don’t throttle like that unless it’s a last resort. Probably need to move to a decentralised streaming system
Open source the websocket streaming from incoming block/transaction data so that API users aren’t forced to pay through the nose for timely data which ought to be free
Open source the websocket streaming from incoming block/transaction data so that API users aren’t forced to pay through the nose for timely data which ought to be free
Exactly. So its a downgrade
Exactly. So its a downgrade
The upgrade needs to be renamed to “slow” and “glacial”
The upgrade needs to be renamed to “slow” and “glacial”
Is there any way to modify the remaining size of an order rather than the total size? I've got a situation where the fill report comes back after the request to modify the price of an order and since you have to specify the size, I'm ending up overshooting my target position when the modified order also gets filled before I can cancel it
Is there any way to modify the remaining size of an order rather than the total size? I've got a situation where the fill report comes back after the request to modify the price of an order and since you have to specify the size, I'm ending up overshooting my target position when the modified order also gets filled before I can cancel it
Feature request: trigger orders by last price as well as mark price
Feature request: trigger orders by last price as well as mark price
Just move a regular stop market order with the mark price
Just move a regular stop market order with the mark price
Hyperliquid