Solana Token Extensions and its Legal Implications

This article was co-authored by Martin Azpiroz, Technical Analyst at BCAS, and Bastien Choquez, Legal Analyst at BCAS.

Solana Token Extensions is the latest native program developed by Solana Labs. It consists of a set of special functionalities, which can be added to Solana tokens with only a few lines of code.

As our Introduction to Solana article underscored, the Solana Layer-1 blockchain was conceived to tackle everyday blockchain problems, such as scalability and transaction cost, through a particular and innovative approach. Within this context, tokens on Solana are no exception, as developers must follow a unique process to create them.

This article aims to provide a technical understanding of Solana Labs' latest development of Solana Token Extensions and its legal implications under MiCA. However, before starting with this native program, it is necessary to provide some context on how tokens are created on Solana. Without further delays, let's get started.

How are Tokens Created in Solana?

Solana's unique token creation approach includes fungible and non-fungible tokens (NFTs). Instead of customising an ERC-20 or ERC-721 smart contract (SC) or creating an entirely new SC like in EVM blockchains such as Ethereum, in Solana, developers must interact with a native program known as the Solana Program Library (SPL) to create tokens. Native programs, developed by Solana Labs, are SCs which facilitate core blockchain functionalities, from token and account creation to SOL staking. The SPL contains 25 instructions that provide support for various tasks, such as:

• NFTs and fungible tokens creation.
• Token swapping.
• Token lending.
• Token’s stake pool generation.
• On-chain name services.

Therefore, token developers must send the appropriate instruction via the Command Line Interface (CLI) or a JavaScript file to the SPL to create a token in Solana without relying on third-party applications. As soon as the SPL receives the "create-token" instruction, it will respond with the address of the new token.

spl-token create-token

Figure 1 - Creating an SPL Token. [1]

The next step is to request the SPL to create an account belonging to the address obtained in the previous step using the "create-account" instruction. The newly created account will be used to store the token. Upon sending the "create-account" instruction, the SPL interacts with the System Program, which manages account creation and token transfer, to create the new account.

spl-token create-account <Token Account>

Figure 2 - Creating a token account. [2]

Finally, once the account has been created, the next step is to mint the desired quantity of tokens. This is done by sending the SPL the "mint" instruction, followed by the token address and the number of tokens to be minted.

spl-token mint <Token Account> <Amount>

Figure 3 - Minting an SPL token. [3]

Why are Solana Token Extensions Necessary?

Blockchains are constantly improving and evolving. Every day, new tools, concepts and models are born to expand the boundaries of what blockchains are capable of. However, evolution usually arises from specific needs or deficiencies. In the case of Solana Tokens Extensions, two main motivations prompted its development.

First, the 25 instructions provided by the SPL remained insufficient when developers wanted to add additional features or functionalities to their Solana tokens. As a natural consequence, the SPL program was forked several times, and different on-chain programs that interacted with it were developed to implement such functionalities. Therefore, when developers wanted to implement additional functionalities to their SPL tokens, such as token transaction taxes, they had to create an on-chain program and deploy it on the Solana blockchain. Then, every time their token was transferred, this program was called, and the specific function that collects the tax was executed. This led to the widespread use of unaudited programs involving two types of risk. On the one hand, Solana tokens have been created by leveraging programs that were not designed, tested, and audited by Solana Labs. This point raises the potential for bugs and errors that hackers can exploit. On the other hand, once the functionality of a token is fragmented among different programs, each time a user interacts with this token, each of these programs is called. Although Solana's network was designed to handle multi-program calls, the more complex the interactions become, the more resources and potential risks are involved. Additionally, this design involving multi-program calls can increase transaction costs for network users.

The second motivation for developing Solana Token Extensions was to offer streamlined tools to companies or organisations seeking to develop tokens while maintaining compliance standards. As we shall explore next, many of these new program functionalities are ideally suited to meet such compliance requirements, a design decision aligned with the current regulatory trend in the cryptocurrency sector. In this scenario, Solana Token Extensions were developed to successfully address the demand for standardised and pre-tested tools to create tokens with extended functionalities and to create tokens that remain compliant in an increasingly regulated environment.

What are Solana Tokens Extensions?

Solana Token Extensions consist of various additional capabilities applicable to fungible and non-fungible SPL tokens. In simple terms, an Extension can be seen as an extra feature or functionality that can be added to a token to enhance its use cases and modify its response to certain user or program interactions. Solana token Extensions cover a wide range of functionalities, from confidentiality to required metadata and non-transferable tokens to nominating special delegates with special control over the tokens.

It is worth noting that these Extensions allow token creators to customise the behaviour and characteristics of their tokens natively. Providing tokens with native features increases their security and future compatibility, as a standard such as Token Extensions streamlines the process of understanding how to handle the tokens created by interacting with this program.

