No mechanism for freezing token accounts

[jackcmay]

An authority may want the ability to "freeze" specific accounts.

Add a new authority to the mint and a new flag in accounts. The authority is able to toggle that flag. Setting the flag to "frozen" disables the account owner and delegate's authority.

[aeyakovenko]

Should be settable only once during token initialization, so it’s possible to guarantee that this token instance cannot freeze accounts.

[mvines]

The freeze authority needs to optionally be a multisig account

[mvines]

Updates:

1. We're like to use the existing mint owner as the freeze authority to avoid changing the mint
2. There's a strong desire that the bit which indicates that an account is frozen ideally sneaks into the account data without any layout changes, to avoid affecting downstream users

[CriesofCarrots]

1. We're like to use the existing mint owner as the freeze authority to avoid changing the mint

This means that freeze-able tokens will by definition have non-fixed supplies, since a mint owner can mint new tokens. Is this an issue?

[mvines]

We should try to avoid changing the layout from token 1's account as this will impact the ability of existing users to easily migrate.

Changing

solana-program-library/token/program/src/state.rs

Line 61 in b619da3

pub is_initialized: bool,

from a bool and enum where "2" == "frozen" would meet this requirement

[mvines]

This means that freeze-able tokens will by definition have non-fixed supplies, since a mint owner can mint new tokens. Is this an issue?

Thanks, great point. Yeah lets add that separate freeze authority to the mint then after all

[CriesofCarrots]

@mvines Is it still okay to expect that the freeze authority will always be the same as the mint owner/multisig, as in Update 1. above? I'm trying to figure out how to handle the accounts passed in with TokenInstruction::InitializeMint, and the options are a bit complicated if we need to support separate owner and freezer.

If it's all good to expect them to be the same, and we need to change the Mint structure anyway, how about bytes for "supply is fixed" and "token is freezable", and stick with a single owner: COption<Pubkey> field? It'll save ~30 bytes.

[mvines]

I think we want the option of a separate freeze authority with a freeze_authority: COption<Pubkey> to the end of Mint.

While we pass the optional owner in as an account, process_initialize_mint() doesn't really care that it's an account. It just does a:

solana-program-library/token/program/src/processor.rs

Line 62 in b619da3

mint.owner = owner;

and we could rework InitializeMint to:

    InitializeMint {
        amount: u64,
        decimals: u8,
        mint_authority: Option<Pubkey>,
        freeze_authority: Option<Pubkey>,
    },

[jackcmay]

We could have the owner and freeze authority be the same during mint init and then allow folks to change either in a seperate instruction. We already have a SetOwner instruction and we probably want a SetFreezer instruction anyway.

[mvines]

We could have the owner and freeze authority be the same during mint init and then allow folks to change either in a seperate instruction

I did consider that but then we do still need a way to toggle freezing in InitializeMint, so we'd still end up adding new fields to InitializeMint

we probably want a SetFreezer instruction anyway.

Yep! Or maybe just replace SetOwner with SetAuthority with an enum input

[jackcmay]

Yeah, I wasn't trying to avoid adding the freeze authority to the mint structure because I think that's necessary. I was addressing @CriesofCarrots 's concern about the complicated InitiaizeMint instruction.

[CriesofCarrots]

Should be settable only once during token initialization, so it’s possible to guarantee that this token instance cannot freeze accounts.

@aeyakovenko said this above. I'd say that precludes any kind of SetFreezer or SetAuthority instruction.

[mvines]

If freezing is disabled on a mint, I agree that it probably shouldn't be possible to enable it later. Like fixed supply. But if freezing is enabled, we do need a Set* to support key rotation of the freezer key

[CriesofCarrots]

Okay, makes sense.
Although I generally prefer the pattern of passing in the authority keys as instruction parameters, in the interest of minimizing the changes between token 1 and 2 and consistency across instructions, I will code out Jack's suggestion for you two to 👀