Fuel is an operating system purpose-built for Ethereum rollups, designed to help developers build decentralized economies at scale.

Fuel Academy

For those hunting on the Fuel Attackathon who have no idea where to start, this is what you need to read right now.

Where You’ll Get the Best ROI Bughunting

Where to Start

Event topics range from how to interact with Fuel, to advanced Sway concepts, and many more. All including a community Q&A and hosted on the Immunefi Discord.

Event Calendar

From June 6th to 19th Fuel and their security partners will be presenting technical walkthroughs to help you understand and bughunt on Fuel.

Live Technical Walkthroughs

Foundations of the Fuel Network

Understand the basics of how the Fuel VM works.

Getting Started with Fuel Network

Ethereum vs. Fuel Network

Follow the lifecycle of a transaction on Fuel.

Lifecycle of a Fuel Transaction

Bridging Fuel and Ethereum

Fuel Network - Basics

Read the technical specifications for the protocol.

Fuel Specifications

Read the technical specifications for the Fuel Virtual Machine.

Fuel VM Specifications

Read the technical specifications for the transaction format used in Fuel.

Fuel Transaction Specifications

Read the technical specifications for ABIs.

Fuel VM and Sway Contract ABI

Fuel Network - Advanced

Learn about the main 4 program types of the Sway language.

Sway: The Big Four

Learn the basics of the Sway language syntax.

Foundations of the Sway Language

Learn blockchain-specific features of the Sway language.

Getting Started with Sway

Test out the Sway without installing anything with the Sway playground.

Sway Playground

Learn how to write, test, and deploy a simple Sway contract.

Writing a Sway Smart Contract

Explore the reference for Sway's std-lib.

Sway Standard Library

Explore utility libraries written in Sway.

Sway Community Libraries

Dive into some advanced features of Sway, like generics and traits.

Advanced Sway

Explore standards for assets, ownership, and more.

Sway Standards (SRC)

Sway Language

Test out queries with the GraphQL playground for Fuel's RPC API.

Data Query Playground

Learn how to query the blockchain through the official Provider API from the Rust SDK

Query Data with the Rust SDK

Learn from example queries to test out the Fuel GraphQL API

Recipes for Data Queries

Learn more about the types, queries, and mutations used in the Fuel GraphQL API.

Investigating on chain data

Investigating on Chain Data

How to setup a PoC locally using FuelVM and the Forc manager.

How to Make PoCs on Fuel

An in-depth guide for installing `fuelup` and other common setup questions.

Setup and Installation

Learn how do query simple state of a contract using the Rust SDK

Interacting with Contracts

Learn how to run and call contracts from a Sway script

Deploying Scripts

Learn what options are available and how to connect to a Fuel node

Fork the Network

Test a Contract

Step-by-step guide for running a local node.

Run your own Node

A security-focused static analyzer for Sway.

Sway Analyzer

Running a Proof of Concept (PoC)

Take a look into known Issues and workarounds for the Sway language.

Sway Known Issues

Fuel Audits & Known Issues

Learn more about the keywords available in the Sway language.

Sway Keywords Reference Guide

What are some differences between Solidity and the Sway Language?

Solidity vs. Sway

What are some differences between Rust and the Sway Language?

Rust vs. Sway

On the Fuel Forum you can ask Fuel questions directly, receive in-depth technical answers, see what others are discussing and search through their archives.

Fuel Forum

June 3rd to July 22nd you can ask Fuel developers and Immunefi questions directly on Immunefi's #fuel-attackathon Discord channel.

Fuel Attackathon Discord

Browse our education summaries about Fuel and catch up on our Twitter Spaces.

Education Summary Twitter Threads & Recordings

Technical FAQ

Fuel Academy is a learning page with everything you need to know to find bugs on Fuel. With guides to help you learn Fuel fast and use Immunefi successfully. Plus a calendar of live technical walkthroughs.

Attackathons are education-based bughunting contests where whitehat hackers compete over a reward pool by submitting impactful bugs in the project's code.

**Before the Attackathon**<br/> Immunefi works with the project to host a security-focused education period, providing top tier education and support to security researchers.

**During the Attackathon**<br/> Whitehats experience ideal bughunting conditions, with direct project support, responsiveness, and duplicate rewards.

**After the Attackathon**<br/> Immunefi spotlights the security accomplishments, with a custom leaderboard, Attackathon findings report, bug fix reviews, and NFT awards.

