1when communicating with the Coordinator on Ethereum mainnet. Do note that many of these examples may contain a different chainId because they were copied from a test environment.
bidProtectionproperty which allows you to specify exactly how much you're bidding for this individual trade. This way you don't have to rely on your math being correct when you calculated the new
stakeSpentquantity. This is especially helpful when you're running a bot with multiple threads or processes, and also when you're running multiple bots using the same exact KSA. For those who are running multiple bots, we do recommend that keepers use separate KSAs, but in case you are sharing a KSA with more than one bot
bidProtectionis critical. Note: In a future update we will make
bidProtectionrequired as opposed to optional.
113973492809359184ROOK, and that the bid will increase their
3809217775909198431191. When the coordinator processes this bid, it will determine how much it preceives that the keeper has bid based on the payment channel information combined with this bid. In the event this keeper has either a multithreading bug or a logic error, the coordinator will detect this mismatch and reject this bid on behalf the keeper citing an error. This error will be communicated back to the keeper as a clear indication that the keeper bidding logic is flawed.
stakeSpentby 1 ROOK each. It's common for keepers to submit each bid in its own thread or process. As long as the keeper sets each bid's
bidProtection, the keeper can rest assured that if they have a bug as a result of the multithreading or multiprocessing, any bids containing a miscalculated
stakeSpentwill be rejected.
auctionIdListand the addresses to ensure that it's relevant to you. Also, check the
actionDeadlineBlockNumberfor when this order fill must be mined into the blockchain by to avoid taking a reputation hit. If you're using an MEV relay like Flashbots, you can lean on
actionDeadlineBlockNumberto determine which blocks to broadcast your trade for. For example, say the current block is 1000 and
actionDeadlineBlockNumber = 1003. You should broadcast your transaction to blocks 1001, 1002, and 1003. Broadcasting to block 1004 is dangerous because if it fills, it will fill after the deadline has ended which will result in a reputation hit for bad behavior. And if you're broadcasting your transaction to mempool, you can include the deadline block number in your transaction and have it gracefully fail in the event the transaction is not mined in on time.
limitOrderwhen constructing their message payload.
_withdrawalTimelockwill be non-zero if the payment channel is currently in the timelocked withdrawal process and will indicate the timestamp of the timelock's expiration.
msg.senderif there is one, and creating a new payment channel otherwise. Not that additional rook cannot be staked for a payment channel that is currently in a withdrawal timelock.