CashTokens AMM DEX designs

Technical
,
#1

Here is an overview of the current Automated Market Maker (AMM) 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 AMM 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.

3 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.

1 Like
#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.

2 Likes
#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.

#9

That’s the spending. The taking you up on the offer.
But here is what I actually asked:

Unless everyone is running their own full node, I have problems figuring out how an SPV mobile wallet will find all the offers and lists all the tokens that are on offer right now.

Cauldron is providing that exact service today, would you be able to write a little plugin into a mobile client that can show the orderbook and the offers and all that without a site/server/platform?

#10

You’d need an indexer, something that parses all transactions on the blockchain and matches redeem scripts to Cauldron contracts. A SPV wallet can query such an indexer to get addresses for those UTXOs and verify independently that it’s valid. Permissionless and doable if anyone wants to spend time developing it.

Note that, at least in the case of Cauldron, a pool has to be “touched” by someone once to be known, otherwise it’s just a P2SH address.

#11

Tapswap is a decentralized exchange.

From a seller perspective, its nice to have a means to sell something at a fixed price, without becoming a constant product market maker indefinitely. Constant product markets are not ideal if the goal is to sell all of something. In addition, the current fee structures on some of the secondary exchanges limit certain use cases, even jedex with suggested base fee of 10k sats seems high.

An open ask market similar to tapswap, but with partial fulfillment might be nice, such as the following:

Open Ask Market with Partial Fulfillment

The design of this market would allow for high-volume with low-fees, priced narrowly at a particular price, with a high clearance rate.

This could be done with just two types contracts:

A market contract.

A market contract takes the category ID of the fungible token being sold as a constructor parameter. The market contract holds no tokens, it merely holds a list of sellers’ asks.

A seller publishes an ask by minting an arbitrary NFT containing their pkh and the fixed-exchange rate they’re willing to accept for a particular token as an immutable commitment.

  • A pathway allowing the seller to burn or withdraw their listing (via their signature) should be available.
  • Or perhaps to a pathway to spend the “seller’s ask NFT” as an input to a transaction clearing off the seller’s vault.

A sellers’ vault.

The seller may then calculate their vault, which is determined using their public key, exchange rate and the category ID for the fungible token.

The seller funds the vault by sending a UTXO with the fungible token to the vault.

There are two spending pathways:

  • Anyone may take FTs from the vault, provided the the seller is paid in the same transaction in BCH at the fixed rate.
  • Alternatively, the seller may also withdraw their tokens from their vault at any time.

Vault threads could be aggregated with the “buyer” getting a single

Benefits

  • It’d be easy for a buyer to lookup the order book for a particular token (1 query), it’d be likewise easy to see which vaults were funded from the best price onward (1 query per vault).
  • Without the need for an specialized indexer or hosting, there’d be little need for intermediaries or commissions.
  • The seller would get a tapswap-like white glove experience, where they don’t have to interact further with the exchange post-listing, if their tokens sell, the funds can be sent to their address in the same transaction.
  • Unlike with tapswap, a seller wishing to sell a lot of fungible tokens could leave them in a single UTXO that could be partially spent by many parties, or taken in a lump sum by a single party.

Ultimately, a p2p DEX might not need a third party or market maker as an intermediary. It should be possible for someone to mint 100 BCH worth of tokens on a primary market for a few hundred sats then offer those tokens for sale on a secondary market without spending 0.3-3 BCH in fees to an exchange.

2 Likes
#12

This is the last step and I think we’re on the same page now.

A place to announce your new contract can be “decentralized” in the way that a smart indexer finds them on-chain and there are various places that allow you to freely download that.
Or, you can have a permissioned site that adds value by having an API that shows the open contracts. Allowing people to announce them on that platform. Allowing innovation because you’re not limited to exact copies of hardcoded scripts / p2sh addresses.
Notice that ‘permissioned’ means that they can exclude a wallet or a user from using their services. Maybe because they want to ask for a fee.

The permissioned way is going to give a much better UX, for a lot of reasons. Mostly because a dedicated server will always be better and faster at trading than a mobile client on a generic indexer.

And that’s when we get back to my point in reply 4 on this thread. The incentive problem that needs to be solved in order to actually move the ecosystem forward.

1 Like
#13

Right, thanks! I’ll edit the post to clarify the topic and comparison table is about Automated Market Maker DEXes (AMMs). :+1:

Decentralized order book

Indeed p2p token market-places definitely also have their use use-cases, and 'partial fulfillment ’ is definitely a missing feature for both buyers and sellers with the current Tapswap contract. With partial fulfillment implemented you could make something resembling a decentralized order book with bids & asks for a specific token.

Order books vs AMMs

However one big drawback of the orderbooks design is that blockchains are slow-to-update. BCH with a 10-minute blocktime would not be suitable to quickly updating bids and asks whereas AMM DEXes have this price updating built-in without having to modify orders. Further, AMMs never have a wide spreads.

Might be worth to make a separate topic to discuss the tradeoffs of AMMs vs orderbook designs for BCH DEXes! :grinning_face_with_smiling_eyes:

2 Likes