Block.timestamp vs order.expiry
A Keeper's guide on block.timestamp vs signed order expiry
The 0x protocol uses unix epoch expiry timestamps which lean on Ethereum's
block.timestamp. to determine whether or not an order has expired. So an order is fillable until block.timestamp exceeds the order expiry. But, a block's timestamp on Ethereum is typically the time that the previous block was mined in. This is critical to understand because this means that under certain circumstances Keepers can still fill orders after they've expired in human time (since block.timestamp = the timestamp the previous block was mined in...)- t = 12300
- A maker signed an order with expiry 12346
- t = 12345
- Block 100 mined in at timestamp 12345
- t = 12345
- Miners set Block 101's block.timestamp to 12345
- Note this block has NOT mined in yet
- t = 12360
- Block 101 mined in at timestamp 12360
- Note this block still has the block.timestamp of 12345
- This means that any Keeper could have still filled that user's order despite the fact that real human time is beyond the expiration date
- In other words, we're using blockchain time and NOT human time
- Miners set Block 102's block.timestamp to 12360
- Note this block has NOT mined in yet
- t = 12375
- The user's order is not fillable, because block.timestamp for this block is = 12360 which exceeds the user's expiry of 12346
This is important to understand because it means that a Keeper likely will not want to immediately delete the user's order from their local order cache when it expires in human time. They should only delete it when it expires in blockchain time.
Last modified 11mo ago