AKA the handbook to deciphering what the FATF Guidance means for DeFi
I am not one who likes writing preambles, but some context as to what led me to write this document is important. The latest guidance issued by the Financial Action Task Force (FATF) is a sound warning bell against the crypto industry, specifically DeFi. For those who don’t know – the FATF is an international organisation responsible for issuing recommendations and guidance notes that are taken up, and implemented as law, by almost every country in the world. The consequences from not doing so are the so-called grey-listing and black-listing processes; while neither can be described as a direct economic sanction, the consequences of either can be catastrophic. The updated Guidance on Virtual Assets (VAs) and Virtual Asset Service Providers (VASPs) is not legally binding on its own, but it is quite likely to be integrated into the laws of many countries worldwide, either as-is, or with various modifications.
The tl;dr of this is the following: if a DeFi protocol or dApp is deemed to be centralised enough, then it will be treated as a centralised VASP for all intents and purposes, meaning that certain measures such as Know-Your-Customer (KYC) and Due Diligence (DD) processes would need to be adhered to by the protocol or dApp in question, including implementing the infamous ‘travel rule’. This can have massive consequences on the operability of the project in question. I shall be using the word “project” from now onwards to refer to a DeFi protocol, dApp, or platform. I will explain, in detail, what the latest FATF Guidance is all about, and then proceed to explain how one can ensure that they are not caught under the Guidance. Keep in mind that various countries may implement the FATF Guidance in an even more restrictive manner.
OK, so what is the latest FATF Guidance all about?
It attempts to bring DeFi operators within the scope of the definition of a VASP. First of all, let’s see:
- How a Virtual Asset (VA) is defined;
- What constitutes a VA Service; and
- What is a VASP.
What is a VA?
Any digital asset that is not a financial asset, and which can be used for payment or investment purposes. It is a purposefully broad definition, which however excludes NFTs. The Guidance does point out an exception to this, namely NFTs that are used for payment or investment purposes in practice. This would be the case of yield-bearing NFTs for example.
What constitutes a VA Service?
- Exchange between virtual assets and fiat currencies;
- Exchange between one or more forms of virtual assets;
- Transfer of virtual assets;
- Safekeeping and/or administration of virtual assets or instruments enabling control over virtual assets; and
- Participation in and provision of financial services related to an issuer’s offer and/or sale of a virtual asset
Therefore, simply handling a transfer of VAs from one address to another is a VA Service, as is custody of assets (including via a smart contract), and swapping services, be it via an AMM, a bridging service, etc. The same also potentially extends to ancillary services such as tumbling, and to protocols that wouldn’t ordinarily be thought of as connected directly to DeFi, such as certain layer-2 solutions, since the latter can be deemed to constitute offering the service of transferring of VAs.
What is a VASP?
Any natural or legal person who is not covered elsewhere under the FATF Recommendations and as a business conducts one or more VA Service for or on behalf of another natural or legal person.
A person can be either a legal person, such as a company, or a natural (individual) person. Such a person must “conduct” a VA Service, meaning that there should be active involvement by such person in offering a VA Service.
Moreover, such a person must conduct the VA Service as a business, generally meaning that the activity is being carried out with the intention to derive profit. Therefore, it excludes entities that carry out such services for non-commercial reasons.
The phrase “for or on behalf of another natural or legal person” includes carrying out of the function in the course of providing a covered service to another person. This person for whom or on whose behalf financial services may be conducted may also be referred to as a “user” or “customer” of those services. In this respect, users of a DeFi protocol would quite likely satisfy this part of the definition.
The obligations in the FATF Standards stem from the underlying financial services offered without regard to an entity’s operational model, technological tools, ledger design, or any other operating feature. Therefore, simply stating that there is a DAO behind a particular DeFi project is not enough to avoid classification as a VASP.
So, is there any way out?
The short answer is “yes”. The longer answer will dissect the definition further, pointing out areas where one would circumvent the definition that has been laid out by FATF.
First of all, it is worth pointing out that writing and releasing open-source code cannot be tantamount to “conducting” a VA Service. However, before developers take a step back and sigh in relief – we are talking about the literal writing of protocol code. If you also develop and run the UI required to access that protocol, and through that UI, users can access VA services that are run on a blockchain network, then the argument starts becoming more complicated. One may argue that you cannot code a fully-fledged and operational protocol plus the UI through which a free-for-all VA service is being offered, and then claim that your role was simply that of a developer, especially if you are also deriving profit from your technological work of art and your continued supportive role is vital for the successful functioning of the protocol. Such would be the case if you get a cut out of each transaction occurring on the protocol, even if done by a roundabout means such as claiming that the cut goes to a DAO-controlled treasury, but then you own 25% of the governance tokens controlling the DAO itself. That’s an old trick in the book, and one which won’t work.
So, what is the situation if one does not do it for profit? Well, that’s where the first crack in the armour appears, and it’s a very solid one. The VASP definition clearly states that the VA service must be conducted “as a business”, meaning that it is being conducted with the aim of deriving profit therefrom, or as a going commercial concern. If one can provide that not only profit was not derived from the creation of protocol, but also that there was no intention to derive profit therefrom, then such argument goes a long way towards exonerating oneself from the definition of a VASP. This is where deployment via a public purpose, non-profit foundation comes in really handy. It’s hard for regulators to argue that a protocol was developed with the intention to derive profit therefrom, when the person releasing it was set up precisely for a non-profit purpose, which purpose should be to develop the protocol further in a sustainable manner. This does not mean that developers do not get compensated fairly for their work, with the term “fair compensation” being subject to a wide latitude of interpretation. Just to make it clear – 50% of the total token supply does not constitute fair compensation, so let’s not get greedy. The same goes for those wise persons setting up a related, for-profit legal entity with the excuse of safeguarding IP rights and so on – the regulators are not stupid. A set up with a for-profit entity may nonetheless get you far if done properly, but it will not be bulletproof.
A second line of defence lies in taking a step back, or a diminished role, in the further development of the protocol once it is successfully deployed. This would ensure that you, as a developer, are not providing a VA Service because, simply put, you are no longer involved in its running. This can be done once sufficient support is attained by way of the permissionless nature of the protocol in question, where other persons can come along and help develop it further. Just to clarify: helping develop a protocol is not tantamount to providing a VA Service. But when you’re the sole and star of the show, it becomes that tiny bit more difficult to argue that you are not providing a VA Service. Vires in numeris, and all that. That being said, even if you are the lone supporter, proving that you are not deriving any profit from it should be sufficient defence from classification as a VASP.
There is also a strong element of peace of mind being afforded to developers in paragraph 82 of the Guidance, which makes it clear that “a person that creates or sells a software application or a VA platform (i.e., a software developer) may therefore not constitute a VASP, when solely creating or selling the application or platform.” This goes perfectly in line with what is being stated above, as that same paragraph goes on to state that “using the application or platform to engage in VASP functions, as a business on behalf of others, however, would change this determination”.
Do note that the creation of a foundation is not necessary in those instances where the project can be deployed in such a way that it is immediately community-owned and run from the outset. We are increasingly seeing projects being deployed only after a solid community has been built out, be it on Discord, Telegram, or any other channel allowing for such communications to take place that would facilitate the running of the project in as decentralised and a distributed a manner as possible. Couple that with a so-called “fair launch” where, at most, the core deploying team gets rewarded for their work in a just manner, and the need for a foundation greatly diminishes. If anything, this should be the preferred method of launching a project, as doing away with a foundation also goes a long way towards proving that the project is as decentralised as can be.
I’d like to conclude this section by making it clear that the above only applies if you might be offering something that may be classified as a VA Service. Certain activities such as providing liquidity, usage of the protocol, node-hosting, etc. are not tantamount to offering a VA Service, so there’s no reason to panic. The same applies for P2P transfers – you won’t get jailed for sending some DOGE to your grandma to get her into crypto.
The FATF Guidance does, however, tackle head-on DeFi applications
In fact, it does so in a bit of a worrying manner. I am going to reproduce paragraph 67 in full here below:
A DeFi application (i.e. the software program) is not a VASP under the FATF standards, as the Standards do not apply to underlying software or technology (see paragraph 82 below). However, creators, owners and operators or some other persons who maintain control or sufficient influence in the DeFi arrangements, even if those arrangements seem decentralized, may fall under the FATF definition of a VASP where they are providing or actively facilitating VASP services. This is the case, even if other parties play a role in the service or portions of the process are automated. Owners/operators can often be distinguished by their relationship to the activities being undertaken. For example, there may be control or sufficient influence over assets or over aspects of the service’s protocol, and the existence of an ongoing business relationship between themselves and users, even if this is exercised through a smart contract or in some cases voting protocols. Countries may wish to consider other factors as well, such as whether any party profits from the service or has the ability to set or change parameters to identify the owner/operator of a DeFi arrangement. These are not the only characteristics that may make the owner/operator a VASP, but they are illustrative. Depending on its operation, there may also be additional VASPs that interact with a DeFi arrangement.
I have emphasised the part above in bold, as I want to spend some time on this part. Exercising control over a particular project goes beyond merely developing it and deriving profit therefrom by way of a cut of the transaction fees. With the advent of DAO governance, and governance tokens representing one’s rights in relation to a related DAO, one needs to be very careful where to draw the line when it comes to determining “sufficient control and influence”. Paragraph 82 of the Guidance, in fact, emphasises the aspect of sufficient control and influence, as it states that “a party directing the creation and development of the software or platform, so that they can provide VASP services as a business for or on behalf of another person, likely also qualifies as a VASP, in particular if they retain control or sufficient influence over the assets, software, protocol, or platform or any ongoing business relationship with users of the software even if this is exercised through a smart contract”. Let’s explore what can potentially constitute sufficient control and influence.
- Allocation of governance tokens
Let’s get rid of the elephant in the room first – allocating oneself a healthy dollop of governance tokens and retaining control over any strategic decisions related to the project is a big no-no. Vesting and lock-up periods won’t help at all either, unless vesting is done in such a way as to receive the tokens when the circulating supply is increasing exponentially in tandem. Still, if the end result is that you end up with 25% of the total token supply, then no amount of clever vesting schedules will help you at the end of the day. This is especially the case if governance tokens grant rights to returns generated by the project, as it would entail the deriving of profit therefrom. Bottom line: don’t be greedy.
- Effective influence over governance votes
Let’s say that you are a truly altruistic person and decide not to allocate yourself any governance tokens whatsoever. Good for you! However, if you go on to exercise influence by constantly submitting proposals yourself to be voted upon, and directing the discussion taking place on such proposals or others that were submitted by third parties, then this may still count as sufficient control and influence. There’s nothing wrong in submitting proposals from time to time on how the project can go forward, but you cannot be the sole voice of leadership in what is meant to be a decentralised protocol.
- Effective influence over governance votes (part 2)
Let’s say that you are a bit less altruistic, but not greedy – you allocate yourself 2.5% of the total token supply, since that will still be enough to have you comfortably retired once your baby becomes a billion-dollar DeFi unicorn. What’s more, voting turnout for proposals is a comfortable 25% of the then-current circulating supply, and you decided never to submit another proposal again, so that you can surely not be seen as exercising sufficient control and influence. But like all nice things in life (or most of them, anyway), interest starts waning, and the voting turnout starts decreasing to the point where voting turnout is regularly below 4% of the total token supply. All of a sudden, the altruistic-not-so-altruistic developer holds enough tokens to comfortably sway any proposals being submitted in his or her favour, even though 2.5% of the token supply may have initially seemed a small portion. This is another solid case for not allocating oneself too many tokens beyond what is deemed to be just and equitable compensation for one’s work.
- I counsel you not to council
OK, let’s say that you don’t allocate yourself any tokens, you blacklist “snapshot.org” from your browser along with those other questionable URLs, and your only role is to take up a seat at the board or council of the non-profit foundation I mentioned earlier on. While this may be one of the safest options to pursue, I still normally advise clients to let non-core team members constitute the board or council of the foundation in order to ensure as much a degree of separation and segregation as possible, especially if the board/council holds some form of veto right in relation to decisions affecting the running of the project. I understand it may be difficult to completely let go of the thing you helped create, but killing one’s ego here opens up the path to salvation, in a sense. Deep thoughts, I know.
- Project-derived returns should be directed fully towards a DAO-owned or foundation-run treasury
I have hinted at this in point 1 above, but let me repeat it – if governance tokens grant you a right to a cut of the returns generated by the project, then you are deriving profit from it, and this in turn can quite likely expose you to potential classification as a VASP. I know that vanilla governance tokens that only allow you to vote are boring, but boring is safe. Besides, with a bit of creativity, that governance token can still generate money. Think outside the box.
- Active hands-on involvement, being it active or passive
I saved the most obvious for last, both because it’s been already quite covered above, but also because there are a couple of other ancillary points I’d like to address. Apart from active hands-on development of the project which must be diminished should one want to lessen the risk, there’s also passive involvement, such as being one of the multi-sig key holders. While this would not, on its own, subject one to definite classification as a VASP, it is certainly an important point to keep in mind, and should be taken into consideration whenever accepting such roles.
Decentralised, moisturised, and focused? Good for you – but FATF is still hungry for more
The following paragraph, being aptly numbered 69, smacks of arrogance on part of FATF. Let’s reproduce it in full (excuse the pun):
Where it has not been possible to identify a legal or natural person with control or sufficient influence over a DeFi arrangement, there may not be a central owner/operator that meets the definition of a VASP. Countries should monitor for the emergence of risks posed by DeFi services and arrangements in such situations, including by engaging with representatives from their DeFi community. Countries should consider, where appropriate, any mitigating actions, where DeFi services operating in this manner are known to them. Such actions may be taken before the launch of the service or during the course of the DeFi services being offered, as necessary. As an example, where no VASP is identified, countries may consider the option of requiring that a regulated VASP be involved in activities related to the DeFi arrangement in line with the country’s RBA or other mitigants. Countries could also consider the ML/TF risks and potential mitigating actions in relation to P2P as set out in this Guidance.
It is clear, from the statement above, that even in the case of a permissionless and decentralised DeFi project, FATF would still like to see some form of control being exercised by a regulated VASP. How and if that would have any effect on the underlying protocol or dApp is questionable, but it goes a long way to show FATF’s intentions of trying to reign in the threat it is perceiving in DeFi.
On that note, I would like to conclude by stating that the FATF Guidance has set off a ticking time bomb. The Guidance itself is not legally binding, but countries will soon be implementing it under their national laws, at which point it will become legally binding depending on the jurisdiction in question. Whether we have six, twelve, or eighteen months is anyone’s guess – it all depends on how quickly countries will act in implementing such Guidance. It is therefore important, now more so than ever, that steps are taken to divest oneself from responsibility and therefore liability, either by having the right legal structures in place, or by pursuing decentralisation to its fullest extent.
Feel free to follow me on Twitter for more crypto regulatory insights - @ImpermanentGain. Their resistance, and your support.