Hi everyone,
I’ve been following the TokaDex roadmap closely and have two technical questions I’d love to get the developers’ perspective on:
- 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!