After the Autonomous Agents are released on livenet, we’ll have a lot of tokens. Stablecoins, shares in prediction markets, synthetic assets, portfolio tokens, many others, and certainly something that we can’t even imagine today. We’ll need an easy way to trade them and ensure that access to trading is as open as possible. This is what a decentralized exchange (DEX) would provide.

We have already started developing a DEX and currently it is alpha-quality. A DEX would be such an important piece of infrastructure that we have to delay the release of AAs on livenet before the DEX is ready (we originally estimated that AAs will be tested on testnet for 2–4 months but now it looks like 2+4 months will be closer to the truth).

Autonomous Agents is an excellent tool for developing decentralized applications and while the DEX will enable trading of mostly AA-issued tokens, the DEX itself will also be AA-based.

However, the AA, which will be the engine of the DEX, is very small, it is only about 300 lines of code. The vast majority of the work is creating a UI and server backend that allow to easily access its functions in a user friendly way.

To reduce the amount of work to be done, we did what we already did in 2015 when we were preparing to launch Obyte (then Byteball) network and needed a user friendly wallet to enable access to the network. Back then, we forked a Bitcoin wallet that was in my opinion the most user friendly wallet at the time — Copay wallet — and significantly reworked it to adapt to the Obyte architecture while trying not to break the UI part too much.

The new Obyte DEX will include much of the UI and backend code from AMP Exchange. The team of ProofSuite, which developed the exchange, did a really good job in making it very user friendly and professionally looking. It is also one of the few existing DEXes which is fully open-source.

You can visit the website of AMP Exchange to get an idea of what the new DEX (which will be called ODEX) will look like, or see a screenshot of its alpha version below.

The architecture

We want the new exchange to be as fast as centralized exchanges to attract professional traders and market makers, including automated ones, and have good liquidity.

Unfortunately, the traditional approach of most DEXes to have the order books on-chain would make it too slow and expensive:

one would have to wait for transaction confirmation to place an order. While waiting, the market conditions might change;

placing an order would require fees even if the order is not eventually filled;

trying to fill an existing order is not guaranteed to succeed because another trader might be slightly faster to fill it, but the fees are paid anyway;

one would have to wait again, and pay fees, to cancel an order. And while waiting, the order can still be filled at unfavorable conditions.

Under such conditions, professional traders would simply refuse to play this game and there would be no liquidity.

Off-chain order books

ODEX will have off-chain order books instead. Instead of sending their orders directly to an exchange AA, users will sign them and send to so called matchers.

Matchers are network nodes that are responsible for storing and matching orders and sending them to the exchange AA for execution. That is, when they see a buy and sell order for the same (or overlapping) price, they will send both orders to an AA and the AA will execute the orders and make the respective changes in the user balances they hold in the AA. Users will be able to deposit funds to the AA and withdraw them at any time, like they do with traditional centralized exchanges (except that there is no risk of theft because the money can be moved only according to the rules coded in the AA).

When a user wants to cancel an order, he will send the corresponding command to the matcher that stores his order and the matcher will immediately remove the order from its database.

What’s good about this design, all orders, trades, and cancels can be immediately reflected on the website of the exchange, therefore it will work as fast as a centralized exchange. The matcher will queue all trades and submit them to the AA, and they will be executed successfully with high certainty because only the matcher is allowed to send matching orders to the AA for execution.

However, a matcher becomes a centralized element of the design. Although the AA won’t allow it to steal any funds or match the orders whose prices don’t match (such as a buy order for price 10 and a sell order for price 11) or modify the orders (they are signed with user’s keys), the matcher can still match orders in unfair order (normally, when there are two orders on the same side and for the same price, the one that came earlier is executed first) or he can choose to ignore the cancels.

Shared liquidity

To alleviate this risk, and to enable liquidity sharing among multiple DEXes, we’ll have several matchers. Anyone can become a matcher and compete against other matchers. Every matcher will run his own instance of ODEX (or only its backend) and they will be able to exchange the orders among themselves. Plus anybody, even non-matcher, can join this network and see all the orders. If anything fishy happens, everyone will be able to see that and the misbehaving matcher risks losing customers. For example, if a properly signed cancel request appears in this network and after a considerable time, which is larger than normal network delays, the cancelled order is matched, we have strong evidence against the misbehaving matcher.

To prevent two matchers from trying to execute the same order at the same time, every order is tied to a single matcher. To avoid fragmentation of the market, every DEX in the network can display orders from other matchers together with the DEX’s own. When an order from a foreign matcher is taken by a user, the match will be routed to the matcher tied to that specific order to be executed.

There is an incentive for exchanges to display foreign orders even though the matching fees for those are collected by someone else.

First: Users are more likely to create orders on a DEX with high liquidity. As matching and execution of orders are always routed to the origin of the maker (pending) orders, the exchange benefits from pending orders created by its users.

Second: It makes a DEX more attractive initially as it wouldn’t have any orders at all before users started trading (who would trade on an exchange without any orders?).

Third: The operator of a DEX may choose to charge an additional affiliate fee on orders submitted through his website to foreign matchers. This fee would be on top of the matcher fee charged by the matcher from where the corresponding maker order originated. Each exchange can define both of these fees individually and, like in any business, maximizing profits while staying competitive will be a delicate balance.

This multi-centered design makes ODEX family of exchanges more decentralized than some existing DEXes with centralized order matching such as IDEX. Each individual ODEX may choose different token listing and user onboarding rules to adapt to the various legal requirements that exist in their jurisdictions.