There is no such thing as a “closed-source decentralised exchange”

Let’s say I run an exchange whereby I provide you with my wallet address to which you send your funds and order information to, then I do some processing on my machine before eventually sending you back your requested assets - would you call that a “decentralised exchange”? The answer should be no, because there is nothing decentralised about handing over your funds to a single entity and trusting them whilst not knowing how their system works.

(Note that here “trust” does not just refer to trusting they aren’t malicious, but also trusting that they aren’t incompetent or reckless and that the security of their systems is to a high standard.)

Now consider how the experience you have when using SundaeSwap differs from that which I just described. You send your funds to an address and wait for them to process it, without knowing any of the technical details of what that entails, before they eventually send your requested assets back. Due to the closed-source nature of SundaeSwap and the lack of technical documentation describing their systems when you use SundaeSwap you may as well be sending your funds to a wallet owned by them instead of a validator script (or ‘smart contract’). You can’t look at the contract first and see how it works and to know with certainty what will happen when you send your funds to it.

You might say that it differs because you can cancel your SundaeSwap order, but cancellations are not automatic and have to be processed by SundaeSwap and the contract code so this would be no different than asking the owner of the wallet to return your funds, at which point it is up to their discretion whether they choose to or not.

Of course, SundaeSwap does make use of validator scripts to run its exchange because just using a wallet with an off-chain backend would be centralised as customers would be required to put their complete trust in SundaeSwap, their private systems and their ability to protect customer funds. By using a validator script, customers funds can only be used in specific ways as defined by the code contained in the script which ensures that nothing unexpected can happen to those funds.

Sounds great! Well, the problem is that because SundaeSwap is closed source we don’t know what the code contained in the validator script is, which means we don’t know what the rules for spending customers funds the script enforces. Something isn’t adding up here… we’re using a validator script so we don’t have to trust SundaeSwap, but then because we can’t see what the validator script does we have to trust that the rules specified in them are what customers are expecting - meaning we have to trust SundaeSwap.

I’ll repeat that: SundaeSwap uses a validator script instead of a wallet with an off-chain backend because that means customers don’t have to trust SundaeSwap. But we can’t know what rules the validator script enforces so we actually do have to trust SundaeSwap.

If the reason for using a validator script was to remove the need to trust SundaeSwap but in the end we are forced to trust them anyway then what is the point in using one? Instead, using a wallet and off-chain backend would mean the exchange could handle orders much faster, there would be no need for Scoopers, there would be less fees and as an end user you have the exact same guarantees that you do currently when using SundaeSwap (none). Seriously. Try to think of how the experience right now would be any different if you sent your order to a wallet controlled by SundaeSwap instead of a closed-source validator script created by SundaeSwap, besides the first 4 bits of the address you send your funds to.

So, if the customer’s experience and the information available to them when using SundaeSwap’s validator script is isomorphic to the experience of just sending funds to a wallet controlled by SundaeSwap and having them process your order off-chain before returning your assets, and we know sending funds to a wallet controlled by a single entity is centralised then it follows that SundaeSwap is not a “decentralised” exchange; it’s a centralised exchange built on a decentralised protocol. They created the rules for the smart contracts and they are the only people who know what those rules are, they have all the information on how the protocol works while everyone else has only the most basic high-level information.

There’s nothing wrong with SundaeSwap being a centralised exchange, I just can’t see how it could be described as decentralised. If they plan on open-sourcing the validator code, which they say they do, then they are a centralised exchange until that point - and in this ecosystem we’ve seen something similar before: IOG openly discussed how the Cardano protocol itself was moving from being centralised towards becoming fully decentralised as it slowly reduced the decentralisation parameter d. That’s fair, it can be a future goal to build towards.

One SundaeSwap team member said they didn’t want to release the code because they didn’t want to enable low-effort knockoffs which could harm users, and I’m sure that is one reason for not open-sourcing the code. I would think that, because the only code which needs to be released is the validator script code and potentially the scooper software/algorithm, that the work required to implement a frontend and have a network of scoopers would block most ‘low-effort’ knockoffs. I understand; no one wants to spend an immense amount of time, money and effort on something only to have someone use it for themselves but that is the space you have chosen to build in should you wish to be a decentralised exchange. If you are not going to open-source the code then at a bare minimum you at least need to provide comprehensive technical documentation describing how the protocol works, which alone will not enable low-effort knockoffs.

