You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/PULL_REQUEST_TEMPLATE.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,3 +24,14 @@ The following changes have been made:
24
24
<!--Delete everything after the "#" symbol and replace it with a number. No spaces between hash and number-->
25
25
26
26
Closes #\<issue number\>
27
+
28
+
## Checklist
29
+
30
+
-[ ] I have linked to any relevant issues.
31
+
-[ ] I have commented my code, particularly in hard-to-understand areas.
32
+
-[ ] I have updated the documentation where relevant (API docs, the reference, and the Sway book).
33
+
-[ ] If my change requires substantial documentation changes, I have [requested support from the DevRel team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
34
+
-[ ] I have added tests that prove my fix is effective or that my feature works.
35
+
-[ ] I have added (or requested a maintainer to add) the necessary `Breaking*` or `New Feature` labels where relevant.
36
+
-[ ] 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).
37
+
-[ ] I have requested a review from the relevant team or maintainers.
The purpose of this repository is to contain standards for the Sway Language which users can import and use.
25
+
The purpose of this repository is to contain standards for the Sway Language which users can import and use.
26
26
27
-
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.
27
+
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.
28
28
29
29
If you don't find what you're looking for, feel free to create an issue and propose a new standard!
30
30
@@ -36,7 +36,7 @@ If you don't find what you're looking for, feel free to create an issue and prop
36
36
### Native Assets
37
37
38
38
-[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.
39
-
-[SRC-3; Mint and Burn](./SRCs/src-3.md) is used to enable mint and burn functionality for Native Assets.
39
+
-[SRC-3; Mint and Burn](./SRCs/src-3.md) is used to enable mint and burn functionality for fungible assets.
40
40
-[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).
41
41
-[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.
42
42
-[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`
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.
93
93
@@ -119,15 +119,15 @@ Example of the SRC-5 implementation where a contract has an owner set at compile
Copy file name to clipboardExpand all lines: SRCs/src-10.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -98,7 +98,7 @@ The `token_address` field MUST represent the bridged token's address on the cano
98
98
99
99
#### - token_id: `b256`
100
100
101
-
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.
101
+
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.
102
102
103
103
#### - decimals: `u8`
104
104
@@ -132,7 +132,7 @@ The `token_address` field MUST represent the bridged token's address on the cano
132
132
133
133
#### token_id: `b256`
134
134
135
-
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.
135
+
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.
The following proposes a standard for simple upgradable proxies.
6
+
7
+
## Motivation
8
+
9
+
We seek to standardize proxy implementation to improve developer experience and enable tooling to automatically deploy or update proxies as needed.
10
+
11
+
## Prior Art
12
+
13
+
[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.
14
+
15
+
Proxy designs fall into three essential categories:
16
+
1. Immutable proxies which are lightweight clones of other contracts but can't change targets
17
+
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
18
+
3.[Diamonds](https://eips.ethereum.org/EIPS/eip-2535) which are both upgradable and can point to multiple targets on a per method basis
19
+
20
+
This document falls in the second category. We want to standardize the implementation of simple upgradable passthrough contracts.
21
+
22
+
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.
23
+
24
+
## Specification
25
+
26
+
### Required Behavior
27
+
28
+
The proxy contract MUST maintain the address of its target in its storage at slot `0x7bb458adc1d118713319a5baa00a2d049dd64d2916477d2688d76970c898cd55` (equivalent to `sha256("storage_SRC14_0")`).
29
+
It SHOULD base other proxy specific storage fields at `sha256("storage_SRC14")` to avoid collisions with target storage.
30
+
It MAY have its storage definition overlap with that of its target if necessary.
31
+
32
+
The proxy contract MUST delegate any method call not part of its interface to the target contract.
33
+
34
+
This delegation MUST retain the storage context of the proxy contract.
35
+
36
+
### Required Public Functions
37
+
38
+
The following functions MUST be implemented by a proxy contract to follow the SRC-14 standard:
If a valid call is made to this function it MUST change the target address of the proxy to `new_target`.
43
+
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).
44
+
45
+
## Rationale
46
+
47
+
This standard is meant to provide simple upgradability, it is deliberately minimalistic and does not provide the level of functionality of diamonds.
48
+
49
+
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.
50
+
This prevents irrecoverable updates if a proxy is made to point to another proxy and no longer has access to upgrade logic.
51
+
52
+
## Backwards Compatibility
53
+
54
+
SRC-14 is intended to be compatible with SRC-5 and other standards of contract functionality.
55
+
56
+
As it is the first attempt to standardize proxy implementation, we do not consider interoperability with other proxy standards.
57
+
58
+
## Security Considerations
59
+
60
+
Permissioning proxy target changes is the primary consideration here.
61
+
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.
Copy file name to clipboardExpand all lines: SRCs/src-20.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,13 +11,13 @@ The following standard allows for the implementation of a standard API for [Nati
11
11
12
12
# Motivation
13
13
14
-
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/).
14
+
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/).
15
15
16
16
# Prior Art
17
17
18
18
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.
19
19
20
-
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).
20
+
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).
21
21
22
22
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.
23
23
@@ -47,7 +47,7 @@ This function must return the symbol of the asset, such as “ETH”. This funct
47
47
48
48
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.
49
49
50
-
## Non-Fungible Asset Restrictions
50
+
## Non-Fungible Asset Restrictions
51
51
52
52
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:
53
53
@@ -56,9 +56,9 @@ Non-Fungible Tokens (NFT) or Non-Fungible Assets on Fuel are Native Assets and t
56
56
57
57
# Rationale
58
58
59
-
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.
59
+
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.
60
60
61
-
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.
61
+
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.
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.
Copy file name to clipboardExpand all lines: SRCs/src-3.md
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Abstract
2
2
3
-
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.
3
+
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.
4
4
5
5
# Motivation
6
6
@@ -16,27 +16,27 @@ Minting and burning were initially added to the [SRC-20](./src-20.md) standard.
16
16
17
17
The following functions MUST be implemented to follow the SRC-3 standard:
This function MUST mint `amount` coins with sub-identifier `vault_sub_id` and transfer them to the `recipient`.
21
+
This function MUST mint `amount` coins with sub-identifier `sub_id` and transfer them to the `recipient`.
22
22
This function MAY contain arbitrary conditions for minting, and revert if those conditions are not met.
23
23
24
24
##### Arguments
25
25
26
26
*`recipient` - The `Identity` to which the newly minted asset is transferred to.
27
-
*`vault_sub_id` - The sub-identifier of the asset to mint.
27
+
*`sub_id` - The sub-identifier of the asset to mint.
28
28
*`amount` - The quantity of coins to mint.
29
29
30
-
### `fn burn(vault_sub_id: SubId, amount: u64)`
30
+
### `fn burn(sub_id: SubId, amount: u64)`
31
31
32
-
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.
32
+
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.
33
33
This function MUST ensure at least `amount` coins have been transferred to the implementing contract.
34
34
This function MUST update the total supply defined in the [SRC-20](./src-20.md) standard.
35
35
This function MAY contain arbitrary conditions for burning, and revert if those conditions are not met.
36
36
37
37
##### Arguments
38
38
39
-
*`vault_sub_id` - The sub-identifier of the asset to burn.
39
+
*`sub_id` - The sub-identifier of the asset to burn.
40
40
*`amount` - The quantity of coins to burn.
41
41
42
42
# Rationale
@@ -57,10 +57,10 @@ The burn function may also introduce a security consideration if the total suppl
0 commit comments