Mit pełnej decentralizacji. Czy Recital 22 MiCA to pułapka dla DeFi?

Transcript

Good morning. Hello everyone. My name is Paweł Filipe, from the Graci Partners law firm. In my professional practice, I deal with issues related to blockchain and cryptoassets, including regulatory and supervisory aspects of the financial market. The topic of our meeting today is the myth of full decentralization, Recital 22 MIK. I think it's worth mentioning at the outset that MIKA is a truly comprehensive regulation that currently governs the cryptoassets market in quite a detailed manner. Yes, if we look, for example, at countries where

MIKA has already entered into force, where CASH licenses are already being issued, we can see that in this VASP regime, even before MIKA came into force, we often had 600 registered entities that could legally provide services, such as currency exchange services or exchange services, in the field of cryptoassets. Currently, in these countries, even those that were previously very popular for establishing cryptocurrency businesses, the number of entities legally conducting this activity under the CASH regime has dropped to often six, eight, or a dozen at most under the Mika

regime. Therefore, in this situation, where Mika is truly a regulation not for startups, not for fledgling start-ups, but a regulation that truly connects the cryptoasset market to the financial market. It also regulates this cryptoasset market in a similar way to the traditional finance market. Certainly, any situation where we can seek exemptions from MIKA, where we can conduct business without obtaining the required CASH license under Mika, is also very attractive to entities, especially smaller ones conducting

cryptocurrency business. First, I think it's worth defining what decentralized finance is, and how these issues were defined even before or at the time Mika came into effect. Here, we see, for example, the definition from Eba's guidelines on money laundering and terrorist financing risk factors. This definition, defining a risk factor, also points to the definition of decentralized finance. It focuses on the fact that decentralized finance is

a situation where control over an application is distributed, right? It is not under the influence of a legal entity, er, an individual. Therefore, this lack of control is a very important feature from the perspective of this definition. In turn, we also have the ISO standard, which you see, which first defines decentralized applications as those operating in a decentralized system, but importantly, it also defines a decentralized system as a distributed system in which control is distributed among individuals or organizations participating in the system's operation . So, here, we see a certain difference between these two definitions: lack of

control, distributed control. This doesn't have to be bad news from the perspective of potential cryptocurrency investors or individuals, as different approaches can also allow us to defend different business models in terms of their immunity from subsidy. We can always try to defend not only a model where this control is absent, but also one where this control is dispersed, against, say, the voices of regulators. Regarding other perspectives on Deffi, it's also worth pointing out that, for example, Esma's position here is that it's an accessless infrastructure.

We're talking about the fact that this access is arbitrary. Access is related to the fact that the traditional legal entity that manages a given application must grant us this access. Where we must undergo some QAC process in decentralized finance, where such decentralization is complete, then certainly in the context of cryptocurrency, we should be able to connect, for example, with our wallet to a specific application and, without further consent or verification processes, be able to operate and use a specific service. Yet another issue is the non-custodial issue, the issue of

storing funds. If we store our own funds, if we have a non-custodial model , where, say, a person using a given service stores their funds on their own non-custodial wallet, then we would also be talking about a decentralized model. Storing funds, in turn—storing funds by the service provider, by the legal entity, or by an individual—is an argument somewhere in the argument that the application, the service, is not decentralized. Yes, and OACD approaches this differently. I mean,

here we see three aspects—we see three aspects pointed out by OSD: this is precisely the issue of dispersion of control, which also appeared a moment ago. We're also talking about the modularity of these solutions, right? About this non-custodial nature. What else can we say? Generally, defining Deffi a bit more, Deffi is intended to fulfill the same functions as traditional finance. We can talk about the transfer of monetary value, the storage of monetary value, and other services provided to clients by service

providers. These services may be analogous to those provided by centralized entities. However, in the case of Deffi, the issue of control, or lack thereof, or distributed control, is the difference between traditional centralized services and decentralized services. Since we're talking about decentralization in the context of the Mika and in the context of the exemptions provided by the Mika, it's worth briefly discussing what the Mika regulates. In particular, it's worth paying attention to the first paragraph

