Moving MULTI/DEX to Canic

Developers
1

Note : we cannot support Motoko canisters as of today but it’ll be a 3-4 day job to get it working. @dominicwilliams

Yes—MULTI/DEX looks like a strong candidate for Canic’s Motoko support, particularly for archive lifecycle, funding and deployment recovery. It already contains a substantial amount of infrastructure that Canic could take responsibility for.

I inspected its backend, archive implementation, funding logic and deployment documentation, alongside Canic’s current documentation. This is an architectural assessment, not a full security audit. MULTI/DEX was at commit 1fff1d7.

Where the fit is strongest

MULTI/DEX has a main exchange canister, a custody bridge stub, an arbitrage simulator, a frontend and a growing archive chain. Much of the infrastructure management lives inside the exchange backend itself. Architecture

Area MULTI/DEX today What Canic could contribute
Archive provisioning Backend creates, installs, tracks and cleans up archive canisters Root-owned allocation and lifecycle recovery, with explicit limits and recorded identities
Cycle funding Separate archive, bridge and arb funding tasks; treasury-to-cycles conversion; external top-up script A common funding hierarchy with reserves, spending bounds and recovery status
Deployment A substantial shell workflow deploying and wiring individual canisters Desired Fleet configuration, qualified artifacts and resumable reconciliation
Operational inventory Application maintains archive identities and operational status Shared infrastructure inventory, while the exchange retains its event-routing index
Authentication II sessions, direct caller checks and application registration gates Optional delegated application identities and consistent infrastructure-role authentication
Expansion Archive chain growth; exchange execution concentrated in one backend Placement and provisioning for additional components once application partitioning is designed

The main benefit is removing infrastructure responsibilities from the exchange’s financial implementation, reducing the amount of custom machinery its maintainers must understand and qualify.

1. Archives are the best first integration

The backend currently implements spawnArchive, _pendingSpawn, orphan reconciliation, archive funding, sealing and archive upgrades.

It has already addressed a lost-continuation problem by splitting creation from installation and retaining the principal before the installation await. So this is not a case of Canic introducing recovery where none exists: it would replace a bespoke lifecycle implementation with a maintained common one. Implementation

The ownership split I would use is:

  • MULTI/DEX: decides when another archive is needed; owns event sequences, hashes, shipping acknowledgements, sealing and history routing.
  • Canic: allocates the archive, installs its qualified artifact, establishes its bindings, funds it and reconciles interrupted lifecycle operations.

Keep archive appends going directly from the exchange to the archive. A Canic Root should not sit in the event-delivery path.

There is an important exception: MULTI/DEX supports removing archive controllers at seal. An immutable archive cannot remain an ordinarily managed, upgradeable Canic child. That needs an explicit lifecycle transition; public funding can continue after management authority ends.

2. Funding is another substantial overlap

MULTI/DEX already handles difficult cases: pending CMC notifications, ambiguous Ledger transfers, stable cooldowns and daily spending limits. An ambiguous transfer blocks further spending until reconciliation. Funding implementation

Canic’s funding model could consolidate these operational responsibilities across the Fleet, using its existing protected funding policies and retained recovery identities. Canic funding

However, the exchange must retain authority over which money can fund operations. Its internal treasury accounting, asset conversion and customer liabilities are application concerns. Canic should receive explicitly authorized infrastructure funding, with one owner for each transfer—not run a competing funding loop against the same balance.

3. Deployment would become more systematic—but stateful upgrades are a real blocker

MULTI/DEX’s deployment workflow handles environment posture, funding, backend/bridge wiring, frontend deployment and seeding. Its runbook also describes archive upgrade ordering when event types change. Deployment runbook

Canic could give this a stronger common structure: exact artifact identities, reviewed effects, retained progress and verification after interruption.

But Motoko support alone would not make Canic ready to manage production exchange releases. Canic currently documents pre-1.0 release transitions as reinstall-only unless explicitly designed otherwise; its backup capability does not promise cross-release state migration. MULTI/DEX expects upgrades to preserve balances and history. That gap must be resolved before adopting Canic for value-bearing release management. Canic release boundary · Backup boundary

4. Controller authority needs particular care

A concrete example: creditAndRegister currently accepts the configured Bridge or a controller. Making a Canic Root a controller would therefore also grant it deposit-credit authority under that check. Source

That illustrates why integration needs an endpoint-by-endpoint authority review. Infrastructure management, application administration and custody authorization must be deliberately mapped.

Likewise, MULTI/DEX’s proposed production custody model calls for NNS-only controllers. Inserting Canic Roots changes that model. Governance control of a Root could be considered, but it is a different trust arrangement requiring explicit design. Custody design