Solana Token Extensions can be divided into two groups depending on the SPL instruction they interact with. The first group includes token Extensions relating to the token Mint, consisting of 13 instructions that modify the token's characteristics when minting it. Meanwhile, the second group comprises 5 Extensions, impacting the token account used to store the token.

Now that we have a clear understanding of their purpose and a general idea of the Solana Token Extensions let's examine each Extension and the instructions required to implement it.

Mint-related Tokens Extensions

Confidential Transactions

This first Extension may spark a legal debate. When implemented, it enables the creation of tokens whose transfer amount will not be disclosed while they are being transferred. It is essential to emphasise the differences with privacy tokens, which generally do not allow anyone but the sender and the receiver to know the amount and to which address it is being transferred; in this case, only the amount is confidential.

A possible use case for this Extension could be a token used for payroll. In this example, while the interest in recording the transaction on the Solana blockchain is maintained, it is intended to prevent other people from knowing the amount employees receive. By leveraging this Extension, the payment will be recorded on the blockchain, but only the sender and the receiver will see the number of tokens sent. On the other hand, if necessary, the token creator can present a third party with the amounts of each transaction involving the token. Additionally, each token's receiver or sender can share this transaction information privately with a third party.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-confidential-transfers auto

Figure 4 - Enabling Confidential Transfer on a new SPL token. [4]

The last word of the above instruction is essential as it defines how users can access a token's confidentiality feature. Enabling confidential transactions in a token using the instruction "auto" means anyone can use this token's confidentiality feature permissionlessly. However, if it is replaced by "manual," users would have to be manually approved by the token creator to send this token with confidentiality in the amount. In this case, the amount will not be confidential when sending this token if a user has not been authorised to use the confidentiality function.

Lastly, users must take another step to access this feature by enabling their accounts to support confidential transfers.

spl-token configure-confidential-transfer-account --address <Account_Pubkey>

Figure 5 - Enabling Confidential Transfer on a Solana Account. [5]

Transfer Fees

The Transfer Fees Extension captures a widely used method in the crypto ecosystem to tax users for each transaction they perform with a token. Prior to Token Extensions, token creators looking to implement such a feature would have to develop an additional on-chain program to capture fees on their tokens. By implementing the Transfer Fees Extension, tokens can natively charge a fee on each transaction, which is immediately sent to a predefined account or distributed to a set of them. An example of a case where this Token Extension can be used is treasury funding, whereby a tax is levied on every transaction. Involving the token would be sent to the project’s treasury account.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --transfer-fee <Fee in basis points> <Maximum Fee>

Figure 6 - Setting transfer fees to an SPL token. [6]

Mint Close Authority

As underscored in our Introduction to Solana article, each Solana account occupies memory space provided by Solana validators. Consequently, each account must pay rent or have at least the amount of SOL necessary to cover the cost of rent for two. The Mint-Close Authority Extension allows token creators to close the account they use to mint their tokens and reclaim their SOL deposit for rent. Before Token Extensions, this was not possible for SPL token creators; however, by leveraging the Mint Close Authority Extension, the account used to create a token can be closed, and the SOLs deposited into it can be retrieved.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-close

Figure 7 - Enabling the Mint Close Authority Extension. [7]

Non-Transferable Tokens

Several blockchains have already issued non-transferable tokens to cover such use cases. By taking advantage of this Extension, users can add the "non-transferable" feature to their fungible and non-fungible tokens with a single line of code, simplifying the process and enhancing their security.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-non-transferable

Figure 8 - Implementing the Non-Transferable Tokens Extension. [8]

Let's see an example of this extension's usefulness. NFTs are an excellent tool for extending personal certificates or representing on-chain ownership of an asset. However, by default, NFTs are transferable assets, and there may be a need for an NFT that cannot be sent to another person, such as those that contain information about a course diploma or, perhaps, a university degree. By applying this extension, these certificates or diplomas, issued as NFTs, can be sent directly to the wallet of their grantee, from where they cannot be transferred.

Interest Bearing Tokens

The Interest Extension allows the establishment of an interest rate on a token natively. Before the advent of the Token Extension, developers had to create a proxy contract that involved periodic rebasing or updates to establish an interest payment to an SPL token. Additionally, this Extension easily shows the cumulative percentage, as the interest is compounded based on the Solana blockchain’s timestamp. Suitable cases for these Extensions are on-chain bonds and staked or debt tokens that require interest to be continuously accrued.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --interest-rate <Interest Rate in Basis Point>

Figure 9 - Setting an interest to an SPL token.

spl-token set-interest-rate <Token Address> <New Interest Rate in Basis Point>

Figure 10 - Modifying an SPL token interest rate. [9]

Transfer Hook

