I just started to play around a bit with MultiDEX and there are several features I’d like to see added.
So let’s start a wish list, here’s mine:
Private OTC trades (multichain).
Let me create a trade only the intended counter party can see and execute. Big blocks move without touching the public book, no market impact, no slippage games. Ship this and onchain becomes the venue for block trades.
Cross-chain DEX aggregation.
Don’t stop at your own books, pull in DEX liquidity from all supported chains and route me to the best price. Swaprunner already have onchain aggregation that works for ICP dex’s.
CEX liquidity via solvers. Go full NEAR Intents alternative: solvers fill orders from CEX books and settle onchain. We get CEX depth, zero KYC. Technically all possible today.
Trailing stop-loss.
Regular stops are static , a trailing stop follows the price up. Set it at, say, 5% below market: price climbs, the stop climbs with it; price drops 5% from the peak, it triggers. Lets you ride a trend and lock in profit without babysitting the chart or manually moving your stop.
Cool suggestions! I like the first one and the last one. The middle two are interesting:
I was thinking about this sort of thing a while ago for how an onchain dex might work to aggregate liquidity across numerous other dexes. I kept coming back to the idea that it seems like undesirable incidental complexity to couple a dex to numerous other dexes (not dependent on any one, but stilling featuring an integration complexity cost that hampers maintainability and reasonability in terms of the source code, which is important for avoiding bugs).
I kept coming back to the idea that in an efficient market there should be no exploitable price disparity between exchanges. So rather than pay the cost of complexity in an aggregation dex with the assumption of an inefficient market, maybe it’s better to implement separate arbitrage bots (maybe that anyone can easily deploy) that keep the market efficient and route profits either directly towards users or towards the preferred dex, driving down trading fees and rewarding liquidity providers.
This would be great for giving the appearance of deeper liquidity on a dex that sort of acts as a facade infront of other dexes, but in practice is seems like it could be brittle if it’s not able to execute lightning fast (which isn’t a strength of on-chain solutions if you’re comparing it to off-chain). Maybe a similar approach to above would work better, where liquidity is gradually extracted from other dexes by bots.
Arb bots fix prices, not depth. Every venue quotes the same price, cool, but if I’m selling $10M someone still has to eat it, and arb bots don’t carry that inventory.
The point of aggregation is one order tapping every pool at once, not exploiting inefficiency.
Bots re-syncing prices after my trade nukes a pool doesn’t help me. Fair point on coupling though, maybe aggregation belongs in a separate router layer (like Swaprunner) so the core DEX stays simple.
On solvers being slow: the fast part isn’t onchain. Solvers quote and hedge offchain, only settlement lands onchain, that’s exactly why NEAR Intents works. The user never sits in the hot path, the solver eats the latency risk. The real question is whether enough solvers show up and quote tight for a mid-cap asset. Bootstrapping problem, not a tech one.
What if the $10M trade automatically tries to match an OTC-like buyer, and gives a very short period of time for bots to commit to filling that order? Then the bots are the ones that reach into the liquidity of other dexes? There’s risk involved there because the whole thing wouldn’t be atomic, but there could be a confidence level in terms of multiple possible sources before the bot is confident it can fill the order and commit to it (a bit like how there’s risk in borrowing protocols, but it’s mitigated by things like dynamic LTV ratios etc.). I guess the dex would need to trust the bot’s ability to fulfil the order though.
Maybe it should work the other way around. The dex (and user) could commit to selling at a certain price… actually the more I’m thinking and writing the more I’m thinking this just looks like an order book exchange (and some bots taking advantage of sell/buyer commitments).
I’m sure something like this could address both price inefficiencies as well as liquidity depth - It’s just not quite clear in my mind how to keep the dex simple and keep everything decoupled. I’m sure someone smart in DFINITY and/or AI (with a rigorous test suite) can find the right approach though.
I definitely agree that there are ways to improve prices and depth that involve utilising other dexes.
One funded account per player keeps the competition fair, so you must use an Internet Identity linked to Google. Your current identity isn’t linked, but you can:
Sign in using Google
If you use the button above, Internet Identity will create a new identity that uses Google as an access method.
Signing in later, use the same door: your play account lives on the identity Google unlocks. If you signed in above, you can choose “Sign in using Google” again.
Alternatively, go to ID.ai and add Google as an access method to an existing identity.
Privacy: we keep only a salted fingerprint of your email — the address itself is never stored and never touches the public exchange ledger.
I don’t like the google part, fair or not there should be other ways to get some play tokens.
Couldn’t agree more. id.ai authentication should be enough.
Funny thing: this exact design is intents (NEAR, UniswapX). Order goes out, solvers race to fill it, and the trust problem you flagged is solved with bonds: commit and fail, get slashed.
Your order book instinct is right too, it’s just RFQ: quotes on demand, no resting orders, DEX stays dumb.
Prompt: Does it have a trade follower feature? Where skillful traders can gain follower copy-traders?
Output: No — MULTI/DEX doesn’t have a copy-trading or trade-follower feature. It offers a public leaderboard (ranked by profit vs. a HODL baseline) so you can see top performers, but there’s no mechanism to automatically mirror or follow another trader’s positions.
Since multidex.ai already has unified liquidity (one AMM vault + shared order books) and a public canister API. What’s missing is an incentive for others to build on top of it.
Add an optional referrer/interface ID to swap and order calls. A portion of the trading fees would automatically go to the interface based on the trading volume it routes through multidex, while LPs continue earning liquidity fees.
Instead of every DEX fragmenting liquidity into separate pools, everyone could build different experiences on top of one deep liquidity layer. I’d especially love to see ICPSwap plug into it.
Sometimes balance is not refreshed, some might panic and think they lost funds.
Sometimes order is pending too long.
Available balance does not count tokens that are in orderbook, so if i have 1k ICP, i can add more than 1k sell orders. Should show as total balance and available to trade.
Close order button lags, makes me want to press it twice as it feels like didnt work on first time.
Margin trading dont show liquidation price before opening position. Cross means all usd balance as colladeral? It does need different wallet, otherwise a disaster.
Dex is interesting idea, but first it has to work perfectly, only than add new stuff. If adding stuff when bad experiense, people will run away. I dont think we can add pools there ourselves, but i hope we can.
Meta aggregators seem to have various risks. This is especially true for cross-chain transactions where they become asynchronous. Are you familiar with the Kyberswap incident? I think it could potentially lead to such an accident.