What I would leave application-owned

Keep matching, margin, liquidation, solvency, deposit deduplication and archive hash-chain semantics within MULTI/DEX. Preserve its synchronous financial state transitions; provisioning or remote authorization must not introduce an await into those critical paths.

Canic also would not automatically distribute its matching engine across subnets. That requires a separate design for market ownership, shared collateral and settlement.

My recommendation: use MULTI/DEX as a demanding Motoko integration pilot, starting with archive provisioning and funding in its valueless #play deployment. Prove interrupted provisioning, funding recovery and direct archive access first. Then tackle deployment integration and authority mapping.

The compelling proposition is: MULTI/DEX owns the exchange; Canic owns the machinery needed to keep its canister estate running.

2

I asked how Canic could improve itself if managing Multidex’s canisters was an option.

MULTI/DEX suggests Canic should become better at managing long-lived, stateful applications written in any IC language. Motoko support is one part; preserving state, separating authority and handling permanent archives are the more consequential requirements.

Based on the code we just inspected, I would prioritize these improvements.

Priority Canic improvement MULTI/DEX requirement it addresses
1 Language-neutral managed-canister contract Manage Motoko canisters without depending on Rust-generated runtime machinery
2 Explicit state-preserving release workflow Upgrade an exchange without discarding balances, pending transfers or history
3 Separate lifecycle authority from application authority A controller responsible for installation should not automatically pass deposit-credit checks
4 Durable child provisioning with application acceptance Create archives safely and publish them only after the exchange accepts them
5 Explicit immutable-canister disposition Seal permanent archives and relinquish control while continuing funding
6 Application-aware retirement and recovery Protect customer assets, outstanding liabilities and historical records

1. Make Motoko support a protocol implementation

Define the minimum Candid contract a managed application must implement, then provide small Rust and Motoko adapters.

That contract should cover the capabilities actually needed: initialization and binding, lifecycle readiness, funding observations and any opted-in retirement support. Version those capabilities explicitly.

Keep the Coordinator, Roots and Stores in Rust. Motoko applications should not need their own implementation of Canic’s control plane.

The qualification target should be the same behavioral contract exercised against both language adapters, including interruption and replay. Compiling a Motoko canister and installing its Wasm is only the first step.

2. Add a narrow, state-preserving upgrade contract

This is the biggest product gap for an exchange. The first version could support one explicitly qualified predecessor-to-successor transition:

  • Bind the existing principal, installed module and proposed artifact.
  • Let the application establish readiness for the upgrade.
  • Record the operation before issuing installation.
  • Reconcile an interrupted or ambiguous result.
  • Verify application readiness before declaring completion.

Avoid promising automatic rollback. Once an upgraded exchange has processed trades or external transfers, restoring an earlier snapshot could invalidate its accounting.

MULTI/DEX also demonstrates why releases need explicit compatibility ordering: an archive must understand events the backend starts producing. Initially, support a declared sequence with readiness checks; a generic dependency scheduler is unnecessary.

3. Treat authority separation as a first-class integration requirement

MULTI/DEX currently uses controller status in some application authorization checks. Adopting a Canic Root as controller would therefore change more than deployment ownership.

Canic’s adapters and examples should distinguish:

Authority Purpose
Lifecycle authority Install code, manage settings and perform permitted lifecycle operations
Service caller Append archive events or submit bridge credits
Application administrator Change exchange-specific configuration
Authenticated subject Act on a particular user’s account

This separates ordinary endpoint permissions. A controller that can replace code still has ultimate power over that canister, so documentation must not imply that endpoint guards remove the underlying governance trust.

4. Separate child readiness from application publication

For an archive, “installed successfully” is insufficient. The exchange must accept its identity, event schema and starting sequence before routing events to it.

Canic should own provisioning progress and return the same child for the same retained request. The application should own the decision that this child becomes its next archive.

That gives a useful generic boundary:

Canic proves the child is provisioned; the application proves it is suitable for use.

Keep archive sequence numbers and hash-chain rules entirely outside Canic.

5. Support relinquishing management without forgetting the canister

A sealed archive may deliberately lose all controllers. Canic should be able to record that terminal disposition without subsequently treating it as broken infrastructure to repair or replace.

Retain its identity, evidence of the transition and optional funding policy. Distinguish public observations from privileged status that is no longer available.

This is broader than exchanges: permanent records and immutable published datasets have the same need.

6. Extend retirement beyond draining a treasury

An exchange can hold liabilities even after its operational treasury is empty. An archive can have no financial balance worth recovering yet contain irreplaceable history.

