Trade

The on-chain 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 off-chain order from an owner of an off-chain 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 on-chain, 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 on-chain accounts to allow these orders to be executed. If all the conditions apply, it adjusts the balance for the existing on-chain accounts, according to the L1 limit order specifications.

Note that the operator deposits the funds from a settlement to an off-chain account in Step 2, but deducts those funds from the on-chain account in Step 3, i.e., after a batch is created and proved on-chain. 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 on-chain 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 on-chain account’s funds should they wish to comply with such requirements.