The Transfer Hook Extension enables the straightforward creation of tokens that automatically call specific programs or part of their logic each time they are transferred. In simple terms, it offers creators more control over how their tokens are transferred and the consequences of these transactions. Whilst the possibilities of this Extension are endless, applying royalties to NFT sales is an illustrative example. Token creators can set up a program that is called each time an NFT from a collection is sold. Using this program, a percentage of each sale can be paid to the creator of the NFT collection.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --transfer-hook <Program Address>

Figure 11 - Setting a transfer hook. [10]

Permanent Delegate

Implementing the Permanent Delegate Extension allows an account to be established as a Mint delegate. Being a Mint delegate means the designated account can burn or transfer any amount of those tokens.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-permanent-delegate

Figure 12 - Setting a permanent delegate. [11]

While this Extension may sound controversial, some examples already operating in this industry can benefit from implementing these functionalities natively and avoid the engineering cost and risk of crafting them manually. Stablecoins such as USDC or USDT, which rely on freezing powers, would benefit from this Extension by implementing it through a line of code. In this example, once an account is linked to activities that do not meet the compliance standards of these stablecoins, the Permanent Delegate can use his powers to transfer these tokens to a different account. This way, these tokens can be confiscated and retrieved instead of being just “frozen”, a function already provided by the SPL, in the compromised account.

Metadata

Working closely with the Metadata Pointer, this Extension allows token creators to incorporate the token's Metadata directly into the Mint account. Additionally, it enables natively embedding token Metadata with custom fields, which was impossible with SPL. Information such as its name, symbol, description and image constitute key metadata parameters. Correctly defining these parameters is extremely important, as they can be displayed by other on-chain programs, such as wallets or decentralised exchanges, to facilitate the user experience when interacting with SPL tokens.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-metadata

Figure 13 - Enabling Metadata.

spl-token update-metadata <Token Address> name <Token Name>

Figure 14 - Modifying a token’s Metadata. [12]

Metadata Pointer

Through the Metadata Pointer Extension, token creators can designate an address that provides the token's Metadata. With the potential proliferation of multiple Metadata programs, this is important because a mint may have several different accounts claiming to describe the token, which in this context means providing its information. When many addresses claim to provide the Metadata for an SPL token, it can be confusing for a user to understand what the correct Metadata is and can be misleading. The Metadata Pointer allows token creators to establish which account defines the Metadata, and users can easily verify it. This information is stored on-chain, which also improves security. Thanks to this Extension, users will be able to check which is the correct address describing the token Mint, as both addresses will point to each other.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --metadata-address <Metadata Address>

Figure 15 - Setting a Metadata Pointer. [13]

Group

The Group Token Extension makes grouping tokens possible. Working in conjunction with the Group Pointer, the Group Extension facilitates the organisation of tokens under one account, describing things like the update authority and maximum group size. This Extension is helpful for NFT collections, where tokens can be “grouped” into one account that describes all of them. When creating an NFT collection, all the NFTs can be "grouped” under one account that will provide information related to the whole collection, such as the collection's name, the number of NFTs that comprise it and a description of the collection. This data can be displayed by on-chain programs such as wallets or NFTs marketplaces to facilitate the user's experience.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-group

Figure 16 - Creating a mint group setting. [14]

Group Pointer

The Group Pointer Extension allows token creators to designate a group account that describes the Mint. However, in this case, unlike the Metadata Pointer, the group account is focused on token grouping configurations. Once a token Mint has a Group Pointer, it is considered a group Mint. As mentioned above, an illustrative example of a group Mint is a collection of NFTs. In simple terms, group mints have settings that enable them to serve as a reference point for a related set of tokens. Thanks to this extension, users and on-chain programs can verify that the tokens belong to a group and which account describes the grouped tokens.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --group-address <Group Address>

Figure 17 - Creating a mint with a group pointer to an external account. [15]

Member

The last Mint-related Extension is the Member one. This Extension, which represents a key part of how token groups are managed, allows token creators to provide information about the members of a group. A member's settings, which describe the group address and member number, can be stored directly in the Mint account itself. This Extension works closely with the Member Pointer one. By leveraging this Extension, each token belonging to a group can have its own description and an identifying number. Once again, on-chain programs can display this information to facilitate user experience.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-member

Figure 18 - Enabling a member. [16]

Member Pointer

Similar to the last "pointer" Extensions, the Member Pointer is used by token creators to designate a member account that describes the Mint. This pointer describes settings for a token membership within a group, like a particular NFT that belongs to a collection. Thanks to this extension, users and on-chain programs can verify which account individually describes a token that belongs to a group of them.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --member-address <Member Address>

Figure 19 - Creating a member pointer. [17]

Account-Related Extensions

Following the analysis of the Extensions related to the instructions for minting tokens in Solana’s blockchain, let's delve into the Extensions that enhance the functionalities of the accounts storing SPL tokens.

Memo Required

