Trade

The onchain account owner calls the function registerLimitOrder, and creates a limit order record on L1. This order is matched against other order/s submitted to the same exchange — potentially including an offchain order from an owner of an offchain account.

The operator sends a settlement to StarkEx with the bundled orders.

After StarkEx creates a batch, SHARP generates a proof for it, it is published and verified onchain, and the StarkEx service calls the StateUpdate function. The stateUpdate contains the data of all the L1 limit orders for this batch. The StarkEx contract then verifies that such orders were indeed submitted through the orderRegistry, and that there is sufficient balance in the relevant onchain accounts to allow these orders to be executed. If all the conditions apply, it adjusts the balance for the existing onchain accounts, according to the L1 limit order specifications.

Note that the operator deposits the funds from a settlement to an offchain account in Step 2, but deducts those funds from the onchain account in Step 3, i.e., after a batch is created and proved onchain. Thus, a successful withdrawal request sent between Steps 2 and 3 might cause the stateUpdate to fail due to a lack of sufficient funds (forcing the operator to revert the settlement, re-prove everything, etc.). A well-timed series of such withdrawals could be a vector for DOS attack on StarkEx.

To prevent this issue, a "lock" is applied on the funds in onchain accounts. On deposit, the funds are automatically locked for defaultVaultWithdrawalLock. With the funds locked, the operator may settle against L1 limit orders without exposure to risk.

Users may customize this lock time on their onchain account’s funds should they wish to comply with such requirements.