Excited to share a new proof of concept: Joint-Execution Decentralized Exchange (Jedex) is a non-custodial, censorship-resistant token DEX architecture for Bitcoin Cash (BCH):
Jedex demos new techniques made possible by CashTokens, an upgrade proposal for 2023:
I also wrote a TLDR in this Twitter thread:
Feedback and reviews are appreciated! This forum topic is ideal for general questions and discussion. Issues and bugs can be reported on the GitHub issue tracker. Thanks!
This is awesome!!
I asked in a private channel whether this AMM-style DEX usecase depends on reworked limits for smart contracts (a CHIP that might only be implemented in 2024) & will paraphrase the reply here for anyone else wondering the same.
→ Jedex is actually 8 different contracts! CashTokens v2 allow to easily break logic into multiple contracts, so the per-contract VM limits are much less of a problem in general. That means that practically any DEX/decentralized oracle design will be at least possible with only the CashTokens upgrade.
A side-effect of the ‘BigInts’ CHIP is that the JeDex Proof-of-Concept will just work as-is!
No more need for the higher-precision math emulation described in the following section:
Tokens with larger supplies than
2^55may be supported by Jedex in two ways: 1) a more complex market maker implementation emulating higher precision math, or 2) a simple, Higher-Denomination Token Equivalent (HDTE) issued by a trustless covenant – users can e.g. trade 1,000,000 fungible tokens for 1 HDTE token, make trades on a HDTE Jedex, and later trade their HDTE tokens with the trustless covenant to redeem the original token at the 1,000,000-to-1 ratio.
In the recent reddit AMA I asked Jason a question about how the Jedex design would be impacted by the new VM limits, here’s the answer:
You explained the JeDex would be unblocked by a BigInts upgrade, is there any other potential improvements to the contract opened up by the regretted VM limits or is the 8 interacting contracts still the optimal design?
I think 8 interacting contracts is still the optimal design (explanation here)! There may be other specific optimizations other than the massive simplification in the market maker covenant (especially in implementing limit orders, thread splitting, and other features), but I’d need to review it again to be certain.
Of course, lots of development teams will probably choose to simply build less-optimized contract systems to reduce complexity, at least until we have better tooling for taming the “multi-input state machine”. So it’s nice to have both options.