Order-book Exchange Whitepaper: Miner Matching on CoNET-DLE

Version: v0.2 (discussion draft) | Date: 25 October 2026 | Basis: the CoNET-DLE whitepaper (revision 2026-09-23, "DLE whitepaper"), the L2 — CoNET-DLE section, the Miner-matched order-book exchange design study ("design study"), and operator decisions of 25 October 2026 | Status: discussion draft. Not approved by the DAO. The DLE chain classes, events and contracts it needs are not implemented or deployed.

Order chains, miner splitting and matching, freeze authorization, and a liquidity-pool fast lane.

How to read the labels

• [Decided]: a rule the operator has decided, with the decision date. An operator decision is not DAO approval.
• [DLE current]: a rule frozen in the DLE whitepaper or its specifications, cited as "DLE §x.y".
• [Needs DLE revision]: a rule this paper needs DLE to add or change. It takes effect only after the DLE specification maintainers adopt it.
• [Proposed]: a design proposed by this paper and not yet decided by the operator.
• [Pending]: an open item, listed in Appendix B.
• In this paper, "chain" means one DLE tip (an independent ledger bound to an L1 NFT), not CoNET L1.
• Where this paper and the DLE whitepaper or its three specifications differ, the DLE documents prevail. Every change this paper needs from DLE is listed in Section 2.3.

Summary

This paper proposes a decentralized order-book exchange that runs entirely on CoNET-DLE.

Funds stay in DLE, held by the user. A user's assets sit on DLE asset chains in the user's own name, each holding at most 100 USDC equivalent. To place an order, the user signs a freeze of some of those asset chains for that order. At fill, DLE moves value out of the frozen asset chains and into the counterparty's asset chains. Cancelling releases the freeze. The exchange has no vault, and nobody can move funds that the user has not frozen by signature [Decided] (2026-10-25).

One order chain per order, with a 0.003% prepayment. The order placer opens one DLE order chain for each order. At placement the placer prepays 0.003% of the full order amount. This prepayment is the chain-opening fee and goes to all validators of that order chain. Cancelling costs nothing more, and the prepayment is not refunded. The minimum order is 1 USDC equivalent [Decided] (2026-10-25). The order chain records the signed terms, the frozen funds and the fill progress, and closes when the order ends.

Idle miners race to match; consensus miners keep it safe. Each trading pair has one market chain. Order matching is done by every idle light miner (one that has staked the CNET threshold), competing for profit to be the first with a winning match: each one includes orders, splits them, computes the result and submits a proposal. The consensus committee DLE draws for the batch recomputes the proposals independently and makes the valid proposal with the largest fill volume the block, and the archive group replays and finalizes it. An invalid proposal costs its submitter [Decided] (2026-10-26). At fill, each order placer pays 0.007% of the filled amount as the matching fee, all of it to the winning matching miner; when two book orders fill each other, each side pays 0.007%. The 0.01% transfer fee is shared by the consensus miners [Decided] (2026-10-26). The 0.003% prepayment and the 0.007% at fill add up to 0.01%.

DLE completes the transfers in parallel. After a fill is final, miners split it into transfers on many asset chains and submit them in parallel. DLE executes them. Every outgoing transfer pays a 0.01% DLE transfer fee on its amount. However many chains a transfer is split across, the total fee equals 0.01% of the amount transferred [Decided] (2026-10-25). Transfers use two phases: first debit to in-flight, then credit. If either side's debit fails, the other side is refunded automatically.

Liquidity pools and the fast lane. Anyone may open a liquidity pool without permission and set its fee rate and price range. A pool is a registration on a DLE storage chain that lists the frozen asset chains of every LP in the pool. When an order turns on the fast lane, miners compare the pools and the book orders together and fill the order at whichever is better for the user. An order placer filled by a pool pays the matching fee, the transfer fee, and the LP fee set at pool opening. LPs also pay the 0.01% DLE transfer fee on what they send out, covered by the pool fee [Decided] (2026-10-25).

Every fee is in the placer's outgoing token. The prepayment, the DLE transfer fee, the matching fee and the LP fee are all computed and paid in the token the order placer sends out, not in the token the LP provides. LPs therefore receive the placer's token, which they can trade into any token on DLE's trading pools [Decided] (2026-10-25).

Ordinary orders use frequent batch auctions. Orders not on the fast lane fill at one uniform clearing price per batch. The order of arrival within a batch does not affect the price, which narrows the room for front-running [Proposed].

