Onchain creation of orders

[MartinquaXD]

Problem

Currently the majority of ways to create orders require the user to do some offchain action. For some users or use cases this is not ideal.

Suggested solution

A way to send a transaction which will result in the creation of an order in the offchain orderbook would be great.

Possibly the simplest way would be to create a helper contract for that. This helper contract only really needs 1 function for that. It should take 2 arguments (cow protocol order struct, signature) and all it has to do is emit an event with that data and signature.
Because the user is posting normal orders, this helper contract does not have to implement any additional security functionality.

Then the backend could index these events from that contract and insert the orders automatically into the offchain orderbook. The maximum validity of regular orders should still be enforced, though.

Also the helper contract should allow you to cancel orders. The same approach (function that emits an event) can be used for this as well. We only need to verify that the cancellation is actually valid be checking that the same address that signed the original order is now also trying to cancel it. This can be done by recovering the public address from the signature together with the signed data.

Additional context

We should not miss any order creation events during restarts so we need to store in the DB which block was last indexed to know where we need to continue after the restart.

Acceptance criteria

A user is able to place an order by submitting a very simple ethereum transaction.

[tosynthegeek]

Hello, I’ve been working on this issue and have a few clarifications regarding the event indexing and order insertion process.

From the description of the issue:

Then the backend could index these events from that contract and insert the orders automatically into the off-chain orderbook. The maximum validity of regular orders should still be enforced, though.

Based on this, I am currently parsing the order from each event and adding it directly to the off-chain orderbook using add_order within the append_events method.

My main question:

How should I handle previously added orders in the event of a reorg, which is processed via the replace_events method? Since the orderbook currently only supports adding and cancelling orders (and not deleting or “uncancelling” them), what is the recommended approach to ensure the offchain orderbook remains consistent with the canonical chain after a reorg?

Any guidance or best practices on handling this scenario would be greatly appreciated.

[github-actions]

This issue has been marked as stale because it has been inactive a while. Please update this issue or it will be automatically closed.