The Fuel Book

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

Alpha

Learn

Build

Coming Soon

  • Modular Blockchains
    • Modular Blockchain Stack
    • What is a Modular Execution Layer
  • The FuelVM
    • VS Move
    • VS Solana
  • Glossary

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 terminology that will 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

Contracts, predicates, and scripts can produce artifacts usable on the blockchain, while a library is simply a project designed for code reuse and is not directly deployable.

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.

deployable on the blockchain:can have state:callable on the blockchain:designed for code reuse:
contract
predicate
script
library✅ (via a contract or predicate)

See the chapter on program types for more information.

Installation

Start by installing the Rust toolchain.

Then, install the Fuel toolchain.

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.

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.

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

Writing the Contract

Then with forc installed, create a contract project inside of your fuel-project folder:

$ cd fuel-project
$ forc new counter_contract
To compile, use `forc build`, and to run tests use `forc test`

----

Read the Docs:
- Sway Book: https://fuellabs.github.io/sway/latest
- Rust SDK Book: https://fuellabs.github.io/fuels-rs/latest
- TypeScript SDK: https://github.com/FuelLabs/fuels-ts

Join the Community:
- Follow us @SwayLang: https://twitter.com/SwayLang
- Ask questions in dev-chat on Discord: https://discord.com/invite/xfpK4Pe

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

Here is the project that Forc has initialized:

$ tree fuel-project
fuel-project
├── Cargo.toml
├── Forc.toml
├── src
│   └── main.sw
└── tests
    └── harness.rs

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. You'll notice a Cargo.toml file because forc uses cargo under the hood.

Open your project in a code editor and delete the boilerplate code in src/main.sw so that you start with an empty file.

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, and there is no function body in the ABI. A contract must either define or import an ABI declaration and implement it. 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.

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

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

Going line by line

#[storage(read, write)] is an annotation which denotes that this function has permission to read and write values in storage.

fn increment(); - We're introducing the functionality to increment and denoting it shouldn't return any value.

#[storage(read)] is an annotation which denotes that this function has permission to read values in storage.

fn counter() -> u64; - We're introducing the functionality to increment the counter and denoting the function's return value.

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
    }
    #[storage(read, write)]
    fn increment(){
        storage.counter = storage.counter + 1;
    }
}

Note return storage.counter; is equivalent to storage.counter.

What we just did

Read and return the counter property value from the contract storage.

fn count() -> u64 {
    storage.counter
}

The function body accesses the value counter in storage, and increments the value by one. Then, we return the newly updated value of counter.

fn increment() {
    storage.counter = storage.counter + 1;
}

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

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
    }

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

Build the Contract

From inside the fuel-project/counter_contract directory, run the following command to build your contract:

$ forc build
  Compiled library "core".
  Compiled library "std".
  Compiled contract "counter_contract".
  Bytecode size is 224 bytes.

Testing your Contract

In the directory tests, navigate to harness.rs. Here you'll see there is some boilerplate code to help you start interacting with and testing your contract.

At the bottom of the file, define the body of can_get_contract_instance. Here is what your code should look like to verify that the value of the counter did get incremented:

#[tokio::test]
async fn can_get_contract_id() {
    let (instance, _id) = get_contract_instance().await;
    // Increment the counter
    let _result = instance.increment().call().await.unwrap();
    // Get the current value of the counter
    let result = instance.count().call().await.unwrap();
    assert!(result.value > 0); 
}

Run the following command in the terminal:

$ forc test
  Compiled library "core".
  Compiled library "std".
  Compiled contract "counter_contract".
  Bytecode size is 224 bytes.
  running 1 test
  test can_get_contract_id ... ok
  test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.11s

Note The forc test command is in the process of being reworked to perform in-language unit testing, at which point we will recommend using cargo directly for your Sway+Rust integration testing. See this issue for more details.

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

Follow these steps to set up a wallet and create an account.

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

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.

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 passing in the testnet endpoint like this:

forc deploy --url https://node-beta-1.fuel.network/graphql --gas-price 1

Note We set the gas price to 1. Without this flag, the gas price is 0 by default and the transaction will fail.

The terminal will ask for the address of the wallet you want to sign this transaction with, paste in the address you saved earlier, it looks like this: fuel1efz7lf36w9da9jekqzyuzqsfrqrlzwtt3j3clvemm6eru8fe9nvqj5kar8

