Account spam prevention via Dedicated Accounts (DA)

[riengi]

Problem

Any account can be easily spammed with scam or ad tokens/NFTs which is really bad, annoying and often undesirable. Currently this is partially "solved" by various applications or wallet features that clean the wallet content from known spam NFTs, tokens, etc. however this approach is far from being really usable or optimal. This should be solved on Solana protocol level IMO.

Proposed Solution

There are multiple ways howto deal with this but probably one of more achievable, simple and practical way would be existence of Dedicated Accounts (DA) which would allow creating new spl-accounts only by the account owner.

It means that spl-token transfer would not allow --fund-recipient to pass to an account that is already Dedicated Account. It means Associated Token Account Program transfer would also need to be modified to recognize DA. DA could be done for example by implementing Dedicated Account Program (or including into some existing core program) where an account could be registered as dedicated only by the account keys owner and if Associated Token Account Program recognizes DA during transfer --fund-receipt, it would refuse creating SPL-token account for that account which would prevent spammer from sending arbitrary tokens into such account.

Simple flow for DA:

• User creates keypair
• User registers account as DA via particular program
• Associated Token Account Program would recognize registered DA account and prevents creating spl-token account by 3rd party via --fund-recipient.

I definitely welcome any other implementation that would result into similar functionality, ie. having account that is spam resistant. Proposed feature would keep current functionality but would also adds possibility of spam-free accounts. Hope it makes sense.

[nikhayes]

There was this convo on twitter recently https://twitter.com/dubbel06/status/1558844647463456769?t=YUbZB2e1jc3X5QVHQ_Y-Wg&s=19

I'm worried that inbox spam levels could get pretty bad with the new compressed nfts

[riengi]

Thanks @nikhayes, yes that's pretty much related. Full-featured claiming would be probably quite heavy approach to this problem with lot of consequences for everyone.

Lite version letting account user/owner to decide (set) if others can create token account should be much less invasive from compatibility point of view I suppose. Optimally, it would be great if AccountInfo struct has this property allowing to set if account owner allows others to create new token account (TAP would behave accordingly). Integer mode account flag would be handy allowing extending to other account behavior-specific needs in the future (even various combinations). But that could (possibly) break the backward compatibility. Other approach (not that clean) would be to store it as regular account data for each account or having some specific account that holds these kind of data for all other accounts as I suggested originally (probably the worst approach after giving it some thoughts, definitely least performant).

I completely agree with you, spam level will be only worse in time, it's already pretty annoying and potentially harmful aka lots of spam NFTs are referencing various scams where less aware users can lose their SOLs easily.