Feature Proposal: Allow setting close authority during initialization of (associated) token account

[rickyrombo]

Why

On Audius, users have derived token accounts on the "Claimable Tokens" program that are associated with their Ethereum wallets used for their Audius accounts. This system allows them to accumulate tokens without any interaction on their part, as their derived token accounts can be created by anyone but only claimable by the desired recipient. When they elect to send these tokens elsewhere, they sign a special Secp256k1 instruction using their Ethereum wallets and send it alongside a Claimable Tokens program in the same transaction.

Given these accounts don't have SOL, a relayer must be used in order to send the tokens. If the recipient wallet doesn't have an associated token account already for the desired token, one must be created for them. However, creating this account exposes a security vulnerability on the relayer wallet. The owner of the recipient wallet can close the token account, sending the tokens back to their Claimable Tokens account, and reclaim the rent paid. Then, restart the process and have the relayer repay the rent. Doing this repeatedly would effectively drain the relayer's SOL.

Some alternatives considered:

1. Require the user pay for their own token account creation
2. Create the token account but only if the token account close authority can be set in the same transaction
3. Allow this draining with custom protections on the relayer to prevent abuse

The typical user of this dApp is not familiar with blockchains, wallets, or SOL, and is typically withdrawing to a centralized exchange like Coinbase to offramp. (As an aside - Unfortunately, even Coinbase's wallets don't come preinitialized with the token account). Therefore, it would cause untenable harm to the user experience to not pay the rent and instead attempt to try to educate the user into creating their own token account.

It's impossible to set the close authority after a token account is created without getting a signature from the owner, which, due to similar reasons as above, precludes this option from our consideration.

Custom relayer protections are possible (this is what we're doing today) but are app-specific, limited in effectiveness, and hard to explain to end-users who end up as false positives for abusive behavior.

Proposed Solutions

1. Allow setting the close authority on the initialization of the token account (and through the create associated token account instructions).

Instead of setting the token account close authority to none here, allow the creator of the token account to set the close authority during initialization via optional instruction data

2. Allow setting the close authority ahead of initialization

Allow "presetting" the close authority prior to the account being initialized (similar to InitializeImmutableOwner )

3. New extension to specify who can receive the rent on close

Somewhat orthogonal, but instead of leveraging the existing close authority, create a new extension that protects the CloseAccount instruction from sending the resulting rent to anywhere but the specified account. This differs from close authorities in that no restriction would be set on who can close the account, but rather, where the resulting funds go.

Implementation

Willing to do a PR for this but wanted to gauge feedback first in case there's a reason this doesn't already exist!