Allow 0x transactions to be cancelled (or expired) #37
Labels
status: implemented
Proposed changes have been implemented (and deployed, if smart contract)
type: core
Preamble
Discussion: #37
Summary
A signed 0x transaction is currently valid until executed. There is no explicit way to cancel or invalidate a transaction. This ZEIP will discuss 3 different mechanisms accomplishing this.
Motivation
There are pros and cons to allowing 0x transactions to be cancelled. The initial decision to not allow cancels in 2.0 was actually intentional.
Argument against cancellation
In many cases, a 0x transaction will be submitted by a user that is not actually the transaction signer (such as a relayer). Allowing the transaction signer to cancel adds an additional griefing vector, where the signer can cancel and force the submitter to waste gas.
Argument for cancellation
If a taker signs a fill transaction that can only be executed by a different address (i.e when
order.senderAddress
is not the taker), that address can withhold the transaction and submit it at a later time. If the market price has moved during this time, a taker may end up filling an order at an undesirable price.Specification
There are at least 3 viable options for allowing 0x transaction cancellations: a
cancelTransaction
function; a monotonically increasingnonce
; or anexpirationTimeSeconds
field. The three options are described in detail below: only option 3 (transaction expirations) was implemented for v3 of the exchange.1
cancelTransaction
functionThe logic for this would be very similar to
cancelOrder
. Pseudocode:2 Force salt to be strictly incrementing by 1
A transaction's
salt
field would serve the same functionality as an Ethereum transaction'snonce
field (and could also be renamed to reflect this). Valid transactions must have anonce
equal to the most recently submitted transaction'snonce
+ 1. Multiple transactions with the samenonce
cannot be submitted, so a "cancellation" would merely be submitting a transaction with the same nonce as the transaction that is intended to be cancelled.3 Add an
expirationTimeSeconds
fieldTransactions mined in a block with timestamp at or after the
expirationTimeSeconds
field would be invalid. This is my personal favorite approach, as it seems to minimize griefing vectors while also limiting the potential damage of a withholding attack (most transactions would likely be very short lived).Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: