fixes

.github/workflows/docs.yaml

@@ -7,5 +7,5 @@ jobs:
   test:
     uses: FuelLabs/github-actions/.github/workflows/mdbook-docs.yml@master
     with:
-      docs-src-path: 'docs'
+      docs-src-path: 'docs/src'
       spellcheck-config-path: 'docs/.spellcheck.yml'

README.md

@@ -35,28 +35,28 @@ 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 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.
+- [SRC-20; Native Asset Standard](./docs/src/src-20-native-asset.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](./docs/src/src-3-minting-and-burning.md) is used to enable mint and burn functionality for fungible assets.
+- [SRC-7; Arbitrary Asset Metadata Standard](./docs/src/src-7-asset-metadata.md) is used to store metadata for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets).
+- [SRC-9; Metadata Keys Standard](./docs/src/src-9-metadata-keys.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](./docs/src/src-6-vault.md) defines the implementation of a standard API for asset vaults developed in Sway.
 
 ### Access Control
 
-- [SRC-5; Ownership Standard](./SRCs/src-5.md) is used to restrict function calls to admin users in contracts.
+- [SRC-5; Ownership Standard](./docs/src/src-5-ownership.md) is used to restrict function calls to admin users in contracts.
 
 ### Contracts
 
-- [SRC-12; Contract Factory](./SRCs/src-12.md) defines the implementation of a standard API for contract factories.
+- [SRC-12; Contract Factory](./docs/src/src-12-contract-factory.md) defines the implementation of a standard API for contract factories.
 
 ### Bridge
 
-- [SRC-8; Bridged Asset](./SRCs/src-8.md) defines the metadata required for an asset bridged to the Fuel Network.
-- [SRC-10; Native Bridge Standard](./SRCs/src-10.md) defines the standard API for the Native Bridge between the Fuel Chain and the canonical base chain.
+- [SRC-8; Bridged Asset](./docs/src/src-8-bridged-asset.md) defines the metadata required for an asset bridged to the Fuel Network.
+- [SRC-10; Native Bridge Standard](./docs/src/src-10-native-bridge.md) defines the standard API for the Native Bridge between the Fuel Chain and the canonical base chain.
 
 ### Documentation
 
-- [SRC-2; Inline Documentation](./SRCs/src-2.md) defines how to document your Sway files.
+- [SRC-2; Inline Documentation](./docs/src/src-2-inline-documentation.md) defines how to document your Sway files.
 
 ## Using a standard
 

docs/.spellcheck.yml

@@ -23,6 +23,6 @@ matrix:
             - code
             - pre
     sources:
-      - 'docs/*.md'
-      - 'docs/**/*.md'
+      - 'docs/src/*.md'
+      - 'docs/src/**/*.md'
     default_encoding: utf-8

docs/spell-check-custom-words.txt

@@ -210,4 +210,53 @@ namespacing
 unsafety
 prioritizations
 polymorphism
-ContractId
+ContractId
+ENS's
+OpenSea's
+URI
+URIs
+Multi
+sha
+EIP
+rata
+withdrawable
+subvault
+soulbound
+configurables
+Configurables
+libs
+backticks
+enum's
+NFT's
+OpenZeppelin
+OpenZeppelin's
+UUPS
+minimalistic
+permissioning
+Permissioning
+Solana
+hardcode
+prepended
+Farcaster
+LinkedIn
+Reddit
+TikTok
+WeChat
+WhatsApp
+UPU
+webpage
+linktree
+SVG
+PNG
+URI
+URIs
+WebP
+HEIF
+WebM
+OGV
+OGG
+WAV
+OGA
+glTF
+GLB
+Uninitalized

docs/src/index.md