Canic should require an application-owned retirement prerequisite where configured. The application decides whether obligations are settled or transferred; Canic verifies that the prerequisite is bound to the exact proposed operation. Generic infrastructure must not infer “safe to delete” from a successful drain.

I would deliver this in three stages: language-neutral contract plus an archive pilot; explicit authority and immutable-archive handling; then qualified state-preserving upgrades and application-aware retirement.

The design discipline should remain yours: one owner per effect, bounded protocols, and application semantics kept out of the framework. MULTI/DEX is especially useful because it tests those boundaries with assets and records that cannot simply be recreated.

3

how much work have the mutli dex team done that could be replaced by canic

A substantial amount of their infrastructure work—but a minority of the exchange as a whole. Canic could take over much of the machinery for creating, funding and operating canisters, once Motoko support and the lifecycle gaps we discussed are addressed.

From the code I inspected:

Work MULTI/DEX has implemented Potential replacement by Canic
Archive creation, installation, pending-spawn tracking and orphan cleanup High — generic canister lifecycle machinery
Archive, bridge and arbitrage-canister cycle funding High — consolidate operational funding under Canic
Ledger → CMC conversion, pending notifications, spending bounds and ambiguous-result handling Partial to high — Canic could own infrastructure funding; exchange treasury accounting stays
Deployment scripts, canister wiring and environment setup Partial to high — generic deployment moves; exchange seeding and posture checks remain
Archive upgrade orchestration Partial — installation/recovery moves; schema compatibility and release ordering remain application-owned
Canister inventory and operational diagnostics Partial — infrastructure inventory moves; archive event routing remains
Authentication and admission Selective — existing II login works; exchange registration and financial permissions remain
Matching, AMM, margin, liquidations, oracle policy, custody and event verification Very little — these are MULTI/DEX’s product

The overlap is real implementation effort, not just a few utility functions. They have already worked through problems such as:

  • Canister creation succeeding but installation or its continuation failing.
  • Keeping sealed archives funded after controller access is removed.
  • A Ledger transfer having an unknown outcome and blocking further spending.
  • Retrying CMC notifications without initiating another payment.
  • Preserving funding cooldowns and budgets across upgrades.
  • Coordinating backend and archive interface changes.

Those are exactly the kinds of operational failure cases a shared framework should absorb. Their repository contains dedicated fixes and tests for several of them.

For scale, their deployment script alone is approximately 65 KB, and the main backend contains separate archive lifecycle and funding sections alongside the financial code. Those sizes show meaningful infrastructure embedded in the application; they are not estimates of removable code.

My rough planning estimate—not a measured code audit—is that a mature Motoko-capable Canic could replace around half to two-thirds of their custom fleet-management machinery. I would not translate that into a percentage of the whole project: the exchange, frontend, financial correctness and domain-specific tests represent a much larger body of work.

Also, replacement would not be free. They would need adapters, authority changes and integration qualification. Some existing implementation tests could disappear, but end-to-end tests proving that deposits, archives and funding still work would remain.

The strongest benefit is future maintenance: their team could stop owning many generic lifecycle and funding failure modes, while Canic’s fixes and qualification would benefit every application using the same contracts.

4 
ok lets say canic wanted to take all the multi dex feedback, work with them, what could this look like in 6 months?

In six months, Canic could have MULTI/DEX running as a supported Motoko application, with much of its bespoke canister-management code removed—and a stronger platform for other stateful IC applications.

That is plausible if both teams commit engineering time and work against one shared integration roadmap. The goal should be a working deployment with demonstrated recovery, rather than absorbing every exchange requirement into Canic.

Month 1: agree on ownership and establish the baseline

Jointly inventory the infrastructure MULTI/DEX already maintains: provisioning, funding, deployment, upgrades, permissions and recovery. For each responsibility, decide whether Canic replaces it, integrates with it or leaves it application-owned.

Deliverables would include:

  • A minimal language-neutral managed-canister contract.
  • A Motoko adapter design.
  • A baseline of infrastructure code, tests, deployment steps and operating costs.
  • A shared set of failure scenarios drawn from MULTI/DEX’s actual incidents.

Their existing fixes and tests become requirements for Canic adoption. Replacing working safeguards must preserve their guarantees.

Month 2: make archives the first working integration

Deploy a disposable #play exchange whose archive canisters are provisioned and funded through Canic.

MULTI/DEX retains event capture, shipping, deduplication, sequence ownership and hash verification. Canic owns the infrastructure lifecycle.

The milestone is concrete: interrupt provisioning at supported failure boundaries, resume it, and demonstrate that the exchange gets the correct archive without duplicate allocation or forgotten funded canisters. Measure the added latency, cycle cost and Wasm overhead.

