As an ex-LiskHQ (Lightcurve) developer, I was enthusiastic about the potential of Lisk Custom Modules. I saw an opportunity to use Custom Modules and multisignature wallets to build a DEX relatively easily (significantly easier than implementing from scratch).
What it does
LDEX allows users to trade and quickly (within a few minutes) convert tokens between different blockchains chain-to-chain whist creating a complete on-chain historical record of trades. Unlike some popular DEXs such as Uniswap which use an Automated Market Maker (AMM) to determine prices, LDEX has a decentralized order book which (from the user's perspective) looks similar to centralized order books on centralized exchanges.
Each LDEX market is independent and can have a different set of validators. Each trade must be signed by the majority of DEX validators in order to go through. Each validator independently analyzes the blockchain state to determine which trades it will sign. The total number of validators and the number of required signatures can vary on a per-market basis.
How we built it
LDEX was built as a Lisk Custom Module but it can interface with many different kinds of blockchain nodes via adapters. LDEX doesn't have its own database; instead, all the inputs of an LDEX market come directly from blockchains and outputs are written directly to blockchains. LDEX currently supports 3 different blockchain technologies: Lisk v2, Lisk v3 and one we wrote ourselves called LDPoS.
The decentralization aspect is provided by multisignature wallets; each account/member of a multisignature wallet corresponds to one DEX validator. The total number of validators in a DEX market is only limited by the number of members which a multisignature wallet allows.
The Lisk SDK has been integrated into the project throughout multiple components on both the front end and back end.
On the back end:
On the front end LDEX UI application:
Challenges we ran into
The financial side was challenging as we did not raise any external funding. Fortunately, the Lisk community voted me into a delegate position on the Lisk blockchain and this gave me a lot of time to work on LDEX.
Another challenge was finding contributors to build the user-facing UI application. Thankfully, some Lisk community members with the right skill set stepped in at the right time. Later, some community members from my other open source project https://socketcluster.io/ also joined and made significant contributions.
On the technical side, there were also many challenges. Before starting work on LDEX, I had done an analysis to check that the Lisk v2 blockchain provided all the features which would be required. Still, many hurdles came up during implementation. No blockers though.
The recent migration from Lisk v2 to Lisk v3 was also a big challenge. There were many unknowns, as usual.
Accomplishments that we're proud of
I'm satisfied with how LDEX came together in the end. It wasn't 100% certain in the beginning that it would be possible to implement a DEX this way as a Custom Module and that it would be flexible enough to support multiple blockchain technologies. It was rewarding to see our community coming together, taking initiatives and delivering. Especially given our lack of funding.
What we learned
Developing LDEX as a Custom Module turned out to be a great decision. Writing a system which relies on blockchain data as its only input is far better than writing a system whose input is based on real world events. Unlike the real world, the blockchain state is immutable and you can replay history as many times as you like. This is very useful for debugging.
What's next for LDEX
- Improve UX/UI of the LDEX UI front end application https://ldex.trading/trade/
- Add support for more official markets
- Make a simple decentralized 'search engine' to automatically find and rank markets based on trade volume and price history.