The Fuel Book

Fuel is the fastest modular execution layer, delivering maximum security and highest flexible throughput.

Check out the new documentation portal here.

Alpha

• Follow Fuel Labs on Twitter for all the alpha.
• Follow Sway, our Rust-based DSL and start writing smart contracts on Fuel.
• Join the Fuel discord where you can ask questions, build with others, and hear about developments first.
• Check out this page to learn about upcoming events, read articles, listen to podcasts, and view presentations on Fuel.
• Apply for a grant to build on Fuel.
• Fuel in the wild

Learn

• Getting Started
  • Why Fuel?
  • What is Fuel?
    • Fuel toolchain
  • The Modular Movement
    • Monolithic Blockchains
  • Fuel Configurations
    • Fuel as a rollup
    • Fuel as an L1
    • Fuel as a state channel
    • Fuel as a side chain
• Technology
  • Parallel Transaction Execution
  • Fraud Proofs
• The FuelVM
  • Contract and Call Model
  • Memory Model
  • Multiple Native Assets
  • VS EVM
• The Sway Language
  • Design Philosophy
  • Safety
• Glossary

Build

• Developer Quickstart
• For Developers
  • Node
  • Sway Language
  • Typescript SDK
  • Rust SDK
  • Indexer

Developer Quickstart

This guide will walk developers through writing a smart contract in Sway, a simple test, deploying to Fuel, and building a frontend.

Before we begin, it may be helpful to understand the terminology that will be used throughout the docs and how they relate to each other:

• Fuel: the Fuel blockchain.
• FuelVM: the virtual machine powering Fuel.
• Sway: the domain-specific language crafted for the FuelVM; it is inspired by Rust.
• Forc: the build system and package manager for Sway, similar to Cargo for Rust.

Understand Sway Program Types

There are four types of Sway programs:

• contract
• predicate
• script
• library

The main features of a smart contract that differentiate it from scripts or predicates are that it is callable and stateful.

A script is runnable bytecode on the chain which can call contracts to perform some task. It does not represent ownership of any resources and it cannot be called by a contract.

See the chapter on program types for more information.

A few pieces of info that will be helpful before moving on:

• This guide was created using VSCode as the code editor.
• Download the Sway language extension in VSCode to get syntax highlighting, keyboard shortcuts, and more.
• Download the rust-analyzer extension in VSCode to get syntax highlighting, code completion, and more.

Writing A Sway Smart Contract

Installation

Start by installing the Rust toolchain.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then, install the Fuel toolchain.

curl --proto '=https' --tlsv1.2 -sSf https://install.fuel.network/fuelup-init.sh | sh

Make sure you have the latest version of fuelup by running the following command:

fuelup self update

Fetching binary from https://github.com/FuelLabs/fuelup/releases/download/v0.19.4/fuelup-0.19.4-aarch64-apple-darwin.tar.gz
Downloading component fuelup without verifying checksum
Unpacking and moving fuelup to /var/folders/tp/0l8zdx9j4s9_n609ykwxl0qw0000gn/T/.tmpiNJQHt
Moving /var/folders/tp/0l8zdx9j4s9_n609ykwxl0qw0000gn/T/.tmpiNJQHt/fuelup to /Users/.fuelup/bin/fuelup

Next, install the beta-4 toolchain with:

fuelup toolchain install beta-4

Finally, set the beta-4 toolchain as your default distribution with the following command:

fuelup default beta-4

default toolchain set to 'beta-4'

You can check your current toolchain anytime by running fuelup show.

Having problems with this part? Post your question on our forum https://forum.fuel.network/. To help you as efficiently as possible, include the output of this command in your post: fuelup show.

Your First Sway Project

We'll build a simple counter contract with two functions: one to increment the counter, and one to return the value of the counter.

Start by creating a new, empty folder. We'll call it fuel-project.

mkdir fuel-project

Writing the Contract

Move inside of your fuel-project folder:

cd fuel-project

Then create a contract project using forc:

forc new counter-contract

You will get this output:

To compile, use `forc build`, and to run tests use `forc test`
----
Read the Docs:
- Sway Book: https://docs.fuel.network/docs/sway
- Forc Book: https://docs.fuel.network/docs/forc
- Rust SDK Book: https://docs.fuel.network/docs/fuels-rs
- TypeScript SDK: https://docs.fuel.network/docs/fuels-ts

Join the Community:
- Follow us @SwayLang: https://twitter.com/SwayLang
- Ask questions on Discourse: https://forum.fuel.network/

Report Bugs:
- Sway Issues: https://github.com/FuelLabs/sway/issues/new

Here is the project that Forc has initialized:

$ tree counter-contract
counter-contract
├── Forc.toml
└── src
    └── main.sw

Forc.toml is the manifest file (similar to Cargo.toml for Cargo or package.json for Node) and defines project metadata such as the project name and dependencies.

Open your project in a code editor and delete everything in src/main.sw apart from the first line.

Every Sway file must start with a declaration of what type of program the file contains; here, we've declared that this file is a contract.

contract;

Next, we'll define a storage value. In our case, we have a single counter that we'll call counter of type 64-bit unsigned integer and initialize it to 0.

storage {
    counter: u64 = 0,
}

ABI

An ABI defines an interface for a contract. A contract must either define or import an ABI declaration. It is considered best practice to define your ABI in a separate library and import it into your contract because this allows callers of the contract to import and use the ABI in scripts to call your contract

For simplicity, we will define the ABI directly in the contract file itself.

abi Counter {
    #[storage(read, write)]
    fn increment();

    #[storage(read)]
    fn count() -> u64;
}

Implement ABI

Below your ABI definition, you will write the implementation of the functions defined in your ABI.

impl Counter for Contract {
    #[storage(read)]
    fn count() -> u64 {
        storage.counter.read()
    }

    #[storage(read, write)]
    fn increment() {
        let incremented = storage.counter.read() + 1;
        storage.counter.write(incremented);
    }
}

Note: storage.counter.read() is an implicit return and is equivalent to return storage.counter.read();.

Here's what your code should look like so far:

File: ./counter-contract/src/main.sw

contract;

storage {
    counter: u64 = 0,
}

abi Counter {
    #[storage(read, write)]
    fn increment();

    #[storage(read)]
    fn count() -> u64;
}

impl Counter for Contract {
    #[storage(read)]
    fn count() -> u64 {
        storage.counter.read()
    }

    #[storage(read, write)]
    fn increment() {
        let incremented = storage.counter.read() + 1;
        storage.counter.write(incremented);
    }
}

Build the Contract

Navigate to your contract folder:

cd counter-contract

changed directory into `counter-countract`

Then run the following command to build your contract:

forc build

  Compiled library "core".
  Compiled library "std".
  Compiled contract "counter-contract".
  Bytecode size is 232 bytes.

Let's have a look at the content of the counter-contract folder after building:

$ tree .
.
├── Forc.lock
├── Forc.toml
├── out
│   └── debug
│       ├── counter-contract-abi.json
│       ├── counter-contract-storage_slots.json
│       └── counter-contract.bin
└── src
    └── main.sw

We now have an out directory that contains our build artifacts such as the JSON representation of our ABI and the contract bytecode.

Testing your Contract

We will start by adding a Rust integration test harness using a Cargo generate template. If this is your first time going through this quickstart, you'll need to install the cargo generate command. In the future, you can skip this step as it will already be installed.

Let's start by running the installation command:

cargo install cargo-generate

 Updating crates.io index...
 installed package `cargo-generate v0.17.3`

Note: You can learn more about cargo generate by visiting its repository.

Now, let's generate the default test harness with the following:

cargo generate --init fuellabs/sway templates/sway-test-rs --name counter-contract

⚠️   Favorite `fuellabs/sway` not found in config, using it as a git repository: https://github.com/fuellabs/sway.git
🔧   Destination: /home/user/path/to/counter-contract ...
🔧   project-name: counter-contract ...
🔧   Generating template ...
🔧   Moving generated files into: `/home/user/path/to/counter-contract`...
✨   Done! New project created /home/user/path/to/counter-contract

Let's have a look at the result:

$ tree .
.
├── Cargo.toml
├── Forc.lock
├── Forc.toml
├── out
│   └── debug
│       ├── counter-contract-abi.json
│       ├── counter-contract-storage_slots.json
│       └── counter-contract.bin
├── src
│   └── main.sw
└── tests
    └── harness.rs

We have two new files!

• The Cargo.toml is the manifest for our new test harness and specifies the required dependencies including fuels the Fuel Rust SDK.
• The tests/harness.rs contains some boilerplate test code to get us started, though doesn't call any contract methods just yet.

Now that we have our default test harness, let's add some useful tests to it.

At the bottom of test/harness.rs, define the body of can_get_contract_id(). Here is what your code should look like to verify that the value of the counter did get incremented:

File: tests/harness.rs

#[tokio::test]
async fn test_increment() {
    let (instance, _id) = get_contract_instance().await;

    // Increment the counter
    instance.methods().increment().call().await.unwrap();

    // Get the current value of the counter
    let result = instance.methods().count().call().await.unwrap();

    // Check that the current value of the counter is 1.
    // Recall that the initial value of the counter was 0.
    assert_eq!(result.value, 1);
}

Here is what your file should look like:

File: ./counter-contract/tests/harness.rs

use fuels::{prelude::*, types::ContractId};

// Load abi from json
abigen!(Contract(
    name = "MyContract",
    abi = "out/debug/counter-contract-abi.json"
));

async fn get_contract_instance() -> (MyContract<WalletUnlocked>, ContractId) {
    // Launch a local network and deploy the contract
    let mut wallets = launch_custom_provider_and_get_wallets(
        WalletsConfig::new(
            Some(1),             /* Single wallet */
            Some(1),             /* Single coin (UTXO) */
            Some(1_000_000_000), /* Amount per coin */
        ),
        None,
        None,
    )
    .await;
    let wallet = wallets.pop().unwrap();

    let storage_config =
        StorageConfiguration::load_from("out/debug/counter-contract-storage_slots.json").unwrap();

    let load_config = LoadConfiguration::default().with_storage_configuration(storage_config);

    let id = Contract::load_from("./out/debug/counter-contract.bin", load_config)
        .unwrap()
        .deploy(&wallet, TxParameters::default())
        .await
        .unwrap();

    let instance = MyContract::new(id.clone(), wallet);

    (instance, id.into())
}

#[tokio::test]
async fn can_get_contract_id() {
    let (_instance, _id) = get_contract_instance().await;

    // Now you have an instance of your contract you can use to test each function
}

#[tokio::test]
async fn test_increment() {
    let (instance, _id) = get_contract_instance().await;

    // Increment the counter
    instance.methods().increment().call().await.unwrap();

    // Get the current value of the counter
    let result = instance.methods().count().call().await.unwrap();

    // Check that the current value of the counter is 1.
    // Recall that the initial value of the counter was 0.
    assert_eq!(result.value, 1);
}

Run cargo test in the terminal:

cargo test

If all goes well, the output should look as follows:

  ...
  running 2 tests
  test can_get_contract_id ... ok
  test test_increment ... ok
  test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.25s

Deploy the Contract

It's now time to deploy the contract to the testnet. We will show how to do this using forc from the command line, but you can also do it using the Rust SDK or the TypeScript SDK.

In order to deploy a contract, you need to have a wallet to sign the transaction and coins to pay for gas. First, we'll create a wallet.

Install the Wallet CLI

If you haven't deployed a contract before, you'll need to set up a local wallet with the forc-wallet plugin. forc-wallet is packaged alongside the default distributed toolchains when installed using fuelup, so you should already have this installed.

You can initialize a new wallet with the command below:

forc wallet new

After typing in a password, be sure to save the mnemonic phrase that is output.

Next, create a new wallet account with:

forc wallet account new

With this, you'll get a fuel address that looks something like this: fuel1efz7lf36w9da9jekqzyuzqsfrqrlzwtt3j3clvemm6eru8fe9nvqj5kar8. Save this address as you'll need it to sign transactions when we deploy the contract.

If you need to list your accounts, you can run the command below:

forc wallet accounts

Get Testnet Coins

With your account address in hand, head to the testnet faucet to get some coins sent to your wallet.

Deploy To Testnet

Now that you have a wallet, you can deploy with forc deploy and adding the --testnet to target the latest network:

forc deploy --testnet

The terminal will ask for the password of the wallet:

Please provide the password of your encrypted wallet vault at "~/.fuel/wallets/.wallet":

Once you unlocked the wallet, the terminal will show a list of the accounts of this wallet:

Account 0 -- fuel18caanqmumttfnm8qp0eq7u9yluydxtqmzuaqtzdjlsww5t2jmg9skutn8n:
  Asset ID                                                           Amount
  0000000000000000000000000000000000000000000000000000000000000000 499999940

Just below the list, you'll see this prompt:

Please provide the index of account to use for signing:

Then you'll enter the number of the account of preference and press Y when prompted to accept the transaction.

Finally, you will get back the network endpoint where the contract was dpeloyed, a ContractId and the block where the transaction was signed. To confirm your contract was deployed. With this ID, you can head to the block explorer and view your contract.

Contract deploy-to-beta-4 Deployed!

Network: https://beta-4.fuel.network
Contract ID: 0x8342d413de2a678245d9ee39f020795800c7e6a4ac5ff7daae275f533dc05e08
Deployed in block 0x4ea52b6652836c499e44b7e42f7c22d1ed1f03cf90a1d94cd0113b9023dfa636

Congrats, you have completed your first smart contract on Fuel ⛽

Here is the repo for this project. If you run into any problems, a good first step is to compare your code to this repo and resolve any differences.

Tweet us @fuel_network letting us know you just built a dapp on Fuel, you might get invited to a private group of builders, be invited to the next Fuel dinner, get alpha on the project, or something 👀.

Need Help?

Get help from the team by posting your question in the Fuel Forum.

Building a Frontend to Interact With Your Contract

To build out our frontend application, we'll do the following:

1. Install the Fuel Browser Wallet.
2. Initialize a React project.
3. Install the fuels SDK dependency.
4. Write our frontend code.
5. Run our project.

Install the Fuel Browser Wallet

Our front end application will need to interact with the Fuel Network, so we'll need to have a browser wallet installed for us to do so.

Fuel Wallet version 0.11.0 is not compatible with beta 4. For compatibility with beta-4, please download the non-backwards compatible Fuel Wallet version 0.12.3.

We have already submitted the beta-4 compatible version to the Chrome Web Store, and it is currently under review.

Please follow the instructions provided below:

Note: This is a temporary measure while the Fuel Wallet version 0.12.3 gets published in the Chrome WebStore.

1. Download FuelWallet zip file
2. Inside Chrome or Brave;
3. Open the extensions page; it can be done by:
   • Clicking on settings -> extensions or;
4. Accessing brave://extensions/ or chrome://extensions/.
5. Enable the "Developer mode" switch on the top right
6. Load fuel-wallet.zip by:
   • Dragging your downloaded Fuel wallet file and dropping it in the extensions page or;
   • Clicking on Load unpacked and selecting the file.
7. If all goes right, an onboarding page will instantly open.

Once you've installed the wallet, take the address of your wallet and use it to get some coins from the testnet faucet.

Initialize a React project

To split our project's contract from frontend code, let's initialize our frontend project: assuming that your terminal is open at your contract's folder /home/user/path/to/counter-contract let's go back up one directory.

cd ..

Now, iniitialize a react project using Create React App.

npx create-react-app frontend --template typescript

The output should be simmilar to:

Success! Created frontend at Fuel/fuel-project/frontend

You should now have your outer folder, fuel-project, with two folders inside: counter-contract and frontend

Install the fuels SDK dependency

The fuels umbrella package includes all the main tools you need for your frontend; Wallet, Contracts, Providers, and more.

Also, it contains the routines for ABI TypeScript generation.

ABI stands for Application Binary Interface. ABI's inform the application the interface to interact with the VM, in other words, they provide info to the APP such as what methods a contract has, what params, types it expects, etc...

Installing

Move into the frontend folder, then run:

cd frontend

Then:

npm install [email protected] @fuel-wallet/[email protected] --save

If the installation wnet correctly the result will be simmilar to this:

added 114 packages, and audited 115 packages in 9s

Next, update the TypeScript configuration at tsconfig.json to add the Fuel Wallet types:

{
  "compilerOptions": {
    "types": ["@fuel-wallet/sdk"]
  }
}

Generating contract types

To make it easier to interact with our contract we use fuels typegen command to interpret the output ABI JSON from our contract, and generate Typescript definitions based on it. This JSON was created when we executed the forc build command to compile our Sway Contract into binary.

If you see the folder fuel-project/counter-contract/out you will be able to see the ABI JSON there. If you want to learn more, read the ABI spec.

Inside the fuel-project/frontend directory run:

npx fuels typegen -i ../counter-contract/out/debug/*-abi.json -o ./src/contracts

A succesful process should print and output like the following:

Generating files..

 - src/contracts/CounterContractAbi.d.ts
 - src/contracts/factories/CounterContractAbi__factory.ts
 - src/contracts/index.ts

Done.⚡

Now you should be able to find a new folder fuel-project/frontend/src/contracts. This folder was auto-generated by our fuels typegen command, and these files abstract the work we would need to do to create a contract instance, and generate a complete TypeScript interface to the Contract, making easy to develop.

Modify the App

Inside the frontend/src folder let's add code that interacts with our contract. Read the comments to help you understand the App parts. Change the file fuel-project/frontend/src/App.tsx to:

File: ./frontend/src/App.tsx

import React, { useEffect, useState } from "react";
import "@fuel-wallet/sdk";
import "./App.css";
// Import the contract factory -- you can find the name in index.ts.
// You can also do command + space and the compiler will suggest the correct name.
import { CounterContractAbi__factory } from "./contracts";

// The address of the contract deployed the Fuel testnet
const CONTRACT_ID =
  "0xa0f2b97f32300d7360b5632e682c1508b326da9a00fbe755646d3809aec90672";

function App() {
  const [connected, setConnected] = useState<boolean>(false);
  const [account, setAccount] = useState<string>("");
  const [counter, setCounter] = useState<number>(0);
  const [loaded, setLoaded] = useState(false);

  useEffect(() => {
    setTimeout(() => {
      checkConnection();
      setLoaded(true);
    }, 200)
    if (connected) getCount();
  }, [connected])

  async function connect() {
    if (window.fuel) {
      try {
        await window.fuel.connect();
        const [account] = await window.fuel.accounts();
        setAccount(account);
        setConnected(true);
      } catch (err) {
        console.log("error connecting: ", err);
      }
    }
  }

  async function checkConnection() {
    if (window.fuel) {
      const isConnected = await window.fuel.isConnected();
      if (isConnected) {
        const [account] = await window.fuel.accounts();
        setAccount(account);
        setConnected(true);
      }
    }
  }

  async function getCount() {
    if (window.fuel) {
      const wallet = await window.fuel.getWallet(account);
      const contract = CounterContractAbi__factory.connect(CONTRACT_ID, wallet);
      const { value } = await contract.functions.count().simulate();
      setCounter(value.toNumber());
    }
  }

  async function increment() {
    if (window.fuel) {
      const wallet = await window.fuel.getWallet(account);
      const contract = CounterContractAbi__factory.connect(CONTRACT_ID, wallet);
      // Creates a transactions to call the increment function
      // because it creates a TX and updates the contract state this requires the wallet to have enough coins to cover the costs and also to sign the Transaction
      try {
        await contract.functions.increment().txParams({ gasPrice: 1 }).call();
        getCount();
      } catch (err) {
        console.log("error sending transaction...", err);
      }
    }
  }

  if (!loaded) return null

  return (
    <>
      <div className="App">
        {
          connected ? (
            <>
              <h3>Counter: {counter}</h3>
              <button style={buttonStyle} onClick={increment}>
                Increment
              </button>
            </>
          ) : (
            <button style={buttonStyle} onClick={connect}>Connect</button>
          )
        }
      </div>
    </>
  );
}

export default App;

const buttonStyle = {
  borderRadius: "48px",
  marginTop: "10px",
  backgroundColor: "#03ffc8",
  fontSize: "20px",
  fontWeight: "600",
  color: "rgba(0, 0, 0, .88)",
  border: "none",
  outline: "none",
  height: "60px",
  width: "400px",
  cursor: "pointer"
}

Finally, replace the value of the CONTRACT_ID variable in App.tsx with the address of the contract you just deployed.

Run your project

Now it's time to have fun, run the project in your browser.

Inside the fuel-project/frontend directory run:

npm start

Compiled successfully!

You can now view frontend in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://192.168.4.48:3000

Note that the development build is not optimized.
To create a production build, use npm run build.

You just built a fullstack dapp on Fuel! ⛽

Here is the repo for this project. If you run into any problems, a good first step is to compare your code to this repo and resolve any differences.

Tweet us @fuel_network letting us know you just built a dapp on Fuel, you might get invited to a private group of builders, be invited to the next Fuel dinner, get alpha on the project, or something 👀.

Updating The Contract

If you make changes to your contract, here are the steps you should take to get your frontend and contract back in sync:

• In your contract directory, run forc build

• In your contract directory, redeploy the contract by running this command and following the same steps as above to sign the transaction with your wallet: forc deploy --testnet

• In your frontend directory, re-run this command: npx fuels typegen -i ../counter-contract/out/debug/*-abi.json -o ./src/contracts

• In your fuel-project/frontend directory, update the contract ID in your App.tsx file

Need Help?

Get help from the team by posting your question in the Fuel Forum.

Getting Started

• Why Fuel?
• What is Fuel?
• Fuel Toolchain

Why Fuel

User Sovereignty with Fraud Proofs

Fuel was designed and built specifically to be fraud-provable, which enable support for trust-minimized light clients. Trust minimized light clients and shared data availability enables trust minimized bridges to other modular execution layers, something impossible to achieve between L1s.

What this means in practice:

• Long-term liquidity access
• Users can validate the chain without having to run full nodes
• Safely bridging assets

Fuel’s optimization for fraud proofs is the use of the UTXO model, which in turn means Fuel has no global state tree or account trees. If you wanted to apply the general construction of a fraud proof to a chain that uses the account model like Ethereum, the cost could be unbound, making it extremely expensive to produce a fraud proof. In this general construction of a fraud proof, given a pre-state and a state transition, you locally execute the transition and compare the output to the post-state produced by the block producer. If these differ, the post-state by the block producer was invalid. If you apply this general fraud proof model to Ethereum today, someone could create a transaction that calls many different contracts, and those contracts could each have up to 24kb of bytecode. In order to locally re-execute, you need to provide all the bytecode for all the contracts that were interacted with.

Read more about trust-minimized light clients and sovereignty here.

Superior DevEx

Fuel’s technology comes together to provide a superior developer experience. Here’s how we do it:

Sway and Fuel Toolchain

The FuelVM is designed to be vertically integrated with tooling.

Unlike EVM which was designed without a language from the start, the FuelVM is built alongside its companion language, Sway, ensuring it has handy and efficient ops, such as getting specific parts of a tx. Sway is a Rust-based DSL created specifically to leverage a blockchain VM without needlessly verbose boilerplate. Sway leverages Rust’s safety and catches errors and bugs at compile-time, giving developers peace of mind. Read more about Sway here.

Fuel Labs has also developed the Fuel Toolchain: the full stack of tools for enabling/assisting the Fuel application development experience. Read more about the Fuel Toolchain here.

Parallel Execution

Fuel brings scale to Ethereum without sacrificing decentralization.The FuelVM is designed to reduce wasteful processing of traditional blockchain virtual machine architectures, while vastly increasing the potential design space for developers. The FuelVM can use all the threads and cores of your CPU to validate transactions.

Fuel Configurations

As a Modular Execution Layer, Fuel can function in any one of these categories. Developers can configure Fuel as-needed by switching out a few modules in the client.

Improved VM

The Ethereum community has suggested many implementation improvements to improve EVM performance. Unfortunately, many of these improvement proposals haven’t been implemented because they would break backward compatibility.

Execution layers built on Ethereum give us a new opportunity to build something better. Designs don’t need to be backward compatible and in fact, can do whatever is necessary to deliver global throughput and adoption for Ethereum. The FuelVM is the EVM greatly improved. Check out this non-exhaustive list of EIPs (Ethereum Improvement Proposals) implemented in the FuelVM here.

The FuelVM and EVM have a lot of overlap. Here's how they're different, view a more complete list at FuelVM vs. EVM

The FuelVM has a globally shared memory architecture instead of context-local memory

The FuelVM has a globally shared memory architecture. Instead of every contract call having its own separate memory space, call data, and return data, all contract call frames share global memory. This chunk of memory is shared amongst all call frames and is globally readable. This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize, copy from call data to memory, etc. Read more about the FuelVM memory model here.

The FuelVM is designed for fraud-provability

The EVM is a complicated machine to construct fraud proofs for. It usually requires a second layer such as WASM or MIPS to be interpreted into a fraud provable system. Check out User Sovereignty with Fraud Proofs and how fraud proofs unlock key functionality.

FuelVM has multiple native assets

In Ethereum, the only native asset is Ether. It’s the only one that gets first-class treatment in terms of cost and ability to be pushed and pulled through a call. In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native-level call and optimization. Read more about support for multiple native assets in the Sway docs, and here.

Read the full specification of the FuelVM here.

What is Fuel?

Fuel v1 began as a layer-2 (L2) scalability technology for a monolithic Ethereum. It was the first optimistic rollup on mainnet Ethereum, deployed at the end of 2020.

Today, Fuel is the fastest modular execution layer. Fuel delivers the highest security and flexible throughput, with a focus on a superior developer experience.

Here’s how we do it:

• Parallel transaction execution
• Fuel Virtual Machine (FuelVM)
• Developer tooling with Sway Language and Forc

Parallel Transaction Execution

Fuel delivers unmatched processing capacity through its ability to execute transactions in parallel by using strict state access lists in the form of a UTXO model. This enables Fuel to use far more threads and cores of your CPU that are typically idle in single-threaded blockchains. As a result, Fuel can deliver far more compute, state accesses, and transactional throughput than its single-threaded counterparts.

With the EVM, it is difficult to know if, and where there are dependencies between transactions, so you are forced to execute transactions sequentially.

The FuelVM uses the UTXO model, enabling parallel transaction execution by identifying transaction dependencies through what is known as state access lists. With the FuelVM, Fuel full nodes identify the accounts that a transaction touches, mapping out dependencies before execution.

FuelVM

The FuelVM learns from the Ethereum ecosystem, implementing improvements that were suggested to the Ethereum VM (EVM) for many years but couldn’t be implemented due to the need to maintain backward compatibility.

Here are some EIP that have been implemented in the FuelVM:

Sway Language

Sway is a domain-specific language (DSL) for the Fuel Virtual Machine (FuelVM), a blockchain-optimized VM designed for the Fuel blockchain. Sway is based on Rust and includes syntax to leverage a blockchain VM without a needlessly verbose boilerplate.

Sway was created alongside the FuelVM and designed for the high-compute Fuel environment. Check out the Sway docs here.

Developer Tooling

Fuel Labs is developing a suite of developer tooling to create a seamless developer experience. By creating everything in-house, Fuel Labs guarantees the maintenance of the toolchain, avoiding the pitfalls of a fragmented developer ecosystem.

Fuel provides a powerful and sleek developer experience with our own domain-specific language, called Sway, and a supportive toolchain, called Forc (the Fuel Orchestrator). Our development environment retains the benefits of smart contract languages like Solidity, while adopting the paradigms introduced in the Rust tooling ecosystem. Now, developers can have a completely vertically-integrated experience where every component from the virtual machine through to the CLI works in harmony.

The Fuel Toolchain: Forc: build, run tests, launch a local instance of a block explorer, format.

Check out the Fuel Toolchain here.

Coming Soon: A suite of auditing facilities, from fuzzing and formal verification to code coverage and runtime gating.

The Fuel Toolchain

The Fuel toolchain is the full stack of tools designed and built by Fuel Labs for enabling and assisting the Fuel application development experience.

Tooling Overview:

• fuel-core: The Fuel VM node client.
• forc: The Fuel Orchestrator. Includes Sway compiler, packaging and plugin support.

Forc plugins by Fuel Labs:

• forc-fmt: The Sway code formatter.
• forc-lsp: The Sway Language Server Protocol implementation.
• forc-explore: Runs the Fuel block explorer.
• forc-client: For deploying and running Sway apps via CLI.
• forc-wallet: For initializing a wallet, adding accounts and signing transactions.
• forc-doc: Generates documentation for Sway projects.
• forc-index: For initializing and deploying an index.
• fuelup: The Fuel toolchain manager - an easy approach to retrieving all of the above.

For more specific documentation on the toolchain, check out the Sway docs here.

Building on Fuel

Developers can get everything they need to start creating Sway applications for the Fuel VM with a single toolchain, blessed by the same teams that create the FuelVM and Sway language.

One common issue developers face when working within the Ethereum ecosystem is how to choose a set of tools to get started. Historically, Ethereum's founders have been particularly focused on the low-level details of the protocol, the EVM and to a lesser extent Solidity, leaving the job of creating accessible, high-level tooling to the community. As a result, many disparate projects have appeared from different 3rd parties that aim to provide these high-level solutions such as truffle, dapptools, hard hat, foundry and many more. It can be difficult for new Ethereum developers to navigate this space and to feel comfortable knowing they're making the right choice in selecting one of these toolchains.

In contrast, Fuel Labs take a curated, "batteries-included"-yet-modular approach to providing tooling. We aim to provide a comprehensive, standardized, canonical set of tools that cover not only the lower levels of the stack (like protocol and VM implementations) but the higher level too (such as package management, editor support, common-use plugins and much more). We aim to do so in a manner that is open, transparent and welcoming of external contributions.

To clarify, the goal is not at all to discourage 3rd parties from extending the fuel ecosystem. Rather, we aim to make the official tool-chain so good as to inspire contributions upstream and to collaborate under one unified developer ecosystem. For those cases where our tooling falls short and additions or extensions are required, we provide an extensible plugin system through forc, enabling community creativity in a manner that is easily-shareable and familiar to fellow Fuel devs.

The Sway VS Code plugin is a great example of our vision for a unified developer experience. The plugin interacts with the Sway language server, a forc plugin that communicates directly with the Sway compiler and shares much of its code-base. The plugin also allows for spinning up a Fuel node, displaying its status in real-time and (in the near future) interact with your smart contracts via the TypeScript SDK. A complete solution from entirely within the plugin, from one team with a shared vision.

You can start experimenting with the Fuel toolchain by following the Fuelup Quickstart Guide.

Modular Movement

Although L2s have opened up a margin of cost reduction for access to the Ethereum ecosystem, the total throughput increase has been modest at best (with both optimistic and ZK approaches). And in times of high traffic on Ethereum, L2s have failed to keep costs low, often rising to several dollars per transaction.

As a community, if we want to achieve true global access to blockchain technology, we cannot settle for a modest reduction in fees. We need dramatic change. Change that not only reduces waste and inefficiency but opens up new use cases never before seen in the blockchain space.

There is an ongoing colossal shift happening in layer-1 (L1) blockchain architectures. We are moving away from a monolithic design, where consensus, data availability, and execution are tightly coupled (e.g. today's Ethereum), to a modular future, where execution is separated from data availability and consensus (e.g. tomorrow's Eth2, or Celestia). This separation allows for specialization at the base layer, delivering a significant increase in bandwidth capacity.

Why Modular?

A modular blockchain architecture does not inherently enable scaling. The properties that are derived as a result are what make this possible. Fuel was built for fraud proofs, enabling trust-minimized light clients, enabling high security without requiring high resource usage.

Security vs. Resource Requirements

In a monolithic architecture, users must choose between high security and high computational resource usage and trusted security and low computational resource usage. For example, Ethereum was designed to allow consumer-grade hardware to be able to run a full node, a type of node that offers maximum security by downloading and verifying every single transaction. By running a full node, users don’t have to trust that the chain is valid and can instead verify themselves. However, running a full node requires a lot of disk space and non-negligible CPU allocation and can take days to sync the blockchain from genesis.

Alternatively, a user can run a light client, also known as an honest majority light client. Instead of downloading all blocks to verify transactions, light clients only download block headers and check their proof-of-work (PoW), assuming the heaviest chain is valid. Honest majority light-clients that trust that a majority of validators are honest and will reject fraudulent transactions.

The amount of computational resources and storage needed to run a light client is lower than a full node by several orders of magnitude.

An easy way to remember the difference: An honest majority light client is only secure if most validators are honest. A full node is honest even if all validators are not honest.

By running a full node, you get the maximum security of verifying transactions but also have to spend a lot of computational resources to achieve this. Because a light client doesn’t need to run 24/7 and doesn’t interact directly with the chain, the computational requirement is much lower, but you also get low security.

Trust-Minimized Light Clients

Fuel’s design lets light clients say that blocks are valid through fraud proofs. This eliminates the need for a trusted party while maintaining low resource requirements and achieving high security. For monolithic chains like Ethereum, there is an ideological incentive to keep the computation requirements for full nodes low to allow users to be truly sovereign.

Because Fuel was built for fraud proofs, the resource requirements for full nodes can be higher, thus increasing bandwidth capacity while still allowing users to verify the chain through trust-minimized light clients.

Monolithic Architecture

Blockchains as we know them have four functions. In no particular order:

• Execution: Execute transactions to make updates to the state.
• Settlement: Dispute resolution.
• Consensus: Defines the state and validates that all nodes on the blockchain have the same state.
• Data availability: Ensure block data has been published to the network.

Monolithic blockchains are a type of blockchain architecture that handle all four functions, at the same time, on this single layer.

Challenges with Monolithic

Some constraints and challenges with a monolithic architecture:

Costly and inefficient transaction verification

In order to verify the validity of transactions in the chain, full nodes must download the entire chain and execute each transaction locally.

Resource constraints

The blockchain is bound by the resource capacity of its nodes. Throughput is constrained by the resource requirements of a single node since the blockchain is replicated, not distributed, across nodes.

Shared resources

In a monolithic architecture, the four functions of the chain operate on the same finite set of compute resources. For example, using a node's capacity for execution means that there's less capacity left over for data availability.

Scalability

Scalability is defined as the ratio of throughput to decentralization. To increase throughput—the number transactions per second—you have to increase bandwidth, compute, and storage capacity, which pushes up the cost to run a full node as a user. This is not scalability, as it reduces the number of people who can run a full node to validate the chain.

What is a Modular Execution Layer

In addition to the properties of a rollup, a modular execution is different because it also has these two additional properties:

• With a modular execution layer, users can run an off-chain light client, allowing users to validate the chain without running a full node.

• A modular execution layer is not tightly coupled to a specific layer 1, allowing for greater flexibility.

Light Clients

One of the core characteristics of a modular execution layer is related to the trust model of the system. A modular execution layer has all the properties of a rollup, and the ability to run a light client. This allows you to have trust-minimized infrastructure. Read more about light clients here.

Flexibility

Another core property of a modular execution layer is that it is not tightly coupled to a specific layer 1. This offers flexibility that allows Fuel to be deployed. Read more about Fuel's flexibility here.

Fuel Configurations

Fuel is a modular architecture and is designed to operate in multiple different configurations.

Fuel Configurations

Defining Rollups

A layer-2 is a term used to describe a set of scaling solutions. A rollup is an off-chain network built on top of the layer-1 that executes transactions off-chain, bundles these transactions, and posts the bundled transactions as a single transaction on the layer-1 chain.

Check out this resource to learn more about rollups and layer-2s.

Fuel as a Rollup or Layer-2

Fuel is designed to run a modular execution layer, a configuration similar to what we call rollups or layer-2s on Ethereum today. Rollups typically use an optimistic or zk-configuration for validity or transaction arbitration. The Fuel technology is agnostic to either of these and can utilize either as a validity or fraud-proving system.

Layer-2s and rollups are primarily designed for monolithic blockchain stacks, which means they are typically not optimized for large amounts of layer-1 bandwidth potential unlike Fuel, which is uniquely configured to handle this potential.

Fuel Configurations

Defining a Layer-1

A layer-1 is a blockchain network responsible for handling all functions of a chain including settlement, execution, data availability, and consensus. This has been colloquially named a layer-1 because rollups, or layer-2s, sit on top of these chains.

Check out this resource to learn more about layer-1s.

Fuel as a Layer-1

The Fuel technology includes all the components to run as a complete layer-1 solution. These components include consensus, data availability, settlement, and transaction execution. The common configurations for running in this mode would be proof of authority and a proof of stake via a Tendermint-BFT style.

While Fuel can run in this configuration, we do not promote or support this outside of testing, as the broader mission of Fuel is to enhance existing blockchains such as Ethereum as a high-performance execution layer.

Fuel Configurations

Defining State Channels

A state channel is a smart contract that enforces off-chain transactions between predefined parties. Each transaction updates the state of the chain and is cryptographically provable on-chain.

Check out this resource to learn more about state channels.

Fuel as a State Channel

The FuelVM is a priced virtual machine architecture with a deterministic state system, which makes it perfect for multi-party channel designs where all parties must have clarity over the exact state of the system at each communication step or window.

While we do not ship a channel configuration of the Fuel technology out of the box, the FuelVM is perfectly situated to handle this particular use case.

Fuel Configurations

Defining Sidechain

A sidechain is a blockchain with a one-way trust-minimized bridge from the base chain.

Check out this resource to learn more about sidechains.

Fuel as a Sidechain

The Fuel technology can also run as a sidechain to an existing layer-1. This means there is a message passing bridge between the layer-1 and Fuel. In this configuration, data availability would be handled by the side chain, while settlement is handled by the layer-1.

There would also be an option to run it in a semi-provable configuration, whereby fraud proofs can be used to ensure better validity guarantees using the layer-1 as an arbitrator.

Technology

• Parallel Transaction Execution
• Fraud Proofs

Parallel Transaction Execution

Ethereum processes transactions sequentially (i.e. one after the other). With modern processors becoming increasingly multi-threaded but stalling on single-core speedups, being able to execute transactions in parallel (i.e. multiple transactions at once) is a highly desirable property.

Without a mechanism for determining and handling dependencies between transactions, executing transactions in parallel is a race condition and would result in non-deterministic execution. There have been attempts to add optimistic concurrent execution logic to Ethereum, but show inconsistent performance benefits and moreover only work in non-adversarial conditions.

EIP-648 proposed to add access lists to transactions, i.e. a list of shared state that would be touched by each transaction. With such a list, clients can partition transactions into sets with disjoint access lists and execute transactions across each set in parallel. However, the EIP was never implemented, in part due to implementation and design inefficiencies that resulted in state accesses being the bottleneck rather than compute.

State Access Lists and UTXOs

Fuel supports parallel transaction execution through strict (i.e. mandatory) access lists, similar to EIP-648. Each transaction must specify which contracts the transaction may interact with; if a transaction attempts to access a contract not in this list then execution will revert. With these access lists, execution can be done in parallel across transactions that touch disjoint sets of contracts. See here for additional context.

Access lists are implemented with UTXOs. UTXOs give other nice properties, but for the purposes of parallel transaction execution serve simply as strict access lists.

Fraud Proofs

Fraud proofs are a blockchain verification mechanism whereby a claim on a new block is accepted unless a proof the claim is invalid is provided within some configurable time window. This allows trust-minimized light clients to be secure under the assumption only a single honest full node is available in the network to produce fraud proofs. Both the Fuel protocol and the FuelVM are designed to be fraud-provable in restrictive environments such as the Ethereum Virtual Machine.

State-transition fraud proofs are a general-purpose fraud proof mechanism, but come with the downside of requiring a global state tree—an inherently sequential bottleneck. UTXO fraud proofs avoid this bottleneck; they simply require each spend of a UTXO to "point" to the creation of the UTXO. Proving the pointer is invalid, or that whatever is being pointed to doesn't match whatever is being spent, are sufficient for exhaustively proving fraud.

The Fuel transaction format and validation logic are fraud-provable with UTXO fraud proofs. The FuelVM relies on an Interactive Verification Game protocol, whereby an execution trace is bisected until a single step must be executed to check for a mismatch. The FuelVM instruction set is specifically designed to be both expressive yet fraud-provable within the Ethereum Virtual Machine.

The FuelVM

• Contract and Call Model
• Memory Model
• Multiple Native Assets

Read the full VM spec here.

Contract and Call Model

Fuel uses a similar model to Ethereum for contracts and cross-contract calls. Contracts may call other contracts with a CALL similar to an Ethereum message call). Unlike the EVM, which can only forward its base asset with a call (i.e. ETH), the FuelVM can forward a single native fungible asset with a call.

Transactions may initiate contract calls. Ethereum transactions may call a single contract directly. Fuel transactions instead execute a script (arbitrary bytecode attached to the transaction), which may call any number of contracts.

Memory Model

The EVM uses a linear memory (i.e. starting at zero and growing), without a defined limit. Allocating memory costs a quadratic amount of gas, which severely limits the amount of memory usable in a single context (i.e. contract call).

In addition, the EVM has a separate memory space per context. Contexts may communicate with each other by copying data to call data and returning data buffers.

The FuelVM uses a single share memory block per transaction. Memory is allocated statically with a known upper bound, allowing for straightforward implementation of heap types such as vectors. Memory in the FuelVM is globally readable across contexts, but locally writable. Each context may only write to portions of the stack and the heap which it has ownership over.

Multiple Native Assets

Fuel supports multiple native assets as first-class citizens. Any single asset may be forwarded with a CALL. Contracts have a balance of all possible assets instead of only the base asset.

Note that only the base asset is usable to pay for gas fees.

FuelVM vs. EVM, Explained

FuelVM learns from the EVM, Solana, WASM, Bitcoin, and Cosmos.

This page is meant to outline the ways the FuelVM differs compared to the EVM in simple terms.

FuelVM vs. EVM

The FuelVM has a globally shared memory architecture instead of context-local memory

The FuelVM has a globally shared memory architecture. Instead of every contract call having its own separate memory space, call data, and return data, all contract call frames share global memory. This chunk of memory is shared amongst all call frames and is globally readable. This allows you to pass data around between contracts without expensive storage and pass chunks of data without having to serialize, copy from call data to memory, etc. Read more about the FuelVM memory model here.

The FuelVM is designed for fraud-provability

The EVM is a complicated machine to construct fraud proofs for. It usually requires a second layer such as WASM or MIPS to be interpreted into a fraud provable system. Check out User Sovereignty with Fraud Proofs and how fraud proofs unlock key functionality.

FuelVM has multiple native assets

In Ethereum, the only native asset is Ether. It’s the only one that gets first-class treatment in terms of cost and ability to be pushed and pulled through a call. In Fuel, any contract can mint its UTXO-based native asset using a set of easy asset opcodes. All of which can gain the benefits of native-level call and optimization. Read more about support for multiple native assets in the Sway docs, and here.

FuelVM uses 64-bit words instead of 256-bit

Modern processors have 64-bit registers, and all of the instruction set operates on 64 bits. Those are the most efficient instructions, and when you deal with 256 bits, you’re dealing with big numbers, and since modern processors aren't made to handle those numbers natively, it means you have to do more in the software.

The FuelVM is register-based instead of stack-based

Register-based VMs typically require fewer instructions to do the same work than stack-based VMs. Because every operation is priced, optimizing to reduce the number of operations needed to do the same amount of work has outsized benefits.

The FuelVM is built with an atomic UTXO paradigm from the start

Fuel uses a system of UTXOs which enable a more efficient system fo transfer and ownership of assets, where the accounts tree doesn't have to be rebuilt every time funds are transferred.

The FuelVM removes approve, transferFrom

The FuelVM removes the need for approve/transferFrom UX with scripts. Unlike the EVM, the FuelVM has scripts, which allow many actions to happen from an origin sender without a contract being deployed. Read more in the Fuel Specification here.

EIPs Implemented in Fuel

The FuelVM implements several EIPs that have been suggested and supported by the community but couldn't be implemented due to the need to maintain backward compatibility. Check out a non-exhaustive list, also available here:

Sway Language

Sway is a smart contract programming language that prioritizes safety and speed and brings modern programming language theory to the blockchain.

Check out the Sway docs here.

Rust + Solidity = Sway

Sway prioritizes compile-time analysis and safety, similar to Rust’s borrow checker and safety-first semantics. Additionally, it has the syntax of Rust. From Solidity, Sway took the notion of a smart-contract-paradigm language with built-in top-level contract storage and blockchain mechanisms for ergonomic and safe contract programming.

In addition to robust documentation, tooling, clear error messages, and more – Sway brings the notion of static auditing to smart contracts. The compiler will catch things that one would typically hire an auditing firm to catch. This is particularly unique. In addition, Sway is highly performant and has extensible optimization passes and a modular backend for targeting different blockchain architectures.

Check out Sway examples here.

Sway Design Philosophy

Sway follows the design philosophies of Rust and Solidity, with some Fuel ideology mixed in. From Solidity, we took the notion of smart contract programming as a paradigm. This led to storage blocks, contract ABIs as entry points, etc.

From Rust, we took the prioritizations of performance, control, and safety. In Rust, this means the borrow checker, safe parallelism (send and sync), annotated unsafety, etc., mainly to save the programmer from referencing freed memory, shared mutable state, and undesirable memory management. This is great for a general-purpose language model. Sway, however, is not general purpose. Sway targets a blockchain VM environment, where execution is not indefinite, and memory allocation and management are less concerned. Instead, we need to optimize for gas costs and contract-level safety. We applied the philosophy of performance, control, and safety and interpreted it in this new context. This is where Sway gets compile time checks of state mutability, namespacing of state variables, static analysis passes, and gas profiling/optimization.

Sway Safety

Sway provides multiple layers of safety. For one, we provide canonical tooling and "one right way" to do things. This results in less ambiguity and more correct/helpful tools. This tooling ships a debugger, gas profiler, testing framework, SDK, formatter, and more. These tools ensure the programmer has nothing between them and the algorithm they are trying to implement. Safety comes from the foundation of a comfortable and ergonomic environment.

In addition, Sway has implemented static analysis checks like a Checks, Effects, Interactions checker, state and storage purity checking, immutable-by-default semantics, and other static compile-time audits to promote safety.

For Developers

• Example Smart Contracts
• Networks
• Running a local node
• Sway Language
• TypeScript SDK
• Rust SDK
• Indexer
• Wallet and Faucet
• Fuelup
• GraphQL API

Sway Application Examples

Developers are encouraged to reference the sway-applications repo for examples for common patterns and functionality. This repository contains smart contracts that are written in Sway in order to demonstrate what can be built, and offer forkable code for others to build on.

We have the following contracts available as a reference:

• Airdrop is a token distribution program where users are able to claim tokens given a valid merkle proof.
• Automated Market Maker (AMM) is a decentralized exchange protocol that manages liquidity pools supplied by its users and determines prices algorithmically while exchanging assets.
• Decentralized Autonomous Organization (DAO) is an organization where users get to vote on governance proposals using governance tokens.
• English Auction is an auction where users bid up the price of an asset until the bidding period has ended or a reserve has been met.
• Escrow is a third party that keeps an asset on behalf of multiple parties. Fundraiser is a program allowing users to pledge towards a goal.
• Multi-Signature Wallet is a wallet that requires multiple signatures to execute a transaction.
• Name-Registry allows users to perform transactions with human readable names instead of addresses.
• Non-Fungible Token (NFT) is a token contract which provides unique collectibles, identified and differentiated by token IDs, where tokens contain metadata giving them distinctive characteristics.
• Oracle is a smart contract that provides off-chain data to on-chain applications. OTC Swap Predicate is a predicate that can be used to propose and execute an atomic swap between two parties without requiring any on-chain state.

View all of the applications here.

Please note all projects currently use forc 0.31.1, and fuel-core 0.14.1.

Networks

On this page, you'll find information on the different testnet networks.

beta-4 testnet

The beta-4 network is the latest Fuel testnet. It builds on the foundation of beta-3, enhancing public P2P access, allowing parallel predicate execution, and introducing a newly redesigned bridging approach that ensures security for full rollups.

Read more about beta-4 here.

beta-3 testnet

The beta-3 network is the third Fuel testnet. It expands on the features of beta-2, introducing P2P networking and the ability to run synchronizing full nodes.

Read more about beta-3 here.

beta-2 testnet

The beta-2 network is the second Fuel testnet, launched with a bridge to Ethereum's Goerli test network. With this network, developers are able to build and test cross-chain dapps, laying the foundations for projects building on Fuel to tap into Ethereum's massive liquidity and existing user base.

Read more about beta-2 here.

beta-1 testnet

The beta-1 network is the first public Fuel testnet, shared by all developers and users that interact with it. Developers may deploy contracts to it at will—no permission or whitelisting required—and users may interact with deployed contracts as well.

Read more about beta-1 here.

The beta-4 testnet

The beta-4 network is the latest Fuel testnet. It builds on the foundation of beta-3, enhancing public P2P access, allowing parallel predicate execution, and introducing a newly redesigned bridging approach that ensures security for full rollups.

Ethereum contracts (Sepolia):

"FuelMessagePortal": 0x457A5a9320d06118764c400163c441cb8551cfa2

"FuelChainState": 0x053cDdc8D065dEB051584a5ae4DB45348be285c9

"FuelERC20Gateway": 0x10530552f00079cfF07f3c6D541C651a667Cf41D

Sepolia block explorer: https://sepolia.etherscan.io/

🚰 Faucet - Use the faucet to get test ETH to deploy contracts with or to interact with contracts. Available here: https://faucet-beta-4.fuel.network/.

📃 GraphQL endpoint - The Fuel Core node uses GraphQL instead of JSON RPC. A playground for the public GraphQL endpoint for beta-4 is available at https://beta-4.fuel.network/playground.

🔍 Block explorer - A block explorer (still heavily in development) is available at https://fuellabs.github.io/block-explorer-v2/. Be sure to select beta-4 from the dropdown on the top right.

Join the Fuel Labs Forum to get support from our team and others building on Fuel!

SDK Versioning

Version 0.55.0 or higher is the recommended version of the TS SDK on beta-4.

Version 0.47.0 or higher is the recommended version for the Rust SDK on beta-4.

Toolchain Configuration

To configure the optimal toolchain for beta-4, ensure you have fuelup installed, then run the following command:

fuelup self update

Then install the beta-4 toolchain with

fuelup toolchain install beta-4

This installs the following components and versions:

• forc 0.45.0
• forc-explore 0.28.1
• forc-index 0.20.7
• forc-wallet 0.3.0
• fuel-core 0.20.4
• fuel-indexer 0.20.7

To set the beta-4 toolchain as your default, run

$ fuelup default beta-4
default toolchain set to 'beta-4-aarch64-apple-darwin'

Predicate

Messages intended for contracts use a pre-defined predicate as the message recipient. This predicate allows anyone to relay the message to the target contract and only the target contract. Once the contract receives the message it can see who originated it along with any special message payload and processes it accordingly. Since anyone can relay the message using this predicate it opens up possibilities for automated message processing as a service.

The predicate root for the beta-4 testnet is 0x86a8f7487cb0d3faca1895173d5ff35c1e839bd2ab88657eede9933ea8988815.

The beta-3 testnet

The beta-3 network is the third Fuel testnet. It expands on the features of beta-2, introducing P2P networking and the ability to run synchronizing full nodes.

Ethereum contracts (Goerli):

"FuelMessagePortal": 0xE6B0E27F85abaCfC5149642c30F4BE9a878Aa4e9

"FuelChainConsensus": 0x4b4b74b2E5CD9775793779619C3547b7863EbEca

"FuelERC20Gateway": 0x8083634a1A5092D3234657092e5CF74655191B8D

The ERC-20 Gateway contract on Georli Ethereum is at 0x8083634a1A5092D3234657092e5CF74655191B8D.

Goerli block explorer: https://goerli.etherscan.io/

🚰 Faucet - Use the faucet to get test ETH to deploy contracts with or to interact with contracts. Available here: https://faucet-beta-3.fuel.network/.

📃 GraphQL endpoint - The Fuel Core node uses GraphQL instead of JSON RPC. A playground for the public GraphQL endpoint for beta-3 is available at https://beta-3.fuel.network/playground.

🔍 Block explorer - A block explorer (still heavily in development) is available at https://fuellabs.github.io/block-explorer-v2/. Be sure to select beta-3 from the dropdown on the top right.

Join the Fuel Labs Forum to get support from our team and others building on Fuel!

SDK Versioning

Version 0.38.0 up to 0.50.0 is the recommended version of the TS SDK on beta-3.

Version 0.39.0 up to 0.44.0 is the recommended version for the Rust SDK on beta-3.

Toolchain Configuration

To configure the optimal toolchain for beta-3, ensure you have fuelup installed, then run the following command:

fuelup self update

Then install the beta-3 toolchain with

fuelup toolchain install beta-3

This installs the following components and versions:

• forc 0.37.3
• forc-explore 0.28.1
• forc-index 0.15.0
• forc-wallet 0.2.2
• fuel-core 0.17.11
• fuel-indexer 0.15.0

To set the beta-3 toolchain as your default, run

$ fuelup default beta-3
default toolchain set to 'beta-3-aarch64-apple-darwin'

Predicate

Messages intended for contracts use a pre-defined predicate as the message recipient. This predicate allows anyone to relay the message to the target contract and only the target contract. Once the contract receives the message it can see who originated it along with any special message payload and processes it accordingly. Since anyone can relay the message using this predicate it opens up possibilities for automated message processing as a service.

The predicate root for the beta-3 testnet is 0x4df15e4a7c602404e353b7766db23a0d067960c201eb2d7a695a166548c4d80a.

The beta-2 testnet

The beta-2 network is launched with a bridge to Ethereum's Goerli test network. With this network, developers are able to build and test cross-chain dapps, laying the foundations for projects building on Fuel to tap into Ethereum's massive liquidity and existing user base.

Ethereum contracts (Goerli):

"FuelMessagePortal": 0x4c7181fff2053D232Fc74Ff165b83FE8Dcb65910

"BinaryMerkleTreeLib": 0x40Ab53ba8BEEe302539f417eCC6C5FBb99F3B7Cd

"FuelSidechainConsensus": 0xF712e555ce59858f680890DA7dc2B51eD048580d

"L1ERC20Gateway": 0x96c53cd98B7297564716a8f2E1de2C83928Af2fe

The ERC-20 Gateway contract on Georli Ethereum is at 0x96c53cd98B7297564716a8f2E1de2C83928Af2fe.

You can view a test ERC-20 token contract at 0x9c3f3a5a53bD127a51Ae9622EC43488FE6a4DcCd on Goerli Ethereum with the corresponding Fuel side token contract deployed at 0x250cbf149be078027eed12eba0fe07617b398ccc8ccf1f43a02adddd4e4f8e56 on the beta-2 testnet.

Goerli block explorer: https://goerli.etherscan.io/

🚰 Faucet - Use the faucet to get test ETH to deploy contracts with or to interact with contracts. Available here: https://faucet-beta-2.fuel.network/.

📃 GraphQL endpoint - The Fuel Core node uses GraphQL instead of JSON RPC. A playground for the public GraphQL endpoint for beta-1 is available at https://node-beta-2.fuel.network/playground.

🔍 Block explorer - A block explorer (still heavily in development) is available at https://fuellabs.github.io/block-explorer-v2/. Be sure to select beta-2 from the dropdown on the top right.

Join the Fuel Labs Discord and head to the 🧪︱testnet-beta-2 channel to get support from our team.

SDK Versioning

Version 0.21.0 is the recommended version of the TS SDK on beta-2.

Version 0.30.0 is the recommended version for the Rust SDK on beta-2.

Toolchain Configuration

To configure the optimal toolchain for beta-2, ensure you have fuelup installed, then run the following command:

$ fuelup self update
Fetching binary from https://github.com/FuelLabs/fuelup/releases/download/v0.12.0/fuelup-0.12.0-aarch64-apple-darwin.tar.gz
Downloading component fuelup without verifying checksum
Unpacking and moving fuelup to /var/folders/tp/0l8zdx9j4s9_n609ykwxl0qw0000gn/T/.tmplX61Ng
Moving /var/folders/tp/0l8zdx9j4s9_n609ykwxl0qw0000gn/T/.tmplX61Ng/fuelup to /Users/camiinthisthang/.fuelup/bin/fuelup
`$ fuelup toolchain install beta-2.`
Downloading: forc forc-explore forc-wallet fuel-core

Adding component forc v0.31.1 to 'beta-2-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/sway/releases/download/v0.31.1/forc-binaries-darwin_arm64.tar.gz
Unpacking and moving forc-doc to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Unpacking and moving forc to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Unpacking and moving forc-deploy to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Unpacking and moving forc-run to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Unpacking and moving forc-lsp to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Unpacking and moving forc-fmt to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Fetching core forc dependencies
Installed forc v0.31.1 for toolchain 'beta-2-aarch64-apple-darwin'

Adding component forc-explore v0.28.1 to 'beta-2-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/forc-explorer/releases/download/v0.28.1/forc-explore-0.28.1-aarch64-apple-darwin.tar.gz
Unpacking and moving forc-explore to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Installed forc-explore v0.28.1 for toolchain 'beta-2-aarch64-apple-darwin'

Adding component forc-wallet v0.1.2 to 'beta-2-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/forc-wallet/releases/download/v0.1.2/forc-wallet-0.1.2-aarch64-apple-darwin.tar.gz
Unpacking and moving forc-wallet to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Installed forc-wallet v0.1.2 for toolchain 'beta-2-aarch64-apple-darwin'

Adding component fuel-core v0.14.1 to 'beta-2-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/fuel-core/releases/download/v0.14.1/fuel-core-0.14.1-aarch64-apple-darwin.tar.gz
Unpacking and moving fuel-core to /Users/camiinthisthang/.fuelup/toolchains/beta-2-aarch64-apple-darwin/bin
Installed fuel-core v0.14.1 for toolchain 'beta-2-aarch64-apple-darwin'

This installs the following components and versions:

• forc 0.31.1
• forc-explore 0.28.1
• forc-wallet 0.1.2
• fuel-core 0.14.1

Predicate

Messages intended for contracts use a pre-defined predicate as the message recipient. This predicate allows anyone to relay the message to the target contract and only the target contract. Once the contract receives the message it can see who originated it along with any special message payload and processes it accordingly. Since anyone can relay the message using this predicate it opens up possibilities for automated message processing as a service.

The predicate root is 0xc453f2ed45abb180e0a17aa88e78941eb8169c5f949ee218b45afcb0cfd2c0a8.

The beta-1 testnet

The beta-1 network is the first public Fuel testnet, shared by all developers and users that interact with it. Developers may deploy contracts to it at will—no permission or whitelisting required—and users may interact with deployed contracts as well.

🚰 Faucet - Use the faucet to get test ETH to deploy contracts with or to interact with contracts. Available here: https://faucet-beta-1.fuel.network.

📃 GraphQL endpoint - The Fuel Core node uses GraphQL instead of JSON RPC. A playground for the public GraphQL endpoint for beta-1 is available at https://node-beta-1.fuel.network/playground.

🔍 Block explorer - A block explorer (still heavily in development) is available at https://fuellabs.github.io/block-explorer-v2.

Join the Fuel Labs Discord and head to the 🧪︱testnet-beta-1 channel to get support from our team.

SDK Versioning

Version 0.17.0 is the recommended version of the TS SDK on beta-1.

Version 0.30.0 is the recommended version for the Rust SDK on beta-1,

Toolchain Configuration

To configure the optimal toolchain for beta-1, ensure you have fuelup installed, then run the following command:

$ fuelup toolchain install beta-1
Downloading: forc forc-wallet fuel-core

Adding component forc v0.26.0 to 'beta-1-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/sway/releases/download/v0.26.0/forc-binaries-darwin_arm64.tar.gz
Unpacking and moving forc to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Unpacking and moving forc-deploy to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Unpacking and moving forc-run to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Unpacking and moving forc-explore to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Unpacking and moving forc-lsp to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Unpacking and moving forc-fmt to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Fetching core forc dependencies
Installed forc v0.26.0 for toolchain 'beta-1-aarch64-apple-darwin'

Adding component forc-wallet v0.1.2 to 'beta-1-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/forc-wallet/releases/download/v0.1.2/forc-wallet-0.1.2-aarch64-apple-darwin.tar.gz
Unpacking and moving forc-wallet to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Installed forc-wallet v0.1.2 for toolchain 'beta-1-aarch64-apple-darwin'

Adding component fuel-core v0.10.1 to 'beta-1-aarch64-apple-darwin'
Fetching binary from https://github.com/FuelLabs/fuel-core/releases/download/v0.10.1/fuel-core-0.10.1-aarch64-apple-darwin.tar.gz
Unpacking and moving fuel-core to /Users/sarah/.fuelup/toolchains/beta-1-aarch64-apple-darwin/bin
Installed fuel-core v0.10.1 for toolchain 'beta-1-aarch64-apple-darwin'

Installed:
- forc 0.26.0
- forc-wallet 0.1.2
- fuel-core 0.10.1


The Fuel toolchain is installed and up to date

This installs the following components:

• forc 0.26.0
• forc-wallet 0.1.2
• fuel-core 0.10.1

Running a local Fuel node

In addition to deploying and testing on the Fuel Testnet, you can also run a local Fuel Node.

There are two types of Fuel networks that can be run:

1. In-memory network (without persistance)
2. Local network with persistance

In-memory local node (without state persistance)

An in-memory node does not persist the blockchain state anywhere, it is only stored in memory as long as the node is active and running.

To spin Up a local in-memory Fuel node, run the following command:

fuel-core run --db-type in-memory

To deploy a contract to the local node, run the following command:

forc deploy <signing-key> --url 127.0.0.1:4000/graphql

Or to deploy without using a signing key:

forc deploy --unsigned --url 127.0.0.1:4000/graphql

Local node (with state persistance)

This node does persist the blockchain state locally.

To run a local node with persistance, you must configure a chainConfig.json file. Here is an example of what that looks like:

{
    "chain_name": "local_testnet",
    "block_production": {
      "ProofOfAuthority": {
        "trigger": "instant"
      }
    },
    "parent_network": {
      "type": "LocalTest"
    },
    "block_gas_limit": 1000000000,
    "initial_state": {
      "coins": [
        {
          "owner": "0x94ffcc53b892684acefaebc8a3d4a595e528a8cf664eeb3ef36f1020b0809d0d",
          "amount": "0xFFFFFFFFFFFFFFFF",
          "asset_id": "0x0000000000000000000000000000000000000000000000000000000000000000"
        },
        {
          "owner": "0x80d5e88c2b23ec2be6b2e76f3499a1a2755bb2773363785111a719513fb57b8e",
          "amount": "0x00000000FFFFFFFF",
          "asset_id": "0x0000000000000000000000000000000000000000000000000000000000000000"
        },
        {
          "owner": "0xf13c949256d0e119fecaec414ea452f21f9dc1870fb6262ff53b37c32cab4749",
          "amount": "0x00000000FFFFFFFF",
          "asset_id": "0x0000000000000000000000000000000000000000000000000000000000000000"
        }
      ]
    },
    "transaction_parameters": {
      "contract_max_size": 16777216,
      "max_inputs": 255,
      "max_outputs": 255,
      "max_witnesses": 255,
      "max_gas_per_tx": 100000000,
      "max_script_length": 1048576,
      "max_script_data_length": 1048576,
      "max_static_contracts": 255,
      "max_storage_slots": 255,
      "max_predicate_length": 1048576,
      "max_predicate_data_length": 1048576,
      "gas_price_factor": 1000000000,
      "gas_per_byte": 4,
      "max_message_data_length": 1048576
    },
    "block_producer": {
      "utxo_validation": true,
      "coinbase_recipient": "0x0000000000000000000000000000000000000000000000000000000000000000"
    },
    "consensus": {
      "PoA": {
        "signing_key": "0x22ec92c3105c942a6640bdc4e4907286ec4728e8cfc0d8ac59aad4d8e1ccaefb"
      }
    }
  }

To start the node, run the following command:

fuel-core run --ip 127.0.0.1 --port 4000 --chain ./chainConfig.json --db-path ./.fueldb

Connecting to the local node from a browser wallet

To connect to the local node using a browser wallet, import the network address as:

http://127.0.0.1:4000/graphql

Sway Language 🌴

Resources to get started with Sway:

• Official Sway docs
• Sway examples repo
• Tutorial: Build a Marketplace with Sway
• Workshop: Build a Game with Sway
• Workshop: Developing Smart Contracts with Sway

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Typescript SDK

The Fuel TS SDK is a toolkit for build dapps on The fuel network. You can use the SDK to execute scripts, interact with contracts, list transactions, balances and more.

To get started using the TypeScript SDK:

• SDK Docs
• TS Quickstart Guide
• TS SDK Repo

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Rust SDK

The Rust SDK for Fuel can be used for a variety of things, including but not limited to:

• Deploying, and testing Sway contracts
• Launching a local Fuel network
• Crafting and signing transactions with hand-crafted scripts or contract calls
• Generating type-safe Rust bindings of contract methods

Getting started with the Rust SDK:

• Rust SDK Docs
• Rust SDK repo

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Fuel Indexer

The Fuel Indexer is a standalone binary that can be used to index various components of the blockchain. These indexable components include blocks, transactions, and receipts and state within a Fuel network, allowing for high-performance read-only access to the blockchain for advanced dApp use-cases.

Events can be indexed by the Fuel Indexer by using WASM modules, as described in the Hello World example.

Getting Started with The Fuel Indexer:

• Indexer Docs

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Faucet and Block Explorer

Assets for the beta-4 testnet can be obtained from the faucet at https://faucet-beta-4.fuel.network/.

Beta-3 Faucet

Assets for the beta-3 testnet can be obtained from the faucet at https://faucet-beta-3.fuel.network/.

Beta-2 Faucet

Assets for the beta-2 testnet can be obtained from the faucet at https://faucet-beta-2.fuel.network/.

Block Explorer

The block explorer for all testnets can be found here.

Fuel Wallet

Note: the wallet is an alpha version. For now, it isn't possible to download the extension directly from the Chrome Web Store.

Fuel has a wallet extension that allows users interact with apps built on the Fuel network with their own wallet.

For instructions on how to download the extension and use the SDK in your app, check out the Fuel Wallet docs here.

Fuelup

fuelup is the official package manager for Fuel that installs the Fuel Toolchain from the official release channels, enabling you to easily switch between different toolchains and keep them updated. It makes building and maintaining Sway applications simpler with forc and fuel-core for common platforms.

Get started with Fuelup:

• Fuelup Docs

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Fuel GraphQL API

The Fuel GraphQL API allows you to query the Fuel blockchain for a wide range of on-chain data. It can be used to query transactions, balances, block information, and more. You can also use it to simulate and submit transactions on the Fuel network.

Getting Started with the API:

• GraphQL Docs

Need Help?

Head to the Fuel discord or the Fuel Forum for help from the team.

Fuel Glossary

Address

An address is a cryptographic hash representing an identity of a wallet or a predicate root.

AssetId

An asset ID is a unique identifier for an on-chain asset. It is derived from the root of the bytecode of the contract minting the asset.

Base Asset

The base asset is the underlying asset needed to perform any transactions on a blockchain. It is used to pay gas for transactions. On Ethereum, the base asset is ETH.

Block

A block is a record of many transactions, that are grouped together and cryptographically hashed. The linked blocks form a chain, also called a blockchain.

Block Explorer

A block explorer is an interface for block and transaction data produced by a blockchain. You can use a block explorer to explore and verify addresses, contracts, and transaction histories.

Block Height

The block height refers to the total number of valid blocks produced in the history of a blockchain, starting with the genesis block.

Block ID

A block ID is a unique identifier for a particular block.

Bridge

A bridge is a mechanism that allows the transfer of data or assets from one blockchain to another.

Bytecode

Bytecode is machine-readable code, usually generated from a compiler.

Chain

Another name for a blockchain.

ChainId

A unique ID for a blockchain.

Client

The Fuel client refers to the software that runs the Fuel Virtual Machine. It can be used to validate and produce blocks, and send transactions.

Coinbase

Coinbase refers to the validators paying themselves for processing a block from the transaction fees. Having a coinbase transaction on each block makes this process transparent to all users.

Consensus

The consensus layer defines the state and validates that all nodes on the blockchain have the same state.

Consensus Parameters

Consensus parameters are the rules used by clients to determine the validity of and finalize a block.

Contract Call

Calling a contract means invoking a function from a smart contract that has been deployed to the blockchain.

Contract ID

The contract ID is a unique identifier for a contract derived from the root of the contract bytecode.

Data Availability

The data availability layer ensures that block data has been published to the network.

EIP

EIP stands for Ethereum Improvement Proposal. It refers to a proposal to upgrade the core software powering the Ethereum blockchain.

EOA

EOA stands for Externally Owned Account. It refers to a wallet address that is not controlled by a contract.

EVM

EVM stands for Ethereum Virtual Machine, which is the virtual machine used for the Ethereum network.

Execution

Execution refers to the processing of transactions by nodes in a network.

Faucet

A faucet is a service that provides free tokens for a testnet.

Forc

Forc is short for Fuel Orchestrator. Similar to Cargo for Rust, Forc is the build system and package manager for Sway. It is used to build, test, and deploy Sway contracts.

Fraud Proof

Fraud proofs are a blockchain verification mechanism whereby a claim on a new block is accepted unless a proof the claim is invalid is provided within some configurable time window. Both the Fuel protocol and the FuelVM are designed to be fraud-provable in restrictive environments such as the Ethereum Virtual Machine.

Fuel

The Fuel blockchain.

Fuels

Fuels is the name of the Fuel Rust and Typescript SDKs used to interact with a contract, similar to ethers.js or web3.js

Fuelup

Fuelup is the official toolchain and package manager for the Fuel toolchain.

FuelVM

The FuelVM is the virtual machine powering the Fuel blockchain.

Fuel Core

fuel-core is the name of the Fuel client implementation.

Gas

Gas is a variable fee charged by a node to process a transaction that is executed on-chain.

Indexer

An indexer is a program that watches and organizes blockchain data so it can be easily queried.

Input

An input refers to a transaction input, which is a UTXO consumed by a transaction.

Layer 1 (L1)

Also called a level 1, this refers to a base layer blockchain that is not built on top of any other blockchain.

Layer 2 (L2)

Also called a level 2, this is a blockchain that is built on top of another blockchain. Layer 2 networks can offer unique benefits like allowing for cheaper transactions or sovereign rollups that can fork without forking the base layer.

Light Client

A light client is a client that doesn't validate blocks and transactions but still offers some functionality to send transactions.

Locked Wallet

A locked wallet is a wallet that can only interact with read-only smart contract methods.

Mainnet

Mainnet refers to the main network of a blockchain, as opposed to a testnet.

Merkle Tree

A Merkle tree is a data structure which uses a cryptographic hash function recursively to condense a set of data into a single value, called the root. It allows efficient proofs that a given element is part of the set.

Message

A type of input that only includes specific metadata, and is often used for bridging.

Mint

Minting refers to the creation of new coins.

Modular

Referring to a blockchain architecture that allows for execution, settlement, consensus, and data availability to run on separate layers.

Monolithic

Referring to a blockchain architecture that handles execution, settlement, consensus, and data availability all at the same time on a single layer.

Native Asset

With Fuel any contract can make its own native asset. On Ethereum, the only native asset is ETH. This allows for much cheaper token transactions because it doesn't require any contract state changes. It also allows you to directly forward any asset in a transaction call, avoiding the need for the approve and transferFrom mechanisms.

Network

Another name for a blockchain.

Node

A client that validates and produces blocks for the network.

Optimistic Rollup

An optimistic rollup is a sidechain that uses fraud proofs to verify transactions instead of relying on a majority of validators to be honest.

Output

An output refers to a transaction output, or which UTXOs are output by a transaction.

Parallel Transactions

Parallel transactions refers to the ability of the FuelVM to process multiple transactions in parallel.

Predicate

A predicate is a pure function that can return true or false, and is sent inside a transaction as bytecode and checked at transaction validity time. If it evaluates to false the transaction will not be processed, and no gas will be used. If it evaluates to true, any coins belonging to the address equal to the Merkle root of the predicate bytecode may be spent by the transaction.

Private Key

A cryptographic key that is used to prove ownership by producing a digital signature. It should be kept private (or secret) as it can grant access to a wallet.

Public Key

A cryptographic key that is generated from its associated private key and can be shared publicly. Addresses are derived from public keys.

Receipt

A receipt is a data object that is emitted during a transaction and contains information about that transaction.

Re-entrancy attack

A type of attack in which the attacker is able to recursively call a contract function so that the function is exited before it is fully executed. This can result in the attacker being able to withdraw more funds than intended from a contract.

Rollup

A rollup is a scaling solution for layer 1 blockchains that "rolls up" or batches transactions as calldata.

Script

A script is runnable bytecode that executes once on-chain to perform some task. It does not represent ownership of any resources and it cannot be called by a contract. A script can return a single value of any type.

Settlement

Settlement refers to how and where on-chain disputes are resolved or settled.

Sidechain

A sidechain is a blockchain that runs independently but is connected to another blockchain (often Ethereum Mainnet) by a two-way bridge.

Signature

A cryptographic signature from a wallet, usually in reference to a signature for a message.

Smart Contract

Also referred to as a contract, a smart contract is a set of programming functions with persistent state that is deployed on a blockchain. Once deployed, the contract code can never be changed or deleted, and anyone can access public functions without permission.

State Channel

State channels allow for users to conduct any number of off-chain transactions while only submitting two on-chain transactions to open and close the channel. This reduces the number of on-chain transactions needed, which reduces the cost and saves time.

Sway

Sway is the official programming language for Fuel. It is a domain-specific language crafted for the FuelVM and inspired by Rust.

Testnet

Testnet is short for test network. You can use a testnet to deploy and test contracts for free.

Toolchain

A toolchain is a set of related tools. The Fuel toolchain includes fuelup, forc, fuel-core, and fuels.

Transaction

A transaction is any interaction with the blockchain, for example sending coins from one address to another.

Unlocked Wallet

An unlocked wallet can interact with both read and write smart contract methods.

UTXO

UTXO stands for unspent transaction output.

UTXO Model

A UTXO model is a blockchain model that doesn't keep track of account balances. Instead, it uses inputs and outputs to manage state, which allows for fast parallel transactions.

Validator

A validator refers to a network validator or node. Validators help validate transactions and produce blocks.

Witness

A witness refers to the cryptographic signatures from actors involved in authorizing a transaction, including the transaction signers, contract callers, and block producers.

Zero-Knowledge Proof

A method that allows for the verification of secret information without revealing the secret.

Zero-Knowledge Rollup

A rollup that uses zero-knowledge proofs to verify transactions. In ZK rollups, each rollup block posted to the contract must be accompanied by a validity proof (a succinct proof that the block is valid), which is also verified by the contract. Blocks are thus finalized immediately, and withdrawals can be processed in the same Ethereum block.