The problem with using a centralised exchange is that you are sending your assets to the exchange and the exchange, at that point, is in full control of your assets and your fate. That is not only limited to the assets that you’ve sent to them, but also to how their matching engine works. Once they have your keys, an unscrupulous exchange is able to front-run your trades and perform all kinds of shenanigans to make profit.

It’s not just the risk of an exchange completely locking up your funds and stopping withdrawals as the result of a liquidity crunch, you also have to consider whether they’re going to operate the platform fairly and reasonably, and more importantly, be able to prove to you that they are doing so. Without proof, you’re blindly trusting that the entity that you’ve just sent all your money to is playing fair.

In theory, you can protect yourself against some of this by using a decentralised exchange. This means you never give up your keys, and you trade assets by interacting through a smart contract, as opposed to a centralised matching engine. It’s the way Uniswap , Sushiswap, and decentralised derivatives exchanges like DyDx and GMX all essentially work.

However, just because it’s decentralised doesn’t mean it’s absolutely trustworthy and nothing can go wrong; you need to be sure of not only what it’s running, but what it’s running on. There are two things to consider;

Firstly; transactions need to be authorised by your keys and your wallet. Even on a decentralised exchange, your funds should be held in your wallet, and you should be approving transactions yourself. Or the funds should be pulled in and out of your wallet on the chain in question. This brings up all kinds of speed issues, but that’s for another discussion and it’s engineering that the industry needs to figure out.

Secondly; you have to have trust in what you’re executing. People (users as opposed to engineers) tend to trust what’s being executed in smart contracts pretty blindly. And they tend to trust what these smart contracts are running on blindly as well. Unless you know that what is running the smart contracts is uncompromised and is behaving as you would expect it to behave, you still have a problem.

Ethereum tries to solve that problem by running the contract multiple times which is arguably super wasteful. Instead, you could rely in part on the hardware. You’d need trusted execution at server-side, both Intel and ARM have solutions for this which you can use. On mobile, it’s a bit more difficult, neither of the platform owners provide this kind of access by default. Samsung could arguably provide access to the secure element and may do for some customers, and Solana mobile seem like they might be open to giving this kind of access once they’re live.

Today it’s hard to think of any cryptocurrency where you can actually be sure that the nodes in question are running the code that they say they are. That’s because nobody’s doing trusted execution, everybody is essentially assuming that because the outputs are the same, the code that’s running is the same. Yet all it takes is the exchange owner prioritising their own traffic in the exchange to make a big difference. The order of transactions matters, both in terms of front running proposed trades and in final execution order.

There are ways you could abuse even a decentralised exchange. Decentralising everything is great, but where systems are running needs to be instrumented too. How do you know what’s running these things? How do you know that somebody hasn’t taken the open source code and modified it, and it is now running a slightly different version. What if a decentralised exchange isn’t running the smart contract that it says it’s running and instead it’s running something similar which has the same overt outputs.

If you’re on Ethereum you can essentially at least look. You know which address is running and you can look at the source code. But you still don’t know, especially considering the amounts of money involved, whether they are running that on a standard Ethereum node, or whether it’s one, which gives them lots of tasty debugging information that they can front run on these incredibly slow distributed exchanges.

We need to know that all the entities we transact with are who they say they are. And given the experiences of 2022, we also need to be able to know that the entities in question — from the companies to the servers running the service — are what they say they are.

Solving this issue has been a key challenge for Self . We believe that provable transparency (so not accidentally moving crypto around to prop up shaky balance sheets during audit week type transparency) is far stronger than regulation because it is not placing restrictions on what a market can legitimately do, either deliberate, or geographical. Properly run, transparent exchanges shouldn’t need regulating, it’s a sign of crippling failure if the market can only be controlled through regulation appropriate to the markets Crypto was conceived to escape from. 

 Creating transparency is far easier with decentralised systems, because they’re inherently transparent, but the same basic approach works if you’re trying to make centralised exchanges safer. You have to go through the execution engine, and identify where you’d be able to place a finger on the scales if you were a bad actor and remove the ability to do that by either making it transparent, or by making it fully automated and transparent.

‍

A system like Self deployed into either decentralised exchanges or, with a bit more work, centralised exchanges can provide the proofs and the protection necessary to make exchanges really secure. Combating determined internal fraud and wanton disregard for the controls any business should have in place is hard, but where it concerns customer funds, transparency strengthened by Self will go a long way to preventing the kind of disaster we have seen in recent weeks.

‍

‍

SBF photo: Doc. Coincu

‍