The Memo Required Extension allows the creation of tokens that will automatically require a memo attached before being transferred each time they are transferred. Memos represent brief on-chain messages, which enable users to add information in the form of a message to their transactions. Furthermore, the token creator can deactivate the requirement to attach a memo before sending transfer instructions. Beyond simply sending a message from the sender to the recipient, this feature is ideally suited for regulatory compliance, reporting and auditing, as banking systems traditionally require a note with transfers.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token

spl-token enable-required-transfer-memos <Token Address>

Figure 20 - Setting a required memo.

spl-token disable-required-transfer-memos <Token Address>

Figure 21 - Disabling a required memo. [18]

Immutable Owner

The Immutable Owner Extension prevents the token owner's account from being changed. The purpose of this Extension is to improve security, as assigning a new owner can be helpful and necessary at times, but it can also create some vulnerabilities, such as account misappropriations. Most on-chain programs assume that the associated account for a token is its owner without checking whether that owner is valid, so programs could be tricked into using the wrong account, potentially stealing tokens from someone. To prevent these scenarios, once a token is created using the Token Extensions Program, the Immutable Owner Extension is automatically enabled and cannot be disabled.

spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token

Figure 22 – Once a new SPL token is created using the Token Extensions Program, the Immutable Owner is automatically enabled. [19]

Additionally, it is important to underscore those tokens created by interacting with the SPL before the release of Token Extensions can implement the Immutable Owner Extension to avoid the aforementioned situations.

CPI Guard

Token creators can implement the CPI Guard Extension to restrict how other programs can interact with the token. Specifically, actions inside the Cross-Program Invocation (CPI), which allows programs deployed in Solana to interact with each other, can be prohibited or configured to request user authorisation. This Extension aims to protect users from implicitly signing actions they cannot see, particularly those hidden in programs other than the System or the Token programs.

An illustrative example can help us understand its utility. When a user signs a transaction to send a token, a program can create an opaque program instruction and perform a CPI transfer without requiring further user authorisation. Implementing the CPI Guard Extension can configure those CPI calls to require the user's approval before execution.

spl-token enable-cpi-guard <Token Account>

Figure 23 - Enabling the CPI Guard. [20]

Reallocate

The Reallocate Extension follows the principle that some Extensions, such as the Memo Requiring or the CPI Guard Extensions, can be enabled after the token's account creation. Therefore, this Extension allows owners to reallocate their token accounts to create space for adding more Extensions. For example, this Extension is required when a token creator wants to activate the Memo Requiring Extension, but the token account has no more space to store this Extension. In that case, the CLI will automatically apply the “Reallocate” instruction to reallocate the token account and allow adding the Memo Requiring Extension.

Default Account State

Enabling the Default Account State Extension will give token creators additional control over their tokens' distribution and use. Once implemented, all token accounts that receive this token will be frozen by default. Practically speaking, this means that users will not be able to transfer, exchange or use the functions of this token once they receive it. To allow its unrestricted use, the token creator must grant permission for it.

One use case where this Extension can be helpful is requiring users to complete a KYC process before using a token. Once users meet the abovementioned requirements, the token creator can unfreeze their account and use it freely.

$ spl-token --program-id TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb create-token --enable-freeze --default-account-state frozen

Figure 24 - Setting a Default Account State. [21]

Extensions and their Compatibility

Although Solana Extensions can be combined when creating a new token or the account that will store it, there are two types of incompatibilities. On the one hand, as a matter of logic, there is no sense in combining the following Extensions:

• Non-transferable + Transfer Hooks/Transfer Fees/Confidential Transfer.
• Confidential transfer + Transfer Hooks, as the first one has restrictions related to who can see the source/destination, and Transfer Hooks would not be allowed to act based on the amount.

Secondly, in the current iteration of Solana Token Extensions, the following combination cannot be implemented:

• Confidential Transfer + Transfer Fees.

However, this is a temporary incompatibility, as these Extensions will become compatible once version 1.18 is available.

Legal Analysis

As highlighted, the Solana Token Extensions aim to provide additional features to developers, companies and organisations willing to maintain compliance standards when developing and issuing crypto-assets. Consequently, it is important to understand how crypto-asset issuances are defined and regulated under the Markets in Crypto-assets Regulation (MiCA) to assess which legal implications the features introduced with Solana Token Extensions may trigger.

What are the rules on crypto-asset issuance under MiCA?

Article 1 of MiCA, related to the Regulation’s subject matter, sums up comprehensively the EU legislators’ approach towards crypto-asset issuances. Its paragraph 2(a) mentions that MiCA lays down transparency and disclosure requirements for the issuance, offer to the public and admission of crypto-assets to trading. The following point goes beyond this general terminology of crypto-assets and adds specific requirements for the authorisation and supervision of issuers of Asset-Referenced Tokens (ARTs) and E-Money Tokens (EMTs), following the token classification elaborated under MiCA. Therefore, while a Chapter was dedicated to issuers’ obligations under both Titles related to ARTs and EMTs, no specific requirements have been drawn regarding the obligations of issuers of other crypto-assets.