of the Mika, mentioned in the first article. And here, as we can see, on the one hand, the Mika regulates what happens on the primary market—the issuance, offering, and admission to trading of several types of cryptoassets. These are asset-linked tokens, tokens that constitute e-money, so a significant portion of stable coins, defined as such in the market, will fall into these categories. These are also different, not different, but different, cryptoassets than ARTS and EMT, which, in turn, are not generally excluded from the MIK, because security tokens, for example, which are similar

to securities, are outside the MIK's regulations. So, this is one aspect: the primary market. We also have the secondary market, meaning the provision of services, service providers, in the field of cryptoassets, namely the KASP, which must obtain licenses from the appropriate regulator. These include services such as exchange services, cryptoasset storage services, and crypto-to-fiat exchanges. These are the services on the secondary market that are also regulated under the MIK. It's also worth mentioning that, of course,

certain aspects of activity, or certain entities that provide services, or issue specific cryptoassets, are also outside the MIK's regulations. MIKA, too, can be said to be a comprehensive regulation, but it also leaves certain aspects of cryptoassets, certain types of activity, outside its scope. These could be, well, on the one hand, subjective exclusions, objective exclusions. Regarding these exclusions, even objective ones, well, for example, NFT tokens—tokens that are unique and non-fungible with other cryptoassets— remain outside the scope of Mika. As I mentioned, Mika does not apply to

cryptoassets that qualify as one or more financial instruments. Therefore, in the case of cryptoassets that constitute financial instruments, we must analyze MiFIT 2 and the relevant laws in individual member states that regulate this traditional financial market. And here, we will need to assign our activities in the crypto industry, but in the field of security tokens, as they are commonly called.

And in the context of what we're talking about, in the context of excluding certain decentralized activities from the scope of Mika, it's worth briefly discussing these services related to cryptoassets. What's crucial from the perspective of our topic is that, first of all, if we're conducting any crypto-asset activity, we must first define whether we provide any of the services licensed under MIKA. Only once we've determined that we do provide one of these services, the next step is to determine whether we provide them in a centralized or decentralized

manner. Well, if we manage to determine that we actually provide a service, as we see here—examples of them, but they are also defined specifically in Article 3 of the MIKA—if our activity meets the characteristics of a specific service, then we then refer to the regulation, which we'll also demonstrate in a moment in the context of whether we're decentralized or not. However, if the answer is the opposite and we demonstrate that we don't provide any of the services regulated by MIKA, then whether we operate in a decentralized manner is of no real concern to us. We can simply operate in

a centralized manner, but our business model simply isn't a regulated service under Mika. Right? Well, given that Mika already represents such a high level of regulation in this market, recipients of rights and obligations also have the right to expect services to be precisely defined, so as to clearly define the boundaries between those services that must undergo the complex Podcasp licensing process and those that are not regulated in the sense that they either won't have to undergo such a process, can operate within the framework of economic freedom, or on the other hand, will have to meet requirements, for example,

licensing requirements, but possibly under other legal acts. Right? So here, as we see, the first step of the decentralization test, right? That's how we can define it: the decentralization test should be to determine whether the service being analyzed exhibits any characteristics characteristic of Mika services. And only then, as we see from the doctrine, do we analyze this decentralization. We can also briefly discuss those services excluded from Mika. Recital 83 of the MIKA regulation, for example, indicates that suppliers of hardware and software for non-custodial wallets are exempt

from this regulation. Therefore, in their case, there is no need to even attempt this analysis from the perspective of the decentralization test, which we will discuss shortly. Another recital of the MIKA regulation indicates that such services are excluded from the MIKA regulation; they are treated as services that can be conducted within the framework of economic freedom. It could even be said that they can be provided centrally, but they will not be subject to MIKA.

Of course, each of these indicated crypto-asset services must also be analyzed in detail. For example, if we have an advisory service, which we also saw on the previous slide, one of the regulated services under MIKA, then this advisory service, to be valid and require a license, must be personalized . So, if we provide certain advisory services, but in a manner that is not personalized from the perspective of a specific client, we can still try to demonstrate that our activity is not regulated. For example, if we're creating a knowledge base or a database of crypto advice, but it's a general

database, not personalized for a specific client, then we can defend our activity by claiming it's not regulated and there's no need to analyze centralization or lack thereof. In the context of decentralized activity in general, Dex aggregators are also an interesting case. Yes, because on the one hand, we have decentralized exchanges where we store funds ourselves and conduct crypto transactions within the system they provide, but we also have Dex aggregators that help users exchange tokens by combining liquidity from several decentralized exchanges. These types of entities also allow us to show