This is when Motoko support becomes a demonstrated capability.

Month 3: consolidate funding and deployment

Extend the integration to the bridge stub, simulator and remaining supported components. Introduce one explicit infrastructure budget and remove competing funding owners as each replacement is qualified.

Replace generic deployment and wiring steps with Canic configuration and reconciliation. Keep exchange-specific seeding, deployment-posture checks and financial initialization in MULTI/DEX.

At this point, the team should be able to stand up another test exchange and recover an interrupted deployment through a documented workflow. Their old infrastructure code should start disappearing from the maintained path.

Month 4: prove state-preserving releases

This is likely the hardest milestone.

Qualify a specific backend-and-archive upgrade, including compatibility ordering, outstanding archive shipments and pending funding operations. Establish exactly when the exchange must pause and what can remain available.

Demonstrate that interruption does not lose balances, repeat payments or publish an incompatible archive. Recovery must reconcile external effects; restoring an old snapshot cannot be treated as a universal undo button.

The result should be a narrow, reliable upgrade contract that can expand with evidence.

Month 5: resolve permanent records and governance

Complete the cases that a disposable game deployment does not fully exercise:

  • Archives that become immutable but still need funding.
  • Retirement blocked by outstanding application obligations.
  • Explicit separation of service callers, application administrators and lifecycle authority.
  • A documented controller/governance model acceptable to both teams.

The NNS-controlled custody ambition would need its own agreement and qualification. A successful Canic integration would not itself establish governance approval or production custody readiness.

Month 6: operate, simplify and publish the evidence

Run the integrated exchange through sustained use and repeated release/recovery exercises. Delete superseded machinery, document the remaining application responsibilities, and publish a reusable Motoko example.

The outcome could look like this:

MULTI/DEX owns Canic owns
Trading, balances, margin and liquidation Managed-canister provisioning and placement
Deposit and withdrawal accounting Authorized infrastructure funding
Oracle and custody policy Lifecycle operation recovery
Event semantics and archive routing Archive installation, bindings and management disposition
Application release-readiness checks Qualified release execution and infrastructure verification
Financial retirement prerequisites Enforcement of configured retirement prerequisites

What would make this a success

I would agree on measurable acceptance criteria at the start:

  • No unexplained orphaned canisters or duplicate funding effects in the agreed fault tests.
  • A qualified upgrade preserving application state and accounting.
  • A measured reduction in MULTI/DEX-owned infrastructure code and maintenance tests.
  • Acceptable cycle, latency and Wasm overhead.
  • A second, small Motoko application using the same contracts without MULTI/DEX-specific framework changes.

That last check matters: it shows Canic has gained reusable capabilities.

The realistic six-month result is an operationally qualified #play integration, a useful Motoko SDK and a proven path for selected stateful upgrades. Real-money production adoption would additionally depend on MULTI/DEX’s custody implementation, security review and governance decisions.

Strategically, this could move Canic from infrastructure proven mainly through your own applications to infrastructure shaped and validated by an independent team—with an exchange providing particularly demanding tests of durability, authority and recovery.

5

If MultiDex is open source, why dont you fork it and run on Canic. Than we can test and see if it works better than what currently has.
I honestly have no idea what Canic is, so i have no idea if its useful nob devs projects like i have.

6

Canic can offload a lot of the Multi/dex developers work. I know that, and it may be 80% there and the last 20% will help me improve it.

This is how open source code gets better.

9

(ai is absoluitely terrible at calculating timeframes for software development)

14

Literally no interest in helping your dex scale, love it! What the hell is going on over there.

15

I’ve been trying to figure that out for years but it’s very tricky. It’s almost as if there’s information that everybody knows about, but there’s other information that only some people know about. I’m sure there’s a big word for that.

But it does seem to create an advantage if you can see clearly what is hard for everybody to see.

16

definitely looks like white with some stains.. haha

17

Why you even need multidex, you had Kongswap, or even better, take over or be part of ICPSwap and implement Canic into that + help them compleate futures platform.

18

Help Multi dex scale with my open source code lol.

19

Do you have numbers that prove the need it to scale. There is rule of keeping system simple, adding more complexity will add more risks.

20

I’d use canic to manage any system that has more than one canister, so yes if that is the case, I’m designing Canic to help.

It’s fine Im going to fork multi/dex as an experiment anyway I just need to get Motoko support in first obvs.

https://miner.toko.app/metrics - here you can see it in action

https://miner.toko.app/metrics/root/2ydug-eaaaa-aaaab-qhfca-cai/interface