This difference in treatment can be observed in many instances. For example, Article 23 introduces restrictions on the issuance of ARTs used widely as a means of exchange based on the estimated quarterly average number and average aggregate value of daily transactions. Regarding EMTs, the primary consideration probably resides in Article 49, which establishes additional requirements for the issuance and redeemability of EMTs to incorporate some of the dispositions applicable to electronic money under Directive 2009/110/EC (EMD II). A topic that we extensively covered in another recent article.

The question then is to define whether the requirements mentioned under Article 1 apply to any issuance of crypto-assets that fall under the scope of MiCA. Indeed, Article 2 of MiCA, which defines the Regulation’s scope, confirms that it applies to natural and legal persons, as well as certain other undertakings engaged in the issuance, offer to the public, and admission to trading of crypto-assets. However, the definition of ‘issuers’ under Article 3 is relatively brief: an issuer is “a natural or legal person, or other undertaking, who issues crypto-assets”.

Recital 20 brings more precision and claims that issuers of crypto-assets are entities that have control over the creation of crypto-assets. Moreover, Recital 22 mentions that the Regulation covers the rights and obligations of crypto-asset issuers and extends Recital 20's logic by stating that “Where crypto-assets have no identifiable issuer, they should not fall within the scope of Title II, III or IV of this Regulation”. Therefore, it appears that the control of a natural or legal person or other undertaking over the creation of tokens qualifies this person or undertaking as an identifiable issuer.

This point is particularly important when defining if an entity is subject to MiCA’s requirements on token issuances. The total absence of control over the creation of tokens could enable the issuer to subvert the application of MiCA. This is notably the case when the minting process is handled through the execution of a smart contract that runs outside of any interference or control from any entity, including its owner, if any.

An example and confirmation of this principle can be found in Article 4(3)(b), which excludes crypto-assets automatically created as a reward for the maintenance of a blockchain or the validation of transactions from the scope of the whole Title II applicable to those crypto-assets that do not qualify as an EMT or ART. Since these crypto-assets are automatically created, their issuer does not exercise any control over their creation and is therefore exempted from the requirements of Title II of MiCA.

Finally, because crypto-asset issuances and offers to the public are intrinsically close, it is important to note that issuers and offerors share most requirements. Due to this proximity, issuers and offerors are often the same person. Article 3 defines ‘offeror’ as “a natural or legal person, or other undertaking, or the issuer, who offers crypto-assets to the public”. This point is further emphasised under Articles 16 and 48, which make it mandatory for both offerors of ARTs and EMTs to be the issuer of the asset they intend to offer.

Therefore, to understand the whole spectrum of MiCA’s dispositions on crypto-assets issuances, it is necessary to study the crypto-asset’s legal qualification and technical features, as well as the issuer's other activities. Without further details, let’s dive deeper into the legal challenges brought by Solana Labs’s latest release.

What are the legal implications of Solana Token Extensions?

Token extensions have different legal implications depending on the features they offer. However, some extensions have been excluded from the analysis below, considering they do not carry specific implications—this applies notably to the Transfer Hook, Immutable Owner, CPI Guard, and Reallocate extensions.

Confidential Transactions

As denoted, this first token Extension is triggering multiple legal challenges. From MiCA’s perspective, the Regulation does not explicitly prohibit crypto-assets with such privacy features regarding the transaction amount. The only instance where the Regulation refers to privacy features is under Article 76(3), related to the operation of a trading platform as a crypto-asset service. The article states that “The operating rules of the trading platform for crypto-assets shall prevent the admission to trading of crypto-assets that have an inbuilt anonymisation function unless the holders of those crypto-assets and their transaction history can be identified by the crypto-asset service providers operating a trading platform for crypto-assets”.

Firstly, it must be noted that this article only applies to the operation of a trading platform, which means that other crypto-asset services do not suffer any restriction regarding the so-called privacy coins. Secondly, as this service is being provided by crypto-asset service providers (CASPs), it does not apply to other persons, such as issuers, offerors or persons seeking admission to trading. Finally, this restriction is not absolute but can be overcome when the CASP operating the trading platform can identify the asset’s holders and their transaction history.

Considering that the Confidential Transactions Extension does not introduce privacy features regarding the holder's identity or transaction history but exclusively on the transaction amount, one may argue that crypto-assets developed with this Extension would not fall under the scope of Article 76(3). Moreover, the possibility of sharing the transaction amount with authorised third parties or limiting confidentiality to specific accounts also allows token creators to subvert this restriction. However, MiCA also introduces different reporting obligations on CASP, National Competent Authorities (NCAs) and certain European authorities such as the European Securities and Markets Agency (ESMA) and the European Banking Authority (EBA). These reporting requirements notably concern the use of ARTs and EMTs and their classification as significant ARTs or EMTs.

