Skip to content

FuelLabs/sway-standards

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Sway Standards logo

Overview

The purpose of this repository is to contain standards for the Sway Language which users can import and use.

Standards in this repository may be in various stages of development. Use of draft standards and feedback on the proposed standards is encouraged. To use a draft, search for a standard using the appropriate GitHub label and implement the standard abi into your contract.

If you don't find what you're looking for, feel free to create an issue and propose a new standard!

Note Sway is a language under heavy development therefore the standards may not be the most ergonomic. Over time they should receive updates / improvements in order to demonstrate how Sway can be used in real use cases.

Standards

Native Assets

Access Control

Contracts

Bridge

Documentation

Using a standard

To import a standard the following should be added to the project's Forc.toml file under [dependencies] with the most recent release:

standards = { git = "https://github.com/FuelLabs/sway-standards", tag = "v0.5.0" }

NOTE: Be sure to set the tag to the latest release.

You may then import your desired standard in your Sway Smart Contract as so:

use standards::<standard>::<standard_abi>;

For example, to import the SRC-20 Native Asset Standard use the following statement in your Sway Smart Contract file:

use standards::src20::SRC20;

Examples of Standards

Minimal example implementations for every standard can be found in the examples/ folder.

SRC-20; Native Asset Standard Examples

Example of the SRC-20 implementation where a contract contains a single asset with one SubId. This implementation is recommended for users that intend to deploy a single asset with their contract.

Example of the SRC-20 implementation where a contract contains multiple assets with differing SubIds. This implementation is recommended for users that intend to deploy multiple assets with their contract.

SRC-3; Mint and Burn Standard Examples

Example of the SRC-3 implementation where a contract only mints a single asset with one SubId.

Example of the SRC-3 implementation where a contract mints multiple assets with differing SubIds.

SRC-5; Ownership Examples

Example of the SRC-5 implementation where a contract does not have an owner set at compile time with the intent to set it during runtime.

Example of the SRC-5 implementation where a contract has an owner set at compile time.

SRC-6; Vault Standard Examples

A basic implementation of the vault standard that supports any number of sub vaults being created for every AssetId.

A basic implementation of the vault standard demonstrating how to restrict deposits and withdrawals to a single AssetId.

A basic implementation of the vault standard demonstrating how to restrict deposits and withdrawals to a single AssetId, and to a single Sub vault.

SRC-7; Arbitrary Asset Metadata Standard Examples

Example of the SRC-7 implementation where metadata exists for only a single asset with one SubId.

Example of the SRC-7 implementation where metadata exists for multiple assets with differing SubIds.

SRC-12; Contract Factory Standard Examples

Example of the SRC-12 implementation where contract deployments contain configurable values that differentiate the bytecode root from other contracts with the same bytecode.

Example of the SRC-12 implementation where all contract deployments are identitcal and thus have the same bytecode and root.

Note All standards currently use forc v0.56.0.

Note The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these documents are to be interpreted as described in RFC 2119: https://www.ietf.org/rfc/rfc2119.txt