One of the main issues that the current TEC proposal faces is taker griefing. The taker can cheaply grief the TEC by requesting to fill an order and then not following through on the fill. In order to prevent trade collisions, the TEC must reserve the order until the approval has expired (real expiration can be decreased if calculated probabilistically). The current proposal includes a mitigation to this problem by allowing the TEC to submit the fill to the chain on behalf of the taker - however, this is not always possible if the order is intended to be filled by a contract (see the TEC Forwarder post as an example of this). 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).
Rather than addressing this issue by adding constraints to the taker, what if we just ignore the trade collisions issue? A TEC can still offer off-chain cancels by not approving fills for cancelled orders. In all other cases, the TEC can sign off on every single fill without reserving orders and not attempt to account for trade collisions. This essentially replicates an open orderbook model while still allowing for soft cancels. In combination with the selective delay proposal, this should create an environment that is significantly better for market makers than the current open orderbook model, even if trade collisions are still possible.
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).
pros:
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
cons:
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.
I’m not sure I agree with this assessment. We can break down order collisions into a few categories and reason about how soft cancels + selective delay would affect each one:
Intentional front-running
Soft cancels + 1 second selective delay should give makers ample opportunity to cancel stale/mispriced orders before any taker can fill them. This will significantly reduce arbitrage opportunities for takers and lower the profitability of front-running.
Accidental trade collisions
I think we’ll definitely see more attempted fills fail because orders are being cancelled more frequently. However, these fills will never hit the chain because they simply won’t be approved if the orders are already soft cancelled. The TEC can also publicly broadcast any fill approvals, which should at least provide some signal to takers that there may be a trade collision if another fill is attempted. It’s hard to say where this nets out without some data, but I suspect it won’t make the situation worse than it currently is. Most current fill failures seem to be due to cancellations/expirations, not actual trade collisions.
Intentional/accidental griefing
These should be pretty much non-existent with soft cancels + selective delay, since makers will be able to soft cancel orders in volatile times with a 1 second lead time over takers. Hard cancels of any kind should be pretty pretty rare with this model.
Expiring orders
Makers shouldn’t have to set aggressive expirations with the ability to soft cancel, so fewer orders that are close to expiration will be executed.
There are definitely good reasons to build in collision prevention, but this model should indirectly reduce the number of collisions on a lot of different fronts.
@abandeali1 I hadn’t read the selective delay proposal until after my write up above so I was missing some context. As I understand it a selective delay order type is optional, so non-delay orders would be subject to the above setbacks. I think we can assume most makers will use selective orders if available because it allows them more optionality in canceling at time of fill.
I agree with many of the premises about selective delay mitigating maker griefing and front-running of mispriced orders, and opens the potential for collisions/front-running on orders with known taker competition (ie. if I see an order with several outstanding fill approvals in the mempool I will place a higher gas price to win the fill).
So, what does this functionality look like for taker’s UX?
A slightly longer delay to the first taker(s) who requests to fill an order (say 1 second) and after this delay a TEC will hand out signatures for anyone that requests one. Is this correct?
I think it’s still a bit of an open question on whether this should be an optional order type or not. I think it could complicate UX a good amount if both are allowed. It’s also quite a bit more complex to implement and track, since there will be no way to verify the type of an order in the short term (cryptographically or onchain).
The way I’m currently thinking about it, the delay would be enforced for every single fill request, not just the first time a fill is requested. So if a taker sees that a fill has already been requested, they will have a slight time disadvantage on requesting the same fill.
To add some color to the actual implementation details:
In the short term, the delay would be auditable but not enforceable. When a TEC receives a fill request, they broadcast the hash of that message. When they approve a fill request 1 second later, they broadcast the entire fill request. Cheating can be detected if the fill appears in the mempool before the second broadcast.
In the long term, the delay could be enforced by having the TEC run a verifiable delay function on the hash of the fill request which can then be verified via smart contract.