For example, to consider an ART significant under Article 43 of MiCA or an EMT significant under Article 56, EBA shall notably establish the average aggregate value of transactions per day in such asset. While issuers should be able to collect and provide such information, EU and national regulators' ability to verify this information on a crypto-asset using the Confidential Transactions feature is questionable. The same issue arises regarding ARTs used widely as a means of exchange, where regulators may restrict further issuances to prevent undesirable effects on the EU’s monetary policy.

Furthermore, this extension brings further legal challenges to regulatory frameworks other than MiCA. In addition to tax laws, which differ depending on the Member State, the proposal for a Sixth Anti-Money Laundering Directive (AMLD6), which would replace the existing Directive 2015/849/EU (AMLD5), and the Transfer of Funds Regulation (2023/1113/EU) (TFR) introduce specific AML/CFT and KYC requirements for transactions with a value equal to or superior to 1,000€. Entities such as CASPs providing transfer services must notably, in this scenario, take adequate measures to assess the ownership or control of self-hosted addresses, as illustrated in one of our recent articles.

Consequently, the offering or availability within the EU of tokens using the Confidential Transactions Extension might be limited since CASPs providing services in relation to such tokens could not be able to fulfil their regulatory obligations under EU laws.

Transfer Fees

In the same way as the Confidential Transactions Extension, the concept inherent to the Transfer Fees Extension is not expressively prohibited under MiCA. However, an important disposition resides in Article 4(3), stating that “a crypto-asset shall not be considered to be offered for free […] where the offeror of a crypto-asset receives from prospective holders of that crypto-asset any fees”. Thus, Article 3(13) defines ‘offeror’ as “a natural or legal person, or other undertaking, or the issuer, who offers crypto-assets to the public”. In contrast, an ‘offer to the public’ is defined under Article 3(12) as “a communication to persons in any form, and by any means, presenting sufficient information on the terms of the offer and the crypto-assets to be offered to enable prospective holders to decide whether to purchase those crypto-assets”.

Consequently, using the Transfer Fees Extension may lead to considering that the crypto-asset is not offered for free, in which case the dispositions of Title II remain applicable unless the crypto-asset classifies as an ART or EMT. Except in this scenario, retail holders would benefit from a right of withdrawal against the offeror under Article 13, forcing the offeror to refund the Transfer Fees charged to the holder, if any. Moreover, Articles 39 and 49 prevent issuers from charging fees for the redemption of ARTs and EMTs, respectively. In that case, issuers would be obliged to refund the fee charged due to the Transfer Fee Extension.

Mint Close Authority

At first glance, the Mint Close Authority seems to be a purely technical Extension, allowing crypto-asset creators to close the account used to mint their crypto-asset due to the memory space they occupy and the fee they must pay as rent. However, this action may lead to important consequences when assessing the crypto-assets modality of issuance.

As mentioned in the description of MiCA’s dispositions on crypto-assets issuances, in the absence of an identifiable issuer, the substance of Recital 22 would exclude the issued crypto-assets from MiCA’s scope regardless of its qualification. However, it is interesting to note that in this scenario, the absence of control over crypto-assets creation cannot be the criterion defining whether the issuer is identifiable or not on its own. Indeed, from a technical point of view, a person or entity is exercising control over the creation of crypto-assets. However, closing the account responsible for minting the crypto-assets may make identifying this person or entity impossible.

Several observations must be made to understand MiCA’s approach on this point better. First, it is essential to remember that the exemption mentioned in Recital 22 has not been fully transposed into the Regulation’s articles. Except for the exception made under Article 4(3)(b) for crypto-assets that are automatically created as a reward for the maintenance of a distributed ledger technology or the validation of transactions, no other articles expressively exclude from the scope of the Regulation those crypto-assets with no identifiable issuer.

Secondly, if the requirement to obtain an authorisation under the Titles related to ARTs and EMTs applies only to offerors and persons seeking admission to trading, their application must contain information on the issuer, such as the issuer’s address, legal entity, and articles of association. This requirement is incompatible with the absence of an identified issuer. Therefore, enforcing these obligations requires the ability to identify the issuer.

Therefore, it is safe to say that NCAs and EU regulators will not restrict themselves from demonstrating control over crypto-asset creation to consider the issuer identifiable. Other criteria, such as the diffusion of marketing communications or the management of a website, could allow those authorities to consider the issuer identifiable and enforce MiCA’s dispositions. In this hypothesis, the legal implications behind the Mint Close Authority Extension appear to be minors.

Non-Transferable Tokens

This Extension allows crypto-asset creators to prevent the transfer of their crypto-assets. As outlined, this feature makes sense for tokenising university diplomas or professional certifications, among other things.