Ultimately, Attackathons serve to secure projects, develop their security ecosystem, and create new opportunities for whitehats.

What's an Attackathon?

solidity-contracts :: The L1 contracts for the Fuel bridge that handle deposits and withdrawals on Ethereum

message-predicates :: The L2 deposit receiver which enables minting of funds on Fuel from the bridge

fungible-token :: The L2 contract on fuel which verifies the deposit receiver and mints the actual tokens

sway :: The sway compiler and most Sway tooling (ie. forc, standard library, etc)  *Note: Only the fuelvm target is in scope. The evm and midenVM target are out of scope

fuel-core :: The blockchain client for the L2

fuel-vm :: The fuelvm and the low level shared libraries with Fuel (ie. tx types, assembly code, etc)

fuel-ts :: The typescript sdk which interacts with the blockchain client and compiler

fuel-rs :: The rust sdk which interacts with the blockchain client and compiler

fuel-connectors :: Web2 library that enables apps to connect to fuel supported wallets

fuel-wallet :: Web2 Fuel Wallet extension that allows users to interact with fuel network and stores the private keys / seed phrase of the user

fuel-explorer :: Web2 bridge and explorer UI, that allows users to bridge funds from sepolia to the Fuel Network and also visualize the transactions of the network

**Fuel's changelog per repo at the end of the code update period is:**
- Fuel Bridge : https://github.com/FuelLabs/fuel-bridge/commit/e3e673e31f9e72d757d68979bb6796a0b7f9c8bc 
- sway : https://github.com/FuelLabs/sway/releases/tag/v0.61.2
- sway-libs : Unchanged
- sway-standards : https://github.com/FuelLabs/sway-standards/releases/tag/v0.5.1
- fuel-core : https://github.com/FuelLabs/fuel-core/blob/2faae02d57be88d271893c822c781f34e5f445bc/CHANGELOG.md#version-0310
- fuel-vm : https://github.com/FuelLabs/fuel-vm/blob/2604237c9ff4a755e48b40b2c006711d22cff19f/CHANGELOG.md#version-0550
- fuel-ts : https://github.com/FuelLabs/fuels-ts/releases/tag/v0.91.0 
- fuel-rs : Unchanged
- fuel-connectors: https://github.com/FuelLabs/fuel-connectors/releases/tag/v0.8.1 
- fuel-wallet : https://github.com/FuelLabs/fuels-wallet/releases/tag/v0.22.0
- fuel-explorer : Unchanged

Additional Known Issues have also been added to the section 'Post Code Update Period Known Issues'. When these issues are fixed they will no longer be considerd known issues and the code will be brought back into scope to find bugs in the fixes. All intended fixes are included in the 'Known Issues' section.


Fuel Network’s codebase can be found here https://github.com/FuelLabs/ . Each asset in scope listed above is of a given hash which is the source of truth of what’s in scope.

Fuel Network will strive to have the Testnet match their Github assets. In cases where they differ, the links in the assets in-scope table will be the source-of-truth as to what’s in-scope. 

**Out of Scope Assets:**
- Only the fuelvm target is in scope for the asset: https://github.com/FuelLabs/sway/tree/7b56ec734d4a4fda550313d448f7f20dba818b59 . The evm and midenVM target are out of scope
- Any smart contract with text stating that THIS CONTRACT IS DEPRECATED is out of scope.
- FuelERC721Gateway contracts are also out of scope because they are pending development of a new version.

**The Testnet deployment can be found here:**

- FuelChainState - https://sepolia.etherscan.io/address/0x404F391F96798B14C5e99BBB4a9C858da9Cf63b5 
- Fuel Message Portal - https://sepolia.etherscan.io/address/0x01855B78C1f8868DE70e84507ec735983bf262dA 
- FuelERC20GatewayV4 - https://sepolia.etherscan.io/address/0xa97200022c7aDb1b15f0f61f374E3A0c90e2Efa0


**Previous Audits & Public Disclosure of Known Issues**

Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk. 

Fuel Network’s completed audit reports can be found at https://github.com/FuelLabs/audits . Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.

