This page is where we track a series of issues which must be changed to enable the tokenization of securities in the US.
One of the biggest questions is how to approach the prevention of money laundering with tokenized securities. Do all holders of tokens need to be identified by a KYC provider, or is it sufficient to require KYC for issuance and redemption, as well as trading into and out of USD and other fiat currencies on centralized exchanges?
On the one hand, blockchain tokens today generally do not require any onchain KYC, and blockchain analytics companies and centralized exchanges manage to track down quite a lot of criminal activity. Another point in favor of this approach is that some foreign regulators, including in Europe, have approved the issuance of tokenized securities without requiring KYC for each token holder, only requiring it for issuance and redemption. Similarly, US regulators like the New York Department of Financial Services have approved of the same approach for USD stablecoins.
On the other hand, current securities regulations in the US require that brokerage companies know the identity of the ultimate holder of each security. And some might make the case that requiring that each token holder be KYCd somehow by someone would greatly improve our ability to track or stop criminal activity. It may also assist in the re-issuance of security tokens for people who have lost access to their keys, though that comes with issues of its own.
Hence the question: How helpful is KYC on each token holder for preventing money laundering and terrorist financing, relative to the system of blockchain analytics and KYC on centralized trading, issuance, and redemption that we have for most crypto assets today?
This question requires that we research the effectiveness of current crypto asset AML systems as well as current AML systems in the traditional securities markets in order to compare them. We also must think about whether full onchain KYC would differ from traditional KYC within centralized platforms.
But this just addresses the benefits of onchain KYC for AML/CTF. We must also consider the costs.
One major cost is the reduction in composability within DeFi. Suppose 50 security token issuers all had their own KYC requirement for their token holders. Now suppose that a DeFi smart contract accepted deposits of all 50 tokens in exchange for an index token that represented a portfolio of them. The security token issuers would probably have programmed their tokens’ transfer methods to check for the recipient address having the right KYC attestation or being on a whitelist – so any smart contract address would also need to be whitelisted. But in order to approve of a smart contract, the issuer would likely need to see that the tokens issued by the contract which indirectly represent ownership in the underlying would inherit their KYC whitelist requirement. In the scenario of an index product that accepts deposit of 50 different tokens, that would mean the contract would have to require the index token holders to go through KYC with *all 50* of the issuers. And then if that index token was accepted as collateral in a lending app, that lending app would need to inherit all of those restrictions as well for its tokenized position, and so on. You can see how this would be a problem for DeFi developers and for end users relative to the efficiency of DeFi composability today.
Hence the question: Is it even possible to introduce onchain KYC requirements without breaking the composability of DeFi applications or otherwise making them extremely impractical to develop and use?
In addition to considering how onchain KYC might impact AML program effectiveness, we must also consider whether and how sanctions enforcement comes into play.
If a security originates in the US, the Office of Foreign Asset Control might prefer to have power over it when it’s held by a US person on behalf of a non-US person. However, depending on the structure of how a security is tokenized, it may or may not be the case that any US person is in possession of the security on behalf of a non-US person.
Put a different way: where is the property? Is it the token itself, or is the property whatever is held by the security token issuer on behalf of the token holder? There are many ways a security token could be issued, ranging from the original issuer and transfer agent representing the asset ownership table as a token from the start (kinda like a CBDC but for a privately issued security) all the way to a 3rd-party company holding the security with a bank or broker and offering only a limited degree of “redemption” rights to token holders, such as redeemability for the cash value to a limited set of market participants, à la USDT. These choices may impact the question of whether a person holding the token in their own custody still has someone else holding their property for them or not, and this may impact the sanctions applicability.
These likely have other legal implications as well.
Hence the question: What are the main routes to security token issuance, and what are the main legal implications they each carry?
Where should the line be drawn on what counts as a smart contract exploit? In general we treat actions as theft when everyone is surprised that the actor was able to withdraw funds from a smart contract in a counter-intuitive or surprising way, but what about cases where there is no crystal clear documentation of how a smart contract is intended to behave? Or what about cases where a smart contract worked as intended by the developers and consistently with documentation, but users had been led to believe the contract would work differently by a tweet, or just an assumption they made?
Should DeFi developers have any regulatory obligation to complete code audits, or should it be left up to the market to drive the use of good security practices?
A sandwich attack is a way that blockchain node operators can take advantage of their ability to order the transactions they include in blocks they validate in order to front run trades submitted to automated market making contracts like Uniswap. You can read more about them (and CoW Swap’s solution to them - good content marketing CoW Swap!) here.
Should regulation be used to prevent this kind of front running and market manipulation? Or should we give the market and the technologists more time to try and sort it out? Given that MEV searchers can operate from anywhere in the world, is it even practical to hunt them down and punish them?
DeFi users depend on UI makers and hosts not to lead them astray.
If a contentious fork happens, how do security token issuers know which chain to continue supporting redemptions on? They can’t choose both.
What if different issuers choose different sides of the fork? We could end up with DeFi applications that assumed certain levels of collateral value suddenly experiencing crisis, as both copies of the application on the two chains only have a portion of the real assets they had before.
Or what if blockchain platforms malfunction in some unexpected way, and somehow trades or transactions revert in ways that lead to significant loss for some users? (This one is more of a “hmm, is there something there to worry about or not?” question.)
One potentially major issue with public blockchains is that they are public. Some users and use cases have more of a need for privacy. Some businesses may not be comfortable with their assets being publicly visible, for instance.
In general, public chains may be problematic in any instance where people transact in person. Suppose you go to a grocery store and pay the store in stablecoins. Someone could sit there and watch a blockchain explorer to see who is transacting with the store’s payment addresses, learning about the holdings and other purchasing history of each person as they pay in the store.
At the same time, introducing full privacy obviously comes with lots of issues of its own. The AML system that’s been set up for stablecoins and DeFi today would not work the same, for instance. Tracking stolen funds would be much harder!
Given the programmability of tokens, handling voting with onchain actions seems quite doable. Likewise, publicly communicating opportunities to vote doesn’t seem like it will be a problem, as token holders could subscribe to a service that aggregates vote notifications about all tokens they hold in their wallets.
But what about countries that are concerned about foreign adversaries acquiring major voting power in their important corporations? Perhaps onchain share holders could be asked to prove their citizenship before voting?
Traditional securities exchanges have the ability to halt trading under certain circumstances. No such ability exists with DEXs or even CEXs when there’s a fragmented market across many exchanges.
Hence the question: what are the key reasons for the various types of market controls that exist in the traditional system, and what are the long-term systemic implications of operating with no such controls?
Since smart contracts let developers and users construct a wide array of financial instruments, some investors have a high appetite for leverage, and smart contracts allow the composition of instrument on top of instrument through tokenization of each position, one has to wonder what kind of precarious leveraged situations the DeFi ecosystem will organically fall into.
But legal contracts have already allowed a similar degree of financial product construction and traditional markets have already explored all manner of bets and leveraged positions, so perhaps this is nothing new.
Should we port over the limitations on types of instruments that each type of entity is allowed to deal in, or is that not going to work due to the global and pseudonymous nature of DeFi or the pace at which new types of instruments emerge? Is there an argument for allowing unchecked accumulation of leverage and the associated deleveragings, or is it going to be necessary to put legal limits on the DeFi system?
In general, securities laws work by identifying who needs to be held accountable in any given situation. But some genuine DeFi applications are fully autonomous, so if something goes wrong there may be no clear party to blame.
Some might say the developers should retain liability, while others might say users should use the software at their own risk.
But even if users are happy to take on the risk themselves, there’s still a question about whether regulators will be satisfied with a circumstance where there is nobody to go to if something goes wrong.
Know of another issue we haven’t listed here yet? Get in touch with us and point it out!
Who we are
The Digital Securities Initiative is an industry-wide collaborative effort with no incorporated entity or member dues required to participate. Contributing organizations sponsor their own team members to spend time on the initiative when it is in their interest.
It was started and is led by Nevin Freeman, who is part of the Reserve project, which has a vision that depends on securities being available within DeFi, but is not itself involved in security tokenization and has no financial interest in any security tokenization company.
To learn more about the initiative and who is involved, read our introduction.