Neon Exchange (NEX) is a decentralized platform on the NEO blockchain that applies a publicly verifiable off-chain matching engine to handle trading volume and support complex orders (such as limit orders) that are not possible on existing DEXs. The exchange aims to trade: Crypto to Crypto, Crypto to Fiat as well as Security Tokens.

There are several regulators that can allow an institution to sell Securities. NEX is applying for an OTF in Liechtenstein, to sell security tokens within the EU. They will, therefore, fall under the Mifid 1 & laws. 

In this article we will dive deep into the laws required for trading Securities within the EU, we are ONLY evaluating NEX ability to sell STOs within the EU. We are NOT evaluating NEX ability to develop a high-quality DEX.

What is MiFID II and how will it affect EU’s financial industry? 

The Markets in Financial Instruments Directive 2004/39/EC (known as “MiFID”) as subsequently amended is a European Union law that provides harmonised regulation for investment services across the 31 member states of the European Economic Area (the 28 EU member states plus Iceland, Norway, and Liechtenstein). The EU’s ambitious regulatory reforms, known as MiFID II, aim to transform Europe’s financial industry.

Strong Concerns Regarding Decentralized Security Token Exchanges 

Decentralized exchanges will have troubles with MiFID II/MiFIR regulation

Decentralized exchanges (DEX) are creating quite a lot of buzz recently. In this post, I will share some information about what regulations trading venues must comply to and why a trading system based on a decentralized exchange will hardly ever comply with MiFID II/MiFIR.

The most problematic issue in DEX is that there is the possibility of frontrunning the trades. While we have seen quite sophisticated ways of front running orders on centralized systems in the traditional systems where huge penalties were given to those who were doing it, decentralized exchanges are not entirely immune to the practice of front running. Once a trade is broadcast to the blockchain, it awaits verification from miners who decide which transactions to include in the following block. Since the frequency of incoming transactions often outweighs the capacity of the subsequent block, transactions not mined immediately sit in a pending transaction pool, also known as a mempool.

However, the transparent nature of a blockchain mempools enables front runners to enter their trades first, profiting on the resulting price movements when prior orders are finally executed. By setting a higher gas price and making it attractive for miners to prioritize their transaction, these malicious actors can ensure that their trade executes before the transaction they are attempting to front-run. Furthermore, miners can participate in front running themselves by choosing to execute their own trades ahead of time.

Relayer-based DEX might solve some of the issues, but the technology is still being developed and was not yet fully tested. Solutions include encrypting the trade data and decrypting it after the block confirmation from miners.

Deep Dive into Technological Problems with NEX and Regulators

Nex aims to implement a decentralized exchange which is essentially an off-chain order matching + on-chain settlement is not a new concept, though admittedly, to our best of knowledge, these exchanges were limited to Ethereum blockchain. An example of such an exchange would be IDEX. Users need to deposit ETH and ETH-based tokens to a smart contract. IDEX utilizes a relatively fast (for a DEX) matching engine for trading. These trades are then cleared via the smart contract (on-chain). Consequently, settlement takes anywhere from 5-20 seconds under normal conditions. Within these 5-20 seconds, the funds are “in transit” and cannot be used by either party. When ETH blockchain is under heavy load, it can happen that all operations requiring interaction with smart contract (deposits, withdrawals, settlement) are stuck due to previous transactions not being cleared (a consequence of sending txs from a single SC). Admittedly rarely, this can render all operations except order matching with already deposited funds temporarily inaccessible.

Interacting with several smart contracts on different blockchains (as proposed in their WP) just amplifies this problem. The solution which they propose (“smart vault”, where traders can elect whether to keep trade amount within the matching engine as opposed to their wallets) is untested and first of its kind, and thus susceptible to double-spending errors.

Consequently, it is in our opinion, that such structure cannot be MiFID II compliant, as the double-spending possibility is a real danger. If Neon decides to forego “smart valut” and goes only for on-chain settlement, the trading experience will greatly suffer and/or required capital will be far greater for high-frequency traders and market makers due to 1-block lag (5-20 sec on ETH blockchain) for settlement compared to any prefunded exchange.

Balances and settlement of direct FIAT pairs are another problem not addressed in the white paper, especially for PvD (payment vs. delivery) issue with institutional clients. They can either find a clearing house (highly unlikely as CCPs are not yet ready to take over the clearing risk for crypto assets) or develop some novel way of guaranteeing the settlement without prefunded accounts (financial institutions do not prefund their trading accounts with exchanges).


