As I understand it the primary implementation difference in this change of proposal is moving from meta-transactions and/or taker exclusivity periods on a claimed order, and instead hand out as many TEC tickets for an order as requested by takers as needed until an order is filled (therefore removing the potential for taker griefing).
- allows filling orders by takers who are using contracts instead of their account balances
- keep similar taker UX
- simplifies TEC design
- allows for makers to soft cancel
- allows for taker order collisions (intentional or not)
- removes taker exclusivity (provides a great UX and instant guarantee to compliant takers)
The motivation to allow makers to soft cancel is to tighten order book spreads. As spreads tighten orders will be more marketable and competition will increase to fill orders close to the spread (and therefore increase collision rates). I’m open to an iterative approach, but with this in mind we need to develop a mechanism to mitigate order collisions as it is a problem now and will became increasingly worse as liquidity grows.
It may be helpful to think through griefing and blacklisting assumptions and scenarios before writing it off completely.
It also assumes aggressive blacklisting for takers who do not follow through, but it still may be economically advantageous for the taker to abuse this issue and accept being blacklisted (it is relatively cheap to create a new account and transfer assets over).
A taker who griefs an order is potentially avoiding filling an order which has moved out-of-the-money due to slippage in the time of the taker requesting the order and the TEC-supplied taker exclusivity expiration period. Switching accounts costs the gas of token transfer and allowance (per token). If this became a systematic problem a TEC could implement a rule to auto-blacklist addresses which received funds from a blacklisted address adding more cost to a malicious taker trying to grief the TEC (albeit this is getting to be complicated). A TEC could even simply allow the order to roll-over back onto a book if a taker does not fill it within the given exclusivity period (the order is either marketable and the next new taker will fill it or it is not and it lands back on the book).
It is worth noting makers have a similar option in the current open order book model to front-run any fill attempts with a cancel if it is (economically) advantageous to them at minimal cost. A relayer’s only mitigation is to stop accepting orders from that maker forcing them to migrate to a new account if it becomes systematic.
TECs have many opportunities to leverage chain data to build up a “reputation” for users to deliver “perks” for being compliant (ie. a taker which has filled 100 orders through the TEC can be given a longer exclusivity period where as a brand new account may be given a much shorter period, etc).
In any case, a TEC could implement logic server-side to enforce any taker rules/blacklisting they see fit while keeping the same on-chain components intact (but potentially moving off SRA spec which we’ve seen relayers do in the past for the sake of UX). I do find there to be a compelling reason to mitigate order collisions at the TEC level given one of the outcomes of the TEC is tighter spreads.