Liquidity Delivery Updates

Some IOrderBook NatSpec comments are stale after recent order-opening changes. Order.sender and OrderData.sender are documented as the address that provided funds, but sender is now the order owner while the funder/msg.sender provides tokens. The cancelOrder() fee comments also refer to same-chain and cross-chain fills even though the section documents cancellations. Finally, OrderCompleted is documented as destination-chain-only, but it can also be emitted by reportFill() on the origin chain.

Update the NatSpec comments to describe sender as the order owner, distinguish it from funder, replace fill wording with cancel wording in cancelOrder() documentation, and clarify where OrderCompleted may be emitted.

The removed cancelOrderFor() functionality cannot be replicated by a generic wrapper in the same way as gasless openOrder() flows. Before the deadline, cancelOrder() authorizes cancellation by checking that msg.sender is the order recipient or, for same-chain orders, the order sender. If a wrapper verifies a user signature and calls cancelOrder(), OrderBook sees the wrapper as msg.sender, so the call fails unless the wrapper itself is the authorized address.

Setting the wrapper as recipient is not equivalent because fills transfer tokenOut directly to recipient without executing a callback. The wrapper would become a custody/accounting layer and would need additional forwarding, claiming, or off-chain keeper logic to route filled funds to the actual user.

Make sure this is intentional. If it's not - consider having the gasless cancel feature back in the OrderBook.

After compiling the orderbook, the FillNativeOrder tests should be checked for success.

Currently, the plan is to compile the program using Solana v2.1.0 and Anchor v0.31.1. However, for different versions of the toolchain, the following issue may materialize:

The SVM FillNativeOrder account context is too large for SBF stack limits. During anchor build, the compiler reports that the generated FillNativeOrder::try_accounts() frame uses a stack offset of 4112, exceeding the 4096 byte maximum. The generated parser then traps at runtime before handler() can execute successfully. Any native same-chain fill_native_order() call fails with ProgramFailedToComplete and an access violation.

As a result, SVM same-chain orders cannot be filled. Solvers cannot deliver the recipient's token_out and receive the escrowed token_in; users are forced into cancellation/refund paths, and same-chain liquidity delivery is unavailable on SVM.

Make sure the right toolchain was used and the tests are passing before deploying the program.

The preimage of the CANCEL_ORDER_TYPEHASH includes whitespaces after the commas that separate each struct element.

    /// @dev keccak256("CancelOrder(bytes32 orderId, address bridgeAdapter, bytes bridgeAdapterArgs)")
    bytes32 public constant CANCEL_ORDER_TYPEHASH = 0x6919f4958bcd1b5b4e13b800c6d41c4792cfc2a12d0bd9ad19da6e0bfe8ac04f;

This implementation is not true to the EIP-712 specification, where the whitespaces are omitted.

Consider using EIP-712 compliant digest if it won't break already existing integrators.