I’m sorry but the information describing the protocol (on a technical level) is not good enough. The exhaustive list of documentation available:

This is just frustrating. I want to read about how this service works so I can perform due diligence and make an informed decision about whether or not I want to use it. I invite you to try find more information - please let me know if I missed something.

In fact, the Scooper blog post states that “third-party aggregators have an out-sized amount of power, even when adhering to the rules of the automated market maker script” but that “if you can somehow establish a limited amount of trust in the aggregators, many of the challenges disappear”. They state that to establish this required amount of trust the first step is to have the community choose which parties can act as an aggregator, followed by allowing the community to run a reference implementation of the order selection algorithm to observe if any aggregators are diverging from the expected behaviour and acting maliciously, and if so “governance” can decide via a vote to remove the aggregators license. Sounds good, besides the fact there is no information available regarding the order selection algorithm, how to vote to remove an aggregator’s license or how licenses work in general. So I guess we can’t establish trust in the aggregators yet, and so they have an out-sized amount of power even when adhering to the rules of the automated market maker script, until we have this information. Until that point guess Scoopers are free to behave as they please unless SundaeSwap is actively monitoring them or community members create their own monitoring tools by reversing the algorithm or protocol.

You might say that the trust is not solely placed in SundaeSwap because they engaged reputable firm Runtime Verification to perform an audit, so the trust is then split between those two parties. This fact alone is not worth much because RV’s report has not been made public, only the fact that it concluded. In fact, because we don’t have some kind of script-hash which relates RV’s audit to the contract(s) SundaeSwap is currently using on-chain this is almost useless information. Note how RV includes commit IDs in their reports to show what code was in the scope of the audit. If RV said “We audited the validator code which, with the addition of our recommended changes outlined in the audit, is being used at the script address addr1…” then we could have more confidence, otherwise we have no idea that the contracts being used today were the ones audited by RV or fixed all the bugs pointed out by RV. …

After writing this I realised that last week RV had eventually published the SundaeSwap audit document (with no announcement yet (?) from RV or SundaeSwap). It’s an interesting read and does in-fact link the audit to the specific addresses being used currently on-chain, which is great. It looks like Runtime Verification did a thorough job, deeming 9 of the total 20 bugs reported as being critical, and this report gives us a tiny glimpse into how some parts of SS works. Having bugs found in an audit is not a bad thing, especially an audit conducted prior to release and for one of the first projects of its kind - it means you made the right decision in paying to engage the security firm.

… Do I think SundaeSwap is malicious? No. Do I think they are incompetent? No. Do I think mistakes, coding bugs and logic bugs happen? Yes! And that’s ok, especially since this is one of the first projects of its kind. A month ago RV published a report about a vulnerability it failed to find in one of their previous audits of a protocol on Algorand which eventually led to $3 million in tokens being stolen. These things happen. Someone even managed to cheese SundaeSwap before it even launched by sending buy-orders before swaps were supposed to go live, allowing them to get in at a cheaper price than the customers that immediately followed. Hiding the code does not protect you (“security through obscurity”), having audits as well as a bug bounty to entice security researchers to find and report bugs for rewards is the industry standard.

There is a reason all the DeFi projects on Ethereum are almost always open-source. Paraphrasing from https://ethereum.org/en/defi/: “DeFi is an open financial system [..] - an alternative to a system that’s opaque and tightly controlled”, “Services […] are automatic and safer now that they are handled by code that anyone can inspect and scrutinise”. Neither of these are true if the project is closed-source. We have all this technology to provide a trust-less environment and yet, after all the years of work to get to this point with the blockchain technology, we just send our transaction to a blackbox and trust a single entity: whoever coded the closed-source validator script we are interacting with. The whole point of a smart contract is that we can be certain that due to the blockchain technology and the cryptography that the rules specified within the smart contract will be enforced, so what’s the point in using one if we don’t what those rules are?

People are sending a combined total of tens (or hundreds) of millions of dollars worth of funds to a contract of which no one but SundaeSwap and maybe Runtime Verification know the contents of. This isn’t regulated like a bank, it’s regulated by code. If we let closed-source become the norm for exchanges on Cardano the ecosystem will likely suffer for it.

10th feb 22