Why DLE. The core risk of centralized exchanges is custody: misuse, theft, freezes and opacity. Existing decentralized exchanges removed custody but brought curve pricing and front-running, small fixed validator sets, upgrade-key and bridge risk, and a capacity ceiling: every market shares one chain's block space and block time, or one validator set's block production. A DLE-based design answers with non-custodial freezes; open matching, where idle miners that stake CNET race to match while randomly drawn consensus committees and archive groups recompute and confirm; deterministic, recomputable matching; separate chains for each market, order and asset balance, so total capacity grows with miners and archive groups instead of one chain's block speed; and a 100 USDC loss cap per asset chain. The costs are latency above a centralized exchange's (one market's batches stay serial, and nothing is measured yet), more complex settlement, fragmented balances, a liquidity cold start, and dependence on DLE components that are not yet live (Sections 1.2–1.5, 6.6).

The DLE components this design depends on are not yet in production. The AssetBurnMintGateway that moves assets into and out of DLE is not live. Production archive signing is not enabled: the archive conformance specification forbids it until its production blockers close. The 30-day lab pilot's final assessment was "partial success, not qualified". This design also needs DLE revisions (Section 2.3): new market-chain and order-chain classes, freeze authorization, two-phase transfers between DLE chains, events that cite another chain's AC, liquidity-pool records on storage chains, transfer fees paid in the transferred token, the new fee allocation, and open matching proposals from staked light miners. This paper promises no launch date, fill speed, liquidity depth or return.

Audience. DAO voters, miners, liquidity providers, DLE specification maintainers and auditors. Example parameters are for illustration only. They are not launch parameters.

1. Scope, landscape and motivation

1.1 Problem

The design study explains that an order book avoids several AMM problems: price comes from explicit quotes, a large trade consumes visible depth, and market makers control their own quotes, inventory and cancellation. Order books have their own problems: spreads widen when depth is thin, a matcher network brings ordering, censorship and front-running risks, and an order waits when no counterparty is present.

This paper's goal is a way to trade on CoNET that does not depend on a curve, does not take custody of funds, and is matched by the miner network, with user-provided liquidity pools to shorten the wait. It does not claim that an order book is better than an AMM in every case.

1.2 Centralized exchanges today

Centralized exchanges (CEXs) are still where most crypto trading happens. According to The Block, decentralized-exchange (DEX) spot volume in July 2026 equaled about 24% of CEX spot volume, the highest on record, up from about 17% a year earlier. The rise came mainly from falling CEX volume rather than growing DEX volume [1].

CEX strengths are real: deep order books, matching measured in milliseconds, fiat on- and off-ramps, customer support and compliance, and a full range of derivatives. Their problems all come from one fact: users must hand their assets to the exchange.

1.3 Decentralized exchanges today

DEXs solve custody: assets stay in user wallets or public contracts, and trades can be checked on chain. But each existing type has a cost:

In short, DEXs removed custody risk but brought curve pricing and MEV, congestion on a shared chain, small fixed validator sets, upgrade-key risk in upgradeable contracts, and bridge risk.

1.4 Why DLE: the problems it addresses

1.4.1 Throughput: where DLE differs from today's order-book DEXs

This is the main architectural difference between this exchange and existing decentralized order books.

Existing order-book DEXs are bounded by one chain. An order book on a shared chain (such as Serum / OpenBook on Solana) shares that chain's block space and block time with every other application. An appchain order book (such as dYdX v4 or Hyperliquid) runs every market through one validator set that produces one sequence of blocks. In both cases total capacity is set by how fast one chain produces blocks and how much one block can carry. Adding validators does not add capacity; it usually adds coordination cost.

DLE has no global block interval. DLE is an event-driven, multi-chain concurrent ledger system [DLE current] (DLE §3.1–§3.2):

• Each ledger is its own chain. In this exchange, each trading pair has its own market chain, each order has its own order chain, and balances sit on many independent asset chains.
• A chain produces a block only when an event arrives ("no event, no block"). Nothing waits for a network-wide slot.
• Each block is produced by a committee of 7 drawn from the on-demand miner waiting queue and finalized by the archive group that hosts that chain. Different chains use different committees at the same time.
• Throughput is the sum of all active event streams across chains, not the speed of one chain.

What this means for an order book.

• More markets in parallel: every trading pair advances independently. A busy pair does not slow other pairs, and adding markets does not compete for one shared block space.
• Many orders per block: a matching batch is one event that can carry many orders, cancels and fills, so one market-chain block clears a whole batch auction at once.
• Settlement in parallel: each fill settles as transfers on different asset chains with different committees, so settlement capacity grows with the number of committees available.
• Capacity grows with participation: as more miners join the waiting queue and archive groups split (fission), more committees and more hosting capacity exist at the same time, so more markets, orders and settlements can run concurrently.

Boundaries. These are architectural properties, not measured results, and they do not mean each transaction gets faster as miners join [DLE current] (DLE §3.4):

• The batches of one trading pair still advance one after another on its market chain. The speed of a single market is bounded by the committee vote (window up to 30 seconds) and archive finality, and by the batch cap B_max.
• Capacity also depends on the number of archive groups and on the committee exposure bound E_C ≤ E_max.
• Fill latency and throughput have not been measured. The 30-day lab assessment was partial success, not qualified, and production signing is not enabled.

1.5 Advantages and disadvantages

Advantages

1. Capacity that grows with miners: an event-driven, multi-chain concurrent ledger, where markets, orders and settlements run on separate chains with separate committees; total capacity grows with miners and archive groups instead of being set by one chain's block speed (Section 1.4.1).
2. Non-custodial: assets always stay on the user's own DLE asset chains; only what the user freezes by signature can leave, and only per the order.
3. Open matching, randomly drawn confirmation: any idle miner that stakes CNET can race to match; a randomly drawn consensus committee and an archive group confirm the result, with no reliance on one company or a few fixed validators.
4. Verifiable results: matching and the reference price are deterministic computations on public data that anyone can recompute.
5. Less front-running: batch auctions clear at one uniform price, so order within a batch does not matter.
6. Parallelism and failure isolation: pairs, orders and assets are separate chains; congestion or a fault in one market does not affect others.
7. Bounded loss: if one asset chain is compromised, the direct loss is at most 100 USDC equivalent.
8. Low, transparent fees: about 0.02% for a full fill (excluding any LP fee), computed on amounts, regardless of how many chains carry it.
9. Incentives tied to work: miners, validators and LPs earn by fill volume, order amount and pool share respectively.
10. Open liquidity: anyone can open or join a pool without permission.
11. No privileged address in governance: listings and parameters are DAO votes; pools need no permission.

Disadvantages

Comparison

References for this section

1. The Block, 3 August 2026, "DEXs capture record 24% of spot crypto trading as CEX volumes sink": theblock.co/post/410476
2. TechCrunch, 21 February 2025, "Crypto exchange Bybit says it was hacked and lost around $1.4 billion": techcrunch.com
3. TechCrunch, 23 December 2025, "Hackers stole over $2.7 billion in crypto in 2025, data shows": techcrunch.com
4. Decrypt, "From Bybit to Coinbase: 2025's Biggest Crypto Hacks and Breaches": decrypt.co
5. Cointelegraph, "Bitget CEO slams Hyperliquid JELLY perps delisting": cointelegraph.com
6. Decrypt, "Biggest Crypto Hacks of All Time": decrypt.co

1.6 Related documents

1.7 Not promised

Fill latency or throughput (neither is measured); depth or spread on any pair; miner or LP income (LPs can lose money); anonymity; launch before the DLE release gates close.

2. CoNET infrastructure used

2.1 Roles of each component

2.2 Current status

The path for assets into DLE is itself not open. Until the DLE production gates close, the exchange can only run on the lab network with test assets (Chapter 15).

2.3 DLE revisions needed [Needs DLE revision]

3. System overview

3.1 Roles

3.2 Data flow

1. Assets enter DLE (L1 burn → asset chain activated, each ≤ 100 USDC)   [needs AssetBurnMintGateway]
2. The placer opens an order chain (L1 birth NFT + DLE genesis) and prepays 0.003% of the order amount
   Genesis binds the signed order and the freeze authorizations (the placer's own asset chains)
   LPs sign pool entry + freeze authorization, registered on the pool's storage chain
        │ L0 encrypted transport
        ▼
3. One batch on the market chain
     Idle matching miners each include orders, compute the result and race to submit a proposal
     The consensus committee (5/7) recomputes every proposal and makes the valid one with the largest
     fill volume the block; the archive group finalizes it with a 4/5 AC
     A proposal contains: newly admitted order chains
     Fast-lane orders first: compare pools and book orders together, fill at once
     Ordinary orders next: frequent batch auction at one clearing price
     Output: fillsRoot, updated book, reference-price curve
        │
        ▼
4. Miners split each fill into transfers on many asset chains and submit them in parallel
     Phase 1: each paying asset chain debits to in-flight (fill amount + matching fee + transfer fee + LP fee)
     Phase 2: with every debit receipt in hand, credit the receiving asset chains; on a debit timeout, refund
        │
        ▼
5. Each order chain updates its fill progress from the market batch and settlement receipts,
   and closes when fully filled, cancelled or expired
6. A user leaving DLE exits normally through AssetBurnMintGateway (L1 remint)

3.3 Three confirmation levels

An interface must never show a lower level as a higher one.

4. Funds: all in DLE, freeze authorization [Decided] (2026-10-25)

Operator decisions: the exchange does not take custody of funds; the user authorizes DLE, which moves funds out and in at fill. LPs must use funds already in DLE; staking moves those funds into a pool opened in DLE, and trades with the pool settle in DLE.

4.1 How funds enter DLE [DLE current]

An external-chain asset first becomes a CoNET L1 canonical token through a Treasury route. AssetBurnMintGateway then burns it on L1 and a DLE asset chain activates the same balance (DLE §4.6). At activation and at every later revaluation, an asset chain holds at most 100 USDC equivalent; any excess must move to new asset chains. A user with more funds therefore holds several asset chains. Leaving DLE uses normal or forced exit, which remints the canonical token on L1.

4.2 Freeze authorization

When opening an order chain, the placer also signs a freeze on each of their asset chains used for the order [Proposed, needs DLE revision R3]:

FreezeForOrder {
    assetTipId,        // the frozen asset chain
    owner,
    amount,            // amount frozen for this order
    orderChainId,      // NFT id of the order chain
    freezeNonce
}

• Once frozen, that balance can only leave by a fill of that order, or be released when the order closes.
• Ownership does not change. The asset chain's owner is still the user (L1 ownerOf). The exchange, the miners, the order chain and the market chain do not hold these funds.
• The frozen amount must cover the order's maximum payment and every fee cap (Section 9.2).

Every matched fill is backed by frozen funds, so a user cannot move funds away after matching and make the fill fail.

4.3 Splitting under the 100 USDC cap

One order often needs several frozen asset chains. A 1,000 conet-USDC buy order needs at least 10. Transfers after a fill are split by a deterministic rule:

• Payment is debited from each asset chain in freeze-record order, one debit event per asset chain.
• When one asset chain takes part in several fills in the same batch, they merge into one event.
• Splitting only spreads a fill across asset chains. It does not change price, quantity or fees. The matching fee, the DLE transfer fee and the LP fee are computed on the total filled or transferred amount, however many chains are involved [Decided] (2026-10-25).

Operator rule: the DLE transfer fee is 0.01% of the amount, whatever the number of chains. For 1,000 USDC it is (100 × 0.01%) × 10 = 1,000 × 0.01%, not 1,000 × (10 × 0.01%).

4.4 Receiving asset chains

Received value must land on some asset chain, which still may not exceed 100 USDC equivalent after the credit. An order names how it receives [Proposed]:

1. Credit the receiving asset chains named in the order, up to their cap.
2. Open new asset chains for any remainder under the DLE spillover rule (DLE §4.6). Each new chain needs a new L1 NFT, which has a birth cost.

Wallets should merge balances from time to time, within each chain's cap. Who pays the birth cost of new receiving chains is pending (Appendix B, B-9).

4.5 Cancel, release and exit

• Cancel: the placer signs a cancel. Once a market batch includes it, the order chain moves to Cancelled under that batch's AC, and the asset chains release the freeze against the order chain's closing record.
• Fill before cancel in the same batch: when one batch holds both a fill and a cancel for the same order, the fill runs first [Decided] (2026-10-25; see Section 10.8; the same rule applies to ordinary orders).
• Amend: instead of cancelling, the placer may change price or quantity on the same order chain. The order rejoins the queue and pays 0.003% again on the new order total (Section 5.1a).
• Release when the market stalls: if the market chain produces no batch for T_unfreeze, the placer may close their own order chain and release the freeze without the market chain.
• Forced exit: DLE forbids any rule that blocks or reduces a forced exit (DLE §4.6). Once an asset chain requests a forced exit, the market stops using its frozen funds. How to handle a part that is matched but not yet debited is a question for the DLE gateway specification (Appendix B, B-10).

4.6 Listable assets

• Must be admitted to DLE: a Treasury V3 canonical token, ACTIVE in AssetAdmissionRegistry, with an approved L1 pool, TWAP oracle and minimum liquidity [DLE current] (DLE §4.6, §13.3).
• If its CoNET supply depends on cross-chain proofs (for example conet-USDC minted from Base USDC deposits), it may not be listed until that proof is shown to reject forged source-chain messages (the general gate in Chapter 17 of the GB whitepaper).
• The DAO votes to approve each pair (Chapter 13).
• Free GB cannot be transferred or traded and cannot be listed (GB whitepaper 1.3, 8.2). Paid GB follows the new GB contract once deployed. The new GB and new conet-USDC contracts are not deployed.

5. Orders and order chains

5.1 One order chain per order [Decided] (2026-10-25)

The operator decided that the order placer pays the fee for opening a DLE chain, and that each order opens its own DLE chain.

An order chain:

• is opened by the placer and bound to a unique L1 NFT owned by the placer;
• binds the signed order and the ACs of the freeze authorizations at genesis;
• records remaining quantity, cumulative fills, settlement receipts and status;
• closes when fully filled, cancelled or expired, and produces no blocks after that (the same idea as a DLE trade chain closing after sale, DLE §4.7).

Chain-opening fee: a 0.003% prepayment [Decided] (2026-10-25). Operator decision: at placement, the placer prepays a 0.003% fee; cancelling costs nothing; at fill the placer pays 0.007% of the filled amount. The operator confirmed that the 0.003% prepayment is the chain-opening fee, received by all validators of that chain, and that the 0.007% matching fee goes to the matching miners.

How the prepayment reaches order-chain validators [Proposed]. The prepayment is recorded on the order chain. For each block the chain produces, one portion goes to the validators who voted to accept that block. When the chain closes, the remainder goes to the accepting validators of the closing block. Portion sizes are set in advance from the expected number of blocks (genesis, a number of fill updates, close), with rounding dust going to the closing block.

Converting the minimum order [Proposed]. On a market quoted in conet-USDC, a buy order is checked on its quote amount and a sell order is converted at the reference price (Section 10.4). Other markets convert to USDC equivalent with the TWAP oracle used for DLE asset admission (DLE §13.3).

Cost-coverage gap [Pending]. A 1 USDC order prepays only 0.00003 USDC equivalent. An order chain's real costs include the gas for minting its L1 birth NFT, the committee and AC for its genesis and later events, and the archive group's long-term storage of its history. With the whole prepayment going to validators, what pays the L1 mint gas and archive storage, and whether small orders cover validator costs, must be assessed after DLE measures costs (Appendix B, B-18).

Effects.

• The prepayment gives every order a cost. Cancelling is free, but repeated place-and-cancel loses the prepayment each time, so spam orders are costly.
• Price and quantity changes can be made on the same order chain without cancelling and opening a new one, but each amendment prepays 0.003% again on the full new order total (Section 5.1a).

5.1a Amending on the same chain [Decided] (2026-10-25)

The operator decided to allow amendment on the same order chain: the placer re-signs to change price or quantity, and the order rejoins the queue. Each amendment prepays 0.003% again on the full new order total.

5.2 Order structure [Proposed]

Order {
    version,
    marketId,          // market chain NFT id
    orderChainId,      // this order's order chain NFT id
    owner,
    side,              // BUY / SELL
    baseAsset,
    quoteAsset,
    quantityLots,
    limitPriceTicks,   // worst acceptable fill price (excluding fees)
    minFillLots,
    maxLotsPerBatch,   // per-batch cap (order splitting); 0 = market default
    timeInForce,       // GTC / GTD / IOC
    fastLane,          // fast lane on or off
    maxPoolFeeBps,     // highest acceptable LP fee rate on the fast lane
    validUntilBatch,   // last market-chain batch (nonce) in which a fast order is valid
    expiry,            // absolute unix seconds, judged on the cited L1 block time
    receiveTipIds,     // receiving asset chains (Section 4.4)
    feePolicyHash,
    nonce
}

domain = {
    name: "CoNET-DLE-Market",
    version: "1",
    chainId: 224422,
    verifyingContract: MarketRegistry   // market registry contract on L1
}
orderHash = EIP712Digest(domain, Order)

• A matcher cannot swap assets, raise quantity, loosen the price, extend validity, change receiving chains or replay a used nonce.
• There is no market order without a price limit. Immediate execution uses a fast-lane order or an IOC order with a worst price.
• Time is judged only from order fields and cited L1 block times, never from a miner's local clock [DLE current] (DLE §10.1).

5.3 Order-chain state machine [Proposed, needs DLE revision R2]

States: None=0, Open=1, PartiallyFilled=2, Filled=3, Cancelled=4, Expired=5, Closed=6.

The market chain is authoritative for remaining quantity. The order chain follows it, for public lookup, asset-chain checks and release.

5.4 Order types

5.5 Integer prices and quantities

Each market fixes lotSize, tickSize and price limits. Fill amount = lots × priceTicks × tickSize, all integer arithmetic. Example: GB (9 decimals) against conet-USDC (6 decimals), lotSize = 10^9 (1 GB), tickSize = 1 (0.000001 conet-USDC); a price of 0.0102 is priceTicks = 10200. Every fee is rounded up in the token's smallest unit (Section 9.2).

6. Splitting and matching

6.1 Batches

DLE's rule is "no event, no block" [DLE current] (DLE §3.2). One block on the market chain is one matching batch. Processing order within a batch:

1. Admit newly opened order chains (citing their genesis ACs) and process the inbox. Record this batch's cancels and amendments; they apply only to orders that existed before this batch and run after this batch's fills (Sections 4.5 and 5.1a).
2. Compute the batch reference price (Section 10.4).
3. Fast lane: process fast-lane orders one by one, comparing pools and book orders together (Section 10.5).
4. Batch auction: run the uniform-price auction on the remaining ordinary orders (Section 6.4).
5. Output fillsRoot, bookRoot, the reference-price curve and the state root.

6.2 Inclusion and censorship resistance

Matching is deterministic. The only thing a matching miner controls is which orders to include, and selecting proposals by fill volume makes a proposal that leaves orders out lose (Section 6.6).

• L1 inbox fallback: a placer may submit an order chain's genesis reference or a cancel to an L1 inbox. The market chain must consume the inbox in order. An entry not consumed within T_inbox can go to DLE's archive censorship challenge (DLE §6.4 ArchiveCensorshipChallenge) [Proposed].
• Many competing miners, rotating committees: orders go over L0 to every idle matching miner, and each batch draws a new consensus committee. A matching miner that leaves out an order only lets a more complete competitor win.
• Aligned incentives: miners earn by fill amount, so leaving out a fillable order means losing its matching fee.

The matching miner decides the order of fast-lane orders in its proposal, which leaves room to reorder. Mitigations: a per-batch cap on fast-lane orders by count and amount, and ordering by order hash plus a batch random seed (Appendix B, B-4).

6.3 Order splitting

"Splitting" has four meanings here:

1. Across batches: each batch's total fill is at most B_max, and maxLotsPerBatch caps each order per batch; the rest carries over.
2. Across counterparties: a fast-lane order can take several pools and several book orders at once (Section 10.5).
3. Across LPs in a pool: a pool fill is spread over many frozen asset chains by LP share (Section 10.6).
4. Across asset chains: each fill's payments and receipts split into parallel transfers on many asset chains (Section 4.3, Chapter 7).

Splitting does not change the order signature or add fees. Cumulative fills of each order are recorded on the market chain and the order chain and never exceed quantityLots. All splitting rules are deterministic, so a matching miner cannot choose who gets the volume. B_max is also the market-chain counterpart of DLE's committee cumulative-exposure rule E_C ≤ E_max (DLE §12.3.2); how it counts is pending (Appendix B, B-8).

6.4 Ordinary orders: frequent batch auction [Proposed]

1. Candidate prices are the limit prices of all participating orders.
2. For each candidate price p: demand D(p) is the remaining quantity of buy orders with limit ≥ p; supply S(p) is the remaining quantity of sell orders with limit ≤ p; fillable volume V(p)=min(D,S), subject to B_max and maxLotsPerBatch.
3. The clearing price maximizes V(p). Ties go, in turn, to the smallest |D-S|, the price nearest the reference price, then the lower price.
4. If the clearing price is more than priceBandBps from the reference price, this batch fills only inside the band.
5. Orders better than the clearing price fill completely. At the marginal price, allocation goes to orders admitted in earlier batches first, then pro rata by remaining quantity within a batch, with leftover lots allocated by ascending keccak(orderHash ‖ batchSeed), where batchSeed comes from L1 beacon randomness.
6. Every fill executes at the clearing price.

The order of arrival within a batch does not change the clearing price, so a matching miner cannot front-run by reordering. Switching to continuous matching within a batch is pending (Appendix B, B-3).

6.5 Self-trade prevention

When buy and sell orders of the same owner would both fill in one batch, the later-admitted one sits out that batch. The same applies between an owner's pool liquidity and their own fast-lane order (Section 10.6).

6.6 Racing to match: idle light miners compete, consensus miners keep it safe [Decided] (2026-10-26)

Operator decision: order matching is done by all idle miners, who race to match first for profit and so bring trades about, while consensus miners maintain security. The operator also decided that the matching miner receives the 0.007% and the consensus miners share the 0.01% transfer fee; that the proposal with the largest fill volume wins, with ties going to the first to arrive; and that becoming a light miner requires staking CNET, with a cost for invalid proposals.

Matching proposal [Proposed]

MatchProposal {
    marketId, batchNonce, parentStateRoot, l1BlockNumber,
    includedOrderRefs[], cancels[], amendments[], poolRefs[],
    referencePriceTicks, clearingPriceTicks,
    fillsRoot, bookRoot,
    totalFillQuote,        // this proposal's fill volume, in the quote asset
    matcher, matcherStakeRef, signature
}

Flow

1. Orders, cancels and amendments are broadcast over L0 to every idle matching miner.
2. Each matching miner starts from the same parent state, chooses which orders to include, computes the result with the deterministic rules, and signs and submits its proposal.
3. The batch's consensus committee collects proposals until the cut-off and recomputes each one independently. A proposal whose result differs from its claims, cites an invalid order, or fails a precondition is invalid.
4. Among valid proposals, the one with the largest fill volume (totalFillQuote) wins [Decided]. Ties go to the one the consensus committee received first [Decided], then to the lower proposal hash.
5. The winning proposal becomes the batch's Batch event: 5 of 7 sign it under the normal DLE flow, and the archive group replays it and forms the AC.
6. When settlement completes, the 0.007% matching fee is credited to the winning matching miner; a voided fill pays nothing.

Cost of an invalid proposal [Decided principle, proposed method]. Each proposal carries a stake reference. A proposal ruled invalid for a reason any third party can recheck (a recomputation mismatch, a missing or expired order, a bad signature) loses a DAO-set share of its submitter's stake, and the submitter may not propose for a number of batches. A valid proposal that loses only because its volume was smaller or it arrived later is not penalized.

Why this design

• Matching is deterministic: for a given set of included orders, there is exactly one result. Matching miners can only compete on how many fillable orders they include. "Largest fill volume wins" rewards the miner who includes more orders and brings about more trades.
• A proposal that leaves orders out loses to a more complete competitor, which makes censorship harder.
• Confirmation is separate from matching: consensus miners do not race for matches, and a matching miner cannot confirm its own result.
• The number of matching miners is not capped; the more idle miners, the stronger the competition.
• Fund safety does not depend on matching miners: a wrong or forged result fails consensus recomputation and the paying asset chain's check of signatures and freezes (Section 7.1).

Boundaries and risks

• "First to arrive" uses the consensus committee's own receive order, which outsiders cannot verify; it matters only for ties.
• A consensus committee could unfairly drop some proposals. Proposed mitigation: matching miners send each proposal to every committee member, and each member attaches to its signature the hash of the largest valid proposal it received, for later review (mechanism pending, Appendix B, B-23).
• One operator could control both a matching miner and consensus miners; role registration and conflict-of-interest rules are needed (DLE OperatorDomainRegistryV1).
• Many proposals consume the committee's recomputation capacity; the stake threshold, penalties and a per-miner per-batch proposal cap limit this.
• The matching miner decides the order of fast-lane orders in its proposal (Section 6.2).

7. Settlement: parallel DLE transfers [Decided] (2026-10-25)

Operator decision: at fill, miners submit many transactions in parallel, and DLE completes the transfers.

7.1 Two-phase transfer [Proposed, needs DLE revisions R4, R5]

One fill involves at least two paying asset chains and two receiving asset chains. DLE has no cross-chain calls, so this paper uses two phases to ensure that either both sides settle or neither does.

Phase 1: debit to in-flight. Miners submit a LegDebit event on each paying asset chain, citing the market batch AC, the fill's position in fillsRoot, and the order chain. The debit = this chain's share of the fill amount + this side's fees (Section 9.2). The asset chain's state machine checks on its own that:

• the debited balance is frozen for this order chain;
• the order signature is valid, the fill price is no worse than the limit, and cumulative fills do not exceed the order quantity;
• fees follow the fee-policy version the order committed to;
• this fill has not been debited on this chain before (the fill id is the replay guard).

If so, the amount moves from available balance to in-flight.

Phase 2: credit or refund.

• Once every LegDebit of a fill has an AC, miners submit LegCredit on each receiving asset chain. The matching fee is credited to the matching miners, the LP fee to the LPs' asset chains, and the DLE transfer fee is allocated by DLE rules. Each paying asset chain submits LegFinalize to clear its in-flight record.
• If a debit is not done within T_leg, the asset chains already debited submit LegRefund with timeout evidence and return the in-flight amount. The fill is void and no fee is charged.

The asset chain's checks do not rely on the market chain being honest. Even if the committee and archive group of a market batch are both captured, a forged fill fails the paying asset chain's own check of the order signature and freeze record. Stealing funds also requires capturing the archive group hosting the paying asset chain.

7.2 Parallelism and merging

• Events on different asset chains do not queue behind each other and can run in parallel.
• Several fills touching the same asset chain in one batch merge into one event.
• A credit may open new asset chains (Section 4.4).

7.3 Receipts and order-chain updates

After every phase-2 event completes, the market chain observes the receipts in a later batch and marks the fill Settled; the order chain updates its cumulative fills. When a fill is voided, the market chain restores the remaining quantity of the honest side and records a failure for the defaulting side (usually the owner of an asset chain that requested a forced exit).

7.4 Cap on unsettled depth

When matched-but-unsettled fill value on a market chain reaches K_unsettled, the state machine refuses new matches and handles only cancels and receipts.

7.5 Execution cost

Each fill produces at least four asset-chain events (two debits, two credits), plus order-chain updates. Each event needs a DLE committee draw and an AC. Merging same-chain events, raising minimum fill size and encouraging users to consolidate asset chains all lower costs. Real costs are not measured.

These are execution costs of committee draws, votes and ACs. Percentage fees are computed on amounts and do not grow with the number of events (Section 4.3).

8. Market-chain state machine [Proposed, needs DLE revision R1]

8.1 States

None=0, Open=1, Halted=2 (circuit breaker: cancels and receipts only), DrainOnly=3 (delisting transition), Closed=4.

8.2 Events

The Batch payload, in order: l1BlockNumber, l1BlockHash, inbox range and accumulator, genesis AC references of newly admitted order chains, cancels and amendments, pool references (pool storage-chain AC and state root), settlement-receipt references, batchSeed, referencePriceTicks, clearingPriceTicks, fillsRoot, bookRoot, priceCurveRoot. Event ids and error codes are assigned by the DLE revision.

8.3 Transition rules (summary)

If any precondition fails, the whole batch is rejected with no partial write [DLE current] (DLE §10.1).

8.4 State-root paths (minimum)

/state, /nonce, /params, /referencePriceTicks, /priceCurve/<batchNonce>, /book/bids/<price>/<orderChainId>, /book/asks/<price>/<orderChainId>, /orders/<orderChainId>/remainingLots, /orders/<orderChainId>/status, /pools/<poolId>/stateRootRef, /fills/<batchNonce>, /unsettled, /failures/<owner>.

9. Fees

9.1 Decided fee rules (2026-10-25)

9.2 Who pays what

Every percentage fee is computed and paid in the payer's own outgoing token [Decided]. The base is the filled amount in that token [Proposed]: for the seller, the filled quantity in the base asset; for the buyer, the filled quote amount. Each fee is rounded up in the smallest unit and computed once per fill (one order against one counterparty), regardless of how many asset chains carry it.

Formulas, with Q the order total and A the payer's outgoing amount in this fill, both in the payer's outgoing token:

prepayment       = ceil(3 × Q / 100,000)
matching fee     = ceil(7 × A / 100,000)
DLE transfer fee = ceil(A / 10,000)
LP fee           = ceil(A × feeBps / 10,000)

When an order fills completely, the placer pays about 0.003% + 0.007% + 0.01% = 0.02% in total, excluding any LP fee. On a partial fill or a cancel, the prepayment still applies to the full order total.

The frozen funds must cover: the maximum outgoing amount + prepayment + matching fee + DLE transfer fee + the highest LP fee (at maxPoolFeeBps).

Fee transfers themselves are not charged further fees [Proposed].

9.3 Effects of paying fees in the placer's token

• Miners, archive groups and LPs receive fees in several tokens: sellers pay in the base asset, buyers in the quote asset.
• LPs receive the placer's token (fill proceeds and the LP fee). They can trade it into other tokens on DLE's trading pools [Decided].
• Fees do not depend on conet-USDC and need no oracle conversion. Pools can open on any pair, and LPs need no conet-USDC fee reserve.
• This differs from the current DLE §13.2 rule ("asset transfer fees are oracle-valued and paid in conet-USDC"), and DLE must be revised to match (R7).

9.4 Fee allocation

Computed separately for each token. Dust among validators goes by ascending address (DLE §13.4). The matching fee is credited to the matching miner when settlement completes; a voided fill pays nothing.

DLE currently splits its 1 bp protocol fee 50/50 between the archive group and validators (DLE §13.4). Here the whole matching fee goes to the matching miner, the DLE transfer fee is shared by consensus miners, and the prepayment goes to order-chain validators. This needs confirmation in a DLE revision (R8).

9.5 Income illustration

Matching miners (0.007% matching fee)

Units are quote-asset equivalent. Sellers pay the matching fee in the base asset, converted here at the fill price. All of it goes to each batch's winning matching miner.

Order-chain validators (0.003% prepayment): computed on the total amount of orders placed, not on volume. With 1,000,000 in daily order totals, about 30. Orders later cancelled or expired count too.

None of this is an income forecast.

9.6 Are incentives aligned?

• Matching miners compete on fill volume: only a proposal that includes more fillable orders wins, and leaving orders out loses to a competitor, so censorship has a cost.
• Invalid proposals lose stake, so spamming proposals has a cost.
• Matching and the reference price are deterministic, so miners cannot earn more by changing results.
• The matching fee is credited only after settlement, so miners have a reason to submit settlement events promptly.
• The prepayment is not refunded, so spam orders and repeated place-and-cancel have a cost. Order-chain validators earn from order flow and matching miners earn from volume, separately.
• Matching and transfer fees together are low, so wash trading is also cheap. Volume statistics should say so.

10. Liquidity pools and the fast-trade fee

10.1 Decided items (2026-10-25)

An external discussion the operator referenced suggested "order book + LP auto-quoting vault + unified splitting + atomic settlement", with request-for-quote later. This chapter takes from it the idea of turning LP funds into executable quotes compared with ordinary orders. The "vault" here is made of LP asset chains frozen in DLE; the funds never leave the LP's own asset chains.

10.2 What a pool is

A liquidity pool is a registration record on a DLE storage chain [Decided]:

PoolRecord {
    poolId,
    creator,
    marketId,                 // trading pair
    feeBps,                   // LP fee rate set by the creator; at least the 1 bp DLE transfer fee
    priceLow, priceHigh,      // price range: the pool quotes only while the reference price is inside it
    lpEntries[] {
        lp,
        assetTipId,           // asset chain the LP froze into the pool (each ≤ 100 USDC)
        asset,                // base or quote asset
        frozenAmount,
        freezeAcRef
    },
    sharesByLp,
    stateRoot
}

• The pool holds no funds. Funds stay on each LP's own asset chains, frozen for the pool.
• Storage chains pay storage and retention fees in conet-GB under DLE rules [DLE current] (DLE §4.2). Who pays the pool record's storage fee is pending (Appendix B, B-12).
• Pool parameters are set at opening. Whether they can change later is pending (Appendix B, B-13).

10.3 Opening, joining and leaving

• Open: anyone creates a PoolRecord on a storage chain, with no permission and no DAO approval [Decided]. The pair must be a listed market.
• Search: pool records are public on DLE. Wallets and miners can search by pair, fee rate, range, size and fill history.
• Join: the LP signs FreezeForPool{poolId, amount} on their own asset chain and, once it has an AC, is added to the pool record. Joining a pool does not open an order chain.
• Leave: the LP requests withdrawal. It takes effect after the next market batch finishes its fast-lane orders [Decided: the taker goes first], and the freeze is released against that batch's AC. If the market stalls for T_unfreeze, the LP may release directly.

10.4 Reference market price [Decided principle, proposed rule]

The operator decided that DLE computes and broadcasts a trade-price curve, and that miners collect orders as evidence and update it in real time. This paper writes that as ReferencePriceV1, computed deterministically in every batch:

1. Trade-price curve: the market chain records each batch's clearing price and fast-lane fill prices as a volume-weighted curve, written to the state root and broadcast over L0.
2. Order evidence: the best bid and best ask on the book at the start of the batch. Every book order has an order chain and frozen funds behind it, so these prices are evidence that someone is willing to trade with real money. Only orders of at least minEvidenceLots count.
3. Calculation:
   • If both best bid and best ask exist and the spread is at most maxSpreadBps, the reference price is their midpoint.
   • Otherwise, it is the volume-weighted average over the last N_ref batches.
   • The result is clamped to that volume-weighted average ± refBandBps.

The book is never crossed after a batch. Raising the midpoint requires opening an order chain and freezing real funds for a higher bid, which anyone may then fill. With the clamp in step 3, there is limited room to push the reference price and then extract value from pools. Parameter values are pending.

10.5 Matching a fast-lane order

At the start of a batch, fast-lane orders are processed one by one. For each fast-lane buy order:

1. Candidate sellers: book sell orders (at their limit prices) and every eligible pool. A pool is eligible if the reference price is inside [priceLow, priceHigh], feeBps ≤ maxPoolFeeBps, and the pool has base asset available. A pool fills at the reference price, with the LP fee paid on top [Proposed].
2. Unified comparison: fill from the lowest real cost to the user upward, until the order is filled, the fill price would exceed the limit, or a per-batch cap is reached [Decided: the better price for the user wins]. A pool's real cost is reference price × (1 + feeBps). A book order's real cost is its limit price (the matching and transfer fees are the same on both sides and do not affect the ranking). On a tie, book orders fill before pools, and pools go by ascending poolId.
3. Unfilled remainder: an IOC order is void. A GTC order keeps being processed as a fast-lane order in later batches until validUntilBatch or expiry, and is then void.

A fast-lane sell order is symmetric: a pool's real proceeds are reference price × (1 − feeBps), and the LP fee is paid in the base asset the placer sends.

"Fast" means the order fills in the next batch at the best available price, without waiting for a counterparty to appear or for the auction to finish. Settlement still uses the two-phase transfer of Chapter 7 and completes in the same time as an ordinary fill.

10.6 Spreading a pool fill across LPs

A pool fill debits LPs' frozen asset chains and credits LPs' asset chains [Decided: miners submit many transactions in parallel and DLE completes the transfers]:

• Share: an LP's share in an asset = the LP's frozen amount of that asset / the pool total of that asset.
• Allocation: a pool sale of base asset is spread by base-asset share. The quote asset the placer pays, plus the LP fee, is credited to LPs in the same proportions. Leftover lots go by ascending LP address.
• LP transfer fee: each LP pays 0.01% DLE transfer fee on its total outgoing amount in this fill, in the token it sends (the base asset when the pool sells), taken from its frozen funds. An LP whose outgoing amount spans several asset chains pays once, on the total [Decided].
• Minimum allocation: an allocation below minLegLots goes to the next LP instead, to avoid many tiny transfers; leftovers rotate (Appendix B, B-14).
• Inventory: after a pool sells base asset, the LP's base asset falls and its quote asset rises. An asset chain holds one asset, so the quote asset is credited to the LP's quote-asset chain registered in the pool, or to a new asset chain if none is registered. Credited assets are frozen into the pool automatically and quote in the opposite direction.

10.7 Fast-order validity [Decided: double bound by batch count and L1 time]

A fast-lane order is bounded by both validUntilBatch (market-chain nonce) and expiry (L1 time), whichever comes first. A batch-only bound can last a long time in a quiet market; a time-only bound can span many batches in a busy one. The DAO sets both caps (Appendix A).

10.8 Withdrawal against a taker in the same batch [Decided: the taker goes first]

When an LP's withdrawal request, a creator's parameter change (if allowed) and a fast-lane order meet in one batch, the fast-lane order runs first and the withdrawal or change after it. LPs tend to withdraw exactly when the price moves against them; if withdrawals ran first, fast-lane orders would miss exactly when they matter most. LPs are compensated by the LP fee, the price range, and being able to leave in the next batch.

10.9 LP returns and the fee floor

Fee floor [Proposed]. The LP fee is feeBps of the filled amount; the LP's DLE transfer fee is 0.01% of its outgoing amount. The two amounts are close but in different tokens. To ensure coverage, feeBps may not be below 1 bp at pool opening, or the pool is rejected. At exactly 1 bp almost all of the LP fee goes to the transfer fee, so creators should leave a margin.

LP net result = fill and inventory gain or loss + LP fee − DLE transfer fee − other own costs. In a one-way market, a pool keeps selling the asset that is rising or buying the one that is falling, and LPs can lose money overall. The pool-entry interface must say so plainly.

10.10 Risks

11. Performance and parallelism

• Parallel across pairs and asset chains: each chain advances with its own committee. More archive groups can host more chains.
• Serial within a pair: a market's batches advance in nonce order.
• Number of order chains and settlement events: one order chain per order, and at least four asset-chain events per fill, more for pool fills. Throughput of chain opening and settlement depends on L1 NFT minting, committee draws and AC speed.
• New committee per event: DLE currently draws a new committee for every block (DLE §6.1). Whether one committee may serve several events needs a DLE revision (Appendix B, B-15).
• No throughput or latency claims: the Received, Matched and Settled latencies must each be measured in a pilot.

12. Security and market integrity

With all funds in DLE, safety rests mainly on DLE itself: committee sampling, an honest majority in archive groups, data availability, and the 100 USDC direct-loss cap per asset chain [DLE current] (DLE §12.2). The safety of a fill's funds comes from the paying asset chain checking the order signature and freeze record itself (Section 7.1).

Until the archive production blockers close (a second independent implementation, production networking, key custody and more), none of the AC-dependent conclusions above hold (DLE §5.2.1; archive conformance specification §11).

13. Governance

• Listing and parameters: listing, delisting, halting and resuming pairs, and lotSize, tickSize, B_max, priceBandBps, reference-price parameters, fast-order validity caps, K_unsettled, the light-miner stake threshold, the invalid-proposal penalty and similar, are decided by DAO proposal and vote. Parameter changes name a future effective batch and do not apply to order chains already opened.
• Liquidity pools: opening a pool needs no permission and no DAO approval [Decided]. The DAO sets only global limits (for example the per-pool per-batch cap, the minimum allocation and the feeBps floor).
• No admin: the market registry contract, market-chain parameters, order chains and pool records have no admin role and no privileged address that can move user or LP funds [Proposed, following the GB system's decision that admin roles do not exist and are folded into DAO management].
• Upgrading the L1 market registry: the proposal is no upgradeability; if upgradeability is kept, it requires a DAO vote with a code hash and a public timelock (Appendix B, B-16).

14. Relationship to GB economics

• The exchange only matches existing assets between users. It mints and burns no tokens, holds no reserves, and does not change GB's paid issuance, exit, official rate R or coverage rules.
• The liquidity pools here are made of user funds and have nothing to do with the treasury. The pool and AMO rules of the GB AMM whitepaper are unaffected; arbitrage closes price gaps between the two.
• A placer selling GB pays every fee in GB, so miners, archive groups and LPs receive GB. These are transfers between users and do not change GB supply.
• Whether the treasury or AMO may place orders or join pools here is outside this paper and would need its own proposal.
• Free GB cannot be listed.

15. Phased launch and release gates

Mapping to the design study's release gates:

Appendix A — Parameters

Appendix B — Open items

Appendix C — Examples

Pair GB / conet-USDC with the parameters of Section 5.5. All figures are for illustration only.

C.1 Two book orders filling each other (batch auction)

Clearing price 0.0102, 2,500 GB filled: Bob 500 and Carol 1,000 in full, Dave 1,000 (1,000 stays on the book), Erin unfilled.

Prepayments (paid when each order chain opened, in the placer's token, to its validators, not refunded on cancel):

Erin does not fill in this batch and Dave fills half; their prepayments do not change.

Fees at fill (each placer pays the 0.007% matching fee and the 0.01% DLE transfer fee in their own outgoing token):

Alice's matching fee is computed per fill: 0.000357 + 0.000714 + 0.000714 = 0.001785.

Matching fees in this batch: 0.001785 conet-USDC and 0.175 GB, all to the matching miner whose proposal won the batch. Converted at the fill price, that is about 0.014% of the 25.5 filled. The DLE transfer fees of this batch are shared by the consensus miners.

Settlement: Alice froze one asset chain holding 30 conet-USDC. Phase 1: Alice's asset chain debits 25.504335 to in-flight; Bob's, Carol's and Dave's GB asset chains debit 500.085, 1,000.17 and 1,000.17 GB. Phase 2: Bob, Carol and Dave's receiving asset chains are credited 5.1, 10.2 and 10.2 conet-USDC; Alice's receiving asset chain is credited 2,500 GB (about 25.5 USDC equivalent, within the 100 cap); fees are credited by the rules. If Carol's debit times out because of a forced exit, Carol's fill is void, Alice's 10.2 + 0.000714 + 0.00102 = 10.201734 conet-USDC for it is refunded, and the other two fills complete. Nobody's prepayment is refunded.

C.2 Fast lane and a liquidity pool

After the batch, the best bid is 0.0098 (Erin) and the best ask 0.0102 (Dave's remaining 1,000 GB). The spread is about 4%, above the example maxSpreadBps of 1%, so the reference price falls back to the recent volume-weighted average, taken as 0.0102.

Pool P: LP fee 0.05%, price range 0.0095–0.0110. LPs: Ann froze 30,000 GB (about 306 USDC equivalent, across 4 asset chains), Ben froze 10,000 GB (about 102 USDC equivalent, across 2 asset chains). Each also registered one conet-USDC asset chain in the pool to receive proceeds.

In the next batch, Gina submits a fast-lane buy of 3,000 GB, limit 0.0104, maxPoolFeeBps 0.1%:

1. Comparison: Dave's ask costs 0.0102; pool P costs 0.0102 × 1.0005 = 0.010205. Dave's 1,000 GB fills first, for 10.2.
2. Pool fill: the remaining 2,000 GB fills from pool P at the reference price 0.0102, for 20.4.

Gina's fees (in conet-USDC). At placement she prepaid 0.003% of her order total 3,000 × 0.0104 = 31.2, that is 0.000936. At fill:

Gina pays 30.615402 conet-USDC at fill, 30.616338 including the prepayment, an all-in average price of about 0.0102054.

Dave's fees (in GB): matching fee 0.07 GB, DLE transfer fee 0.1 GB, total sent 1,000.17 GB; he receives 10.2 conet-USDC. His prepayment was paid at placement.

Spreading the pool fill (by GB share: Ann 75%, Ben 25%):

Ann's 0.15 GB transfer fee is about 0.00153 USDC at the reference price; after the 0.00765 conet-USDC LP fee covers it, about 0.00612 USDC equivalent remains. Ben keeps about 0.00204. With a 0.05% LP fee, five times the transfer-fee rate, about 80% of the LP fee stays with the LPs. Ann's and Ben's conet-USDC is frozen into the pool automatically for quotes in the opposite direction; they can trade it into other tokens on DLE trading pools.

Matching fees in this batch: Gina's 0.002142 conet-USDC and Dave's 0.07 GB. Order-chain validators: Gina's order chain received her 0.000936 conet-USDC prepayment. LPs do not open order chains and pay no prepayment.

Appendix D — Glossary

Appendix E — Revision history