The terminal will output your contract id. Be sure to save this as you will need it to build a frontend with the Typescript SDK.

The terminal will output a transaction id to sign and prompt you for a signature. Open a new terminal tab and view your accounts by running forc wallet list. If you followed these steps, you'll notice you only have one account, 0.

Grab the transaction id from your other terminal and sign with a specified account by running the following command:

forc wallet sign` + `[transaction id here, without brackets]` + `[the account number, without brackets]`

Your command should look like this:

$ forc wallet sign 16d7a8f9d15cfba1bd000d3f99cd4077dfa1fce2a6de83887afc3f739d6c84df 0
Please enter your password to decrypt initialized wallet's phrases:
Signature: 736dec3e92711da9f52bed7ad4e51e3ec1c9390f4b05caf10743229295ffd5c1c08a4ca477afa85909173af3feeda7c607af5109ef6eb72b6b40b3484db2332c

Enter your password when prompted, and you'll get back a signature. Save that signature, and return to your other terminal window, and paste that in where its prompting you to provide a signature for this transaction.

Finally, you will get back a TransactionId to confirm your contract was deployed. With this ID, you can head to the block explorer and view your contract.

Note You should prefix your TransactionId with 0x to view it in the block explorer

block explorer

Create a Frontend to Interact with Contract

Now we are going to

  1. Initialize a React project.
  2. Install the fuels SDK dependencies.
  3. Modify the App.
  4. Run our project.

Initialize a React project

To split better our project let's create a new folder frontend and initialize our project inside it.

In the terminal, go back up one directory and initialize a react project using Create React App.

$ cd ..
$ npx create-react-app frontend --template typescript
Success! Created frontend at Fuel/fuel-project/frontend

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

project folder structure

Install the fuels SDK dependencies

On this step we need to install 3 dependencies for the project:

  1. fuels: The umbrella package that includes all the main tools; Wallet, Contracts, Providers and more.
  2. fuelchain: Fuelchain is the ABI TypeScript generator.
  3. typechain-target-fuels: The Fuelchain Target is the specific interpreter for the Fuel ABI Spec.

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...

Install

Move into the frontend folder, then install the dependencies:

$ cd frontend
$ npm install fuels --save
added 65 packages, and audited 1493 packages in 4s
$ npm install fuelchain typechain-target-fuels --save-dev
added 33 packages, and audited 1526 packages in 2s
Generating contract types

To make it easier to interact with our contract we use fuelchain to interpret the output ABI JSON from our contract. This JSON was created on the moment we executed the forc build 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 Specs here.

Inside counter-contract/frontend run;

$ npx fuelchain --target=fuels --out-dir=./src/contracts ../counter_contract/out/debug/*-abi.json
Successfully generated 4 typings!

Now you should be able to find a new folder fuel-project/frontend/src/contracts. This folder was auto-generated by our fuelchain command, this 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.

Create A Wallet (Again)

For interacting with the fuel network we have to submit signed transactions with enough funds to cover network fees. The Fuel TS SDK don't currently support Wallet integrations, requiring us to have a non-safe wallet inside the WebApp using a privateKey.

Note This should be done only for development purpose. Never expose a web app with a private key inside. The Fuel Wallet is in active development, follow the progress here.

In the root of the frontend project create a file, createWallet.js

const { Wallet } = require("fuels");

const wallet = Wallet.generate();

console.log("address", wallet.address.toString());
console.log("private key", wallet.privateKey);

In a terminal, run the following command:

$ node createWallet.js
address fuel160ek8t7fzz89wzl595yz0rjrgj3xezjp6pujxzt2chn70jrdylus5apcuq
private key 0x719fb4da652f2bd4ad25ce04f4c2e491926605b40e5475a80551be68d57e0fcb

Note You should use the generated address and private key.

Save the private key, you will need this later to set it as a string value for a variable WALLET_SECRET in your App.tsx file. More on that below.

First, take the address of your wallet and use it to get some coins from the testnet faucet.

Now you're ready to build and ship ⛽

Note The team is working to simplify the process of creating a wallet, and eliminate the need to create a wallet twice. Keep an eye out for these updates.

Modify the App

Inside the frontend 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:

import React, { useEffect, useState } from "react";
import React, { useEffect, useState } from "react";
import { Wallet } from "fuels";
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 = "<YOUR-CONTRACT-ID>";
//the private key from createWallet.js
const WALLET_SECRET = "<YOUR-PRIVATE-KEY>"
// Create a Wallet from given secretKey in this case
// The one we configured at the chainConfig.json
const wallet = new Wallet(WALLET_SECRET, "https://node-beta-1.fuel.network/graphql");
// Connects out Contract instance to the deployed contract
// address using the given wallet.
const contract = CounterContractAbi__factory.connect(CONTRACT_ID, wallet);

function App() {
  const [counter, setCounter] = useState(0);
  const [loading, setLoading] = useState(false);
  useEffect(() => {
    async function main() {
      // Executes the counter function to query the current contract state
      // the `.get()` is read-only, because of this it don't expand coins.
      const { value } = await contract.functions.count().get();
      setCounter(Number(value));
    }
    main();
  }, []);
  async function increment() {
    // a loading state
    setLoading(true);
    // 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();
      const { value } = await contract.functions.count().get();
      setCounter(Number(value));
    } finally {
      setLoading(false);
    }
  }
  return (
    <div className="App">
      <header className="App-header">
        <p>Counter: {counter}</p>
        <button
          disabled={loading}
          onClick={increment}>
          {loading ? "Incrementing..." : "Increment"}
        </button>
      </header>
    </div>
  );
}
export default App;

### Run your project

Now it's time to have fun run the project on your browser;

Inside `fuel-project/frontend` run;

```console
$ npm start
Compiled successfully!

