Hooks as they are used at the moment are non-trivial to enforce. Pre-hooks must manipulate some condition that then allows the trade to take place (i.e just-in-time vault-relayer allowance setting), and post-hooks would require some economic game with the solver committing to bond beforehand and requiring the post-hook to retrieve the funds. These are non-trivial and cause drastic limitations on developer experience / adoption.
Acceptance criteria
Pre and post hooks are first class citizens of the signed order.
Hooks are able to determine the context from which they are being called (e.g. order owner, order details).
A hook's context is contractually enforced.
Details
Hooks are a way that users are able to express their desired pre and post interactions associated with their order. These hooks are then executed by the HooksTrampoline, therefore all hooks, irrespective of the user whose order they're associated with, are executed with the same msg.sender.
Hooks are specified in appData, which is not parsable by smart contract and represents a keccak256 hash of a JSON stringified object, therefore there is no way for the settlement contract to enforce pre and post hooks.
Possible Solutions
Include a Hook(address target,bytes callData) and Order(..., Hook[] preHooks, Hook[] postHooks) compound types in the EIP-712 order type.
Tweak the HooksTrampoline such that the context is guaranteed to be passed. This context should allow for the Hook to determine the order it's associated with, and the order's owner, e.g. by passing an index that is used to retrieve the order from a transient stored array on a callback, with the index being appended to the callData of the hook, or borrowing inspiration from ERC-2771.
Should the hook also already have access to the clearing prices of the order that is about to be executed (could be useful to determine the correct amount to unstake for instance)?
Problem
Hooks as they are used at the moment are non-trivial to enforce. Pre-hooks must manipulate some condition that then allows the trade to take place (i.e just-in-time vault-relayer allowance setting), and post-hooks would require some economic game with the solver committing to bond beforehand and requiring the post-hook to retrieve the funds. These are non-trivial and cause drastic limitations on developer experience / adoption.
Acceptance criteria
Details
Hooks are a way that users are able to express their desired pre and post interactions associated with their order. These hooks are then executed by the
HooksTrampoline
, therefore all hooks, irrespective of the user whose order they're associated with, are executed with the samemsg.sender
.Hooks are specified in
appData
, which is not parsable by smart contract and represents akeccak256
hash of a JSON stringified object, therefore there is no way for the settlement contract to enforce pre and post hooks.Possible Solutions
Hook(address target,bytes callData)
andOrder(..., Hook[] preHooks, Hook[] postHooks)
compound types in the EIP-712 order type.HooksTrampoline
such that the context is guaranteed to be passed. This context should allow for the Hook to determine the order it's associated with, and the order's owner, e.g. by passing an index that is used to retrieve the order from a transient stored array on a callback, with the index being appended to the callData of the hook, or borrowing inspiration fromERC-2771
.Research track