Recital 17 introduces a clear guideline: "Digital assets that cannot be transferred to other holders do not fall within the definition of crypto-assets”. The rest of the Recital also refers to loyalty schemes as an example of such crypto-assets. Moreover, this Recital is reflected within the definition of a crypto-asset under MiCA’s Article 3, which expressively refers to the ability to transfer such a crypto-asset. Therefore, it is safe to assume that if a crypto-asset presents features that make it technically impossible to transfer the asset, it would be excluded from the scope of MiCA.

Interest Bearing Tokens

The Interest-Bearing Tokens Extension offers an unchallenged solution to developing Decentralised Finance (DeFi). By implementing this feature, Solana Token Extensions provide developers with a highly valuable tool for their project but also carries many legal implications. Indeed, Article 40 and Article 50 prohibit the granting of interest concerning ARTs and EMTs, respectively, amplifying the difference in the regime between these crypto-assets and others.

The Regulation prevents interest from being granted on these crypto-assets, both from the issuer and for the CASPs providing services related to these crypto-assets. Moreover, the Regulation precises that any remuneration or other benefit related to the length of time during which a holder holds the crypto-assets shall be treated as interest, including net compensation or discounts received from third parties. This addition extends considerably the scope of the prohibition. It is also important to note that such crypto-assets offering interest or compensation may be susceptible to qualify as financial instruments and, therefore, to be excluded from MiCA’s scope under Article 2.

Moreover, the prohibition applies to the granting of interest, not to the issuance of ARTs and EMTs with interest bearing. Consequently, issuers are still allowed to issue such crypto-assets but cannot grant interest to holders in the European market. Also, the prohibition applies to issuers and CASPs, but the Regulation does not mention anything towards offerors and persons seeking admission to trading. Thus, those activities remain compliant with MiCA even if they concern ARTs or EMTs granting interest to their holders.

Nevertheless, the prohibition's scope is still considerable, and applying the Interest-Bearing Token Extension associated with a crypto-asset referencing the value of another asset would trigger important legal implications under MiCA.

Permanent Delegate

This Extension is particularly suitable for using EMTs and ARTs. EMTs and ARTs can be used as a means of exchange and reach important thresholds in terms of volume transacted. Therefore, these types of crypto-assets are subject to specific requirements under MiCA, and some requirements related to AML/CFT under other legal frameworks find a particular resonance towards them. Notably, Article 94(3)(f) of MiCA entrusts to NCAs the power to request the freezing or sequestration of assets. However, this technical ability to freeze or sequester assets differs from burning crypto-assets, which involves the technical destruction of the concerned crypto-assets.

On the other hand, the Permanent Delegate Extension allows the account designated as a Mint delegate to transfer crypto-assets, which is also helpful for law enforcement. However, a question may arise whether this technical feature can constitute a transfer of crypto-assets in light of the definition given to this service under Article 3(26) of MiCA. According to this article, this service consists of “providing services of transfer, on behalf of a natural or legal person, of crypto-assets from one distributed ledger address or account to another”.

The Permanent Delegate Extension undoubtedly allows crypto-assets creators to transfer crypto-assets held in one account to another, such as the one designated as a Mint delegate. However, in circumstances involving law enforcement, the transfer is not processed on behalf of clients but rather unknowingly to them. One may argue that the definition of transfer services does not expressively state that the transfer must intervene on behalf of the client but on behalf of a natural or legal person, which legal person can be the NCA requesting the transfer of the crypto-assets.

If this interpretation seems strict, it is not to be excluded, and crypto-assets creator implementing this Extension while minting their crypto-assets must properly assess the risk to qualify as a CASP and to be required to comply with further requirements.

Metadata Pointer and Metadata

One of the main requirements under MiCA for issuers, offerors, and persons seeking admission to trading is the obligation to act honestly, fairly, and professionally in the best interest of their crypto-asset holders. This obliges them to provide a wide range of clear and not misleading information through their crypto-asset white papers and marketing communications.

The Metadata Pointer and Metadata Extensions cannot cover the tenor of such an obligation alone due to the amount of information that must be communicated in the above documents. However, these features allow issuers, offerors and persons seeking admission to trading to ensure these documents are accessible to holders and prospective holders. It also allows for the communication of additional information and facilitates the updating of information contained in the white paper.

Group Pointer and Group, Member Pointer and Member

These four token Extensions share the same use cases, specifically regarding NFT collections. As the Metadata Pointer and Metadata Extensions, they constitute a useful tool for token creators to disclose publicly information about their tokens, which disclosure is sometimes a requirement under MiCA. Therefore, those Extensions also demonstrate the issuer's willingness to comply with the Regulation and facilitate this mission.

Memo Required Extension

As mentioned, this Extension is particularly suitable for regulatory compliance. Indeed, EU regulatory frameworks applicable to crypto-assets and their transfer require further diligence in identifying the source of funds, processing user verification, and establishing transaction volume. However, complying with these legal requirements becomes increasingly complicated as holders can transfer their crypto-assets between custodians and self-hosted wallets, bridge them between blockchains, or interact with various protocols.