, or show us, the best path for investment. Keeping in mind that we have a specific amount of crypto assets we want to sell, or a specific amount we want to acquire, such a Dex aggregator allows us to determine the shortest and best path, and which decentralized exchanges to purchase our planned investment from. Importantly, on the one hand, we have these DEX aggregators that simply show us this path, and we then decide on our own investment. We can certainly defend

this model, arguing that it's not a regulated service within the meaning of MIKA. However, if such a DEX aggregator operates in a resolver or market maker model, where, say, we prepare, sign our transaction, and submit it to the market for execution, then we'll be more likely to talk about it being a regulated service, and even if it's a service provided by, say, a crypto broker, they should also obtain a license for the service of accepting

and transmitting orders, placing cryptoassets, and executing orders. Therefore, only once we've determined that this is a resolver or market maker model can we answer the question of whether we're providing this service in a decentralized manner and thus avoid the need to obtain a license under MIKA . Recital 22 of the ICC is a key issue when it comes to decentralization from the perspective of the ICC. What's worth noting? The ICC no longer addresses decentralization in these provisions and articles. In the articles, where we already have

specific legal obligations imposed on their addressees, the ICC only refers to decentralization in the recital. Importantly, like the ICC, like most European Union legal acts, whether regulations or other acts, it has a structure where, on the one hand, we have recitals that indicate the objectives of a given legal act. On the other hand, we have provisions and articles that precisely define the obligations and rights of the addressees of these norms, for example, entities that provide these crypto-asset services in a centralized

manner. This shows us that, in fact, despite the fact that DeFi is a huge thing, a large part of the crypto market, in the Mika regulation, it was relegated not only to a single theme, but to a theme, not to a specific provision that, for example, would already provide a specific test for this centralization or decentralization in the form of specific standards. It's also worth examining how this theme was constructed. On the one hand, it states at the beginning that the more recent Mika regulation will apply to specific entities that provide crypto-asset

services. In this case, when part of such activity is carried out decentrally. And only in the next sentence do we have the indication that if crypto-asset services are provided in a fully decentralized manner without intermediaries, they should not be covered by the Mika regulation. Thus, this demonstrates a very important point: centralization and decentralization can be gradable. It's not a binary concept. We may be able to provide services in a fully decentralized manner, or perhaps not at all, but we also have varying degrees of centralization, which is certainly a

very important issue and something we will discuss shortly. Regarding the gradual nature of decentralization, Mika will not apply when services are fully decentralized. Yes, it's also worth considering the structure of this provision. On the one hand, this recital states that Mika still applies when some services are performed in a fully decentralized manner. And when cryptocurrency services are provided in a fully decentralized manner, then we have this exclusion, so this gradual nature of decentralization is crucial.

It's also worth mentioning what we also mentioned in this recital—well, we can go back a bit—the issue of issuing cryptoassets, which is also worth mentioning in a few sentences. If the issuance of cryptoassets is carried out in such a way that the entity issuing it is unknown or impossible to identify, then such an issuance will not have to meet the requirements on the primary market of the issuer. This is also specified in the above recital. Therefore, we can talk about decentralization in the case of services and decentralization in the case of a public offering on the primary market of cryptoassets, where

the lack of an identifiable issuer is crucial. This is a situation where, if we cannot identify the issuer, we do not have to meet the requirements applicable to the primary market. In my opinion, such an important case, which can help us understand how to approach decentralization and gradualization, is the case that took place in the United States before the United States Trade Commission (CFTC), namely the case of Deridex Incorporate. Regarding the model adopted by Deridex, it developed

and operated a blockchain-based trading platform, Algorant, which it advertised as a decentralized derivatives platform called Onchain. The platform enabled trading in leveraged perpetual contracts. In terms of chronology, this happened in 2022 or 2023, and Deridex retained significant control over the protocol, the Deridex protocol. And what can this tell us, help us understand how to approach decentralization at Mika? Let's consider the following elements. Yes, the protocol was undoubtedly based on

smart contracts. However, Deridex retained significant control over this protocol. On the one hand, from a technical and technological perspective , the company could update the code or disable the smart contract. On the other hand, this affected the provision of services. The company could suspend trading and block the deposit of collateral. What else is worth mentioning? The defendant also operated a website for sourcing orders. So we had this front-end, a smart contract at the back, but on the front-end, there was a page that allowed people interested in investing to join this

