Release v0.5.0 (#101)

* docs: fix typos in README (#86)

* change vault_sub_id back to sub_id

* docs: improve SRC-20 (#88)

* docs: improve SRC-3 (#85)

* Update to latest Sway

Transform abusive usage of configurables into constants to support
latest version of Sway that uses encoded configurables.

* Update README.md

* SRC-14 Simple Proxy Standard

* Apply suggestions from code review

Co-authored-by: Cameron Carstens <bitzoic.eth@gmail.com>

* Set standard target address storage location

* Apply suggestions from code review

Co-authored-by: SwayStar123 <46050679+SwayStar123@users.noreply.github.com>

* Update SRCs/src-14.md

Co-authored-by: Cameron Carstens <bitzoic.eth@gmail.com>

* Correct typo

* Apply suggestions from code review

Co-authored-by: João Matos <joao@tritao.eu>

* Add link to UUPS

* Update to forc v0.60.0 (#96)

* Update to forc v0.60.0

* Run formatter

* address PR comments

* Update CI

* Delete docs.yml and gh-pages.yml

* Update pull request template to include checklist (#93)

* Fix README for release

---------

Co-authored-by: Paul Razvan Berg <paul.razvan.berg@gmail.com>
Co-authored-by: SwayStar123 <swayambhanded@gmail.com>
Co-authored-by: Paul Razvan Berg <prberg@proton.me>
Co-authored-by: SwayStar123 <46050679+SwayStar123@users.noreply.github.com>
Co-authored-by: IGI-111 <igi-111@protonmail.com>
Co-authored-by: João Matos <joao@tritao.eu>
Co-authored-by: K1-R1 <77465250+K1-R1@users.noreply.github.com>

.github/PULL_REQUEST_TEMPLATE.md

@@ -24,3 +24,14 @@ The following changes have been made:
 <!--Delete everything after the "#" symbol and replace it with a number. No spaces between hash and number-->
 
 Closes #\<issue number\>
+
+## Checklist
+
+- [ ] I have linked to any relevant issues.
+- [ ] I have commented my code, particularly in hard-to-understand areas.
+- [ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
+   - [ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
+- [ ] I have added tests that prove my fix is effective or that my feature works.
+- [ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant.
+- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs Code Review Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
+- [ ] I have requested a review from the relevant team or maintainers.

.github/workflows/ci.yaml

@@ -15,9 +15,9 @@ concurrency:
 env:
   CARGO_TERM_COLOR: always
   REGISTRY: ghcr.io
-  RUST_VERSION: 1.75.0
-  FORC_VERSION: 0.56.0
-  CORE_VERSION: 0.24.2
+  RUST_VERSION: 1.77.0
+  FORC_VERSION: 0.60.0
+  CORE_VERSION: 0.26.0
   PATH_TO_SCRIPTS: .github/scripts
 
 jobs:

README.md

@@ -9,8 +9,8 @@
     <a href="https://github.com/FuelLabs/sway-standards/actions/workflows/ci.yml" alt="CI">
         <img src="https://github.com/FuelLabs/sway-standards/actions/workflows/ci.yml/badge.svg" />
     </a>
-    <a href="https://crates.io/crates/forc/0.49.1" alt="forc">
-        <img src="https://img.shields.io/badge/forc-v0.49.1-orange" />
+    <a href="https://crates.io/crates/forc/0.60.0" alt="forc">
+        <img src="https://img.shields.io/badge/forc-v0.60.0-orange" />
     </a>
     <a href="./LICENSE" alt="forc">
         <img src="https://img.shields.io/github/license/FuelLabs/sway-standards" />
@@ -22,9 +22,9 @@
 
 ## Overview
 
-The purpose of this repository is to contain standards for the Sway Language which users can import and use. 
+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. 
+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!
 
@@ -36,7 +36,7 @@ If you don't find what you're looking for, feel free to create an issue and prop
 ### Native Assets
 
 - [SRC-20; Native Asset Standard](./SRCs/src-20.md) defines the implementation of a standard API for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) using the Sway Language.
-- [SRC-3; Mint and Burn](./SRCs/src-3.md) is used to enable mint and burn functionality for Native Assets.
+- [SRC-3; Mint and Burn](./SRCs/src-3.md) is used to enable mint and burn functionality for fungible assets.
 - [SRC-7; Arbitrary Asset Metadata Standard](./SRCs/src-7.md) is used to store metadata for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets).
 - [SRC-9; Metadata Keys Standard](./SRCs/src-9.md) is used to store standardized metadata keys for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) in combination with the SRC-7 standard.
 - [SRC-6; Vault Standard](./SRCs/src-6.md) defines the implementation of a standard API for asset vaults developed in Sway.
@@ -66,7 +66,7 @@ To import a standard the following should be added to the project's `Forc.toml`
 standards = { git = "https://github.com/FuelLabs/sway-standards", tag = "v0.5.0" }
 ```
 
-> **NOTE:** 
+> **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:
@@ -87,7 +87,7 @@ Minimal example implementations for every standard can be found in the [`example
 
 #### SRC-20; Native Asset Standard Examples
 
-##### - [Single Native Assset](./examples/src20-native-asset/single_asset/src/single_asset.sw)
+##### - [Single Native Asset](./examples/src20-native-asset/single_asset/src/single_asset.sw)
 
 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.
 
@@ -119,15 +119,15 @@ Example of the SRC-5 implementation where a contract has an owner set at compile
 
 ##### [Multi Asset Vault](./examples/src6-vault/multi_asset_vault/)
 
-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 that supports any number of sub vaults being created for every `AssetId`.
 
 ##### [Single Asset Vault](./examples/src6-vault/single_asset_vault/)
 
-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`.
 
 ##### [Single Asset Single Sub Vault](./examples/src6-vault/single_asset_single_sub_vault/)
 
-A basic implementation of the vault standard demonstrating how to restrict deposits and withdrawals to a single AssetId, and to a single Sub vault.
+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
 
@@ -147,10 +147,10 @@ Example of the SRC-12 implementation where contract deployments contain configur
 
 ##### [Without Configurables](./examples/src12-contract-factory/without_configurables/src/without_configurables.sw)
 
-Example of the SRC-12 implementation where all contract deployments are identitcal and thus have the same bytecode and root.
+Example of the SRC-12 implementation where all contract deployments are identical and thus have the same bytecode and root.
 
 > **Note**
-> All standards currently use `forc v0.56.0`.
+> All standards currently use `forc v0.60.0`.
 
 <!-- TODO:
 ## Contributing

SRCs/src-10.md

@@ -98,7 +98,7 @@ The `token_address` field MUST represent the bridged token's address on the cano
 
 #### - token_id: `b256`
 
-The `token_id` field MUST represent the token's ID on the canonical chain. The `ZERO_B256` MUST be used if this is a fungible token and no token ID exists.
+The `token_id` field MUST represent the token's ID on the canonical chain. The `b256::zero()` MUST be used if this is a fungible token and no token ID exists.
 
 #### - decimals: `u8`
 
@@ -132,7 +132,7 @@ The `token_address` field MUST represent the bridged token's address on the cano
 
 #### token_id: `b256`
 
-The `token_id` field MUST represent the token's ID on the canonical chain. The `ZERO_B256` MUST be used if this is a fungible token and no token ID exists.
+The `token_id` field MUST represent the token's ID on the canonical chain. The `b256::zero()` MUST be used if this is a fungible token and no token ID exists.
 
 #### name: `String`
 

SRCs/src-14.md

@@ -0,0 +1,80 @@
+# Simple Upgradable Proxies
+
+## Abstract
+
+The following proposes a standard for simple upgradable proxies.
+
+## Motivation
+
+We seek to standardize proxy implementation to improve developer experience and enable tooling to automatically deploy or update proxies as needed.
+
+## Prior Art
+
+[This OpenZeppelin blog post](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades#proxies-and-implementations) is a good survey of the state of the art at this time.
+
+Proxy designs fall into three essential categories:
+1. Immutable proxies which are lightweight clones of other contracts but can't change targets
+2. Upgradable proxies such as [UUPS](https://eips.ethereum.org/EIPS/eip-1822) which store a target in storage and delegate all calls to it
+3. [Diamonds](https://eips.ethereum.org/EIPS/eip-2535) which are both upgradable and can point to multiple targets on a per method basis
+
+This document falls in the second category. We want to standardize the implementation of simple upgradable passthrough contracts.
+
+The FuelVM provides an `LDC` instruction that is used by Sway's `std::execution::run_external` to provide a similar behavior to EVM's `delegatecall` and execute instructions from another contract while retaining one's own storage context. This is the intended means of implementation of this standard.
+
+## Specification
+
+### Required Behavior
+
+The proxy contract MUST maintain the address of its target in its storage at slot `0x7bb458adc1d118713319a5baa00a2d049dd64d2916477d2688d76970c898cd55` (equivalent to `sha256("storage_SRC14_0")`).
+It SHOULD base other proxy specific storage fields at `sha256("storage_SRC14")` to avoid collisions with target storage.
+It MAY have its storage definition overlap with that of its target if necessary.
+
+The proxy contract MUST delegate any method call not part of its interface to the target contract.
+
+This delegation MUST retain the storage context of the proxy contract.
+
+### Required Public Functions
+
+The following functions MUST be implemented by a proxy contract to follow the SRC-14 standard:
+
+#### `fn set_proxy_target(new_target: ContractId);`
+
+If a valid call is made to this function it MUST change the target address of the proxy to `new_target`.
+This method SHOULD implement access controls such that the target can only be changed by a user that possesses the right permissions (typically the proxy owner).
+
+## Rationale
+
+This standard is meant to provide simple upgradability, it is deliberately minimalistic and does not provide the level of functionality of diamonds.
+
+Unlike in [UUPS](https://eips.ethereum.org/EIPS/eip-1822), this standard requires that the upgrade function is part of the proxy and not its target.
+This prevents irrecoverable updates if a proxy is made to point to another proxy and no longer has access to upgrade logic.
+
+## Backwards Compatibility
+
+SRC-14 is intended to be compatible with SRC-5 and other standards of contract functionality.
+
+As it is the first attempt to standardize proxy implementation, we do not consider interoperability with other proxy standards.
+
+## Security Considerations
+
+Permissioning proxy target changes is the primary consideration here.
+This standard is not opinionated about means of achieving this, use of [SRC-5](https://github.com/FuelLabs/sway-standards/blob/master/SRCs/src-5.md) is recommended.
+
+## Example ABI
+
+```sway
+abi SRC14 {
+    #[storage(write)]
+    fn set_proxy_target(new_target: ContractId);
+}
+```
+
+## Example Implementation
+
+### [Minimal Proxy](../examples/examples/src14-simple-proxy/owned/src/minimal.sw)
+
+Example of a minimal SRC-14 implementation with no access control.
+
+### [Owned Proxy](../examples/examples/src14-simple-proxy/owned/src/owned.sw)
+
+Example of a SRC-14 implementation that also implements [SRC-5](https://github.com/FuelLabs/sway-standards/blob/master/SRCs/src-5.md).

SRCs/src-2.md

@@ -331,7 +331,7 @@ This standard will improve security by providing developers with relevant inform
 /// use ownable::Ownership;
 ///
 /// storage {
-///     owner: Ownership = Ownership::initalized(Identity::Address(Address::from(ZERO_B256))),
+///     owner: Ownership = Ownership::initalized(Identity::Address(Address::zero())),
 /// }
 ///
 /// fn foo() {

SRCs/src-20.md

@@ -11,13 +11,13 @@ The following standard allows for the implementation of a standard API for [Nati
 
 # Motivation
 
-A standard interface for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) on Fuel allows external applications to interact with the native asset, whether that be decentralized exchanges, wallets, or Fuel's [Scripts](https://docs.fuel.network/docs/sway/sway-program-types/scripts/) and [Predicates](https://docs.fuel.network/docs/sway/sway-program-types/predicates/). 
+A standard interface for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) on Fuel allows external applications to interact with the native asset, whether that be decentralized exchanges, wallets, or Fuel's [Scripts](https://docs.fuel.network/docs/sway/sway-program-types/scripts/) and [Predicates](https://docs.fuel.network/docs/sway/sway-program-types/predicates/).
 
 # Prior Art
 
 The SRC-20 Native Asset Standard naming pays homage to the [ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) seen on Ethereum. While there is functionality we may use as a reference, it is noted that Fuel's [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) are fundamentally different than Ethereum's tokens.
 
-There has been a discussion of the Fungile Token Standard on the [Fuel Forum](https://forum.fuel.network/). This discussion can be found [here](https://forum.fuel.network/t/src-20-fungible-token-standard/186). 
+There has been a discussion of the Fungible Token Standard on the [Fuel Forum](https://forum.fuel.network/). This discussion can be found [here](https://forum.fuel.network/t/src-20-fungible-token-standard/186). 
 
 There has also been a Fungible Token Standard and Non-Fungible Token Standard implementations added to the [Sway-Libs](https://github.com/FuelLabs/sway-libs) repository before the creation of the [Sway-Standards](https://github.com/FuelLabs/sway-standards) repository. The introduction of this standard in the [Sway-Standards](https://github.com/FuelLabs/sway-standards) repository will deprecate the Sway-Libs Fungible Token Standard.
 
@@ -47,7 +47,7 @@ This function must return the symbol of the asset, such as “ETH”. This funct
 
 This function must return the number of decimals the asset uses - e.g. 8, which means to divide the coin amount by 100000000 to get its user representation. This function MUST return `Some` for any assets minted by the contract.
 
-## Non-Fungible Asset Restrictions 
+## Non-Fungible Asset Restrictions
 
 Non-Fungible Tokens (NFT) or Non-Fungible Assets on Fuel are Native Assets and thus follow the same standard as Fungible Native Assets with some restrictions. For a Native Asset on Fuel to be deemed an NFT, the following must be applied:
 
@@ -56,9 +56,9 @@ Non-Fungible Tokens (NFT) or Non-Fungible Assets on Fuel are Native Assets and t
 
 # Rationale
 
-As the SRC-20 Native Asset Standard leverages Native Assets on Fuel, we do not require the implementation of certain functions such as transfer or approval. This is done directly within the FuelVM and there is no smart contract that requires updating of balances. As Fuel is UTXO based, any transfer events may be indexed on transaction receipts. 
+As the SRC-20 Native Asset Standard leverages Native Assets on Fuel, we do not require the implementation of certain functions such as transfer or approval. This is done directly within the FuelVM and there is no smart contract that requires updating of balances. As Fuel is UTXO based, any transfer events may be indexed on transaction receipts.
 
-Following this, we have omitted the inclusion of any transfer functions or events. The provided specification outlines only the required functions and events to implement fully functional native assets on the Fuel Network. Additional functionality and properties may be added as needed.
+Following this, we have omitted the inclusion of any transfer functions or events. The provided specification outlines only the functions necessary to implement fully functional native assets on the Fuel Network. Additional functionality and properties may be added as needed.
 
 # Backwards Compatibility
 
@@ -87,7 +87,7 @@ abi MyAsset {
 
 # Example Implementation
 
-## [Single Native Assset](../examples/src20-native-asset/multi_asset/src/multi_asset.sw)
+## [Single Native Asset](../examples/src20-native-asset/multi_asset/src/multi_asset.sw)
 
 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.
 

SRCs/src-3.md

@@ -1,6 +1,6 @@
 # Abstract
 
-The following standard enables the minting and burning of native assets for any fungible assets within the Sway Language. It seeks to define mint and burn functions defined separately from the [SRC-20](./src-20.md) standard. Any contract that implements the SRC-3 standard MUST implement the [SRC-20](./src-20.md) standard.
+The following standard enables the minting and burning of native assets for any fungible assets within the Sway Language. It seeks to define mint and burn functions defined separately from the [SRC-20](./src-20.md) standard.
 
 # Motivation
 
@@ -16,27 +16,27 @@ Minting and burning were initially added to the [SRC-20](./src-20.md) standard.
 
 The following functions MUST be implemented to follow the SRC-3 standard:
 
-### `fn mint(recipient: Identity, vault_sub_id: SubId, amount: u64)`
+### `fn mint(recipient: Identity, sub_id: SubId, amount: u64)`
 
-This function MUST mint `amount` coins with sub-identifier `vault_sub_id` and transfer them to the `recipient`. 
+This function MUST mint `amount` coins with sub-identifier `sub_id` and transfer them to the `recipient`. 
 This function MAY contain arbitrary conditions for minting, and revert if those conditions are not met.
 
 ##### Arguments
 
 * `recipient` - The `Identity` to which the newly minted asset is transferred to.
-* `vault_sub_id` - The sub-identifier of the asset to mint.
+* `sub_id` - The sub-identifier of the asset to mint.
 * `amount` - The quantity of coins to mint.
 
-### `fn burn(vault_sub_id: SubId, amount: u64)`
+### `fn burn(sub_id: SubId, amount: u64)`
 
-This function MUST burn `amount` coins with the sub-identifier `vault_sub_id` and MUST ensure the `AssetId` of the asset is the sha-256 hash of `(ContractId, SubId)` for the implementing contract. 
+This function MUST burn `amount` coins with the sub-identifier `sub_id` and MUST ensure the `AssetId` of the asset is the sha-256 hash of `(ContractId, SubId)` for the implementing contract. 
 This function MUST ensure at least `amount` coins have been transferred to the implementing contract. 
 This function MUST update the total supply defined in the [SRC-20](./src-20.md) standard. 
 This function MAY contain arbitrary conditions for burning, and revert if those conditions are not met.
 
 ##### Arguments
 
-* `vault_sub_id` - The sub-identifier of the asset to burn.
+* `sub_id` - The sub-identifier of the asset to burn.
 * `amount` - The quantity of coins to burn.
 
 # Rationale
@@ -57,10 +57,10 @@ The burn function may also introduce a security consideration if the total suppl
 ```rust
 abi MySRC3Asset {
     #[storage(read, write)]
-    fn mint(recipient: Identity, vault_sub_id: SubId, amount: u64);
+    fn mint(recipient: Identity, sub_id: SubId, amount: u64);
     #[payable]
     #[storage(read, write)]
-    fn burn(vault_sub_id: SubId, amount: u64);
+    fn burn(sub_id: SubId, amount: u64);
 }
 ```