TEC with continuous time matching

⌨️ Technical Development Core Protocol
1

Here is a high level draft spec of the TEC (Trade Execution Coordinator) contracts currently being developed. A spec for the actual TEC server is being written in parallel and will be added later.

Creating orders

Each order must specify the TEC contract’s address as its senderAddress. The feeRecipientAddress of each order should specify an address that is controlled by the TEC server. The current version only supports a single fee per order, so it is likely that the TEC server and relayer are the same entity.

Filling orders

A taker may select any of these orders to be used as inputs for any arbitrary function call on the Exchange contract. The taker creates a signed 0x transaction with the desired input and sends this message to the TEC server.

struct ZeroExTransaction {
    uint256 salt;           // Arbitrary number to ensure uniqueness of transaction hash.
    address signerAddress;  // Address of transaction signer.
    bytes data;             // AbiV2 encoded calldata.
}

After verifying that the transaction does not conflict with any previously approved transactions, the TEC server should respond with a signed approval message that includes:

  • An expiration timestamp in seconds. The taker will have until this timestamp (as recorded on the blockchain) to submit the transaction to the TEC contract and settle the trade.
  • A signature from the TEC server of eip712Hash(transaction.hash, transaction.signature, expiration) . The address recovered from this signature should correspond to the feeRecipientAddress of the maker’s order.
struct TECApproval {
    bytes32 transactionHash;                // EIP712 hash of the transaction, using the domain separator of this contract.
    bytes transactionSignature;             // Signature of the 0x transaction.
    uint256 approvalExpirationTimeSeconds;  // Timestamp in seconds for which the signature expires.
}

If the selected orders contain multiple feeRecipientAddress fields, then the taker must send the signed 0x transaction to multiple TEC servers that can produce a valid signature on behalf of each feeRecipientAddress . Each TEC server should respond with a signed approval message. In addition, each TEC server should send the signed approval to each other TEC server involved in the transaction approval. The taker may then submit the 0x transaction to the TEC contract with all of the valid signatures for each order included in the transaction. The minimum of the expiration times provided in all of the approvals will be enforced.

At any point, a required feeRecipientAddress may submit the 0x transaction to the TEC contract and omit its own approval. The intent is for the TEC server to submit the transaction on behalf of the taker if the taker fails to submit the transaction before the approval has expired (or if the taker requests an expiration time of 0).

Cancelling orders

Orders may be cancelled by their maker without approval from the TEC by sending a 0x transaction to the TEC contract that calls cancelOrder, batchCancelOrders, or cancelOrdersUpTo on the Exchange contract.

In addition, makers may request that the TEC “soft cancels” their order. The TEC must respond with a signed cancel receipt that acts as a promise that the cancelled order will not be filled at a later date. The full behavior for soft cancels will be specified in the TEC server specification.

Discussion points

  • While this protocol allows for liquidity sharing between TEC servers, it does require a high degree of coordination among all of the TECs involved. The taker and each TEC needs a signature from each other TEC in order for this scheme to be effective.
  • A single TEC can prevent a transaction from being submitted by withholding their signature. In the future, an m of n signature scheme can potentially be used to only require an honest subset of the TECs to approve each transaction.
  • Different TECs may have different expiration thresholds, and the taker is forced to use the earliest expiration.
  • It is difficult to determine which TEC is responsible for submitting the transaction on behalf of the taker if the taker fails to submit the transaction before the expiration.
1 Like
2

What if my matching orders had to go through a proxy contract before calling the Exchange contract? Can the ZeroExTransaction struct be substituted by something slightly more abstract, that would support arbitrary function calls outside of the Exchange contract? After executing its proxy logic (for instance, adding new orders to the set), this proxy contract would store the TEC signature(s) but call the Exchange contract using its own Validator-type signature. The validator function would then verify the original TEC signature(s) with the TEC contract.

3

Can you elaborate more on what type of behavior you would be looking to achieve with this? If I’m understanding correctly, the TEC would be signing off on arbitrary function calls rather than Exchange-only function calls?

Seems like an interesting idea, but I want to make sure I’m understanding it correctly.

4

Suppose that a Relayer wants to roll-out a matchOrders implementation in his own contract. One reason for this might be that the 0x matchOrders implementation gives all the spread to the arbitrageur, which may not be universally desirable. The custom matching logic that I need actually factors-in more parameters, but I figure that this example concisely illustrate the point.

Regardless of what the matching logic actually does, it can be mirrored between the TEC and the contract that implements it, so I don’t see any reason why the transaction must be limited to the Exchange contract. Of course, your TEC implementation will be geared towards the 0x contract but Relayers should have the option to fork it if they choose to.