Kadia DEX: know your assumptions
Source: kadia-dex docs/guide/assumptions.md at commit 28b2eba (28b2ebad314c5a32c779ca2b4093e71fe8c142ea). The IDs (S1, N3, …) are the guarantee and non-guarantee tables in the DEX design specification, §2.3, which has the exact wording.
What you’re trusting
Section titled “What you’re trusting”| You trust | For | If it fails |
|---|---|---|
| Ergo consensus | Running the contracts exactly as written | Everything on Ergo is affected, not just Kadia. |
| The contract code | Every guarantee below | Funds in markets and orders can be lost. The contracts haven’t been audited. |
| Your wallet | Showing you the real transaction before you sign | You could sign something the app didn’t describe. Check what your wallet shows. |
| The app you use | Showing correct prices, balances and order status | It can mislead you, but it can’t take funds you didn’t sign away. The contracts enforce your minimum and your refund. |
| That someone runs a settler | Your order getting filled | Nothing is lost. Your order waits until expiry, then anyone can refund it. |
| That someone runs a keeper | Timely refunds and fresh markets | You can always cancel with your own key. See storage rent below. |
| The governance key holders (guardians 2 of 5, upgraders 3 of 5) | Pausing only for cause, and upgrading only to a market you can inspect during the 14-day notice | A market can be paused or wound down, and an upgrade can orphan your open orders. You can still remove liquidity, cancel and refund at any time. |
You don’t trust Kadia’s servers, the settler or the keeper with your funds. None of them have on-chain privileges. The one on-chain privilege in the system is governance (below): its key holders can pause and wind down markets and, with 14 days’ notice, upgrade them, but they can’t move your funds or stop you removing liquidity or cancelling an order.
If you trade
Section titled “If you trade”Guaranteed by the contracts:
- You get at least your minimum, or nothing happens. An order is spent in exactly one of three ways (S1):
- you cancel it;
- a settlement pays you at least your entitlement and your
minOut; - after expiry, it’s refunded to you minus at most your execution-fee cap.
- The same reference price as everyone in your batch. Every order filled in one transaction has its minimum computed from the same reference price and fee (S2). Realized prices can differ slightly through rounding and overpayment.
- Your payout can’t be redirected. It must go to the payout address in your order, tagged with your order’s id (S3).
- You cap the fee. Your order refuses a market whose fee is higher than the maximum you set, or whose band is wider than you accept.
Not guaranteed:
- That your order fills at all (N1, N6). A settler can leave any order out, and large orders may be too big for the pool’s band to absorb.
- The best possible price (N2). The settler picks the batch and can move the price anywhere the rules allow above your
minOut.minOutis your protection, so keep it tight. - Timing (N5). Everything is measured in block heights, about 2 minutes each, not wall-clock time.
- Automatic refunds (N7). Anyone can refund an expired order and keep up to your execution-fee cap. Kadia’s keeper does so on a best-effort basis.
- Partial fills. A swap order fills completely or not at all. A limit order (the testnet’s partial-fill order) can fill in parts, and isn’t guaranteed to fill at all.
If you provide liquidity
Section titled “If you provide liquidity”Guaranteed:
- An exit always exists (S7). A finite sequence of removal steps (redeem orders in the contract) returns your LP share without needing traders or anyone else’s liquidity. That guarantees the transactions exist, not that they get included (see N9 below). One condition under the protocol fee: the treasury’s pending fee must stay below its cap (2⁶² shares). On a Kadia-verified market that takes roughly 15,600× growth in the value of an LP share, from fees or donations, with no fee claim in between. Anyone can make a claim, and the keeper makes one weekly. If the cap were ever reached on a market that is also below its trading floors, exits would wait for a claim, and that claim for a donation (A20-2).
- The pool is paid at least the fair post-trade price plus the pool fee on each block’s net flow (S4). Orders matched against each other in a batch never touch the pool, so not every trade pays the pool fee.
- The market’s parameters never change after it’s created (S5).
- Within a block, the price stays within the band around the block’s opening price (S6).
Not guaranteed:
- Protection from arbitrage (N3).
- Within a block, a settler can chain several settlements and capture another trade’s price impact.
- Across blocks, the price can move by up to the band each block, and that compounds.
- Arbitrageurs take the difference from liquidity providers, as on every AMM.
- That the market stays tradeable (N13). A market can reach a state where no swap is possible. Your funds aren’t trapped: you can still exit.
- That your LP order goes through promptly (N9). LP orders only run at the start of a block, and someone willing to pay for a swap every block can delay them.
- Exact pro-rata amounts on exit (N14). Each removal step rounds down, losing under one raw unit per step. On ERG/token markets, an isolated exit can also leave the market’s box minimum behind.
- That trading continues after large exits (G4). A market can end up below its trading floors. Swaps are then impossible until added liquidity lifts both reserves, but exits still work, except in the rare fee-cap case above (A20-2).
- Token-to-token collateral (N12). A token-to-token market’s ERG collateral stays in the market box for good and is never paid to liquidity providers.
- The value of burned LP tokens (N10). LP tokens burned outside the market leave their share in the pool, where nobody can remove it and it isn’t redistributed.
System-level risks
Section titled “System-level risks”- Storage rent (N8). Ergo lets anyone spend a box that is about four years old, whatever its script.
- Orders expire long before then, and the keeper refunds them.
- Markets are kept fresh by normal use and by keeper maintenance.
- If every keeper stopped for about four years, an idle market could be claimed through rent.
- Your own payouts carry a rent reserve by default, so your tokens survive a rent collection.
- Custom payout scripts (A04). Whoever fills or refunds your order picks the payout box’s extra registers and its creation height. The Kadia app always pays to your wallet address, which ignores them.
- Rust and Scala node disagreement on rent (S04). The two Ergo node implementations currently disagree on some rent cases. Kadia won’t launch until a fix gives identical results on both.
- Market history. The guarantees assume every spend of a market since its creation followed the contract rules. The registry replays every market and quarantines any that fail. The Kadia app only trades markets the registry lists as verified.
- Pause and upgrade keys (r12). A market linked to Kadia’s official governance box can be paused by 2 of 5 guardians, for up to 30 days at a time (renewable). It can be wound down for good, or upgraded, by 3 of 5 upgraders. An upgrade takes effect only after 14 days’ notice (10,080 blocks), and none can take effect from block 2,550,000; the upgraders can also cancel an upgrade, or give up the upgrade path for good. Source: kadia-dex
docs/specs/r12-governance.mdata75c9ec.- What they stop: new swaps and new deposits (during an announced upgrade, only deposits pause; swaps continue).
- What they never stop: removing liquidity, cancelling an order, refunding an expired order, maintenance and the treasury claim.
- An upgrade replaces the market’s script, so orders on the old version stop filling: cancel them and place them again. Their cancel and refund never touch the market, so nothing is stuck.
- If the governance box can’t be found, the market refuses swaps and deposits, not exits.
- A market’s parameters (fee, band, treasury) can’t be changed by governance.
- This is a deliberate trade: a bug found after launch can be paused instead of drained, at the price of trusting the key holders not to pause without cause.
- Only the official governance counts. Anyone can deploy a copy of the market script governed by their own key. The registry admits only markets linked to the official governance box, and the Kadia app marks any other as not official and takes no order on it.
- The protocol fee is capped. A market’s protocol share is fixed when it’s created. The contract allows up to half of the pool’s growth, but the registry won’t verify a market above one sixth (1,667 bps).
Community pools
Section titled “Community pools”Anyone can create a pool on Kadia from the browser. A launch market is created by Kadia and named in its launch manifest. A community pool is created by someone else and found on chain by the service.
- Why a check is needed. The contracts can’t count how many LP tokens exist: that’s a fact about the transaction that minted the token, not about the pool’s box. If a creator minted extra LP tokens, they could redeem them against everyone else’s liquidity.
- What Kadia checks. Kadia’s service and SDK follow a community pool only when its LP token was minted once, with exactly the pool’s LP total, by the transaction that created the pool. Then the pool goes through the same admission and history checks as a launch market, and is traded only once verified. Anyone can run the same check with one command,
dex-genesis supply. - What to do. Use pools through the Kadia app or another tool that runs this check. A pool shown by a tool that doesn’t check its genesis can look like any other and still be unsafe.
- What the check doesn’t say. It proves the pool was set up by the rules, not that its tokens are worth anything. Kadia doesn’t review community pools’ tokens.
- Governance applies too. The pause, wind-down and upgrade controls cover community pools as well, because the market script reads the official governance box.
See Fees for who pays what.