@@ -0,0 +1,63 @@
+# Sway Standards
+
+The purpose of the Sway Standards [repository](https://github.com/FuelLabs/sway-standards) 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**
+> All standards currently use `forc v0.60.0`.
+
+## 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:
+
+```toml
+standards = { git = "https://github.com/FuelLabs/sway-standards", tag = "v0.4.4" }
+```
+
+> **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:
+
+```sway
+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:
+
+```sway
+use standards::src20::SRC20;
+```
+
+## Standards
+
+### Native Assets
+
+- [SRC-20; Native Asset Standard](./src-20-native-asset.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](./src-3-minting-and-burning.md) is used to enable mint and burn functionality for fungible assets.
+- [SRC-7; Arbitrary Asset Metadata Standard](./src-7-asset-metadata.md) is used to store metadata for [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets).
+- [SRC-9; Metadata Keys Standard](./src-9-metadata-keys.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](./src-6-vault.md) defines the implementation of a standard API for asset vaults developed in Sway.
+- [SRC-13; Soulbound Address](./src-13-soulbound-address.md) defines the implementation of a soulbound address.
+
+### Security and Access Control
+
+- [SRC-5; Ownership Standard](./src-5-ownership.md) is used to restrict function calls to admin users in contracts.
+- [SRC-11; Security Information Standard](./src-11-security-information.md) is used to make communication information readily available in the case white hat hackers find a vulnerability in a contract.
+
+### Contracts
+
+- [SRC-12; Contract Factory](./src-12-contract-factory.md) defines the implementation of a standard API for contract factories.
+- [SRC-14; Simple Upgradeable Proxies](./src-14-simple-upgradeable-proxies.md) defines the implementation of an upgradeable proxy contract.
+
+### Bridge
+
+- [SRC-8; Bridged Asset](./src-8-bridged-asset.md) defines the metadata required for an asset bridged to the Fuel Network.
+- [SRC-10; Native Bridge Standard](./src-10-native-bridge.md) defines the standard API for the Native Bridge between the Fuel Chain and the canonical base chain.
+
+### Documentation
+
+- [SRC-2; Inline Documentation](./src-2-inline-documentation.md) defines how to document your Sway files.

docs/src-10-native-bridge.md → docs/src/src-10-native-bridge.md

@@ -10,7 +10,7 @@ A standard interface for bridges intends to provide a safe and efficient bridge
 
 The standard is centered on Fuel’s [Bridge Architecture](https://github.com/FuelLabs/fuel-bridge/blob/main/docs/ARCHITECTURE.md). Fuel's bridge system is built on a message protocol that allows to send (and receive) messages between entities located in two different blockchains.
 
-The following standard takes reference from the [FungibleBridge](https://github.com/FuelLabs/fuel-bridge/blob/3971081850e7961d9b649edda4cad8a848ee248e/packages/fungible-token/bridge-fungible-token/src/interface.sw#L22) ABI defined in the fuel-bridge repository.
+The following standard takes reference from the [`FungibleBridge`](https://github.com/FuelLabs/fuel-bridge/blob/3971081850e7961d9b649edda4cad8a848ee248e/packages/fungible-token/bridge-fungible-token/src/interface.sw#L22) ABI defined in the fuel-bridge repository.
 
 ## Specification
 
@@ -23,7 +23,7 @@ The following functions MUST be implemented to follow the SRC-10; Native Bridge
 The `process_message()` function accepts incoming deposit messages from the canonical chain and issues the corresponding bridged asset.
 
 - This function MUST parse a message at the given `message_index` index.
-- This function SHALL mint an asset that follows the [SRC-8; Bridged Asset Standard](./src-8.md).
+- This function SHALL mint an asset that follows the [SRC-8; Bridged Asset Standard](./src-8-bridged-asset.md).
 - This function SHALL issue a refund if there is an error in the bridging process.
 
 ### - `fn withdraw(to_address: b256)`
@@ -45,19 +45,19 @@ The `claim_refund()` function is called if something goes wrong in the bridging
 
 ### `DepositType`
 
-The `DepositType` enum decribes whether the bridged deposit is made to a address, contract, or contract and contains additional metatdata. There MUST be the following varients in the `DepositType` enum:
+The `DepositType` enum describes whether the bridged deposit is made to a address, contract, or contract and contains additional metadata. There MUST be the following variants in the `DepositType` enum:
 
-#### Address: `()`
+#### `Address`: `()`
 
-The `Address` varient MUST represent when the deposit is made to an address on the Fuel chain.
+The `Address` variant MUST represent when the deposit is made to an address on the Fuel chain.
 
-#### Contract: `()`
+#### `Contract`: `()`
 
-The `Contract` varient MUST represent when the deposit is made to an contract on the Fuel chain.
+The `Contract` variant MUST represent when the deposit is made to an contract on the Fuel chain.
 
-#### ContractWithData: `()`
+#### `ContractWithData`: `()`
 
-The `ContractWithData` varient MUST represent when the deposit is made to an contract and contains additional metadata for the Fuel chain.
+The `ContractWithData` variant MUST represent when the deposit is made to an contract and contains additional metadata for the Fuel chain.
 
 #### Example
 
@@ -148,7 +148,7 @@ pub struct MetadataMessage {
 
 ## Required Standards
 
-Any contract that implements the SRC-10; Native Bridge Standard MUST implement the [SRC-8; Bridged Asset Standard](./src-8.md) for all bridged assets.
+Any contract that implements the SRC-10; Native Bridge Standard MUST implement the [SRC-8; Bridged Asset Standard](./src-8-bridged-asset.md) for all bridged assets.
 
 ## Rationale
 

docs/src-11-security-information.md → docs/src/src-11-security-information.md

@@ -8,7 +8,7 @@ White hat hackers may find bugs or exploits in contracts that they want to repor
 
 ## Prior Art
 
-The [security.txt](https://github.com/neodyme-labs/solana-security-txt) library for Solana has explored this idea. This standard takes inspiration from the library, with some changes.
+The [`security.txt`](https://github.com/neodyme-labs/solana-security-txt) library for Solana has explored this idea. This standard takes inspiration from the library, with some changes.
 
 ## Specification
 
@@ -21,7 +21,7 @@ The following describes the `SecurityInformation` type.
 - The struct MAY contain a URL or the information directly for the following fields: `project_url`, `policy`, `encryption`, `source_code`, `auditors`, `acknowledgments`, `additional_information`.
 - The struct MUST contain the information directly for the following fields: `name`, `contact_information`, `preferred_languages`, `source_release`, and `source_revision`.
 - The struct MUST contain at least one item in the `preferred_languages` field's `Vec`, if it is not `None`. Furthermore, the string should only contain the [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes) language code and nothing else.
-- The struct MUST contain at least one item in the `contact_information` field's `Vec`. Furthermore, the string should follow the following format `<contact_type>:<contact_information>`. Where `contact_type` describes the method of contact (eg. `email` or `discord`) and `contact_information` describes the information needed to contact (eg. `example@example.com` or `@EXAMPLE`).
+- The struct MUST contain at least one item in the `contact_information` field's `Vec`. Furthermore, the string should follow the following format `<contact_type>:<contact_information>`. Where `contact_type` describes the method of contact (e.g. `email` or `discord`) and `contact_information` describes the information needed to contact (e.g. `example@example.com` or `@EXAMPLE`).
 
 #### `name: String`
 
@@ -54,11 +54,11 @@ A URL to the project's source code.
 
 #### `source_release: Option<String>`
 
-The release identifier of this build, ideally corresponding to a tag on git that can be rebuilt to reproduce the same binary. 3rd party build verification tools will use this tag to identify a matching github release.
+The release identifier of this build, ideally corresponding to a tag on git that can be rebuilt to reproduce the same binary. 3rd party build verification tools will use this tag to identify a matching GitHub release.
 
 #### `source_revision: Option<String>`
 
-The revision identifier of this build, usually a git commit hash that can be rebuilt to reproduce the same binary. 3rd party build verification tools will use this tag to identify a matching github release.
+The revision identifier of this build, usually a git commit hash that can be rebuilt to reproduce the same binary. 3rd party build verification tools will use this tag to identify a matching GitHub release.
 
 #### `auditors: Option<Vec<String>>`
 

docs/src-12-contract-factory.md → docs/src/src-12-contract-factory.md

@@ -94,7 +94,7 @@ Example of the SRC-12 implementation where contract deployments contain configur
 
 ### Without Configurables
 
-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.
 
 ```sway
 {{#include ../examples/src12-contract-factory/without_configurables/src/without_configurables.sw}}

docs/src-13-soulbound-address.md → docs/src/src-13-soulbound-address.md

@@ -4,7 +4,7 @@ The following standard allows for the implementation of Soulbound Address on the
 
 ## Motivation
 
-A standard enables soulbound assets on Fuel and allows external applications to query and provide soulbound assets, whether that be decentralized exchanges, wallets, or other external applications.
+This standard enables soulbound assets on Fuel and allows external applications to query and provide soulbound assets, whether that be decentralized exchanges, wallets, or other external applications.
 
 ## Prior Art
 
@@ -60,7 +60,7 @@ On the Fuel Network, the process for sending any [Native Assets](https://docs.fu
 
 ## Backwards Compatibility
 
-This standard is compatible with Fuel's [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) and the [SRC-20](./src-20.md) standard.
+This standard is compatible with Fuel's [Native Assets](https://docs.fuel.network/docs/sway/blockchain-development/native_assets) and the [SRC-20](./src-20-native-asset.md) standard.
 
 ## Security Considerations