> For the complete documentation index, see [llms.txt](https://docs.moduluszk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.moduluszk.io/economics-fees-and-state/ordering-and-what-users-would-see.md).

# Ordering, and what users would see

The fee design carries no ordering-based priority tip. The recommended answer to contention for pooled state is uniform per-block clearing, which removes intra-block ordering, and a priority tip is an ordering instrument; a design cannot carry both \[A]. That answer is part of the conditional recommendation, and the concurrency design as a whole is documented when it is settled. 

One user-facing consequence is available if the recommended transaction architecture is adopted. Where third parties compose users' partial transactions into complete ones, the composer can pay the network fee and take settlement in whatever the user already holds; an existing production system does exactly this today \[S]. A required fee asset can then be mandatory at the protocol level and invisible at the user level \[A]. This is a property of an architecture that is itself open, and it is recorded here as a consequence, never as a promise.