It was suggested that if the second-to-last hop is malicious, they could create a new onion blob and potentially compromise the payment. In response to this concern, it was proposed that the sender and receiver could agree on a shared secret value, such as the hash of the contract, that would be included in the per-hop payload for the final hop. If the payload does not match this value, then the payment should be rejected as a prior node has unsuccessfully attempted to recreate the onion packet. This solution would add an extra layer of security to the payment negotiation process.