You can now view frontend in the browser.

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

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

screenshot of the UI

✨⛽✨ Congrats you have completed your first DApp on Fuel ✨⛽✨

Tweet us @fuellabs_ 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 --url https://node-beta-1.fuel.network/graphql --gas-price 1
  • In your frontend directory, re-run this command: npx fuelchain --target=fuels --out-dir=./src/contracts ../fuel-counter/out/debug/*-abi.json
  • In your frontend directory, update the contract ID in your App.tsx file

Need Help?

Head over to the Fuel discord to get help.

Getting Started

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

parallel transaction execution in the FuelVM

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

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 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:

EIPDescriptionImplementation
Easy ParallelizabilityAllow transactions in the EVM to be processed in parallel by specifying what addresses they can access.Fuel can execute transactions in parallel by using strict state access lists with our UTXO model. This allows Fuel to use of all the threads and cores of your CPU to validate transactions.
EIP-2098: Compact Signature RepresentationReduce signatures from 65 bytes to 64 bytes to simplify handling transactions in client code, reduce gas costs, and reduce transaction sizes.Fuel compresses signature data by a byte, from 65 to 64 bytes.
EIP-3074: AUTH and AUTHCALL opcodesIntroduces two EVM instructions, AUTH and AUTHCALL, to enable batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond.Fuel has scripts and predicates that, when combined, allow the execution of multiple calls in a single batch.
EIP-3102: Binary Trie StructureIntroduces binary structure and merkelization rule for the account and storage tries, which are merged into a single “state” trie. Binary tries make for smaller (~4x) proofs than hexary tries, making it the design of choice for a stateless-friendly Ethereum.Fuel uses a binary Sparse Merkle Trie instead of a Patricia Merkle Trie, which makes for smaller proofs and results in better performance.
EIP-4758: Deactivate SELFDESTRUCTRename SELFDESTRUCT opcode to SENDALL, and only immediately move all ETH in the account to the target; no longer destroying code or storage or alters the nonce. Disabling SELFDESTRUCT will be a requirement for statelessness.The FuelVM doesn't have a SELFDESTRUCT opcode which can complicate client implementations.
EIP-5027: Remove the limit on contract code sizeRemove the limit on the code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts. With the dramatic growth of decentralized applications, the functionalities of smart contracts are becoming more and more complicated, and thus, the sizes of newly developed contracts are steadily increasing. As a result, we are facing more issues with the 24576-bytes contract size limit.FuelVM doesn't have a limit on the size of a single contract below their physical limits. We have an instruction that allows you to load bytecode from another contract into the current execution context, allowing you to use it as a single contract even if you have to split bytecode across multiple transactions. It'll have a single monolithic bytecode and one state. In EVM, if you spit a contract across two transactions, it's two separate contracts, and you have to do things like delegate calls to share the state between the two contracts and can't do things like jump between bytecode on each contract.
EIP-5065: Instruction for Transferring EtherAdd a new instruction that transfers ether to a destination address without handing over the flow of execution to it. Ethereum currently has no ideal way to transfer ether without transferring the execution flow. People have come up with reentrancy guards and similar solutions to prevent some types of attacks, but it’s not an ideal solution.The FuelVM has an instruction called TR, short for transfer, which transfers a native asset to a contract but doesn't allow the receiving contract to execute logic. You might want to do this to ensure the receiving contract cannot reenter. This doesn't exist as a native, first-class instruction in the EVM- you can do this by self-destructing a contract but it's a messy workaround that only works for ETH.
EIP-86: Abstraction of Transaction Origin and Signature and EIP-2938: Account AbstractionImplements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism currently hard-coded into transaction processing.FuelVM has stateless account abstraction, enabling application-layer logic to configure validity rules of transactions. On Ethereum today, a transaction is valid if the user has enough Ether, the nonce is correct, and signature is valid. With account abstraction, the user can change the validity of the transaction logic without a hard fork. This could mean changes to the signature scheme or natively locking an account behind a multisig.
EIP-1051: Overflow Checking for the EVMThis EIP adds overflow checking for EVM arithmetic operations and two new opcodes that check and clear the overflow flags. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation.Overflow checking is built into the FuelVM and can be optionally disabled.
EIP-2803: Rich TransactionsIf a transaction has a to of address x, then the data of the transaction will be treated as EVM bytecode, and it will be executed from the context of the CALLER of the transaction (aka: the transaction signer). Many Ethereum DApps require users to approve multiple transactions to produce one effect. This results in a poor user experience and complicates the experience of interacting with DApps.The FuelVM has scripts that implement this.
EIP-2926: Chunk-based Code MerkelizationBytecode is currently the second contributor to block witness size after the proof hashes. Transitioning the trie from hexary to binary reduces the hash section of the witness by 3x, thereby making code the first contributor. By breaking contract code into chunks and committing to those chunks in a Merkle tree, stateless clients would only need the chunks that were touched during a given transaction to execute it.To get a code hash on Ethereum, you hash together all the byte code. The problem is that if you want to do things with statelessness or fraud proofs, to show that this hash is valid, you have to provide all the byte code, up to 24KB per contract. This EIP suggests we should merkalize it instead of hashing. The FuelVM implements this by having code roots instead of code hashes.

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 full stack of tools designed and built by Fuel Labs for enabling/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.
  • Fuel Indexer: A standalone binary that can be used to index various components of the blockchain. Check out the docs here.

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.
  • 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 type script 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

fuel1

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

graph showing security versus resource requirements on running full node, honest-majority light client, and trust-minimized light client

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.

monolithic

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.

Fuel Configurations

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

image of fuel running in different configurations across consensus, settlmenent, data availability, and execution

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

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 restritive 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

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 my copying data to call data and return 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 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:

EIPDescriptionImplementation
Easy ParallelizabilityAllow transactions in the EVM to be processed in parallel by specifying what addresses they can access.Fuel can execute transactions in parallel by using strict state access lists with our UTXO model. This allows Fuel to use of all the threads and cores of your CPU to validate transactions.
EIP-2098: Compact Signature RepresentationReduce signatures from 65 bytes to 64 bytes to simplify handling transactions in client code, reduce gas costs, and reduce transaction sizes.Fuel compresses signature data by a byte, from 65 to 64 bytes.
EIP-3074: AUTH and AUTHCALL opcodesIntroduces two EVM instructions, AUTH and AUTHCALL, to enable batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond.Fuel has scripts and predicates that, when combined, allow the execution of multiple calls in a single batch.
EIP-3102: Binary Trie StructureIntroduces binary structure and merkelization rule for the account and storage tries, which are merged into a single “state” trie. Binary tries make for smaller (~4x) proofs than hexary tries, making it the design of choice for a stateless-friendly Ethereum.Fuel uses a binary Sparse Merkle Trie instead of a Patricia Merkle Trie, which makes for smaller proofs and results in better performance.
EIP-4758: Deactivate SELFDESTRUCTRename SELFDESTRUCT opcode to SENDALL, and only immediately move all ETH in the account to the target; no longer destroying code or storage or alters the nonce. Disabling SELFDESTRUCT will be a requirement for statelessness.The FuelVM doesn't have a SELFDESTRUCT opcode which can complicate client implementations.
EIP-5027: Remove the limit on contract code sizeRemove the limit on the code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts. With the dramatic growth of decentralized applications, the functionalities of smart contracts are becoming more and more complicated, and thus, the sizes of newly developed contracts are steadily increasing. As a result, we are facing more issues with the 24576-bytes contract size limit.FuelVM doesn't have a limit on the size of a single contract below their physical limits. We have an instruction that allows you to load bytecode from another contract into the current execution context, allowing you to use it as a single contract even if you have to split bytecode across multiple transactions. It'll have a single monolithic bytecode and one state. In EVM, if you spit a contract across two transactions, it's two separate contracts, and you have to do things like delegate calls to share the state between the two contracts and can't do things like jump between bytecode on each contract.
EIP-5065: Instruction for Transferring EtherAdd a new instruction that transfers ether to a destination address without handing over the flow of execution to it. Ethereum currently has no ideal way to transfer ether without transferring the execution flow. People have come up with reentrancy guards and similar solutions to prevent some types of attacks, but it’s not an ideal solution.The FuelVM has an instruction called TR, short for transfer, which transfers a native asset to a contract but doesn't allow the receiving contract to execute logic. You might want to do this to ensure the receiving contract cannot reenter. This doesn't exist as a native, first-class instruction in the EVM- you can do this by self-destructing a contract but it's a messy workaround that only works for ETH.
EIP-86: Abstraction of Transaction Origin and Signature and EIP-2938: Account AbstractionImplements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism currently hard-coded into transaction processing.FuelVM has stateless account abstraction, enabling application-layer logic to configure validity rules of transactions. On Ethereum today, a transaction is valid if the user has enough Ether, the nonce is correct, and signature is valid. With account abstraction, the user can change the validity of the transaction logic without a hard fork. This could mean changes to the signature scheme or natively locking an account behind a multisig.
EIP-1051: Overflow Checking for the EVMThis EIP adds overflow checking for EVM arithmetic operations and two new opcodes that check and clear the overflow flags. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation.Overflow checking is built into the FuelVM and can be optionally disabled.
EIP-2803: Rich TransactionsIf a transaction has a to of address x, then the data of the transaction will be treated as EVM bytecode, and it will be executed from the context of the CALLER of the transaction (aka: the transaction signer). Many Ethereum DApps require users to approve multiple transactions to produce one effect. This results in a poor user experience and complicates the experience of interacting with DApps.The FuelVM has scripts that implement this.
EIP-2926: Chunk-based Code MerkelizationBytecode is currently the second contributor to block witness size after the proof hashes. Transitioning the trie from hexary to binary reduces the hash section of the witness by 3x, thereby making code the first contributor. By breaking contract code into chunks and committing to those chunks in a Merkle tree, stateless clients would only need the chunks that were touched during a given transaction to execute it.To get a code hash on Ethereum, you hash together all the byte code. The problem is that if you want to do things with statelessness or fraud proofs, to show that this hash is valid, you have to provide all the byte code, up to 24KB per contract. This EIP suggests we should merkalize it instead of hashing. The FuelVM implements this by having code roots instead of code hashes.

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

Testnet Node

Connect Rust SDK to Fuel Node

Check out these docs to connect your SDK to Fuels testnet here.

Deploy a Contract to Testnet

To deploy a contract to the testnet, you'll need to create a wallet using forc-wallet and then run the following command: forc deploy --url https://node-beta-1.fuel.network/graphql --gas-price 1

Check out the Developer Quickstart to see a working example of how to deploy a contract to testnet.

Sway Language 🌴

Resources to get started with Sway:

Need Help?

Head to the Fuel discord 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:

Need Help?

Head to the Fuel discord for help from the team.

Rust SDK

Rust SDK for Fuel. It 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; And more, fuels-rs is still in active development.

Getting started with the Rust SDK:

Need Help?

Head to the Fuel discord 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:

Need Help?

Head to the Fuel discord for help from the team.

Fuel Wallet

You can deploy a contract to a local fuel instance without signing with a wallet by running the following command:

forc deploy --unsigned

To deploy a contract to the testnet, you'll need a Fuel wallet. You can initialize a wallet and an account for your wallet to sign transactions.

Check out the documentation for a step-by-step guide to initializing a wallet and creating an account.

Fuel Faucet

Assets for the Testnet node can be obtained from the faucet at https://faucet-beta-1.fuel.network/.

Block Explorer

The block explorer for the testnet can be found here.