# How does TokaDex handle order book ordering and UTXO splitting/recomposition in the UTXO model?

**URL:** <https://forum.nexa.org/t/how-does-tokadex-handle-order-book-ordering-and-utxo-splitting-recomposition-in-the-utxo-model/1725>\
**Category:** Help\
**Created:** [July 29, 2026, 8:10am UTC](https://forum.nexa.org/t/how-does-tokadex-handle-order-book-ordering-and-utxo-splitting-recomposition-in-the-utxo-model/1725 "2026-07-29T08:10:12Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![aiya](https://forum.nexa.org/letter_avatar_proxy/v4/letter/a/9de053/32.png) [@aiya](https://forum.nexa.org/u/aiya)\
**Post date:** [July 29, 2026, 8:10am UTC](https://forum.nexa.org/t/how-does-tokadex-handle-order-book-ordering-and-utxo-splitting-recomposition-in-the-utxo-model/1725/1 "2026-07-29T08:10:13Z")

</div>

Hi everyone,

I’ve been following the TokaDex roadmap closely and have two technical questions I’d love to get the developers’ perspective on:

1. Order book priority in the UTXO model

In an account-model chain (e.g., Hyperliquid), the order book is essentially a shared mutable state — the contract maintains a sorted order list, and ordering (price-time priority) is straightforward. But in the UTXO model, where each order would presumably exist as an independent UTXO, how does TokaDex plan to maintain a consistent, globally ordered order book? Specifically:

How does a taker discover and sort open orders across the UTXO set?  
What determines price-time priority when the orders are scattered across discrete UTXOs rather than stored in a single contract?  
Does the consensus layer itself enforce ordering, or is this handled at the application/tx construction level?  
2. Splitting and recomposing UTXOs during partial fills and cancellations

A core challenge with UTXO-based trading: every order modification involves destroying old UTXOs and creating new ones. This seems particularly tricky for:

Partial fills: a sell order for 1,000 tokens gets filled for 300 — the original UTXO needs to be split into two new UTXOs (the filled portion and the remaining 700). Is this handled atomically within a single transaction? What are the gas/complexity implications?  
Order cancellations: canceling an open order means consuming the order UTXO — does the user need to pay a transaction fee just to cancel? Is there any mechanism to batch or amortize this cost?  
High-frequency order updates: if a market maker wants to adjust their bid/ask frequently, each update would be an on-chain transaction consuming and recreating UTXOs. Is this practical at any meaningful frequency on Nexa?  
Would really appreciate any insight from the devs — especially around how Read-Only Inputs and Native Tokens are expected to interact with these scenarios in TokaDex’s architecture.

Thanks!