**Post Code Update Period Known Issues:**
- P2P is doing a lot of database lookups - https://github.com/FuelLabs/fuel-core/issues/2023
- Sequential opcodes return an error when touching the last storage key - https://github.com/FuelLabs/fuel-core/issues/2022
- Unlimited spamming of TxPool - https://github.com/FuelLabs/fuel-core/issues/2021
- Transaction pool can be manipulated to do a lot of cleanups - https://github.com/FuelLabs/fuel-core/issues/2020
- The block production should take into account the available number of transactions - https://github.com/FuelLabs/fuel-core/issues/2019
- During block production should modify the block after passing all checks - https://github.com/FuelLabs/fuel-core/issues/2018
- Slow GraphQL request sender can drain resources of the node - https://github.com/FuelLabs/fuel-core/issues/2017
- WDCM and WQCM implementation mismatch with the specification - https://github.com/FuelLabs/fuel-vm/issues/791

The following fixes will be deployed for the above known issues, at which point they'll no longer be known issues and will be brough back into scope to find bugs in again:
- Optimize getting of transactions for blocks during network synchronization to decrease the load from p2p service.
- Fix for the edge case for sequential opcodes to not return an error when the last key of operation is still in the range.
- Handled the gas price and number of available transactions during the selection of the transaction in the TxPool.
- Updated the executor's block production logic to modify the block only after transaction is valid.
- Added increasing the base gas price based on the demand.
- Optimize SMT updates within the transactions execution.
- Fix 'WDCM' and `WQCM` to match the specification.

**Miscellaneous issues:**

- https://github.com/FuelLabs/fuels-rs/issues/1361
- https://github.com/FuelLabs/sway/issues/6060
- https://github.com/FuelLabs/sway-playground/issues/56
- https://github.com/FuelLabs/sway/issues/5727
- https://github.com/FuelLabs/fuels-wallet/issues/1322
- https://github.com/FuelLabs/fuels-ts/issues/2443
- https://github.com/FuelLabs/sway/issues/6091
- https://github.com/FuelLabs/fuels-ts/issues/2492
- https://github.com/FuelLabs/sway/issues/6118
- https://github.com/FuelLabs/fuel-explorer/issues/366
- https://github.com/FuelLabs/sway/issues/418
- https://github.com/FuelLabs/sway/issues/5892
- https://github.com/FuelLabs/sway/issues/5124
- https://github.com/FuelLabs/sway/issues/15
- https://github.com/FuelLabs/sway/issues/5886
- https://github.com/FuelLabs/sway/issues/5049 
- https://github.com/FuelLabs/fuel-core/issues/1961
- https://github.com/FuelLabs/fuel-core/issues/1966
- https://github.com/FuelLabs/fuel-core/issues/1967
- https://github.com/FuelLabs/fuel-core/issues/1049
- https://github.com/FuelLabs/fuel-core/issues/1968
- https://github.com/FuelLabs/fuel-core/issues/1969
- https://github.com/FuelLabs/fuel-core/issues/1970
- https://github.com/FuelLabs/fuel-core/issues/1971
- https://github.com/FuelLabs/fuel-vm/issues/764
- https://github.com/FuelLabs/fuel-vm/issues/757

There may be other low severity findings tracked in these repos github issues which are not exhaustively listed here. You can check for publicly described issues on GitHub before sending the submission by using keywords from the finding.

## Asset In Scope Policies

**Asset Accuracy Assurance**

Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.

**Private Known Issues Reward Policy**

Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward.

**Primacy of Impact vs Primacy of Rules**

Fuel Network adheres to the Primacy of Rules, which means that the whole Attackathon is run strictly under the terms and conditions stated within this page.

Fuel is an operating system purpose built for Ethereum Rollups. Fuel allows rollups to solve for PSI (parallelization, state minimized execution, interoperability) without making any sacrifices.

Unintended permanent chain split requiring hard fork (network partition requiring hard fork)

Bypassing the bridge timelock

Permanent freezing of funds on the L1 Bridge side

Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Direct theft of any user NFTs, whether at-rest or in-motion, other than unclaimed royalties

Permanent freezing of funds

Permanent freezing of NFTs

Unauthorized minting of NFTs

Predictable or manipulable RNG that results in abuse of the principal or NFT

Unintended alteration of what the NFT represents (e.g. token URI, payload, artistic content)

Direct loss of funds

Execute arbitrary system commands

Subdomain takeover with already-connected wallet interaction

Direct theft of user funds

Permanent freezing of funds (fix requires hardfork)

