Social attacks with monetary value

Snapchain is a simple blockchain where Farcaster social activity takes place. Every cast, reaction and follow is stored as a Snapchain transaction.
A snapchain transaction is a social action like making a new post. Alice says “Hello World” by making an add-post transaction, signing it with her app key and broadcasting it. Nodes verify that every transaction is correctly signed according to the specification. Common actions like deleting posts or following other users have their own transaction types. Snapchain transactions are self-authenticating and anyone trace the authenticity from the message to the app key to the wallet to the farcaster id. (snapchain whitepaper)
Snapchain transactions were not designed to transfer monetary value, but recently, we see more and more cases where snapchain transactions trigger (directly or indirectly) onchain transactions.
For example, NOICE and Tip’n Earn users allocate an amount of ERC-20 tokens and the apps send small tips whenever the user likes, recasts or comments: In addition to its inherent social value, my “like” is now worth $0.1 —and I’m sure we will see cases where much more value is transferred by Farcaster activity (I know of at least one such case that will be announced in the next few days).
This creates attack vectors that the design of Snapchain did not have to worry about.
The first attack vector is miniapps designed to be used as marketing tools, like amps.fun.
These apps allow users to “sell” their social reactions. For example, I can pay a user through amps.fun and automatically get a like or recast from them.
If an amps.fun user has also set up noice or tipn, and the cost of getting a social reaction from them is lower than the value I get from the tips, then I can pay them $x and get more than $x back as tips, draining their allowance.
Sure, no one would set these apps in such a way that I can steal their money (though, users are often careless).
But what if their like is used as a vote that affects how a retro funding round worth >$30k is distributed? Or if social activity (especially actions with a tip attached to them must be genuine, right?) is used to define an airdrop distribution?
The second attack vector is app keys.
This is a breach of trust, or even an actual hack.
Every Farcaster application (even Farcaster.xyz) that you use to cast, like, recast, follow, will ask you to sign an appkey. Then, they use this key to sign Snapchain transactions (casts, likes, etc) on your behalf.
If one of these apps go rogue, or get hacked, the attacker can create a cast, and then comment, like and recast as any of their users, in order to collect tips triggered by these social transactions.
What can we do?
The most important part is awareness. Many of these attacks can be averted if users and developers are aware of the risks described above.
An other “soft” measure could be an “advisor” app that checks known combinations and alert users: “Warning: You tip $0.6/like using noice, $0.6/like using tipn, and you set your like value to $1 on ampsfun”.
Apps should also encourage users to set low allowances (if you tip $.1/like, do not set the app allowance to $200), and notify them when they are running low.
Tipping apps can also check the appkey used for a social interaction, before sending the tip. An appkey associates the application FID with the user FID, so you could request additional confirmation when you see a new app used: “You used ampsfun/coinbase/opencast, is it ok to trigger tips when this app is used”? Whitelisting well-known clients like Farcaster.xyz in advance will make this invisible to 99.99% of the cases and add minimal UX friction.
In some cases, appkeys can be checked retroactively. If you use social activity to define the distribution of an airdrop or a grant, make sure you analyze the app keys used in each case and act (for example ignore some of them) accordingly.
Finally, when Snapchain implements appkey freezing (app keys are frozen and can’t be used, but are not revoked), we should put in place the tools and habits that will let users easily freeze unused appkeys.