Forced operations overview

forced operation

In order to guarantee self custody of funds, thereby preventing censorship, StarkEx enables a user to perform a forced request at any point in time. The user initiates a forced request with an on-chain transaction. If you, the operator, do not serve the request within a specified period of time, the user can freeze the contract, and thus the exchange, and withdraw directly from the frozen contract.

Forced withdrawal and forced trade

StarkEx Perpetual Trading supports the following forced operations:

  • Forced withdrawal

  • Forced trade

Forced withdrawal can only withdraw collateral. When a user holds any synthetic assets and wants to withdraw the entire value of their position, they must first execute a forced trade to sell their synthetic assets in exchange for collateral.

Forced withdrawal

The forcedWithdrawalRequest function is an anti-censorship mechanism that enables a user to withdraw their funds without the application’s permission. This function consumes a lot of gas and is expected to be used only as an anti-censorship mechanism.

To avoid a potential denial of service (DoS) attack on the application by a flood of full withdrawal requests, the cost of such requests must be limited. So the request’s cost exceeds 1M gas, and a single batch can include a maximum of only ten forced withdrawal requests.

Forced trade has no fee other than a normal gas fee, but the gas fee that the submitter pays is likely much higher than the off-chain trade fees.

For information on regular withdrawals, see The withdrawal flow and Withdrawing funds from the StarkEx contract

Forced trade

The second vault in a forced trade can belong to the same user.

A forced trade request is considered valid at the smart contract level, and the request is recorded as an action item that the application must serve, only if the following conditions are true:

  • The values of public Stark key for both traders match their Ethereum addresses.

  • No request has been received with the same parameters, including the nonce.

  • \(\text{blockchain_time} / 3600 \leq \text{submission_expiration_time}\)

If this is the case, the request is moved to the application. The trade takes effect if the specified values for the position ID correspond to the specified values for public Stark key, and the trade leaves both positions above the maintenance margin, or improves the ratio of value to maintenance margin.

If any of these conditions are not true, StarkEx processes the transaction, but proves the request to be invalid and does not execute the trade. This satisfies the force operation mechanism to show that the application served the request.


Alice wants to withdraw all of her funds.

  • She has a position with +1 BTC and 0 USDC.

  • The price of 1 BTC is 20,000 USDC.

She wants to submit an on-chain forced withdrawal request. However, she can only withdraw collateral. So she submits a forced trade request to sell her BTC for USDC.

After the forced trade is fulfilled Alice can execute a forced withdrawal request to obtain all her funds.

Forced operation flows

There are two possible flows, based on how you, the operator, respond to the forced operation request:

The operator serves the forced operation request

  1. The user sends the forced operation to the contract.

  2. The operator sends the forced operation to StarkEx.

  3. StarkEx decides whether the on-chain request is valid based on the identity of the exact request and the business logic involved.

Example: Serving the forced operation
  1. Alice sends an on-chain forced withdrawal request to withdraw 1,000 USDC from a specific off-chain position that she claims to own.

  2. The operator sends the forced operation to StarkEx.

    The operator determines the order in which it processes transactions, and can place the forced operation anywhere in the transaction queue as long as they process it within the grace period.

  3. StarkEx determines if the forced operation is valid.

    Valid request

    1,000 USDC is deducted from Alice’s off-chain balance, and registered on-chain as belonging to Alice.

    Invalid request

    If either of the following is true, StarkEx proves the request is not valid, and does not move any funds on-chain:

    • Alice has less than 1,000 USDC.

    • Alice’s public Stark key does not match the public Stark key registered with the position .

    After the proof for this request is submitted, whether the request is valid or invalid, the request is removed from the pending forced operations area in the StarkEx contract. If the request is invalid, the operator does not need to serve the request, and Alice cannot freeze the contract. If Alice wants to try again, she must submit a new request.

The operator does not serve the forced operation request

  1. The user sends the forced operation to the contract.

  2. The operator does not send the forced operation to StarkEx.

When the freeze grace period has passed and the forced operation is still in the pending forced operations area, any user can call the freezeRequest function, with the public Stark key and the position ID they used in the ignored forced operation.

As a result, the exchange becomes frozen, and it can accept no further state updates. Withdrawals of on-chain funds are still possible.