Add rent awareness to spl-token

[mvines]

Current spl-token is completed rent unaware, which leads to a couple problems:

1. If the Token account is not rent-exempt,

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

   Lines 19 to 26 in f8f51c1

   	pub struct Token {
   	/// The total supply of tokens.
   	pub info: TokenInfo,
   	/// Optional token owner, used to mint new tokens. The owner may only
   	/// be provided during token creation. If no owner is present then the token
   	/// has a fixed supply and no further tokens may be minted.
   	pub owner: COption<Pubkey>,
   	}

   and if it's rent collected then all the basic information about the token is lost, as well as the ability to mint new tokens or burn existing tokens
2. If the Account account is not rent-exempt,

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

   Lines 41 to 52 in f8f51c1

   	pub struct Account {
   	/// The type of token this account holds.
   	pub token: Pubkey,
   	/// Owner of this account.
   	pub owner: Pubkey,
   	/// Amount of tokens this account holds.
   	pub amount: u64,
   	/// If `delegate` is None, `amount` belongs to this account.
   	/// If `delegate` is Option<_>, `amount` represents the remaining allowance
   	/// of tokens this delegate is authorized to transfer from the `source` account.
   	pub delegate: COption<AccountDelegate>,
   	}

   and if it's rent collected then the supply field in the Token account is now wrong.

(1) is probably not a big issue, but (2) certainly is.

Possible solution:
a) Require the Token account to be rent-exempt
b) Remove the supply field from Token account so that an Account account that is not rent-exempt cannot poison the supply. This increases the burden on Rpc and other clients, as the token supply must now be calculated by enumerating all the Account accounts for a given token

[mvines]

An alternative to Possible solution (b) is to redefine the supply field to be "total minted supply" rather than "current supply". Under this scheme the Burn instruction doesn't need the Token account anymore.

[jackcmay]

Why do we care about total minted supply? Isn't that something we could harvest from history?

[mvines]

Why do we care about total minted supply? Isn't that something we could harvest from history?

Tyera and I brainstormed on this a little earlier. I initially was arguing for removing the supply entirely if it wasn't going to be able to reflect tokens that had been implicitly burned by rent delinquency. However the utility of keeping it around as the "total minted supply" seemed to be:

1. At least you get a sense of "no worse than"
2. Tokens "burned" by transferring them to an address with no private key already show up in the "supply", so it's not exactly super accurate already

One argument I can now see for not including "total minted supply" at all, so that some tokens will be used to reflect off-chain assets. So if tokens are being minted/burned regularly, we'll see "total minted supply" continually growing and that could confuse the situation if somebody incorrectly assumes that "total minted supply" is the actual supply of that off-chain asset.

[jackcmay]

IMO the arguments for total minted supply are weak and its definition and usage will most likely be misunderstood and sew confusion.

[mvines]

IMO the arguments for total minted supply are weak and its definition and usage will most likely be misunderstood and sew confusion.

I'm down with that I guess, unless @CriesofCarrots can re-convince me otherwise!

[mvines]

With TokenInfo::supply on its way out, we could reduce TokenInfo::decimals from u64 to a u8 and then shove it into the Stake::Account struct. This:
a) Allows a front-end to accurately render a token balance without having to fetch the Mint account
b) Reduces the Mint account to only holding owner: COption<Pubkey>

[CriesofCarrots]

With TokenInfo::supply on its way out, we could reduce TokenInfo::decimals from u64 to a u8 and then shove it into the Stake::Account struct. This:
a) Allows a front-end to accurately render a token balance without having to fetch the Mint account
b) Reduces the Mint account to only holding owner: COption<Pubkey>

This would be really nice simplification, imo

[jackcmay]

@mvines, @CriesofCarrots If we sticking decimals into State::Account are you suggesting that the InitializeAccount instruction take decimals? That seems like it could get disjointed between accounts associated with the same mint. If we can't leave it to the front-end to know the decimals then maybe we leave it in TokenInfo

[CriesofCarrots]

@mvines, @CriesofCarrots If we sticking decimals into State::Account are you suggesting that the InitializeAccount instruction take decimals? That seems like it could get disjointed between accounts associated with the same mint. If we can't leave it to the front-end to know the decimals then maybe we leave it in TokenInfo

Ack, fair point. I suppose one option would be to carry decimals in both places. Keep it in TokenInfo so that it's available there to populate the field in Token Accounts on Initialize. But that seems not worth it to me.

[mvines]

Both places wfm, it's just a u8. It's in the mint for InitializeAccount to use, but then gets stored in each token so that one can fully render a token in a generic token explorer UI with just the information in the token account itself

[jackcmay]

@mvines There is a chicken and egg issue with decimals.

• initialize an account by passing the token pubkey with an uninitialized mint (decimals are unknown)
• initialize the mint by passing an initialized account (decimals are known)

I'm inclined to leave decimals in the mint and out of the account, pulling the mint account to find out decimals (which doesn't change) seems reasonable.

If we want to keep decimals in accounts we could unwind the initialization sequence.

Maybe:

• InitializeMint always takes an owner
• InitializeMint is the first step
• Then Initialize accounts passing an initialized mint
• Use MintTo to mint coins
• Use Revoke or 'SetOwner' to remove the owner from the Mint, once removed can never be added back thus converting the mint to a fixed supply.

[mvines]

I'm inclined to leave decimals in the mint and out of the account, pulling the mint account to find out decimals (which doesn't change) seems reasonable.

Yeah ok. It's not that big of a deal to pull the mint. Let's just leave it as is then