Adding additional open standards to drive institutional liquidity and support issuers

[wbnns]

Hi friends! Happy holidays to all that are celebrating! :) As 2021 draws to a close would like to propose additional features / open standards to incorporate into SPL Token, with this as an umbrella issue of sorts (please LMK if it would be better to open separate issues, just wanted to be sensitive about other people's notifications, etc. -- thought it would be good to get feedback here, first).

---

Abstract

The SPL Token library defines a common implementation for fungible and non-fungible tokens (NFTs) on Solana. To make it easier for institutions to deploy assets and supply additional liquidity, would like to spearhead the effort here of contributing to an open initiative to bring additional open standards for the introduction of additional commands detailed below to make it more feasible for institutions and issuers to interact with the network.

Institutions and issuers have complex transactional and reporting requirements. Assets must not only be able to adhere to corporate, regulatory and compliance policies but they must also be able to integrate with technology platforms underpinning their organizations.

Additional open standards and features that institutions and issuers can leverage in SPL Token will help bring additional institutional liquidity and more assets to Solana as it scales.

Restrictions

Institutions and issuers need the ability for certain types of token transfers to be restricted, so that any wallets interacting with a token can first query to determine if the transfer is allowed, and if not, show the appropriate error to the user (including the reason code/text).

Roles

Institutions and issuers need the ability to be able to specify more granular roles when it comes to a token’s administrative functions. Below are some examples of those that are most relevant to these entities, based on our experience setting up role-based functions on assets on other networks and blockchains:

• Owner: Owners are responsible for managing permissions of all roles.
• Burner: These accounts can burn tokens from accounts.
• Minter: These accounts can mint new tokens to other accounts.
• Pauser: These accounts can halt all transfers on the token.
• Reclaimer: These accounts can reclaim tokens from other accounts into their own.
• Allowlister: These accounts can configure allowlist rules and add/remove accounts from allowlists.
• Denylister: These accounts can add or remove addresses to or from the denylist.

Allowlists

This feature for institutions and issuers would ensure that before tokens can be transferred, a transaction must be validated that the source is allowed to send to that destination and that the destination can receive funds. If the sender does not check this in advance and sends an invalid transfer, the transfer functionality will fail and the transaction will revert.

Owner accounts would have the ability to transfer tokens to any valid recipient, regardless of the allowlist configuration state.

An Owner could enable and disable the allowlist functionality to remove the allowlist restrictions on transfers. The default state would be set as enabled/disabled in the initialization of the token.

Examples:

• Allowlist A is only allowed to send to itself.
• Allowlist B is allowed to send to itself and allowlist A.
• Allowlist C is allowed to send to itself and allowlists A and B.
• Allowlist D is not allowed to transfer to any allowlist, including itself.

Administrators will have the ability modify a allowlist after a token has been initialized.

Denylists

This feature for institutions and issuers would ensure that before tokens can be transferred, if the denylisting feature was enabled, it would check to ensure both the source and destination are not denylisted. If either is denylisted the transfer will fail.

An Owner could enable and disable the denylist functionality to add or remove restrictions on transfers. The default state would be set as disabled.

Accounts with the Denylister could add or remove accounts to or from the denylist.

Pausing

This feature for institutions and issuers would ensure that the Pauser accounts may pause/un-pause a token.

When a token is paused all transfers will be blocked. When deployed a token is initially un-paused.

Reclaim

This feature for institutions and issuers would ensure Reclaimer accounts can reclaim tokens from any account. Reclaiming tokens would have no effect on the total supply, it increases the balance of the account reclaiming the tokens and decreases the balance of the account the tokens are reclaimed from.

Summary

These features enable institutions and issuers to bring additional institutional liquidity and more assets to Solana as it continues to scale.

They also enable institutions and issuers to instantiate assets that fall within regulatory and guidelines and are compliant in their jurisdictions. Without this, in some places, like in the United States, it will be difficult for institutions and issuers to deploy assets on Solana unless they are domiciled through offshore entities.

[vmcvpn]

We are actively looking into whether this as can be easily accomplished on Solana as many of our tokens will be securities. eg ERC 1400. This is critical for global security token issuers.

[jpbogle]

Hi @wbnns and @vmcvpn

We are achieving some of these similar features for NFTs using our protocol called Cardinal (https://cardinal.so) to build programmable NFT certificates. The protocol works by using functionality like delegate and freeze in SPL token and CPIing into token program and builds on top of it in a new program. I think all these features can be built in a similar way potentially and maybe we can discuss? I am not positive but of course these features could also be built in a whole new token program but it may be more complicated given solana doesn’t have a way to implement a common interface so it wouldn’t work in most places.

[wbnns]

@jpbogle

Heya! Thanks for mentioning this! I think the biggest thing that we're trying to ensure though is that this is possible within SPL token without using a new program.

Otherwise it complicates things quite a bit because all platforms will have to support the new program as well. All of them already support SPL token.

[buffalu]

you might be able to get some of this functionality by using the combination of the SPL token program and a wrapper program that owns the various admin keys associated with the account, perhaps owned by a multi-sig. There's probably more creative ways to do the below.

On freezing + thawing accounts: https://spl.solana.com/token#freezing-accounts This should get you Allowlister and Denylister. Can transfer ownership of freeze_authority to another program that has ability to do this.

for reclaimer, you can freeze an account, mint the equivalent, and send to yourself. would want to wrap this in a program as well to make sure it's atomic + can't be screwed up.

for pausing/unpausing, you'd probably have to modify some account passed into transfer that has a bit set for the state.

this is somewhat related, but might give you ideas: https://github.com/step-finance/step-staking/blob/main/programs/step-staking/src/lib.rs#L38

[erwanor]

Denylists

This feature for institutions and issuers would ensure that before tokens can be transferred, if the denylisting feature was enabled, it would check to ensure both the source and destination are not denylisted. If either is denylisted the transfer will fail.

An Owner could enable and disable the denylist functionality to add or remove restrictions on transfers. The default state would be set as disabled.

Accounts with the Denylister could add or remove accounts to or from the denylist.

Just a quick comment about denylists and the current implementation in the SPL library. As you probably know, it is already possibly to Freeze or Thaw an initialized SPL account: https://github.com/solana-labs/solana-program-library/blob/master/token/program/src/processor.rs#L698

However, Account::unpack checks that the account is initialized and fails otherwise. So as it stand, this can only be a reactive measure i.e you cannot take a list (say OFAC for example) and pre-emptively make sure that none of those addresses will touch your securities or what-have-you.

[jommi9]

Was this implemented?

[joncinque]

Token-2022 has many features to allow almost all of this behavior

• Reclaimer: This is done with the "permanent delegate" extension on the mint https://spl.solana.com/token-2022/extensions#permanent-delegate
• Allow list / deny list / pausing: This will be possible through the "transfer-hook-interface" being added #4151 -- token creators can implement their own program that is called on any transfer, allowing them to implement any logic that they want to permit / prohibit a transfer. This logic could involve an allow / deny list or a total pause.
• Roles: all of the roles are already available, except for the separation of owner and burner. This could be done through a new "account extension" in token-2022 to specify a delegate that can only burn. Otherwise, this could also be done through a separate "owner" program that owns a token account and allows other keys certain actions.