CashTokens DEX design

Technical
,
#1

Here is an overview of the current DEX designs for CashTokens on Bitcoin Cash:

Overview Table

Name Status Type Curve # contracts contract code MEV solution Links
Cauldron Live Closed Pools CPMM 1 contract (raw) BCH script None Link
Fex cash Live Public Pools CPMM 7 contracts CashScript None Link
Jedex Demo Public Pools CPMM 8 contracts Libauth template Joint-Execution Link

Takeaways

With the 3 existing DEX designs we already have a nice cross-sections of the design-space and contract tooling options.

Both FexCash & Jedex use a modular NFT desgin, whereas a cauldron contract is just a single utxo.
The Cauldron design takes advantage of the UTXO design to allow many micro pools to be combined in a single transaction. While this fractures liquidity over many UTXOs, it has the special advantage of simplifying the contract design by a lot.

How DEXes best handle MEV is still an actively debated topic with potential tradeoffs of the ‘joint-execution’ being discussed.

VM Limits & BigInts

The current Fex.Cash code has ‘Customized Multiplication and Division’ to work around overflow issues. This complexity could be removed if/when the BigInts CHIP activates on Bitcoin Cash. It would also allow for the Cauldron DEX to work with very large token supplies, where it would currently just fail on overflow.

One area where we haven’t seen experimentation is on the choice of the AMM curve, likely because this is prohibitive with the current VM & integer Limits. A lack of certain math opcodes might also play a major role in this.

2 Likes
#2

Please explain what is the difference between “Closed Pools” vs “Public Pools”.

1 Like
#3

Actually I did write the cauldron contract with libauth template.
https://github.com/hosseinzoda/cashlab/blob/main/src/cauldron/cauldron-libauth-template.json

1 Like
#4

On the topic of open vs closed.

I noticed a incentive problem we have today.

The best user interface and thus experience you can have with a dex is when it is part of the wallet that people use anyway. This means that you’ll have to see a screen added to said wallet to make this happen. Which costs time and money in development and maintainance.
The alternative is to ship your own wallet, which is what various parties are trying to do today. While that may increase the UX over a plain website version, it actually makes the cost of development much heigher. So unless you’re already shipping a wallet, this sounds like a bad idea.

Last there is the idea to have a separatation of wallet development and dex-app-developement and have some sort of bridge that is trustless. This has been contemplated for years and still doesn’t actually work. From a first-principles concept this can’t work due to the conflict of there being 1 app shipped by two parties and when money is lost, who to blame?

The incentive problem then is still not mentioned, I’ll get to it soon!
When the community finally comes to the conclusion that the way to go is a ‘module’ for a specific dex in common wallets, we start to see the problem. There still needs to be some development to actually build this. Probably one per wallet, which should be easy enough (I did the send&sweep module in less than a week in my wallet). But, yeah, someone needs to do the work.
The incentive problem: the wallet dev could do the work, but if the marketplace is centralized and the match-making is a server operated by the DEX developers, the investment of work is high risk. The wallet module may be cut off for whatever reason. Making their investment worse than worthless. The wallet devs can’t earn any money from the module, as far as I can see either.
The reverse is similar an issue, the dex devs can build a module but depend on the wallet devs to review and ship the code in their actuall wallet app.

So, the real question with regard to DEXs to me incentives and specifically how the match-making platforms are going to look like.
Are match-making platforms going to be closed, which is great for UX, or are they going to be open which makes the wallet dev much more expensive.

#5

With ‘public pool’ I mean a pool where anyone can provide liquidity to. To have this functionality you need some kind of NFT receipts which prove how much you added to the pool. Cauldron has a micro pool design which is ‘closed’ in that it doesn’t allow other people to add to a large existing pool.

Cool, thanks for sharing! But for the contract code I meant the tooling how the contract was originally written/created. The Cauldron Whitepaper just has the raw BCH script and I was told that they did development this way also :+1:

#6

I’m not sure how you define “closed match-making”. All these protocols have “open” match-making (although I know too little about Jedex to know for sure) – it’s just that any wallet that would do a swap would have to contact an indexer somewhere to get the relevant UTXO. Just because no one hasn’t implemented that doesn’t make the protocol anymore “closed” than if there was public endpoints to get the spendable UTXOs available somewhere.

1 Like
#7

That was what the long post was about. The short short version is: is there a permissioned site/server/platform?
As written this specifically applies to matchmaking. Finding offers, placing offers.

#8

Short answer: No.
The examples above are AMM contracts. The “offers” are UTXOs that anyone can spend.