DEX Aggregators

Who this page is for

This page is for platforms that want to route taker flow into Canonic, including DEX aggregators, routers, and other offchain quoting systems.

It focuses on taker integration, not maker operation.

What Canonic exposes

For routing and execution, the main surfaces are:

• deployed MAOB markets listed in Contract Deployments
• official MAOBPreviewer deployments listed in Contract Deployments
• taker entrypoints documented in Takers
• read-only quoting patterns documented in Read-only Quoting
• generated contract references in MAOB.sol
• generated contract references in MAOBPreviewer.sol

Integration path

The normal integration flow is:

1. discover supported markets and addresses
2. verify the contracts on the block explorer
3. read live midpoint and depth
4. produce a quote and choose guardrails
5. choose the correct taker function
6. ensure token approvals are in place
7. submit the transaction
8. parse the result and surface fills / failures back to the caller

Step 1: Discover markets

Start from Contract Deployments.

For each market, you need at minimum:

• MAOB address
• base token / quote token mapping
• network selection

If your router maintains a market registry, treat the deployment page as the public source of truth for currently documented markets.

Step 2: Verify contracts on the block explorer

After resolving addresses, verify them on Blockscout before routing production flow.

For each chain, confirm:

• the MAOB address matches Contract Deployments
• the contract source is verified on the block explorer
• the official MAOBPreviewer address for that chain matches Contract Deployments
• you are reading the correct network before caching the address in your registry

This is the fastest way to catch wrong-network addresses, stale copies, or unverified contracts before they affect routing.

Step 3: Read market state

Before quoting, fetch:

• getMidPrice()
• getRungs() and / or rungCount()
• getDepth(maxPerSide) for a fast summary
• takerFee()
• minQuoteTaker()
• marketState()

Use Read-only Quoting as the primary guide here.

If your system simulates exact fills, make sure you match Canonic’s rounding and remainder behavior. For high-confidence previews, use the official MAOBPreviewer flow described there.

Step 4: Choose the taker function

Canonic’s taker API is easier to integrate if you map user intent explicitly:

• user wants to spend up to a quote amount to buy base: buyBaseTargetIn
• user wants to receive exactly a base amount: buyBaseExactOut
• user wants to sell up to a base amount: sellBaseTargetIn
• user wants to receive exactly a quote amount: sellBaseExactOut

If your router already has exact-in and exact-out abstractions, the mapping is straightforward, but you must still set the right guardrails.

See Takers for parameter-level details.

Step 5: Set execution guardrails

Every integration should set:

• a short deadline
• the relevant min / max amount guard
• maxRung if you want to cap traversal distance from midpoint
• minQuotePerRung if you want to ignore dust-heavy rungs

If you quote optimistically and route without conservative buffers, you should expect more onchain reverts.

Step 6: Handle approvals and settlement

Taker flows are standard ERC-20 interactions:

• buying base usually spends quote tokens
• selling base spends base tokens
• fees are charged in the output token side described in Takers

Your integration should ensure the spender has:

• sufficient token allowance
• sufficient token balance
• sufficient native gas

Step 7: Handle failure modes explicitly

Your router should surface meaningful errors for:

• insufficient liquidity
• stale or missing oracle data
• min / max guard failures
• paused market state
• invalid or expired deadlines

The relevant revert classes are listed in Takers and Read-only Quoting.

Operational recommendations

• Cache deployments, but refresh them when docs change.
• Refresh depth and midpoint frequently; do not treat them as static.
• Refuse to quote if the oracle is stale by your policy.
• Prefer conservative slippage buffers for first integrations.
• Instrument failure rates by market and function so you can tune guardrails.

What is still offchain

Canonic can be quoted offchain safely, but your router is still responsible for:

• market discovery
• quote freshness policy
• slippage policy
• retry behavior
• user-facing error messages

The protocol gives you deterministic execution rules, not a hosted routing API.

Recommended reading order

1. Contract Deployments
2. Read-only Quoting
3. Takers
4. MAOB.sol

If you also want to make markets

Routing flow and maker flow are separate concerns. If you want to post liquidity as well, continue with Market Makers and Makers.