CAP-0046-06: Built-in Token Contract in Soroban

[Siddharth Suresh]

Hi,

I just updated CAP-0046-06 and wanted to get some feedback - https://github.com/stellar/stellar-protocol/blob/master/core/cap-0046-06.md. There are still some open issues around authentication and asset compliance, but the recent changes aim to improve upon the token contract that people have been experimenting with on Futurenet.

Here are the high level changes from the most recent iteration - 

• Token balances have been updated from BigInt to u128.
• Approve was replaced with increase_allowance and decrease_allowance.
• Some naming changes to make Soroban terminology match up with Stellar classic. 
  • burn -> clawback.
  • freeze->deauthorize
  • unfreeze->authorize
• Allow the admin to disable clawback, along with rules on how it's set for wrapped assets.

Thanks,

Siddharth

[Siddharth Suresh]

There is also an open question on how auth_required should work with tokens that

wrap a Stellar classic asset. On Stellar classic, any trustline created tied to

an issuer that has AUTH_REQUIRED_FLAG set will be deauthorized on creation.

Maintaining this requirement is important because it can be used to indicate a

trustline that has gone through KYC verification. If we ignore

AUTH_REQUIRED_FLAG in Soroban, then it would be possible for accounts,

contracts, and ed25519 identifiers to interact with a token without going through this

verification.

I have two possible solutions that we can discuss. Neither are great but hopefully

we can build off of them -

1. When init_asset is called to initialize a token that wraps a classic asset,

set a flag that disables all non-admin functions on the token contract if

the issuer exists and it has AUTH_REQUIRED_FLAG set. This effectively locks

assets from that issuer out of Soroban, unless the issuer wraps the users

Soroban invocation with a authorize/deauthorize contract function sandwich. This

assumes Soroban will have a mechanism to do multiple invocations atomically.

2. This second solution is more flexible for issuers. If a new balance is being

written for an identifier in the token contract and it's for a token that wraps

a classic Stellar asset, check if the issuer has AUTH_REQUIRED_FLAG set. If it

does, then reject the write with a failure indicating that the balance is not

authorized. That identifier should explicitly be authorized by the issuer before

it can be used. If the issuer doesn't exist, then just assume it's authorized

because the issuer account can be created by anyone without AUTH_REQUIRED_FLAG

set. Something to note here is that the most recent CAP update flipped how token

authorization worked. Instead of setting a flag indicating that an identifer is

deauthorized (or frozen as it used to be called), a flag is set when a new

balance is created indicating that it's authorized. This allows a proposal like

#2 to work, but it's not ideal because each balance will now use an extra ledger

entry that indicates authorization by default for a scenario that most tokens

don't care about. An explicit authorized flag (as opposed to deauthorized flag)

should only be used if we're convinced there's no better method. An alternative

to this would be to introduce a second flag that must be set specifically for

auth_required assets.

Siddharth