Custom order simulation

[m-sz]

Description

The order simulation endpoint allows one to simulate a specific, existing order. It is useful to be able to simulate any, custom order.

Changes

Implements a POST endpoint /api/v1/debug/simulation that allows a request specifying custom order details to be simulated:

pub struct SimulationRequest {
    pub sell_token: Address,
    pub buy_token: Address,
    #[serde_as(as = "HexOrDecimalU256")]
    pub sell_amount: alloy::primitives::U256,
    #[serde_as(as = "HexOrDecimalU256")]
    pub buy_amount: alloy::primitives::U256,
    pub kind: OrderKind,
    pub owner: Address,
    #[serde(default)]
    pub receiver: Option<Address>,
    #[serde(default)]
    pub sell_token_balance: SellTokenSource,
    #[serde(default)]
    pub buy_token_balance: BuyTokenDestination,
    /// Full app data JSON. Defaults to `"{}"` if omitted.
    #[serde(default)]
    pub app_data: Option<String>,
    #[serde(default)]
    pub interactions: Interactions,
}

• Add exhaustive order details in a follow-up PR.

How to test

E2E test that runs a custom order simulation on a trader with no funds (it reverts), then account is funded and the same request passes.

[gemini-code-assist]

Code Review

This pull request introduces a new debug endpoint, POST /api/v1/debug/simulation, which allows for the simulation of arbitrary orders without requiring them to be stored in the database. The changes include updates to the OpenAPI specification, the addition of a new request handler in the orderbook API, and a corresponding simulation method in the core orderbook logic. Feedback focuses on the SimulationRequest schema, which is currently missing critical fields like validTo, partiallyFillable, and feeAmount that are necessary for realistic simulations. Additionally, the order simulation logic needs to ensure internal consistency by correctly hashing appData and calculating the OrderUid before processing the swap.

[fafk]

LGTM, but isn't a lot missing? Like simulating different order types, different signatures etc?

[m-sz]

@fafk I'll add more order details to the request body by re-using OrderCreation struct

[m-sz]

Actually, thinking more about it. The signatures etc. are all validated as part of order creation, while it is not strictly necessary to come up with a simulation. I think it does not make much sense for the order simulation endpoint to actually fully validate an order etc, which would limit its ability to experiment with arbitrary orders.

The same order that passes simulation (because the interactions, balances, allowances are ok) would be able to fail the validation due to signature checks etc. which I understand is fine.

The most important, especially for our partners is to simulate order execution before trying to place it.

[m-sz]

As discussed with @fafk, the order simulation request object is going to stay as-is. If it proves not enough for Aave we can always extend it with additional fields per their requirements.

[squadgazzz]

LGTM. Some nits.

[m-sz]

1. Changed the sellAmount to be NonZeroU256
2. Removed full path usage
3. blockNumber added to OpenApi spec
4. Revisited error handling for malformed inputs, now returns properly BadRequest
5. Reduced log level to warn for user errors.