Specification
There are two type of hooks available:pre and post. Pre hooks are executed before any order signature is checked (in particular, before any funds are taken from the order owner). Post hooks are executed after all orders in a batch are settled (that is, the proceeds of the orders have already been credited to the receiver).
Both pre and post hooks are specified as an array of hooks.
Each hook is described by three parameters:
-
target: the target address of the Ethereum call. Using implementing EIP-2612 approvals as an example, this would be the token contract. -
callData: the data of the Ethereum call. In the example above, the ABI-encoded function call topermit. -
gasLimit: a hard limit on the amount of gas needed by the call. An order quote uses this value to estimate the total fee needed to execute an order. The more gas needed, the higher fee will be needed for the order to be settled. If the call requires more gas than specified here, the Ethereum call in the hook will be internally reverting but the order will be executed regardless.
When placing partially fillable orders with hooks, pre-hooks will only be executed on the first fill. Therefore, your hook should ensure that the liquidity is sufficient for the entire order to be filled. On the other hand, post-hooks are executed on every fill.
Creating orders with hooks
Orders are linked to hooks through the app data. As long as the full appdata with hook information is included when posting the order to the orderbook API, the order will be stored with hook information included and settlements using this order will include its pre and post hooks.Call context
Hooks may be executed through the HooksTrampoline, a pragmatic way to meet many of the security guarantees of hooks execution. Anyone can execute calls using the trampoline, so you must not expect a call to the trampoline to be trusted.Security
The parameters of a hook are signed by the user along with the order as part of the app data.Solver execution rules
The driver encodes all matched orders’ pre- and post-hooks into the solution on behalf of the solver, so the solver does not need to add them manually. ThepreInteractions and postInteractions fields in the solver’s response are only for additional calls the solver itself needs (e.g., AMM approvals), not for user hooks.
Hooks must be executed exactly as specified by the user — the target, callData, and gasLimit parameters must be forwarded without modification. Pre-hooks are executed before pulling funds from the user, and post-hooks are executed after crediting the order proceeds to the receiver.
When executing a hook, the solver must forward at least gasLimit gas to the hook call. If the hook consumes more gas than the specified gasLimit, the hook call reverts internally, but the order itself still executes. This means hooks are best-effort — critical logic should be designed such that the order depends on the hook succeeding (e.g., by setting allowances in a pre-hook).
Solvers should account for hook gas costs when computing solution quality, as the additional gas consumption affects the net value of the settlement. For orders that include hooks, UDCP (Uniform Directed Clearing Price) exceptions apply to account for gas cost differences between solutions with and without hooks. Refer to the competition rules for full enforcement details.