Asset custody

As with all decentralized exchanges, users need to deposit assets to a respective smart contract before they start trading. This situation is not preferred from a regulatory standpoint, as it is unclear who, if anyone, owns these assets from the moment they are deposited to the SC. Upcoming Liechtenstein legislation ( recognizes an official status of crypto custodians (TT Protector – A person who holds tokens on TT Systems in their own name on account for a third party. TT Protectors are required to be licensed according to the Trustee Act or the Banking Act). In our opinion, Neon will still be responsible for these assets as a custodian, regardless if they are deposited on a smart contract or in a central wallet.

This adds additional regulatory obligations, which, importantly, cannot be avoided given the DEX business model – no one else can take the custodian role even if regulated custodians for security tokens emerge, as long as a smart contract is in the middle of the trading process.


Regulatory prospects

Given that fact, it is unclear whether it will seek any license under MiFID II, or it will register under the upcoming Liechtenstein Blockchain Law. Even assuming that they apply for a MiFID II license, it is in our opinion more likely that they will seek an OTF, as evident from their roadmap. If they opt for OTF license which enables them to target retail clients directly without an intermediary broker, they will be limited to listing non-equity instruments which would make their whole business model of listing security tokens obsolete (the vast majority of security tokens being issued now are equity or equity-like instruments). Given our knowledge from talking with the regulator, they have not yet approached FMA with the plan to acquire the OTF license. 


Additional Comments

Massive unverified OTC trading of Neon Exchange white-listed addresses. Pooled Neon SAFTs for half million dollars were often seen and pooled out without AML or KYC. 




If you would like to learn more or join the conversation please follow us on Twitter or join our Telegram and Discord. For more high-quality reviews for Security tokens and upcoming ICOs please subscribe to our newsletter. 


Requirements form MiFID 2 / MiFIR with links


RTS 1 on transparency requirements for trading venues and investment firms in respect of shares, depositary receipts, exchange-traded funds, certificates and other similar financial instruments

RTS 2 on transparency requirements for trading venues and investment firms in respect of bonds, structured finance products, emission allowances and derivatives


RTS 1 and RTS 2 set standards for pre- and post-trade transparency obligations for both trading venues and investment firms.


RTS 6 specifying the organisational requirements of investment firms engaged in algorithmic trading


RTS 6 are quite a game changer for algo-traders since they must comply with the standards set in it, especially on the resilience of trading systems and Direct Electronic Access obligations.


RTS 7 specifying organisational requirements of trading venues


RTS 7 is one of the most important standards for trading venues since it sets forth the organizational requirements of trading venues, which include governance, appropriate staffing, and detailed standards for capacity and resilience of the company and its IT systems. Decentralized exchanges might have many problems with the whole Chapter II of RTS 7 especially Article 11, Article 18 and Article 20.


RTS 8 specifying the requirements on the money making arrangements and schemes


RTS 8 sets standards for arrangements between market makers and trading venues


RTS 9 on the ratio of unexecuted orders to transactions


RTS 9 sets standards for trading venues where they must monitor the ratio of cancelled orders compared to matched orders for all trading participants


RTS 10 requirements to ensure fair and non-discriminatory co-location services and fee structures


RTS 11 on the tick size regime for shares, depositary receipts and, exchange traded funds


RTS 11 sets the standard for determining tick size based on the liquidity and the price of the asset which is something DEX might have technical problems with


RTS 15 on clearing access in respect of trading venues and central counterparties


RTS 15 is an interesting one as it deals with clearing members of trading venues, which is something regulated financial institutions are used to as CCPs take over the risk, while decentralized exchanges are set up in a way that CCPs cannot be directly involved


RTS 17 on the admission of financial instruments to trading on regulated markets


RTS 17 defines the standards for listing requirements


RTS 22 on the reporting of transactions to competent authorities


RTS 22 sets standards on how to report transactions to the national regulator and ESMA


RTS 25 on the level of accuracy of business clocks


RTS 25 sets standards on how time should be synchronized across servers (both on trading venue and members of the venue). This is problematic when using on-chain orderbook and matching on decentralized exchanges


RTS 27 on the data to be provided by execution venues on the quality of execution of transactions


RTS 28 on the annual publication by investment firms of information on the identity of execution venues and on the quality of execution


Some of the Implementing Technical Standards, available at the website of European Commission.