Application-Specific Ordering (ASO)

Application-Specific Ordering (ASO) lets developers influence how transactions are ordered within each miniblock.
It’s designed for apps that need fine-grained control over execution order—like matching engines, auctions, or sequenced interactions—without sacrificing throughput or decentralization.

Application Specific Ordering is available via the Priority event in Solidity.

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.

How It Works

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

• Once validated, the miniblock is finalized, state is updated, and preconfirmation proofs are attached.

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.

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.