smart contract. Yes, Deridex, through the protocol, maintained custody of user assets. Another important element, importantly, the defendant Deridex also retained a small portion of the interest paid by users on such leveraged positions. So, if we consider all these arguments, and at the same time, consider how Mika is, how we initially defined decentralized finance , then a certain picture of how we should approach the issue of decentralization begins to emerge. As we said, it must be gradual. We

certainly won't be talking about decentralization in the case of a company like Delides, where certain processes are automated, where certain processes are managed by a smart contract, but significant control over it remains. And now we see several points here where we can discuss various aspects of decentralization. Yes, on the one hand, there's the technical, technological aspect that stems from this ruling, right? The inability to change the algorithm once it's launched, the inability to stop the algorithm from running. These are the technological elements that allow us to say the application is decentralized. Another aspect is

perhaps the most important from the perspective of interfering with the service itself. So, if Deridex, as mentioned, could suspend trading or prevent the deposit of collateral, then there was undoubtedly a specific involvement of this entity, a service provided. It wasn't that this service was somehow created or programmed, and Deridex had no involvement in it whatsoever; it only took active steps. Another issue is the lack of control over user funds. Deridex, as we're talking about, exercised control.

Another issue is remuneration. For example, if remuneration were paid by these users, service providers, in a decentralized manner, on the principle that the remuneration would be divided among different wallet addresses, then we could also defend this as a decentralized model. Here we have a specific legal entity—the company that collected this fee. Then we have access, the issue that access requires consent—meaning that we connect, for example, with our wallet and don't need to undergo any verification or consent from that legal entity. So, importantly , the conclusions from the Deridex case actually align with how decentralized

finance was defined a moment ago, right ? Because the definitions we provided at the beginning also mentioned distributed control, a lack of control, and the issue of this service being run in a non-cash-based, non-custodial model, and the issue of access and consent from the entity providing the service not being required. So, we have various aspects, and this also shows us that conducting this decentralization test, as I think we can define it, will certainly not be easy. For example, if it were only a matter of services provided, the situation would be easier . However, there are various aspects we

must always consider when determining whether we are dealing with full or partial decentralization. This also certainly applies to what else we can say about this decentralization test. I don't think that full decentralization necessarily requires a complete lack of any involvement on the part of the legal entity. I think that, for example , in our business models as entrepreneurs, we can try to convince others that if we have no influence on the service, if, for example, we don't

have the ability to change the algorithm after it's launched or stop it, but as the legal entity we collect some remuneration for providing access to this application, I still think we are able to raise issues in discussions with the regulator about the fact that we are not an entity providing a centralized service, that we can be considered an entity providing a fully decentralized service. So we must consider all the gradable elements and, based on this, build our own line of argument as entrepreneurs, for example, in discussions with regulators. And

ladies and gentlemen, in summary, what can we say, returning somewhat to the answer to the question posed in the title of this speech? I think that, of course, Recital 22 of the MIKA Act may prove to be a trap for many entrepreneurs operating in the European Union or providing crypto-asset services here. We will certainly have many entities implementing various solutions—smart contracts, Volta— automated service provision, expecting that this type of business will help them avoid the need to obtain a MIKA license. On the other hand, however, we must remember that this

decentralization must be complete. Bearing in mind that we have various aspects of decentralization, regulators may adopt a more liberal or conservative approach to this topic, this may indeed prove to be a trap. Yes , because with a liberal approach, to the extent possible in light of Recital 22, the regulator may be more inclined to support the position that, for example, services provided in a decentralized manner—that there is no involvement in a specific service, while simultaneously maintaining, for example, the front-end or the collection of remuneration by an entity , a specific legal entity—perhaps we

can exclude the need to obtain a license due to full decentralization. On the other hand, with such a restrictive approach, any involvement here—let's say, legal entities, or equally natural persons—may exclude our application from being considered fully decentralized. I think the regulators 'approach to this will certainly be a very important issue. We will certainly need to closely monitor how, here, ESMA, or regulators in individual EU countries, respond to these types of models, whether in

individual cases, or perhaps by issuing more detailed guidelines. Thank you.