Skip to main content
Most blockchains enforce a single, global transaction ordering model. This works for simple transfers, but breaks down for applications that require deterministic sequencing, such as trading engines, auctions, liquidations, or any workflow where order directly affects outcomes. ASO gives developers a native way to express ordering intent — and gives users more predictable, fair execution.

​
Why This Matters

​
For Builders:

ASO enables builders to design applications that would otherwise require:
  • centralized matching engines
  • off-chain sequencing
  • trusted relayers
  • complex MEV workarounds
With ASO, builders can:
  • enforce deterministic execution order when needed
  • reduce race conditions and edge-case exploits
  • simplify application logic
  • keep execution fully onchain and permissionless
This unlocks onchain-native designs that previously weren’t viable without centralization.

​
For Users

For users, ASO translates into:
  • fairer execution
  • fewer surprise reorders
  • more predictable outcomes
  • reduced hidden MEV effects
Whether trading, bidding, or interacting with sequenced workflows, users benefit from applications that behave consistently even under load.

​
How ASO Works

ASO is implemented using a lightweight ordering hint mechanism embedded directly in transactions. Applications emit a Priority event to express ordering intent for their own transactions. Fiber validators understand this signal and respect it during block construction. This process:
  • applies only within the emitting contract
  • does not give global ordering power
  • preserves network-wide decentralization and throughput

​
Using ASO in Solidity

Application Specific Ordering is available via the Priority event in Solidity.
Priority.sol
contract Main {
    function doSomething(uint256 priority) public {
        emit Priority(priority);
    }
}
The Priority event is understood by Fiber validators. Validators use a double-pass block building process to respect application-provided ordering while preserving correctness and throughput. Each validator builds miniblocks in two passes to ensure correctness and consistency.

​
1. Receive transaction

  • The validator accepts transactions into its local queue.

​
2. First-pass simulation (tx-level validation)

  • Each transaction is dry-run to check nonce, balance, intrinsic gas, and to collect emitted events (such as Priority).

​
3. Extract ordering intents

  • The validator parses ordering events and organizes them into intent sets, grouped by namespace (the emitting contract address).

​
4. Assemble a miniblock candidate

  • Transactions are selected based gas fees first, then ordering priorities.

​
5. Simulate the miniblock

  • The full miniblock candidate is simulated end-to-end to verify that all ordering constraints can coexist safely.

​
6. Resolve conflicts

  • Any conflicting or invalid transactions (for example, incompatible priorities or invalidated balances) are deferred to the next miniblock.

​
7. Seal the miniblock

​
Why a Double-Pass?

The double-pass model ensures effective ordering while preserving correctness and throughput even in high traffic conditions.

​
Ordering Semantics

​
Namespacing

  • Priorities are scoped per contract.
    Two contracts can emit identical priorities without interference.

​
Priority Rules

  • Higher priority values execute earlier within the same namespace.
  • Ties are broken by fee and hash ordering.
  • Transactions are never reordered across priority boundaries.

​
Safety

  • If a transaction’s ordering intent conflicts with higher-priority or invalid state conditions,
    it’s deferred to the next miniblock.

​
Cross-Contract Independence

Ordering applies only within each contract’s namespace. Different contracts operate independently.
ContractTxPriorityResult
AtxA110before txA2
AtxA25after txA1
BtxB11independent of A’s order
Validators can interleave transactions from different contracts freely.

​
Developer Tips

  • Use ordering hints only when explicit sequencing matters.
  • Avoid emitting conflicting priorities for the same miniblock.
  • Keep transactions idempotent - a deferred tx might be retried in the next miniblock.

​
Why This Is Different

ASO is not:
  • a global sequencer
  • an MEV auction
  • an off-chain ordering service
It is a native protocol primitive — designed to give applications just enough control, without compromising the network.