Closed wbnns closed 6 months ago
vmcvpn
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago 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
commented
1 year ago Was this implemented?
joncinque
commented
1 year ago Token-2022 has many features to allow almost all of this behavior
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:
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:
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.