Therefore, using the Memo Required Extension allows token creators to develop a crypto-asset which cannot be transferred without communicating information related to the token holder’s wallet, the beneficiary or recipient of the transfer, asset ownership, etc. The disclosure of such information prior to processing the transfer would enable CASPs and other entities providing services in relation to these crypto-assets to fulfil their legal obligations, increasing the chance for the asset to be listed on centralised exchanges and be widely adopted.

Default Account State

Following the same approach as the Memo Required Extension, the Default Account Stake allows persons providing services related to this crypto-asset to meet their regulatory requirements, notably under AMLD6 and TFR. In practice, this feature offers an extra layer of security since holders must be granted permission before being able to transfer their crypto-assets. Therefore, KYC procedures and due diligence can be completed before granting access to the relevant account, and the crypto-assets it holds can remain frozen if the user presents a specific risk level.

Conclusion

Throughout this article, our primary purpose has been to present this set of new SPL token functionalities that Solana Labs offers to its developers and the legal consequences they entail.

From a technical point of view, the real value of Solana Token Extensions is that these particular functionalities can be implemented in each new token natively, with a few lines of code and by leveraging pre-tested tools that certainly facilitate development in blockchain environments.

Moreover, the fact that they were developed by the same team involved in creating the Solana blockchain is an extra reassurance. Thanks to this fact, the compatibility of SPL tokens implementing Token Extensions with different industry solutions will be far more accessible compared to a scenario in which each new token implements its custom modifications.

From a legal point of view, these new Token Extensions can help crypto-assets creators meet the different requirements they are subject to under several legal frameworks, most notably MiCA. However, they sometimes create complex legal situations, requiring issuers to develop a deep understanding of legal mechanisms or to seek legal assistance. In a less important proportion, some of the features offered by Solana Labs through this variety of new Extensions directly conflict with regulatory dispositions. They could prevent issuers of tokens carrying those features from complying with specific requirements.

---

[1] “Solana Documentation - SPL Tokens” https://spl.solana.com/token

[2] “Solana Documentation - SPL Tokens” https://spl.solana.com/token

[3] “Solana Documentation - SPL Tokens” https://spl.solana.com/token

[4] “Solana Documentation – Confidential Token - QuickStart” https://spl.solana.com/confidential-token/quickstart

[5] “Solana Documentation – Confidential Token - QuickStart” https://spl.solana.com/confidential-token/quickstart

[6] “Solana Documentation - Tokens 2022 - Extensions - Transfer Fees” https://spl.solana.com/token-2022/Extensions#transfer-fees

[7] “Solana Documentation - Tokens 2022 - Extensions - Mint Close Authority” https://spl.solana.com/token-2022/Extensions#mint-close-authority

[8] “Solana Documentation - Tokens 2022 - Extensions - Non-Transferable Tokens” https://spl.solana.com/token-2022/Extensions#non-transferable-tokens

[9] “Solana Documentation - Tokens 2022 - Extensions - Interest-Bearing Tokens” https://spl.solana.com/token-2022/Extensions#interest-bearing-tokens

[10] “Solana Documentation - Tokens 2022 - Extensions - Transfer Hook” https://spl.solana.com/token-2022/Extensions#transfer-hook

[11] “Solana Documentation - Tokens 2022 - Extensions - Permanent Delegate” https://spl.solana.com/token-2022/Extensions#permanent-delegate

[12] “Solana Documentation - Tokens 2022 - Extensions - Metadata” https://spl.solana.com/token-2022/Extensions#metadata

[13] “Solana Documentation - Tokens 2022 - Extensions - Metadata Pointer” https://spl.solana.com/token-2022/Extensions#metadata-pointer

[14] “Solana Documentation - Tokens 2022 - Extensions - Group” https://spl.solana.com/token-2022/Extensions#group

[15] “Solana Documentation - Tokens 2022 - Extensions - Group Pointer” https://spl.solana.com/token-2022/Extensions#group-pointer

[16] “Solana Documentation - Tokens 2022 - Extensions - Member” https://spl.solana.com/token-2022/Extensions#member

[17] “Solana Documentation - Tokens 2022 - Extensions - Member Pointer” https://spl.solana.com/token-2022/Extensions#member-pointer

[18] “Solana Documentation - Tokens 2022 - Extensions - Required Memo” https://spl.solana.com/token-2022/Extensions#required-memo-on-transfer

[19] “Solana Documentation - Tokens 2022 - Extensions - Immutable Owner” https://spl.solana.com/token-2022/Extensions#immutable-owner

[20] “Solana Documentation - Tokens 2022 - Extensions - CPI Guard” https://spl.solana.com/token-2022/Extensions#cpi-guard

[21] “Solana Documentation - Tokens 2022 - Extensions - Default Account State” https://spl.solana.com/token-2022/Extensions#default-account-state