该用户的聊天记录定位。
Does this also break existing l4 orderbook servers if they rely on timestamps at all to show queue positioning, since newer timestamps can be ahead of older timestamps now? If so, that'd be a bit frustrating.
Does this also break existing l4 orderbook servers if they rely on timestamps at all to show queue positioning, since newer timestamps can be ahead of older timestamps now? If so, that'd be a bit frustrating.
A concern regarding the system as it currently looks in the docs: With a 400ms window, that is enough time for someone to see order `A` land, check their bid to see they bid `X`, and then bid `X+1` for order `B` and have that land within 400ms of order `A`, thus getting in front. If `A` bid `1.0000bps` then `B` can get away with bidding `1.0001bps` which is practically the same, and `A` loses their position even though their order lands 300-400ms earlier. This feels really wrong because there's nothing `A` can do, any worthwhile bid they can place is also likely worthwhile to other parties, who can get in front of them by essentially matching their bid. I think this would be solvable by making the window a lot shorter than 400ms, reading the transaction requires ~100ms at the lower end, and placement latency is about 150-250ms, so if the window is 250ms instead of 400ms it would become really hard to snipe other parties bids.
A concern regarding the system as it currently looks in the docs: With a 400ms window, that is enough time for someone to see order `A` land, check their bid to see they bid `X`, and then bid `X+1` for order `B` and have that land within 400ms of order `A`, thus getting in front. If `A` bid `1.0000bps` then `B` can get away with bidding `1.0001bps` which is practically the same, and `A` loses their position even though their order lands 300-400ms earlier. This feels really wrong because there's nothing `A` can do, any worthwhile bid they can place is also likely worthwhile to other parties, who can get in front of them by essentially matching their bid. I think this would be solvable by making the window a lot shorter than 400ms, reading the transaction requires ~100ms at the lower end, and placement latency is about 150-250ms, so if the window is 250ms instead of 400ms it would become really hard to snipe other parties bids.
Some questions about the ALO priority fees new "concrete example": At what point in time is the 400ms window actually starting? Is it at time `t` when the new level opens, or is it at time `t'` where the first ALO order is placed at the new level? Or is it that a new window starts every 400ms completely independent of these things? If so, the example seems broken (or at least unclear), as it shows order `B` being placed 399ms after order `A`, and is very unlikely to be in the same window if it's a new auction every 400ms.
Some questions about the ALO priority fees new "concrete example": At what point in time is the 400ms window actually starting? Is it at time `t` when the new level opens, or is it at time `t'` where the first ALO order is placed at the new level? Or is it that a new window starts every 400ms completely independent of these things? If so, the example seems broken (or at least unclear), as it shows order `B` being placed 399ms after order `A`, and is very unlikely to be in the same window if it's a new auction every 400ms.
Hyperliquid