The routing hook contract actually introduces a new trust assumption. Initially, we also tried using routing contracts to integrate hooks, but we found that it requires trusting a third-party facilitator not to act maliciously. Here’s a simple example: A user submits two parts of data: - Data and signature related to ERC3009 - Data related to hook execution ✅ For an honest facilitator, they will call the SettlementRouter according to the user’s intent, transfer funds to the merchant, and execute the hook—everything works perfectly. For a malicious facilitator, they can use only the ERC3009-related data and signature to directly call the `transferWithAuthorization` function of ERC3009, transferring funds into the Router contract without calling the Router’s `settleAndExecute` to perform the transfer and hook execution. In this case, the merchant doesn’t receive the funds, and the hook logic isn’t executed. Therefore, this introduces a new trust assumption: users need to trust that the facilitator is honest. However, nuwa has done something very well here—he added a "recovery logic" in the Router contract: If a malicious facilitator transfers the user’s funds into the Router contract, an honest facilitator can use the same input to leverage the funds in the Router contract to help the user continue transferring funds to the merchant and executing the hook logic. This trust assumption is very weak but still exists: users need to trust that at least one facilitator is honest. I think this is an acceptable trust assumption. https://(github.com)/nuwa-protocol/x402-exec/blob/main/contracts/src/SettlementRouter.sol