Temporary freezing of network transactions by delaying one block by 3000% or more of the average block time of the preceding 24 hours beyond standard difficulty adjustments

Theft of unclaimed yield

Theft of unclaimed royalties

Permanent freezing of unclaimed yield

Permanent freezing of unclaimed royalties

Temporary freezing of funds for at least 1 hour

Temporary freezing of NFTs for at least 1 hour

Taking down the application/website

Subdomain takeover without already-connected wallet interaction

Network not being able to confirm new transactions (total network shutdown)

Causing network processing nodes to process transactions from the mempool beyond set parameters (e.g. prevents processing transactions from the mempool)

Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours

Shutdown of greater than or equal to 30% of network processing nodes without brute force actions, but does not shut down the network

A bug in the respective layer 0/1/2 network code that results in unintended smart contract behavior with no concrete funds at direct risk

Modification of transaction fees outside of design parameters

Smart contract unable to operate due to lack of token funds

Block stuffing

Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Theft of gas

Unbounded gas consumption

Retrieve sensitive data/files from a running server, such as:   /etc/shadow, database passwords, blockchain keys (this does not include non-sensitive environment variables, open source code, or usernames)

Malicious interactions with an already-connected wallet, such as:  Modifying transaction arguments or parameters, Substituting contract addresses, Submitting malicious transactions

Injection of malicious HTML or XSS through metadata

Injecting/modifying the static content on the target application without JavaScript (persistent), such as:  HTML injection without JavaScript, Replacing existing text with arbitrary text, Arbitrary file uploads, etc

RPC API crash affecting projects with greater than or equal to 25% of the market capitalization on top of the respective layer

Shutdown of greater than 10% or equal to but less than 30% of network processing nodes without brute force actions, but does not shut down the network

Contract fails to deliver promised returns, but doesn't lose value

Temporary freezing of funds up to 1 hour

Temporary freezing of NFTs up to 1 hour

Compiler bug

Bugs in the Fuel VM and Compiler are the top priority for Fuel. Whitehats who focus here will earn the greatest rewards and acclaim from Fuel.

**Proof of Concept (PoC) Requirements**

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the [Immunefi PoC Guidelines and Rules](https://immunefisupport.zendesk.com/hc/en-us/articles/9946217628561-Proof-of-Concept-PoC-Guidelines-and-Rules).

**Feasibility Limitations**

The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.

Therefore, Immunefi has developed a set of [feasibility limitation standards](https://immunefisupport.zendesk.com/hc/en-us/articles/16913132495377-Feasibility-Limitation-Standards) which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

The following reward terms are a summary, for the full details read our [Fuel Attackathon Reward Terms](https://immunefisupport.zendesk.com/hc/en-us/articles/25655313192721-Fuel-Attackathon-Reward-Terms).

The reward pool size varies based on the severity of bugs found:

- If one or more Low severity bugs are found the reward pool will be $100,000 USD
- If one or more Medium severity bugs are found the reward pool will be $250,000 USD
- If one or more High severity bugs are found the reward pool will be $500,000 USD

- If 1 Critical severity bug is found the reward pool will be $800,000 USD
- If 2 Critical severity bugs are found the reward pool will be $900,000 USD
- If 3 or more Critical severity bugs are found the reward pool will be $1,000,000 USD

For this Attackathon, duplicates and private known issues are valid for a reward.

Rewards are distributed according to the impact of the vulnerability based on the [Immunefi Vulnerability Severity Classification System V2.3](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/). 

**Reward Payment Terms**

Payouts are handled by the Fuel Network team directly and are denominated in USD. However, payments are done in USDC.

Rewards will be distributed all at once based on Immunefi’s distribution formula after the event has concluded and the final bug reports have been resolved.

**Insight Rewards Payment Terms**

Insight Rewards: Portion of the Rewards Pool

* The "Insight" severity was introduced on Boost & Attackathon programs to recognize contributions that extend beyond identifying immediate vulnerabilities. Currently, it's not an option to select the Insight severity when submitting a report. However, our team or program will designate it accordingly if applicable. "Insights" underscores our commitment to valuing all types of contributions that contribute to a more secure environment and will always be rewarded. [View more information about Insights](https://immunefisupport.zendesk.com/hc/en-us/articles/13333032674961-Severity-Classification-System?utm_source=immunefi)

Attackathon | Fuel Network

Status

Status