Crypto Gloss

Fuel: The Fastest Modular Execution Layer

Authors Fuel Labs
Year 2022
Project Fuel Network
License Apache-2.0
Official Source https://docs.fuel.network/docs/about-fuel/

This page is an educational summary and analysis of an official whitepaper or technical paper, written for reference purposes. It is not a verbatim reproduction. CryptoGloss does not claim authorship of the original work. All intellectual property rights remain with the original author(s). The official document is linked above.

Fuel is a modular execution layer for Ethereum described in Fuel Labs’ 2022 technical documentation. Fuel v2 is designed as a rollup — it uses Ethereum (or another data availability layer like Celestia) for data publication and settlement, while providing its own high-performance execution environment.

Fuel’s core claim: the UTXO-based execution model is superior for parallelism because UTXOs have explicit ownership (each UTXO belongs to exactly one transaction at a time) — allowing the execution engine to process independent transactions simultaneously without conflicts. This contrasts with account-based models (Ethereum EVM) where global mutable state requires sequential transaction processing within a block.

Supporting this is the FuelVM — a purpose-built virtual machine — and Sway — a domain-specific smart contract language. Together, these give Fuel a high-performance execution stack that can run as a rollup publishing proofs to Ethereum.

> Documentation: docs.fuel.network

Publication and Context

Fuel Labs developed the original Fuel v1 (2020) as the first optimistic rollup on Ethereum testnet, predating Optimism’s mainnet. Fuel v1 was a minimalist optimistic rollup with limited scripting capabilities.

Fuel v2 (2022–2024) is a complete redesign: a multi-asset UTXO rollup with a custom VM, custom language, and full modular architecture. Fuel v2 is built to be used as a component in modular blockchain stacks — it handles execution, while other layers handle data availability, settlement, and consensus.

The modular blockchain thesis (associated with Celestia, EigenDA, Avail) was gaining traction in 2022. Fuel positioned itself as the execution specialist in this modular stack: not a sovereign blockchain but an ultra-optimized execution environment deployed over any DA layer.

UTXO-Based Execution and Parallelism

Why UTXOs Enable Parallelism

In a UTXO model (Bitcoin’s model), each transaction consumes specific prior outputs and creates new outputs. The inputs and outputs of each transaction are explicitly declared:

TX_1: Consumes UTXO_A, UTXO_B → Creates UTXO_C, UTXO_D
TX_2: Consumes UTXO_E, UTXO_F → Creates UTXO_G

If TX_1 and TX_2 consume different UTXOs (no overlap), they are independent and can execute in parallel. The execution engine can detect this by inspecting the declared inputs — before executing either transaction.

In an account model (Ethereum’s model), transaction execution requires reading global state (account balances, contract storage). Two transactions both calling the same contract may or may not conflict — you can only know after execution. This forces conservative sequential execution or complex speculation with rollback.

FuelVM Native Parallelism

FuelVM is designed around this insight:

  • All transaction inputs (UTXOs, messages, contracts touched) are declared in the transaction header
  • The execution engine pre-computes a conflict graph before executing
  • Independent transactions execute in parallel across CPU cores
  • Only conflicting transactions execute serially

Predicates and Scripts

FuelVM introduces two novel execution primitives:

Predicates: Stateless spending conditions evaluated over the current transaction context. A predicate is a program that returns true or false; if true, the UTXO can be spent. Predicates cannot read or write state — they are purely functional. This enables any complex spending condition without smart contract storage.

Scripts: Programs that run once, call contracts, and produce execution results. Scripts replace Ethereum’s “EOA transaction” concept — in Fuel, every transaction is a script execution.

Contracts: Stateful programs (similar to EVM contracts) with persistent storage. Contracts are called by Scripts.

FuelVM Architecture

Register-based VM (not stack-based like EVM):

  • 64 registers (vs. infinite stack in EVM)
  • Native 64-bit arithmetic
  • Built-in operations for hash functions, elliptic curve, memory management
  • Explicit memory model (not implicit stack growth)

Register-based VMs are generally faster than stack-based VMs for the same workload; the EVM’s stack design is a historical artifact of simplicity rather than performance.

Sway: Smart Contract Language

Sway is Fuel’s programming language, designed specifically for FuelVM:

  • Syntax influenced by Rust (ownership system, explicit error handling, algebraic types)
  • Compiled by Forc (Fuel Orchestrator) to FuelVM bytecode
  • Distinguishes between Scripts, Predicates, and Contracts at the language level (different compilation targets)
  • Built-in support for multi-asset (Fuel’s native equivalent of ERC-20 is a built-in primitive, not a contract standard)

forc is Fuel’s package manager and build tool, analogous to Cargo (Rust) or Hardhat (Ethereum).

Multi-Asset Native Support

In Ethereum/EVM, every token is an ERC-20 contract. Sending USDC requires calling a contract function. In Fuel, multi-asset is a native protocol primitive:

  • Any asset (not just the gas token) can be included in UTXO inputs/outputs
  • The protocol handles asset transfers natively without smart contracts
  • This simplifies token-transfer security (no “approve” vulnerability class)
  • Native multi-asset is similar to Cardano’s native asset model or Bitcoin’s (planned) TAPROOT assets

Reality Check

Fuel’s technical design is sophisticated and addresses real EVM limitations:

  • UTXO parallelism is a genuine performance advantage over sequential EVM execution
  • Register-based VM design is more efficient than stack-based EVM
  • Native multi-asset eliminates entire classes of ERC-20 approval vulnerabilities

Practical challenges:

  • Ecosystem maturity: Fuel’s ecosystem as of 2024 is tiny relative to EVM ecosystems. Sway requires new language learning; existing Solidity developers face a full rewrite.
  • No EVM compatibility: Unlike most Ethereum L2s (OP Stack, Arbitrum, zkEVM), Fuel does not support Solidity — a significant barrier to developer adoption in a market where EVM compatibility is the default expectation.
  • Mainnet timing: Fuel v2 mainnet launched in late 2024; production time and TVL were early-stage at time of writing.

Legacy

Fuel v1 (2020) was one of the first production optimistic rollups on Ethereum. Fuel v2’s modular execution design is technically ambitious. The UTXO+parallelism architecture influenced academic and industry discussions about optimal execution environments for rollups. Fuel’s design is intellectually consistent with the modular blockchain thesis and sits alongside Celestia (DA), Avail (DA), and EigenDA as components of a modular stack.

Related Terms

Research

  • Fuel Labs. (2022). Fuel: The Fastest Modular Execution Layer. docs.fuel.network.

— Primary technical documentation; describes FuelVM architecture, UTXO execution model, Predicates/Scripts/Contracts, Sway language, and native multi-asset support.

  • Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. bitcoin.org.

— Bitcoin’s UTXO model is the conceptual foundation for Fuel’s parallelism argument; Fuel extends UTXO to smart contract execution.

  • Kalodner, H., Goldfeder, S., Chen, X., Weinberg, S.M., & Felten, E.W. (2018). Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.

— Arbitrum optimistic rollup; context for the rollup design space Fuel originates from (Fuel v1 was a competing optimistic rollup approach).