It outlines a hypothetical user interface (UI) scenario where a user, Alice, adds a contact, Bob, at the point of making a payment. This process involves Alice scanning an offer that contains Bob's contact key, prompting her to add Bob as a contact and complete the payment. The concern arises with attackers like Mallory, who could deceive users into associating their key with another person's name through misleading offers, thus gaining the ability to forge payments from that person.

The sender expresses worry over the creativity of attackers in exploiting this system, suggesting that while it may be more challenging than simply falsifying information in a payer note, it represents a significant security risk. They argue that it might be simpler and safer to educate users to only trust the amount in a payment notification rather than who it appears to come from because if attackers gain access to trusted fields like the contact list, they could cause more substantial damage.

Further issues are raised regarding what happens if a contact key gets compromised, especially for organizations using a single key for numerous transactions with customers, or if a user like Bob uses multiple wallets for payments, potentially leading to confusion and mistrust if payments appear untrusted due to different contact keys being used. The sender concludes by questioning the overall safety and efficiency of the proposed system, linking to an article discussing "stop energy" to illustrate their concerns about the direction of the discussion. They suggest that focusing on ensuring users understand that only the payment amount is trustworthy might be a more straightforward and secure approach.