From d79cdf1b07f901ceba91b85ffacde23916bfbf61 Mon Sep 17 00:00:00 2001 From: cshannon1218 Date: Wed, 3 Dec 2025 13:20:38 -0600 Subject: [PATCH] Core Contracts build doc edits. --- .../core-contracts/02-fungible-token.md | 52 +++--- .../cadence/core-contracts/03-flow-token.md | 53 +++--- .../core-contracts/04-service-account.md | 38 ++-- .../cadence/core-contracts/05-flow-fees.md | 11 +- .../06-staking-contract-reference.md | 64 ++++--- .../07-epoch-contract-reference.md | 81 +++++---- .../core-contracts/08-non-fungible-token.md | 72 ++++---- .../cadence/core-contracts/09-nft-metadata.md | 24 ++- .../core-contracts/10-nft-storefront.md | 162 +++++++++--------- .../core-contracts/11-staking-collection.md | 108 +++++++----- .../core-contracts/12-hybrid-custody.md | 14 +- docs/build/cadence/core-contracts/13-evm.md | 24 +-- .../build/cadence/core-contracts/14-burner.md | 21 +-- .../build/cadence/core-contracts/15-bridge.md | 94 +++++----- docs/build/cadence/core-contracts/index.md | 39 +++-- .../build/cadence/differences-vs-evm/index.md | 104 ++++++----- 16 files changed, 553 insertions(+), 408 deletions(-) diff --git a/docs/build/cadence/core-contracts/02-fungible-token.md b/docs/build/cadence/core-contracts/02-fungible-token.md index 555c4c476f..2eb4464fa3 100644 --- a/docs/build/cadence/core-contracts/02-fungible-token.md +++ b/docs/build/cadence/core-contracts/02-fungible-token.md @@ -21,14 +21,15 @@ keywords: - token specification --- +# Fungible Token Contract + The `FungibleToken` contract implements the Fungible Token Standard. It is the second contract ever deployed on Flow. -- [Basic Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/fungible-tokens) -- [Fungible Token Guide](../../../blockchain-development-tutorials/tokens/fungible-token-cadence.md) -- [Fungible Token Standard Repo](https://github.com/onflow/flow-ft) +- [Basic Fungible Token Tutorial] +- [Fungible Token Guide] +- [Fungible Token Standard Repo] -The `FungibleTokenMetadataViews` and `FungibleTokenSwitchboard` contracts -are also deployed to the same account as `FungibleToken`. +The `FungibleTokenMetadataViews` and `FungibleTokenSwitchboard` contracts are also deployed to the same account as `FungibleToken`. Source: [FungibleToken.cdc](https://github.com/onflow/flow-ft/blob/master/contracts/FungibleToken.cdc) @@ -41,10 +42,7 @@ Source: [FungibleToken.cdc](https://github.com/onflow/flow-ft/blob/master/contra # Transactions -All `FungibleToken` projects are encouraged to use -the generic token transactions and scripts in the `flow-ft` [repo](https://github.com/onflow/flow-ft/tree/master/transactions). -They can be used for any token that implements the fungible token standard properly -without changing any code besides import addresses on different networks. +All `FungibleToken` projects are encouraged to use the generic token transactions and scripts in the `flow-ft` [repo]. They can be used for any token that implements the fungible token standard properly without any code change besides import addresses on different networks. # Events @@ -56,18 +54,15 @@ A.{contract address}.{contract name}.{event name} The components of the format are: -- `contract address` - the address of the account the contract has been deployed to -- `contract name` - the name of the contract in the source code -- `event name` - the name of the event as declared in the source code +- `contract address` - the address of the account the contract has been deployed to. +- `contract name` - the name of the contract in the source code. +- `event name` - the name of the event as declared in the source code. -## FungibleToken Events +## FungibleToken events -Contracts that implement the Fungible Token standard get access -to standard events that are emitted every time a relevant action occurs, -like depositing and withdrawing tokens. +Contracts that implement the Fungible Token standard get access to standard events that are emitted every time a relevant action occurs, like deposit and withdraw tokens. -This means that projects do not have to implement their own custom events -unless the standard events do not satisfy requirements they have for events. +This means that projects do not have to implement their own custom events unless the standard events do not satisfy requirements they have for events. The `FungibleToken` events will have the following format: @@ -76,8 +71,7 @@ A.{contract address}.FungibleToken.Deposited A.{contract address}.FungibleToken.Withdrawn ``` -Where the `contract address` is the `FungibleToken` address on the network being queried. -The addresses on the various networks are shown above. +Where the `contract address` is the `FungibleToken` address on the network being queried. The addresses on the various networks are shown above. ### FungibleToken.Deposited @@ -92,9 +86,7 @@ access(all) event Deposited ( ) ``` -Whenever `deposit()` is called on a resource type that implements -`FungibleToken.Vault`, the `FungibleToken.Deposited` event is emitted -with the following arguments: +Whenever `deposit()` is called on a resource type that implements `FungibleToken.Vault`, the `FungibleToken.Deposited` event is emitted with the following arguments: - `type: String`: The type identifier of the token being deposited. - Example: `A.4445e7ad11568276.FlowToken.Vault` @@ -123,9 +115,7 @@ access(all) event Withdrawn ( ) ``` -Whenever `withdraw()` is called on a resource type that implements -`FungibleToken.Vault`, the `FungibleToken.Withdrawn` event is emitted -with the following arguments: +Whenever `withdraw()` is called on a resource type that implements `FungibleToken.Vault`, the `FungibleToken.Withdrawn` event is emitted with the following arguments: - `type: String`: The type identifier of the token being withdrawn. - Example: `A.4445e7ad11568276.FlowToken.Vault` @@ -152,8 +142,7 @@ access(all) event Burned ( ) ``` -Whenever a fungible token that implements `FungibleToken.Vault` is burned -via the `Burner.burn()` method, this event is emitted with the following arguments: +Whenever a fungible token that implements `FungibleToken.Vault` is burned via the `Burner.burn()` method, this event is emitted with the following arguments: - `type: String`: The type identifier of the token that was burnt. - Example: `A.4445e7ad11568276.FlowToken.Vault` @@ -161,3 +150,10 @@ via the `Burner.burn()` method, this event is emitted with the following argumen - Example: `0.00017485` - `fromUUID: UInt64`: The UUID of the Vault that was burnt. - Example: `177021372071991` + + + +[Basic Fungible Token Tutorial]: https://cadence-lang.org/docs/tutorial/fungible-tokens +[Fungible Token Guide]: ../../../blockchain-development-tutorials/tokens/fungible-token-cadence.md +[Fungible Token Standard Repo]: https://github.com/onflow/flow-ft +[repo]: https://github.com/onflow/flow-ft/tree/master/transactions diff --git a/docs/build/cadence/core-contracts/03-flow-token.md b/docs/build/cadence/core-contracts/03-flow-token.md index 72cf46586e..48c9b11230 100644 --- a/docs/build/cadence/core-contracts/03-flow-token.md +++ b/docs/build/cadence/core-contracts/03-flow-token.md @@ -21,9 +21,11 @@ keywords: - Flow testnet --- +# Flow Token Contract + The `FlowToken` contract defines the FLOW network token. -Source: [FlowToken.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowToken.cdc) +Source: [FlowToken.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -32,18 +34,16 @@ Source: [FlowToken.cdc](https://github.com/onflow/flow-core-contracts/blob/maste | Testnet | `0x7e60df042a9c0868` | | Mainnet | `0x1654653399040a61` | -# Transactions +## Transactions -Transactions and scripts for `FlowToken` are in the `flow-core-contracts` [repo](https://github.com/onflow/flow-core-contracts/tree/master/transactions/flowToken). +Transactions and scripts for `FlowToken` are in the `flow-core-contracts` [repo]. As mentioned in the `FungibleToken` page, developers are encouraged to use -the generic token transactions in the `flow-ft` [repo](https://github.com/onflow/flow-ft/tree/master/transactions) instead. +the generic token transactions in the [`flow-ft` repo] instead. -# Events +## Events -Flow relies on a set of core contracts that define key portions of the Flow protocol. Those contracts are core contracts -and are made to emit the events documented below. You can read about the [core contracts here](./index.md) -and view their source code and event definitions. +Flow relies on a set of core contracts that define key portions of the Flow protocol. Those contracts are core contracts and are made to emit the events documented below. You can read about the [core contracts here] and view their source code and event definitions. Events emitted from core contracts follow a standard format: @@ -53,18 +53,17 @@ A.{contract address}.{contract name}.{event name} The components of the format are: -- `contract address` - the address of the account the contract has been deployed to -- `contract name` - the name of the contract in the source code -- `event name` - the name of the event as declared in the source code +- `contract address` - the address of the account the contract has been deployed to. +- `contract name` - the name of the contract in the source code. +- `event name` - the name of the event as declared in the source code. -### Flow Token Contract +### Flow token contract Description of events emitted from the [FLOW Token contract](./03-flow-token.md). -The contract defines the fungible FLOW token. Please note that events for the fungible token contracts are the same -if deployed to a different account but the `contract address` is -changed to the address of the account the contract has been deployed to. -### Tokens Initialized +The contract defines the fungible FLOW token. Please note that events for the fungible token contracts are the same if deployed to a different account but the `contract address` is changed to the address of the account the contract has been deployed to. + +### Tokens initialized Event that is emitted when the contract gets created. @@ -80,7 +79,7 @@ access(all) event TokensInitialized(initialSupply: UFix64) | ------------- | ------ | -------------------------------- | | initialSupply | UFix64 | The initial supply of the tokens | -### Tokens Withdrawn +### Tokens withdrawn Event that is emitted when tokens get withdrawn from a Vault. @@ -97,7 +96,7 @@ access(all) event TokensWithdrawn(amount: UFix64, from: Address?) | amount | UFix64 | The amount of tokens withdrawn | | from | Address? | Optional address of the account that owns the vault where tokens were withdrawn from. `nil` if the vault is not in an account's storage | -### Tokens Deposited +### Tokens deposited Event that is emitted when tokens get deposited to a Vault. @@ -114,7 +113,7 @@ access(all) event TokensDeposited(amount: UFix64, to: Address?) | amount | UFix64 | The amount of tokens withdrawn | | to | Address? | Optional address of the account that owns the vault where tokens were deposited to. `nil` if the vault is not in an account's storage | -### Tokens Minted +### Tokens minted Event that is emitted when new tokens gets minted. @@ -130,7 +129,7 @@ access(all) event TokensMinted(amount: UFix64) | ------ | ------ | ---------------------------- | | amount | UFix64 | The amount of tokens to mint | -### Tokens Burned +### Tokens burned Event that is emitted when tokens get destroyed. @@ -146,7 +145,7 @@ access(all) event TokensBurned(amount: UFix64) | ------ | ------ | ---------------------------- | | amount | UFix64 | The amount of tokens to burn | -### Minter Created +### Minter created Event that is emitted when a new minter resource gets created. @@ -174,6 +173,14 @@ Event that is emitted when a new burner Resource gets created. access(all) event BurnerCreated() ``` -### Staking Events +### Staking events + +To learn more about staking events, read [staking/events/] + + -To learn more about staking events, read [staking/events/](../../../protocol/staking/07-staking-scripts-events.md) +[FlowToken.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowToken.cdc +[repo]: https://github.com/onflow/flow-core-contracts/tree/master/transactions/flowToken +[`flow-ft` repo]: https://github.com/onflow/flow-ft/tree/master/transactions +[core contracts here]: ./index.md +[staking/events/]: ../../../protocol/staking/07-staking-scripts-events.md diff --git a/docs/build/cadence/core-contracts/04-service-account.md b/docs/build/cadence/core-contracts/04-service-account.md index ac71f708ce..5deddce8fa 100644 --- a/docs/build/cadence/core-contracts/04-service-account.md +++ b/docs/build/cadence/core-contracts/04-service-account.md @@ -20,6 +20,8 @@ keywords: - network configuration --- +# Service Account Contracts + The service account is the account that manages the core protocol requirements of Flow. | Network | Contract Address | @@ -31,14 +33,13 @@ The service account is the account that manages the core protocol requirements o Here are three important contracts deployed to the service account: -# FlowServiceAccount +## FlowServiceAccount -`FlowServiceAccount` tracks transaction fees, deployment permissions, and provides -some convenience methods for Flow Token operations. +`FlowServiceAccount` tracks transaction fees, deployment permissions, and provides some convenience methods for Flow Token operations. -Source: [FlowServiceAccount.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowServiceAccount.cdc) +Source: [FlowServiceAccount.cdc] -## Events +### Events Important events from `FlowServiceAccount` are: @@ -47,16 +48,13 @@ access(all) event TransactionFeeUpdated(newFee: UFix64) access(all) event AccountCreationFeeUpdated(newFee: UFix64) ``` -# RandomBeaconHistory +## RandomBeaconHistory -- `RandomBeaconHistory` stores the history of random sources generated by - the Flow network. The defined Heartbeat resource is - updated by the Flow Service Account at the end of every block - with that block's source of randomness. +- `RandomBeaconHistory` stores the history of random sources generated by the Flow network. The defined Heartbeat resource is updated by the Flow Service Account at the end of every block with that block's source of randomness. -Source: [RandomBeaconHistory.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/RandomBeaconHistory.cdc) +Source: [RandomBeaconHistory.cdc] -## Events +### Events Important events from `RandomBeaconHistory` are: @@ -75,15 +73,13 @@ access(all) event RandomHistoryMissing(blockHeight: UInt64, gapStartHeight: UInt access(all) event RandomHistoryBackfilled(blockHeight: UInt64, gapStartHeight: UInt64, count: UInt64) ``` -# NodeVersionBeacon +## NodeVersionBeacon -- `NodeVersionBeacon` holds the past - and future protocol versions that should be used - to execute/handle blocks at a given block height. +- `NodeVersionBeacon` holds the past and future protocol versions that should be used to execute or handle blocks at a given block height. -Source: [NodeVersionBeacon.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/NodeVersionBeacon.cdc) +Source: [NodeVersionBeacon.cdc] -## Events +### Events Important events from `NodeVersionBeacon` are: @@ -102,3 +98,9 @@ access(all) event VersionBeacon( /// freeze period is measured in blocks (from the current block). access(all) event NodeVersionBoundaryFreezePeriodChanged(freezePeriod: UInt64) ``` + + + +[FlowServiceAccount.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowServiceAccount.cdc +[RandomBeaconHistory.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/RandomBeaconHistory.cdc +[NodeVersionBeacon.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/NodeVersionBeacon.cdc \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/05-flow-fees.md b/docs/build/cadence/core-contracts/05-flow-fees.md index 7bcf6893c1..ddb096ce71 100644 --- a/docs/build/cadence/core-contracts/05-flow-fees.md +++ b/docs/build/cadence/core-contracts/05-flow-fees.md @@ -21,11 +21,11 @@ keywords: - blockchain fees --- -## FlowFees +# Flow Fees Contract The `FlowFees` contract is where all the collected flow fees are gathered. -Source: [FlowFees.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowFees.cdc) +Source: [FlowFees.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -56,7 +56,7 @@ access(all) event FeeParametersChanged(surgeFactor: UFix64, inclusionEffortCost: The `FlowStorageFees` contract defines the parameters and utility methods for storage fees. -Source: [FlowStorageFees.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowStorageFees.cdc) +Source: [FlowStorageFees.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -76,3 +76,8 @@ access(all) event StorageMegaBytesPerReservedFLOWChanged(_ storageMegaBytesPerRe // Emitted when the minimum amount of Flow tokens that an account needs to have reserved for storage capacity changes. access(all) event MinimumStorageReservationChanged(_ minimumStorageReservation: UFix64) ``` + + + +[FlowFees.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowFees.cdc +[FlowStorageFees.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowStorageFees.cdc diff --git a/docs/build/cadence/core-contracts/06-staking-contract-reference.md b/docs/build/cadence/core-contracts/06-staking-contract-reference.md index f6a5c49636..3a8223823a 100644 --- a/docs/build/cadence/core-contracts/06-staking-contract-reference.md +++ b/docs/build/cadence/core-contracts/06-staking-contract-reference.md @@ -21,11 +21,11 @@ keywords: - staking requirements --- -## Contract +# Flow Staking Contract Reference The `FlowIDTableStaking` contract is the central table that manages staked nodes, delegation and rewards. -Source: [FlowIDTableStaking.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowIDTableStaking.cdc) +Source: [FlowIDTableStaking.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -34,39 +34,37 @@ Source: [FlowIDTableStaking.cdc](https://github.com/onflow/flow-core-contracts/b | Testnet | `0x9eca2b38b18b5dfe` | | Mainnet | `0x8624b52f9ddcd04a` | -## Transactions and Scripts +## Transactions and scripts -Transactions for the staking contract are in the `flow-core-contracts` repo. -Developers and users are advised to use [the staking collection transactions](../../../protocol/staking/14-staking-collection.md) -to stake tokens instead of the basic transactions that are used for tests. +Transactions for the staking contract are in the `flow-core-contracts` repo. Developers and users are advised to use [the staking collection transactions] to stake tokens instead of the basic transactions that are used for tests. -### Getting Staking Info with Scripts +### Getting staking info with scripts These scripts are read-only and get info about the current state of the staking contract. | ID | Name | Source | | ----------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **`SC.01`** | Get Delegation Cut Percentage | [idTableStaking/get_cut_percentage.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_cut_percentage.cdc) | -| **`SC.02`** | Get Minimum Stake Requirements | [idTableStaking/get_stake_requirements.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_stake_requirements.cdc) | -| **`SC.03`** | Get Total Weekly Reward Payout | [idTableStaking/get_weekly_payout.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_weekly_payout.cdc) | -| **`SC.04`** | Get Current Staked Node Table | [idTableStaking/get_current_table.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_current_table.cdc) | -| **`SC.05`** | Get Proposed Staked Node Table | [idTableStaking/get_proposed_table.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_proposed_table.cdc) | -| **`SC.06`** | Get Total Flow Staked | [idTableStaking/get_total_staked.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_total_staked.cdc) | -| **`SC.07`** | Get Total Flow Staked by Node Type | [idTableStaking/get_total_staked_by_type.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_total_staked_by_type.cdc) | -| **`SC.08`** | Get All Info about a single NodeID | [idTableStaking/get_node_info.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_info.cdc) | -| **`SC.09`** | Get a node's total Commitment (delegators) | [idTableStaking/get_node_total_commitment.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_total_commitment.cdc) | -| **`SC.10`** | Get All Info about a single Delegator | [idTableStaking/delegation/get_delegator_info.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/delegation/get_delegator_info.cdc) | -| **`SC.11`** | Get a node's total Commitment | [idTableStaking/get_node_total_commitment_without_delegators.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_total_commitment_without_delegators.cdc) | - -### Delegator Transactions - -Documentation for delegating with tokens is described in the staking documentation -for [the staking collection](../../../protocol/staking/14-staking-collection.md) +| **`SC.01`** | Get Delegation Cut Percentage | [idTableStaking/get_cut_percentage.cdc] | +| **`SC.02`** | Get Minimum Stake Requirements | [idTableStaking/get_stake_requirements.cdc] | +| **`SC.03`** | Get Total Weekly Reward Payout | [idTableStaking/get_weekly_payout.cdc] | +| **`SC.04`** | Get Current Staked Node Table | [idTableStaking/get_current_table.cdc] | +| **`SC.05`** | Get Proposed Staked Node Table | [idTableStaking/get_proposed_table.cdc] | +| **`SC.06`** | Get Total Flow Staked | [idTableStaking/get_total_staked.cdc] | +| **`SC.07`** | Get Total Flow Staked by Node Type | [idTableStaking/get_total_staked_by_type.cdc] | +| **`SC.08`** | Get All Info about a single NodeID | [idTableStaking/get_node_info.cdc] | +| **`SC.09`** | Get a node's total Commitment (delegators) | [idTableStaking/get_node_total_commitment.cdc] | +| **`SC.10`** | Get All Info about a single Delegator | [idTableStaking/delegation/get_delegator_info.cdc] | +| **`SC.11`** | Get a node's total Commitment | [idTableStaking/get_node_total_commitment_without_delegators.cdc] | + +### Delegator transactions + +Documentation for token delegation is described in the staking documentation +for [the staking collection]. ## Events The `FlowIDTableStaking` contract emits an event whenever an important action occurs. -See the [staking events Documentation](../../../protocol/staking/07-staking-scripts-events.md) for more information about each event. +See the [staking events Documentation]for more information about each event. ```cadence /// Epoch @@ -114,3 +112,21 @@ See the [staking events Documentation](../../../protocol/staking/07-staking-scri access(all) event NewStakingMinimums(newMinimums: {UInt8: UFix64}) access(all) event NewDelegatorStakingMinimum(newMinimum: UFix64) ``` + + + +[FlowIDTableStaking.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowIDTableStaking.cdc +[the staking collection transactions]: ../../../protocol/staking/14-staking-collection.md +[idTableStaking/get_cut_percentage.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_cut_percentage.cdc +[idTableStaking/get_stake_requirements.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_stake_requirements.cdc +[idTableStaking/get_weekly_payout.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_weekly_payout.cdc +[idTableStaking/get_current_table.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_current_table.cdc +[idTableStaking/get_proposed_table.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_proposed_table.cdc +[idTableStaking/get_total_staked.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_total_staked.cdc +[idTableStaking/get_total_staked_by_type.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_total_staked_by_type.cdc +[idTableStaking/get_node_info.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_info.cdc +[idTableStaking/get_node_total_commitment.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_total_commitment.cdc +[idTableStaking/delegation/get_delegator_info.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/delegation/get_delegator_info.cdc +[idTableStaking/get_node_total_commitment_without_delegators.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_total_commitment_without_delegators.cdc +[the staking collection]: ../../../protocol/staking/14-staking-collection.md +[staking events Documentation]: ../../../protocol/staking/07-staking-scripts-events.md \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/07-epoch-contract-reference.md b/docs/build/cadence/core-contracts/07-epoch-contract-reference.md index 450146067d..a614134f86 100644 --- a/docs/build/cadence/core-contracts/07-epoch-contract-reference.md +++ b/docs/build/cadence/core-contracts/07-epoch-contract-reference.md @@ -23,16 +23,15 @@ keywords: # Contract -The `FlowEpoch` contract is the state machine that manages Epoch phases and emits service events. -The `FlowClusterQC` and `FlowDKG` contracts manage the processes that happen during the Epoch Setup phase. +The `FlowEpoch` contract is the state machine that manages Epoch phases and emits service events. The `FlowClusterQC` and `FlowDKG` contracts manage the processes that happen during the Epoch Setup phase. These contracts are all deployed to the same account as the `FlowIDTableStaking` contract. Sources: -- [FlowEpoch.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowEpoch.cdc) -- [FlowClusterQC.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowClusterQC.cdc) -- [FlowDKG.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowDKG.cdc) +- [FlowEpoch.cdc] +- [FlowClusterQC.cdc] +- [FlowDKG.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -41,44 +40,68 @@ Sources: | Testnet | `0x9eca2b38b18b5dfe` | | Mainnet | `0x8624b52f9ddcd04a` | -# Transactions +## Transactions -## Getting Epoch Info +### Get epoch info These scripts are read-only and get info about the current state of the epoch contract. | ID | Name | Source | | ----------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -| **`EP.01`** | Get Epoch Metadata | [epoch/get_epoch_metadata.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_metadata.cdc) | -| **`EP.02`** | Get Configurable Metadata | [epoch/get_config_metadata.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_config_metadata.cdc) | -| **`EP.03`** | Get Epoch Counter | [epoch/get_epoch_counter.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_counter.cdc) | -| **`EP.04`** | Get Epoch Phase | [epoch/get_epoch_phase.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_phase.cdc) | +| **`EP.01`** | Get Epoch Metadata | [epoch/get_epoch_metadata.cdc] | +| **`EP.02`** | Get Configurable Metadata | [epoch/get_config_metadata.cdc] | +| **`EP.03`** | Get Epoch Counter | [epoch/get_epoch_counter.cdc] | +| **`EP.04`** | Get Epoch Phase | [epoch/get_epoch_phase.cdc] | -## Quorum Certificate Transactions and Scripts +## Quorum certificate transactions and scripts | ID | Name | Source | | ----------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **`QC.01`** | Create QC Voter | [quorumCertificate/get_epoch_metadata.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/create_voter.cdc) | -| **`QC.02`** | Submit QC Vote | [quorumCertificate/get_config_metadata.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/submit_vote.cdc) | -| **`QC.03`** | Get Collector Cluster | [quorumCertificate/scripts/get_cluster.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_cluster.cdc) | -| **`QC.04`** | Get QC Enabled | [quorumCertificate/scripts/get_qc_enabled.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_qc_enabled.cdc) | -| **`QC.05`** | Get Node Has Voted | [quorumCertificate/scripts/get_node_has_voted.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_node_has_voted.cdc) | -| **`QC.06`** | Get QC Voting Complete | [quorumCertificate/scripts/get_voting_completed.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_voting_completed.cdc) | +| **`QC.01`** | Create QC Voter | [quorumCertificate/get_epoch_metadata.cdc] | +| **`QC.02`** | Submit QC Vote | [quorumCertificate/get_config_metadata.cdc] | +| **`QC.03`** | Get Collector Cluster | [quorumCertificate/scripts/get_cluster.cdc] | +| **`QC.04`** | Get QC Enabled | [quorumCertificate/scripts/get_qc_enabled.cdc] | +| **`QC.05`** | Get Node Has Voted | [quorumCertificate/scripts/get_node_has_voted.cdc] | +| **`QC.06`** | Get QC Voting Complete | [quorumCertificate/scripts/get_voting_completed.cdc] | -## DKG Transactions and Scripts +## DKG transactions and scripts | ID | Name | Source | | ------------ | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **`DKG.01`** | Create DKG Participant | [dkg/create_participant.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/create_participant.cdc) | -| **`DKG.02`** | Get Configurable Metadata | [dkg/send_whiteboard_message.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/send_whiteboard_message.cdc) | -| **`DKG.03`** | Send Final Submission | [dkg/send_final_submission.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/send_final_submission.cdc) | -| **`DKG.04`** | Get DKG Enabled | [dkg/scripts/get_dkg_enabled.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_dkg_enabled.cdc) | -| **`DKG.05`** | Get DKG Completed | [dkg/scripts/get_dkg_completed.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_dkg_completed.cdc) | -| **`DKG.06`** | Get Whiteboard Messages | [dkg/scripts/get_whiteboard_messages.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_whiteboard_messages.cdc) | -| **`DKG.07`** | Get Final Submissions | [dkg/scripts/get_final_submissions.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_final_submissions.cdc) | -| **`DKG.08`** | Get Node Has Submitted | [dkg/scripts/get_node_has_submitted.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_node_has_submitted.cdc) | +| **`DKG.01`** | Create DKG Participant | [dkg/create_participant.cdc] | +| **`DKG.02`** | Get Configurable Metadata | [dkg/send_whiteboard_message.cdc] | +| **`DKG.03`** | Send Final Submission | [dkg/send_final_submission.cdc] | +| **`DKG.04`** | Get DKG Enabled | [dkg/scripts/get_dkg_enabled.cdc] | +| **`DKG.05`** | Get DKG Completed | [dkg/scripts/get_dkg_completed.cdc] | +| **`DKG.06`** | Get Whiteboard Messages | [dkg/scripts/get_whiteboard_messages.cdc] | +| **`DKG.07`** | Get Final Submissions | [dkg/scripts/get_final_submissions.cdc] | +| **`DKG.08`** | Get Node Has Submitted | [dkg/scripts/get_node_has_submitted.cdc] | # Events -See the [epoch documentation](../../../protocol/staking/05-epoch-scripts-events.md) -for a list and documentation for important `FlowEpoch` events. +See the [epoch documentation] for a list and documentation for important `FlowEpoch` events. + + + +[FlowEpoch.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowEpoch.cdc +[FlowClusterQC.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowClusterQC.cdc +[FlowDKG.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/epochs/FlowDKG.cdc +[epoch documentation]: ../../../protocol/staking/05-epoch-scripts-events.md +[epoch/get_epoch_metadata.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_metadata.cdc) +[epoch/get_config_metadata.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_config_metadata.cdc +[epoch/get_epoch_counter.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_counter.cdc +[epoch/get_epoch_phase.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/epoch/scripts/get_epoch_phase.cdc) +[quorumCertificate/get_epoch_metadata.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/create_voter.cdc) +[quorumCertificate/get_config_metadata.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/submit_vote.cdc +[quorumCertificate/scripts/get_cluster.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_cluster.cdc +[quorumCertificate/scripts/get_qc_enabled.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_qc_enabled.cdc +[quorumCertificate/scripts/get_node_has_voted.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_node_has_voted.cdc +[quorumCertificate/scripts/get_voting_completed.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/quorumCertificate/scripts/get_voting_completed.cdc +[dkg/create_participant.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/create_participant.cdc +[dkg/send_whiteboard_message.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/send_whiteboard_message.cdc +[dkg/send_final_submission.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/send_final_submission.cdc +[dkg/scripts/get_dkg_enabled.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_dkg_enabled.cdc +[dkg/scripts/get_dkg_completed.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_dkg_completed.cdc +[dkg/scripts/get_whiteboard_messages.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_whiteboard_messages.cdc +[dkg/scripts/get_final_submissions.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_final_submissions.cdc +[dkg/scripts/get_node_has_submitted.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/dkg/scripts/get_node_has_submitted.cdc \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/08-non-fungible-token.md b/docs/build/cadence/core-contracts/08-non-fungible-token.md index 0a3f065b98..0aaccaec0b 100644 --- a/docs/build/cadence/core-contracts/08-non-fungible-token.md +++ b/docs/build/cadence/core-contracts/08-non-fungible-token.md @@ -21,14 +21,15 @@ keywords: - digital assets --- -The `NonFungibleToken` contract interface implements the Fungible Token Standard. -All NFT contracts are encouraged to import and implement this standard. +# Non-Fungible Token Contract -- [Basic Non-Fungible Token Tutorial](https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1) -- [Non Fungible Token Guide](../../../blockchain-development-tutorials/tokens/nft-cadence.md) -- [Non Fungible Token Standard Repo](https://github.com/onflow/flow-nft) +The `NonFungibleToken` contract interface implements the Fungible Token Standard. All NFT contracts are encouraged to import and implement this standard. -Source: [NonFungibleToken.cdc](https://github.com/onflow/flow-nft/blob/master/contracts/NonFungibleToken.cdc) +- [Basic Non-Fungible Token Tutorial] +- [Non Fungible Token Guide] +- [Non Fungible Token Standard Repo] + +Source: [NonFungibleToken.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -37,14 +38,11 @@ Source: [NonFungibleToken.cdc](https://github.com/onflow/flow-nft/blob/master/co | Testnet | `0x631e88ae7f1d7c20` | | Mainnet | `0x1d7e57aa55817448` | -# Transactions +## Transactions -All `NonFungibleToken` projects are encouraged to use -the generic token transactions and scripts in the `flow-nft` [repo](https://github.com/onflow/flow-nft/tree/master/transactions). -They can be used for any token that implements the non-fungible token standard properly -without changing any code besides import addresses on different networks. +All `NonFungibleToken` projects are encouraged to use the generic token transactions and scripts in the `flow-nft` [repo]. You can use them for any token that implements the non-fungible token standard properly, and you won't have to change any code besides import addresses on different networks. -# Events +## Events Events emitted from all contracts follow a standard format: @@ -54,18 +52,15 @@ A.{contract address}.{contract name}.{event name} The components of the format are: -- `contract address` - the address of the account the contract has been deployed to -- `contract name` - the name of the contract in the source code -- `event name` - the name of the event as declared in the source code +- `contract address` - the address of the account the contract has been deployed to. +- `contract name` - the name of the contract in the source code. +- `event name` - the name of the event as declared in the source code. -## NonFungibleToken Events +## NonFungibleToken events -Contracts that implement the Non-Fungible Token standard get access -to standard events that are emitted every time a relevant action occurs, -like depositing and withdrawing tokens. +Contracts that implement the Non-Fungible Token standard get access to standard events that are emitted every time a relevant action occurs, like token deposits and withdrawls. -This means that projects do not have to implement their own custom events -unless the standard events do not satisfy requirements they have for events. +This means that projects do not have to implement their own custom events unless the standard events do not satisfy requirements they have for events. The `NonFungibleToken` events will have the following format: @@ -74,8 +69,7 @@ A.{contract address}.NonFungibleToken.Deposited A.{contract address}.NonFungibleToken.Withdrawn ``` -Where the `contract address` is the `NonFungibleToken` address on the network being queried. -The addresses on the various networks are shown above. +Where the `contract address` is the `NonFungibleToken` address on the network being queried. The addresses on the various networks are shown above. ### NonFungibleToken.Deposited @@ -89,9 +83,7 @@ access(all) event Deposited ( ) ``` -Whenever `deposit()` is called on a resource type that implements -`NonFungibleToken.Collection`, the `NonFungibleToken.Deposited` event is emitted -with the following arguments: +Whenever `deposit()` is called on a resource type that implements `NonFungibleToken.Collection`, the `NonFungibleToken.Deposited` event is emitted with the following arguments: - `type: String`: The type identifier of the token being deposited. - Example: `A.4445e7ad11568276.TopShot.NFT` @@ -99,8 +91,7 @@ with the following arguments: - Example: `173838` - `uuid: UInt64`: The UUID of the token that was deposited. - Example: `177021372071991` -- `to: Address?`: The address of the account that owns the Collection that received - the token. If the collection is not stored in an account, `to` will be `nil`. +- `to: Address?`: The address of the account that owns the Collection that received the token. If the collection is not stored in an account, `to` will be `nil`. - Example: `0x4445e7ad11568276` - `collectionUUID: UInt64`: The UUID of the Collection that received the token. - Example: `177021372071991` @@ -117,9 +108,7 @@ access(all) event Withdrawn ( ) ``` -Whenever `withdraw()` is called on a resource type that implements -`NonFungibleToken.Collection`, the `NonFungibleToken.Withdrawn` event is emitted -with the following arguments: +Whenever `withdraw()` is called on a resource type that implements `NonFungibleToken.Collection`, the `NonFungibleToken.Withdrawn` event is emitted with the following arguments: - `type: String`: The type identifier of the token being withdrawn. - Example: `A.4445e7ad11568276.TopShot.NFT` @@ -127,8 +116,7 @@ with the following arguments: - Example: `113838` - `uuid: UInt64`: The UUID of the token that was withdrawn. - Example: `177021372071991` -- `from: Address?`: The address of the account that owns the Collection that - the token was withdrawn from. If the collection is not stored in an account, `to` will be `nil`. +- `from: Address?`: The address of the account that owns the Collection that the token was withdrawn from. If the collection is not stored in an account, `to` will be `nil`. - Example: `0x4445e7ad11568276` - `providerUUID: UInt64`: The UUID of the Collection that the token was withdrawn from. - Example: `177021372071991` @@ -144,17 +132,21 @@ access(all) event Updated( ) ``` -Whenever a non-fungible token is updated for whatever reason, -projects should call the `NonFungibleToken.emitNFTUpdated()` function -to emit this event. It indicates to event listeners that they should query -the NFT to update any stored information they have about the NFT in their database. +Whenever a non-fungible token is updated for whatever reason, projects should call the `NonFungibleToken.emitNFTUpdated()` function to emit this event. It indicates to event listeners that they should query the NFT to update any stored information they have about the NFT in their database. - `type: String`: The type identifier of the token that was updated. - Example: `A.4445e7ad11568276.TopShot.NFT` -- `id: UInt64`: The ID of the token that was updated. Note: This may or may not be the UUID. +- `id: UInt64`: The ID of the token that was updated. This may or may not be the UUID. - Example: `173838` - `uuid: UInt64`: The UUID of the token that was updated. - Example: `177021372071991` -- `owner: Address?`: The address of the account that owns the Collection that owns - the token. If the collection is not stored in an account, `to` will be `nil`. +- `owner: Address?`: The address of the account that owns the Collection that owns the token. If the collection is not stored in an account, `to` will be `nil`. - Example: `0x4445e7ad11568276` + + + +[repo]: https://github.com/onflow/flow-nft/tree/master/transactions +[Basic Non-Fungible Token Tutorial]: https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1) +[Non Fungible Token Guide]: ../../../blockchain-development-tutorials/tokens/nft-cadence.md) +[Non Fungible Token Standard Repo]: https://github.com/onflow/flow-nft) +[NonFungibleToken.cdc]: https://github.com/onflow/flow-nft/blob/master/contracts/NonFungibleToken.cdc) \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/09-nft-metadata.md b/docs/build/cadence/core-contracts/09-nft-metadata.md index 719e25da50..7d0c7a750e 100644 --- a/docs/build/cadence/core-contracts/09-nft-metadata.md +++ b/docs/build/cadence/core-contracts/09-nft-metadata.md @@ -21,14 +21,15 @@ keywords: - NFT optimization --- -The `ViewResolver` and `MetadataViews` contracts implement a standard to attach onchain metadata -to NFTs. This standard was originally proposed in [FLIP-0636](https://github.com/onflow/flips/blob/main/application/20210916-nft-metadata.md). +# NFT Metadata Contract + +The `ViewResolver` and `MetadataViews` contracts implement a standard to attach onchain metadata to NFTs. This standard was originally proposed in [FLIP-0636]. It is deployed at the same address as the `NonFungibleToken` contract interface. -Source: [ViewResolver.cdc](https://github.com/onflow/flow-nft/blob/master/contracts/ViewResolver.cdc) +Source: [ViewResolver.cdc] -Source: [MetadataViews.cdc](https://github.com/onflow/flow-nft/blob/master/contracts/MetadataViews.cdc) +Source: [MetadataViews.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -37,10 +38,19 @@ Source: [MetadataViews.cdc](https://github.com/onflow/flow-nft/blob/master/contr | Testnet | `0x631e88ae7f1d7c20` | | Mainnet | `0x1d7e57aa55817448` | -There exists a tool, [Flow NFT Catalog](https://flow-nft-catalog.com), which enables dapp developers the ability to unlock interoperability of your NFT collection across the Flow ecosystem. This will help make your NFT collection's metadata more discoverable and interoperable. +There exists a tool, [Flow NFT Catalog], which allows dapp developers to unlock interoperability of your NFT collection across the Flow ecosystem. This will help make your NFT collection's metadata more discoverable and interoperable. To optimize your NFT collections for this catalog, you'll need to: -1. Update your NFT contract to support `ViewResolver` and `MetadataViews` with implementation of the [core NFT views](../advanced-concepts/metadata-views.md). +1. Update your NFT contract to support `ViewResolver` and `MetadataViews` with implementation of the [core NFT views]. 2. Deploy the updated contract to both testnet and mainnet. -3. Afterwards, onboard your NFT to the Flow NFT catalog at [https://flow-nft-catalog.com](https://flow-nft-catalog.com). +3. Afterwards, onboard your NFT to the Flow NFT catalog at [https://flow-nft-catalog.com]. + + + +[FLIP-0636]: https://github.com/onflow/flips/blob/main/application/20210916-nft-metadata.md +[ViewResolver.cdc]: https://github.com/onflow/flow-nft/blob/master/contracts/ViewResolver.cdc +[MetadataViews.cdc]: https://github.com/onflow/flow-nft/blob/master/contracts/MetadataViews.cdc +[Flow NFT Catalog]: https://flow-nft-catalog.com +[core NFT views]: ../advanced-concepts/metadata-views.md +[https://flow-nft-catalog.com]: https://flow-nft-catalog.com \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/10-nft-storefront.md b/docs/build/cadence/core-contracts/10-nft-storefront.md index 183bb86675..2d8d1711ec 100644 --- a/docs/build/cadence/core-contracts/10-nft-storefront.md +++ b/docs/build/cadence/core-contracts/10-nft-storefront.md @@ -21,10 +21,9 @@ keywords: - Flow marketplace --- -The NFT Storefront contracts implement a standard way to list NFTs for sale -and buy them from listings. `NFTStorefrontV2` is the more powerful and full-featured -version, so developers and users are encouraged to use it instead of `NFTStorefront` -or their own implementation. +# NFT Storefront Smart Contract + +The NFT Storefront contracts implement a standard way to list NFTs for sale and buy them from listings. `NFTStorefrontV2` is the more powerful and full-featured version, so developers and users are encouraged to use it instead of `NFTStorefront` or their own implementation. Source: [NFTStorefrontV2.cdc] @@ -46,106 +45,117 @@ Source: [NFTStorefront.cdc] The `NFTStorefrontV2` contract lets you create a _non-custodial Resource (NFT) marketplace_ on the FLOW blockchain. -`NFTStorefrontV2` makes it simple for Sellers to list NFTs in dApp specific marketplaces. DApp developers leverage the APIs provided by the contract to manage listings being offered for sale and to transact NFT trades. +`NFTStorefrontV2` makes it simple for Sellers to list NFTs in dApp specific marketplaces. dApp developers leverage the APIs provided by the contract to manage listings for sale and to transact NFT trades. ![dapps_1](https://user-images.githubusercontent.com/14581509/191749748-714f9d8f-cb41-4be4-a3d2-ec84cb8b5ffb.png) -Developers should use the `NFTStorefrontV2` to create their marketplace and to enable p2p purchases. The diagram below shows how dApps can facilitate the creation of NFT listings for different marketplaces and how marketplaces can filter their listings. +Developers should use the `NFTStorefrontV2` to create their marketplace and to alloq p2p purchases. The diagram below shows how dApps can facilitate the creation of NFT listings for different marketplaces and how marketplaces can filter their listings. -Listings made through a specific dApp storefront can be simultaneously listed on 3rd party marketplaces beyond that dApp. Well known 3rd party marketplaces listen for compatible NFT listing events enabling the automation of listings into their marketplace dashboards. +Listings made through a specific dApp storefront can be simultaneously listed on 3rd party marketplaces beyond that dApp. Well known 3rd party marketplaces listen for compatible NFT listing events, which allows the automation of listings into their marketplace dashboards. ![dapps_2](https://user-images.githubusercontent.com/14581509/191753605-e1c48a57-0c3c-4509-808b-8fee4e7d32e8.png) -Using the `NFTStorefrontV2`, marketplaces can instantly and easily tap into the vibrant FLOW NFT ecosystem and allow NFT holders to list their NFTs and enables creator royalties. +With the `NFTStorefrontV2`, marketplaces can instantly and easily tap into the vibrant FLOW NFT ecosystem and allow NFT holders to list their NFTs and allows creator royalties. -Marketplaces then process an NFT trade by interacting directly with seller storefronts. Flow's account based model ensures that NFTs listed for sale always reside in the Seller account until traded, regardless of how many listings are posted across any number of marketplaces, for the same NFT. +Marketplaces then interact with seller storefronts directly to process an NFT trade. Flow's account based model ensures that NFTs listed for sale always reside in the Seller account until traded, regardless of how many Listings are posted across any number of marketplaces, for the same NFT. ![marketplace_1](https://user-images.githubusercontent.com/14581509/191755699-fe0570cb-80a3-408c-8eef-4051e3209481.png) -## Functional Overview +## Functional overview -A general purpose sale support contract for NFTs implementing the Flow [`NonFungibleToken`] standard. -Each account that wants to list NFTs for sale creates a `Storefront` resource to store in their account and lists individual sales within that Storefront as Listings. There is usually one Storefront per account held at the `/storage/NFTStorefrontV2`. +A general purpose sale support contract for NFTs that implement the Flow [`NonFungibleToken`] standard. Each account that wants to list NFTs for sale creates a `Storefront` resource to store in their account and lists individual sales within that Storefront as listings. There is usually one Storefront per account held at the `/storage/NFTStorefrontV2`. -Each listing can define one or more sale cuts taken out of the sale price to go to one or more addresses. Listing fees, royalties, or other considerations can be paid using sale cuts. Also, the listing can include a commission as one of these sale cuts is paid to whoever facilitates the purchase. +Each listing can define one or more sale cuts taken out of the sale price to go to one or more addresses. Listing fees, royalties, or other considerations can be paid with sale cuts. Also, the listing can include a commission as one of these sale cuts is paid to whoever facilitates the purchase. -Listings can have an optional list of marketplace [receiver capabilities] used to receive the commission for fulfilling the listing. An NFT may be listed in one or more Listings, and the validity of each listing can easily be checked. +Listings can have an optional list of marketplace [receiver capabilities] used to receive the commission after the seller fulfills the listing. An NFT may be listed in one or more listings, and the validity of each listing can easily be checked. -Interested parties can globally track Listing events onchain and filter by NFT types, IDs and other characteristics to determine which to make available for purchase within their own marketplace UIs." +Interested parties can globally track listing events onchain and filter by NFT types, IDs and other characteristics to determine which to make available for purchase within their own marketplace UIs." -## Selling NFTs +## Sell NFTs `NFTStorefrontV2` offers a generic process for creating the listing for an NFT. It provides all the essential APIs to manage those listings independently. -Many marketplaces create a single storefront resource to manage different individual listings. We recommend creating the listing under the user-owned storefront resource to make it trustless and platform-independent. Users should possess the `Storefront` resource under their account to create the listing using the storefront contract. +Many marketplaces create a single storefront resource to manage different individual listings. We recommend that you create the listing under the user-owned storefront resource to make it trustless and platform-independent. Users should possess the `Storefront` resource under their account to create the listing using the storefront contract. -## Creating a successful listing using the NFTStorefrontV2 contract. +## Create a successful listing with the NFTStorefrontV2 contract. -As recommended above, the first step is to create and store the [Storefront resource] in the user account using the [setup_account] transaction. +As recommended above, the first step is to create and store the [Storefront resource] in the user account with the [setup_account] transaction. -The next step is to create a listing under the newly created storefront resource. If the user (repetitive) already holds the storefront resource, then use the existing resource. The seller can come with multiple requirements for listing their NFTs, and We try our best to cover most of them below. +The next step is to create a listing under the newly-created storefront resource. If the user (repetitive) already holds the storefront resource, then use the current resource. The seller can come with multiple requirements to list their NFTs, and we try our best to cover most of them below. -### **Scenario 1:** Selling NFTs corresponds to more than one cryptocurrency, i.e. FLOW, USDC etc. +### **Scenario 1:** Sell NFTs that correspond to more than one cryptocurrency, such as FLOW, USDC etc. -The `NFTStorefrontV2` contract doesn't support selling an NFT for multiple different currencies with a single listing. However, this can be achieved by creating multiple listings for the same NFT for each different currency. +The `NFTStorefrontV2` contract doesn't support an NFT sale for multiple different currencies with a single listing. However, to achieve this, you can create multiple listings for the same NFT for each different currency. -**Example -** Alice wants to sell a kitty and is open to receiving FLOW and USDC +**Example -** Alice wants to sell a kitty and is open to receive FLOW and USDC ![scenario_1](./scenario_1.png) -Putting an NFT on sell called listing, seller can create a listing using [sell_item] transaction by providing some required details to list an NFT, i.e. Receiving currency type, [Capability] from where NFT will be deducted etc. If interested look [`createListing`] for more details. +A seller puts an NFT on sale, a process called listing. To create a listing with the [sell_item] transaction, the seller provides some required details to list an NFT, such as the receiving currency type, and the [Capability] from where the network deducts the NFT. For more information, see [`createListing`]. -To receive a different currency seller has to provide a different **Receiver currency type** , i.e. `salePaymentVaultType` As depicted in the above diagram, There are two listing formations with almost the same inputs. The only differentiator is the `salePaymentVaultType` parameter that needs to be different when creating duplicate NFT listings with different sale currency types. +To receive a different currency, the seller must provide a different **Receiver currency type** , such as `salePaymentVaultType`. As depicted in the above diagram, there are two listing formations with almost the same inputs. The only differentiator is the `salePaymentVaultType` parameter that needs to be different when the seller creates duplicate NFT listings with different sale currency types. -### **Scenario 2:** Peer-to-Peer (p2p) listing of NFT: A listing anyone can fulfil. +### **Scenario 2:** Peer-to-Peer (p2p) listing of NFT: A listing anyone can fulfill. -Dapps can leverage the **NFTStorefrontV2** to facilitate the creation of a listing for the seller independent of any marketplace. Dapps or marketplaces can list those listings on their platforms, or seller can settle it p2p. +dApps can leverage the **NFTStorefrontV2** to facilitate a listing's creation for the seller independent of any marketplace. dApps or marketplaces can list those listings on their platforms, or seller can settle it p2p. -The seller can use [sell_item] transaction to create a p2p listing, providing the `marketplacesAddress` with an empty array. The seller has a choice of providing [commission] to the facilitator of sale, which can also act as a discount if the facilitator and the purchaser are the same. +The seller can use [sell_item] transaction to create a p2p listing. To do this, they provide the `marketplacesAddress` with an empty array. The seller can provide [commission] to the facilitator of sale, which can also act as a discount if the facilitator and the purchaser are the same. ### **Scenario 3:** The seller wants to list its NFT in different marketplaces. -`NFTStorefrontV2` offers two different ways of doing it. +`NFTStorefrontV2` offers two different ways to do it. -- The seller can create a listing and provide the `marketplacesAddress` that it wants to have a listing on using [sell_item] transaction. +- The seller can create a listing and provide the `marketplacesAddress` that it wants to have a listing on with the [sell_item] transaction. Marketplaces can listen to `ListingAvailable` events and check whether their address is included in the `commissionReceivers` list; If yes, the marketplace would be rewarded during the successful fulfilment of the listing. - Example - Bob wants to list on marketplace 0xA, 0xB & 0xC and is willing to offer 10% commission on the sale price of the listing to the marketplaces. + Example - Bob wants to list on marketplace 0xA, 0xB & 0xC and will offer 10% commission on the sale price of the listing to the marketplaces. ![scenario_3](https://user-images.githubusercontent.com/14581509/190966834-8eda4ec4-e9bf-49ef-9dec-3c47a236d281.png) -- Another way to accomplish this is to create separate listings for each marketplace on which a user wants their listing using [sell_item_with_marketplace_cut] transaction. In this case, the marketplace would be incentivized by earning one of the parts of the [`saleCut`] by appending marketplace saleCut in `saleCuts` array during the creation of the listing. +- Another way to accomplish this is to create separate listings for each marketplace on which a user wants their listing with the [sell_item_with_marketplace_cut] transaction. In this case, the marketplace would earn one part of the [`saleCut`] as an incentive. It appends the marketplace saleCut in the `saleCuts` array when it creates the listing. ### Considerations 1. **Ghost listings -** _Ghost listings are listings which don't have an underlying NFT in the seller's account. However, the listing is still available for buyers to attempt to purchase_. StorefrontV2 is not immune to ghost listings. Usually, ghost listings will cause a purchaser's transaction to fail, which is annoying but isn't a significant problem. Ghost listings become a problem for the seller when the listed NFT comes back to the seller's account after its original sale. The ghost listing will no longer be invalid when it comes back, and anyone can purchase it even if the seller doesn't want to sell it at that price anymore. - **Note -** _We recommend that marketplaces and p2p dApps create an off-chain notification service that tells their users (i.e., sellers) to remove the listings if they don't hold the NFT anymore in the same account._ +:::info + +_We recommend that marketplaces and p2p dApps create an off-chain notification service that tells their users (sellers) to remove the listings if they don't hold the NFT anymore in the same account._ + +::: 2. **Expired listings -** `NFTStorefrontV2` introduces a safety measure to specify that a listing will expire after a certain period that can be set during the creation so no one can purchase the listing anymore. It is not a fool-proof safety measure, but it does give some safe ground to the sellers for the ghost listings & stale listings. - **Note -** _We recommended for marketplaces and p2p dApps not to show the expired listings on their dashboards._ +:::info + + _We recommended for marketplaces and p2p dApps not to show the expired listings on their dashboards._ + + ::: -## Purchasing NFTs +## Purchase NFTs -Purchasing NFTs through the `NFTStorefrontV2` is simple. The buyer has to provide the payment vault and the `commissionRecipient` , if applicable, during the purchase. p2p dApps don't need any intermediaries to facilitate the purchase of listings. [`purchase`] API offered by the `Listing` resource gets used to facilitate the purchase of NFT. +To purchase NFTs through the `NFTStorefrontV2` is simple. The buyer has to provide the payment vault and the `commissionRecipient` , if applicable, during the purchase. p2p dApps don't need any intermediaries to facilitate the purchase of listings. [`purchase`] API offered by the `Listing` resource gets used to facilitate the purchase of NFT. -During the listing purchase all saleCuts are paid automatically. This also includes distributing royalties for that NFT, if applicable. If the vault provided by the buyer lacks sufficient funds then the transaction will fail. +During the listing purchase, all saleCuts are paid automatically. This also includes royalty distribution for that NFT, if applicable. If the vault provided by the buyer lacks sufficient funds, then the transaction will fail. ### Considerations -1. **Auto cleanup -** `NFTStorefrontV2` offers a unique ability to do auto cleanup of duplicate listings during a purchase. It comes with a drawback if one NFT has thousands of duplicate listings. It will become the bottleneck during purchasing one of the listings as it will likely trigger an out-of-compute error. +1. **Auto cleanup -** `NFTStorefrontV2` offers a unique ability to do auto cleanup of duplicate listings during a purchase. It comes with a drawback if one NFT has thousands of duplicate listings. It will become the bottleneck during purchases one of the listings as it will likely trigger an out-of-compute error. - **Note -** _We recommended NOT to have more than 50 duplicate listings of any given NFT._ +:::info -2. **Unsupported receiver capability** - A common pitfall during the purchase of an NFT that some saleCut receivers don't have a supported receiver capability because that entitled sale cut would transfer to first valid sale cut receiver. However, it can be partially solved by providing the generic receiver using the [`FungibleTokenSwitchboard`] contract and adding all the currency capabilities the beneficiary wants to receive. More on the `FungibleTokenSwitchboard` can be read in [Fungible Token Switchboard] + _We recommended NOT to have more than 50 duplicate listings of any given NFT._ -## Enabling creator royalties for NFTs +::: -The `NFTStorefrontV2` contract optionally supports paying royalties to the minter account for secondary resales of that NFT after the original sale. Marketplaces decide for themselves whether to support creator royalties when validating listings for sale eligibility. We encourage all marketplaces to support creator royalties and support community creators in the **FLOW** ecosystem. +2. **Unsupported receiver capability** - A common pitfall during the purchase of an NFT that some saleCut receivers don't have a supported receiver capability because that entitled sale cut would transfer to first valid sale cut receiver. However, it can be partially solved if you provide the generic receiver with the [`FungibleTokenSwitchboard`] contract and add all the currency capabilities the beneficiary wants to receive. For more information about the `FungibleTokenSwitchboard`, see [Fungible Token Switchboard] -Providing that a seller's NFT supports the [Royalty Metadata View] standard, then marketplaces can honor royalties payments at time of purchase. `NFTStorefrontV2` dynamically calculates the royalties owed at the time of listing creation and applies it as a saleCut of the listing at the time of purchase. +## Allow creator royalties for NFTs + +The `NFTStorefrontV2` contract optionally supports royalty payments to the minter account for secondary resales of that NFT after the original sale. Marketplaces decide for themselves whether to support creator royalties when they validate listings for sale eligibility. We encourage all marketplaces to support creator royalties and support community creators in the **FLOW** ecosystem. + +If a seller's NFT supports the [Royalty Metadata View] standard, then marketplaces can honor royalties payments at time of purchase. `NFTStorefrontV2` dynamically calculates the royalties owed at the time of listing creation and applies it as a saleCut of the listing at the time of purchase. ```cadence // Check whether the NFT implements the MetadataResolver or not. @@ -166,19 +176,19 @@ if nft.getViews().contains(Type()) { } ``` -Complete transaction can be viewed in [sell_item]. +You can view a complete transaction in [sell_item]. -saleCut only supports a single token receiver type and therefore beneficiaries of a `saleCut` can also only receive the token type used for the purchase. To support different token types for saleCuts we recommend using the [`FungibleTokenSwitchboard`] contract. The contract defines a generic receiver for fungible tokens which itself handles routing of tokens to the respective vault for that token type. Learn more about this in [Fungible Token Switchboard]. +saleCut only supports a single token receiver type and therefore beneficiaries of a `saleCut` can also only receive the token type used for the purchase. To support different token types for saleCuts, we recommend that you use the [`FungibleTokenSwitchboard`] contract. The contract defines a generic receiver for fungible tokens which itself handles routing of tokens to the respective vault for that token type. You can learn more about this in [Fungible Token Switchboard]. -## Enabling marketplace commissions for NFT sales +## Allow marketplace commissions for NFT sales -`NFTStorefrontV2` enables optional commissions on trades for marketplaces which require it as a condition to list a NFT for sale. Commission & commission receivers are set by the seller during initial listing creation. At time of purchase the commission amount is paid once only to the commission receiver matching the marketplace receiver address which facilitated the sale. +`NFTStorefrontV2` allows optional commissions on trades for marketplaces which require it as a condition to list a NFT for sale. The seller sets commission and commission receivers during initial listing creation. At time of purchase, the commission amount is paid once only to the commission receiver that matches the marketplace receiver address which facilitated the sale. -For NFT listings in marketplaces which don't require commission, commission receivers can be set as nil. Setting the buyer of the NFT and `commissionRecipient` to the same has the effect of applying a discount for the buyer. +For NFT listings in marketplaces which don't require commission, you can set commission receivers as `nil`. If you set the buyer of the NFT and `commissionRecipient` to `nil`, it applies a discount for the buyer. ![scenario_2](https://user-images.githubusercontent.com/14581509/190966499-c176203f-b6a6-4422-860f-1bf6f2bcdbb6.png). -## APIs & Events offered by NFTStorefrontV2 +## APIs and events offered by NFTStorefrontV2 ## Resource Interface `ListingPublic` @@ -194,7 +204,7 @@ resource interface ListingPublic { } ``` -An interface providing a useful public interface to a Listing. +An interface that provides a useful public interface to a Listing. ### Functions @@ -204,8 +214,7 @@ An interface providing a useful public interface to a Listing. fun borrowNFT(): &NonFungibleToken.NFT? ``` -This will assert in the same way as the NFT standard borrowNFT() -if the NFT is absent, for example if it has been sold via another listing. +This will assert in the same way as the NFT standard borrowNFT() if the NFT is absent, for example if it has been sold via another listing. --- @@ -215,9 +224,7 @@ if the NFT is absent, for example if it has been sold via another listing. fun purchase(payment FungibleToken.Vault, commissionRecipient Capability<&{FungibleToken.Receiver}>?): NonFungibleToken.NFT ``` -Facilitates the purchase of the listing by providing the payment vault -and the commission recipient capability if there is a non-zero commission for the given listing. -Respective saleCuts are transferred to beneficiaries and funtion return underlying or listed NFT. +Facilitates the purchase of the listing by providing the payment vault and the commission recipient capability if there is a non-zero commission for the given listing. Respective saleCuts are transferred to beneficiaries and funtion return underlying or listed NFT. --- @@ -227,7 +234,7 @@ Respective saleCuts are transferred to beneficiaries and funtion return underlyi fun getDetails(): ListingDetails ``` -Fetches the details of the listings +Fetches the details of the listings. --- @@ -237,8 +244,7 @@ Fetches the details of the listings fun getAllowedCommissionReceivers(): [Capability<&{FungibleToken.Receiver}>]? ``` -Fetches the allowed marketplaces capabilities or commission receivers for the underlying listing. -If it returns `nil` then commission is up to grab by anyone. +Fetches the allowed marketplaces capabilities or commission receivers for the underlying listing. If it returns `nil`, then commission is up for grabs by anyone. --- @@ -265,8 +271,7 @@ resource Storefront { } ``` -A resource that allows its owner to manage a list of Listings, and anyone to interact with them -in order to query their details and purchase the NFTs that they represent. +A resource that allows its owner to manage a set of listings, and anyone to interact with them in order to query their details and purchase the NFTs that they represent. Implemented Interfaces: @@ -288,7 +293,7 @@ fun createListing(nftProviderCapability Capability<&{NonFungibleToken.Provider, ``` insert -Create and publish a Listing for an NFT. +Create and publish a listing for an NFT. --- @@ -299,7 +304,7 @@ fun removeListing(listingResourceID UInt64) ``` removeListing -Remove a Listing that has not yet been purchased from the collection and destroy it. +Remove a listing that has not yet been purchased from the collection and destroy it. --- @@ -310,7 +315,7 @@ fun getListingIDs(): [UInt64] ``` getListingIDs -Returns an array of the Listing resource IDs that are in the collection +Returns an array of the listing resource IDs that are in the collection. --- @@ -332,7 +337,7 @@ fun cleanupExpiredListings(fromIndex UInt64, toIndex UInt64) ``` cleanupExpiredListings -Cleanup the expired listing by iterating over the provided range of indexes. +Iterate over the provided range of indexes to clean up the expired listings. --- @@ -361,8 +366,7 @@ resource interface StorefrontPublic { ``` StorefrontPublic -An interface to allow listing and borrowing Listings, and purchasing items via Listings -in a Storefront. +An interface to allow listing and borrowing listings, and purchase items via listings in a Storefront. ### Functions @@ -372,7 +376,8 @@ in a Storefront. fun getListingIDs(): [UInt64] ``` -getListingIDs Returns an array of the Listing resource IDs that are in the collection +getListingIDs +Returns an array of the listing resource IDs that are in the collection --- @@ -382,7 +387,8 @@ getListingIDs Returns an array of the Listing resource IDs that are in the colle fun getDuplicateListingIDs(nftType Type, nftID UInt64, listingID UInt64): [UInt64] ``` -getDuplicateListingIDs Returns an array of listing IDs that are duplicates of the given nftType and nftID. +getDuplicateListingIDs +Returns an array of listing IDs that are duplicates of the given nftType and nftID. --- @@ -392,7 +398,8 @@ getDuplicateListingIDs Returns an array of listing IDs that are duplicates of th fun borrowListing(listingResourceID UInt64): &Listing{ListingPublic}? ``` -borrowListing Returns a read-only view of the listing for the given listingID if it is contained by this collection. +borrowListing +Returns a read-only view of the listing for the given listingID if it is contained by this collection. --- @@ -402,7 +409,8 @@ borrowListing Returns a read-only view of the listing for the given listingID if fun cleanupExpiredListings(fromIndex UInt64, toIndex UInt64) ``` -cleanupExpiredListings Cleanup the expired listing by iterating over the provided range of indexes. +cleanupExpiredListings + Iterates over the provided range of indexes to clean up the expired listing. --- @@ -436,9 +444,7 @@ Returns an array of listing IDs of the given `nftType` and `nftID`. event StorefrontInitialized(storefrontResourceID: UInt64) ``` -A Storefront resource has been created. Consumers can now expect events from this Storefront. Note that we do not specify an address: we cannot and should not. Created resources do not have an owner address, and may be moved -after creation in ways we cannot check. `ListingAvailable` events can be used to determine the address -of the owner of the Storefront at the time of the listing but only at that precise moment in that precise transaction. If the seller moves the Storefront while the listing is valid, that is on them. +A Storefront resource was created. Consumers can now expect events from this Storefront. We do not specify an address: we cannot and should not. Created resources do not have an owner address, and may be moved after creation in ways we cannot check. `ListingAvailable` events can be used to determine the address of the owner of the Storefront at the time of the listing but only at that precise moment in that precise transaction. If the seller moves the Storefront while the listing is valid, that is on them. --- @@ -448,8 +454,7 @@ of the owner of the Storefront at the time of the listing but only at that preci event StorefrontDestroyed(storefrontResourceID: UInt64) ``` -A Storefront has been destroyed. Event consumers can now stop processing events from this Storefront. -Note - we do not specify an address. +A Storefront has been destroyed. Event consumers can now stop processing events from this Storefront. We do not specify an address. --- @@ -459,8 +464,7 @@ Note - we do not specify an address. event ListingAvailable(storefrontAddress: Address, listingResourceID: UInt64, nftType: Type, nftUUID: UInt64, nftID: UInt64, salePaymentVaultType: Type, salePrice: UFix64, customID: String?, commissionAmount: UFix64, commissionReceivers: [Address]?, expiry: UInt64) ``` -Above event gets emitted when a listing has been created and added to a Storefront resource. The Address values here are valid when the event is emitted, but the state of the accounts they refer to may change outside of the -`NFTStorefrontV2` workflow, so be careful to check when using them. +Above event gets emitted when a listing is created and added to a Storefront resource. The Address values here are valid when the event is emitted, but the state of the accounts they refer to may change outside of the `NFTStorefrontV2` workflow, so be careful to check when you use them. --- @@ -470,7 +474,7 @@ Above event gets emitted when a listing has been created and added to a Storefro event ListingCompleted(listingResourceID: UInt64, storefrontResourceID: UInt64, purchased: Bool, nftType: Type, nftUUID: UInt64, nftID: UInt64, salePaymentVaultType: Type, salePrice: UFix64, customID: String?, commissionAmount: UFix64, commissionReceiver: Address?, expiry: UInt64) ``` -The listing has been resolved. It has either been purchased, removed or destroyed. +The listing was resolved. It was either purchased, removed or destroyed. --- @@ -480,7 +484,7 @@ The listing has been resolved. It has either been purchased, removed or destroye event UnpaidReceiver(receiver: Address, entitledSaleCut: UFix64) ``` -A entitled receiver has not been paid during the sale of the NFT. +A entitled receiver wasn't paid during the sale of the NFT. --- diff --git a/docs/build/cadence/core-contracts/11-staking-collection.md b/docs/build/cadence/core-contracts/11-staking-collection.md index 0e807ea29e..f149c5a5af 100644 --- a/docs/build/cadence/core-contracts/11-staking-collection.md +++ b/docs/build/cadence/core-contracts/11-staking-collection.md @@ -21,22 +21,17 @@ keywords: - collection events --- -# Contract +# Flow Staking Collection Contract Reference -The `FlowStakingCollection` contract is a contract that manages a resource containing a user's stake and delegation objects. +The `FlowStakingCollection` contract is a contract that manages a resource which contain a user's stake and delegation objects. -The `FlowStakingCollection` allows a user to manage multiple active nodes or delegators -and interact with node or delegator objects stored in either their optional locked account -or in the StakingCollection itself (stored in the main account). -If a user has locked tokens, StakingCollection allows a user to interact with their locked tokens -to perform staking actions for any of their nodes or delegators. +The `FlowStakingCollection` allows a user to manage multiple active nodes or delegators and interact with node or delegator objects stored in either their optional locked account or in the StakingCollection itself (stored in the main account). If a user has locked tokens, StakingCollection allows a user to interact with their locked tokens to perform staking actions for any of their nodes or delegators. -The staking collection also manages creating a node's machine accounts if they have any collector or consensus nodes. -It also allows them to deposit and withdraw tokens from any of their machine accounts through the staking collection. +The staking collection also manages a node's machine accounts creation process if they have any collector or consensus nodes. It also allows them to deposit and withdraw tokens from any of their machine accounts through the staking collection. -See the [Staking Collection Docs](../../../protocol/staking/14-staking-collection.md) for more information on the design of the staking collection contract. +See the [Staking Collection Docs] for more information on the design of the staking collection contract. -Source: [FlowStakingCollection.cdc](https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowStakingCollection.cdc) +Source: [FlowStakingCollection.cdc] | Network | Contract Address | | ------------------------- | -------------------- | @@ -49,51 +44,49 @@ Source: [FlowStakingCollection.cdc](https://github.com/onflow/flow-core-contract Use the following transactions to interact with the StakingCollection. -\_Note: The StakingCollection differentiates between stake and delegation requests through -passing an optional DelegatorID argument. For example, if you wish to Stake New Tokens for an active node, -pass `nil` as the optional DelegatorID argument to the Stake New Tokens transaction. -The same applies for all the other staking operation transactions. +:::info + +The StakingCollection differentiates between stake and delegation requests through passing an optional DelegatorID argument. For example, if you wish to Stake New Tokens for an active node, pass `nil` as the optional DelegatorID argument to the Stake New Tokens transaction. The same applies for all the other staking operation transactions. + +::: | ID | Name | Source | | ------------ | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **`SCO.01`** | Setup Staking Collection | [stakingCollection/setup_staking_collection.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/setup_staking_collection.cdc) | -| **`SCO.02`** | Register Delegator | [stakingCollection/register_delegator.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/register_delegator.cdc) | -| **`SCO.03`** | Register Node | [stakingCollection/register_node.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/register_node.cdc) | -| **`SCO.04`** | Create Machine Account | [stakingCollection/create_machine_account.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/create_machine_account.cdc) | -| **`SCO.05`** | Request Unstaking | [stakingCollection/request_unstaking.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/request_unstaking.cdc) | -| **`SCO.06`** | Stake New Tokens | [stakingCollection/stake_new_tokens.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_new_tokens.cdc) | -| **`SCO.07`** | Stake Rewarded Tokens | [stakingCollection/stake_rewarded_tokens.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_rewarded_tokens.cdc) | -| **`SCO.08`** | Stake Unstaked Tokens | [stakingCollection/stake_unstaked_tokens.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_unstaked_tokens.cdc) | -| **`SCO.09`** | Unstake All | [stakingCollection/unstake_all.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/unstake_all.cdc) | -| **`SCO.10`** | Withdraw Rewarded Tokens | [stakingCollection/withdraw_rewarded_tokens.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_rewarded_tokens.cdc) | -| **`SCO.11`** | Withdraw Unstaked Tokens | [stakingCollection/withdraw_unstaked_tokens.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_unstaked_tokens.cdc) | -| **`SCO.12`** | Close Stake | [stakingCollection/close_stake.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/close_stake.cdc) | -| **`SCO.13`** | Transfer Node | [stakingCollection/transfer_node.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/transfer_node.cdc) | -| **`SCO.14`** | Transfer Delegator | [stakingCollection/transfer_delegator.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/transfer_delegator.cdc) | -| **`SCO.15`** | Withdraw From Machine Account | [stakingCollection/withdraw_from_machine_account.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_from_machine_account.cdc) | -| **`SCO.22`** | Update Networking Address | [stakingCollection/update_networking_address.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/update_networking_address.cdc) | +| **`SCO.01`** | Setup Staking Collection | [stakingCollection/setup_staking_collection.cdc] | +| **`SCO.02`** | Register Delegator | [stakingCollection/register_delegator.cdc] | +| **`SCO.03`** | Register Node | [stakingCollection/register_node.cdc] | +| **`SCO.04`** | Create Machine Account | [stakingCollection/create_machine_account.cdc] | +| **`SCO.05`** | Request Unstaking | [stakingCollection/request_unstaking.cdc] | +| **`SCO.06`** | Stake New Tokens | [stakingCollection/stake_new_tokens.cdc] | +| **`SCO.07`** | Stake Rewarded Tokens | [stakingCollection/stake_rewarded_tokens.cdc] | +| **`SCO.08`** | Stake Unstaked Tokens | [stakingCollection/stake_unstaked_tokens.cdc] | +| **`SCO.09`** | Unstake All | [stakingCollection/unstake_all.cdc] | +| **`SCO.10`** | Withdraw Rewarded Tokens | [stakingCollection/withdraw_rewarded_tokens.cdc] | +| **`SCO.11`** | Withdraw Unstaked Tokens | [stakingCollection/withdraw_unstaked_tokens.cdc] | +| **`SCO.12`** | Close Stake | [stakingCollection/close_stake.cdc] | +| **`SCO.13`** | Transfer Node | [stakingCollection/transfer_node.cdc] | +| **`SCO.14`** | Transfer Delegator | [stakingCollection/transfer_delegator.cdc] | +| **`SCO.15`** | Withdraw From Machine Account | [stakingCollection/withdraw_from_machine_account.cdc] | +| **`SCO.22`** | Update Networking Address | [stakingCollection/update_networking_address.cdc] | ## Scripts | ID | Name | Source | | ------------ | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **`SCO.16`** | Get All Delegator Info | [stakingCollection/scripts/get_all_delegator_info.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_all_delegator_info.cdc) | -| **`SCO.15`** | Get All Node Info | [stakingCollection/scripts/get_all_node_info.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_all_node_info.cdc) | -| **`SCO.22`** | Get Delegator Ids | [stakingCollection/scripts/get_delegator_ids.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_delegator_ids.cdc) | -| **`SCO.17`** | Get Node Ids | [stakingCollection/scripts/get_node_ids.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_node_ids.cdc) | -| **`SCO.18`** | Get Does Stake Exist | [stakingCollection/scripts/get_does_stake_exist.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_does_stake_exist.cdc) | -| **`SCO.19`** | Get Locked Tokens Used | [stakingCollection/scripts/get_locked_tokens_used.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_locked_tokens_used.cdc) | -| **`SCO.20`** | Get Unlocked Tokens Used | [stakingCollection/scripts/get_unlocked_tokens_used.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_unlocked_tokens_used.cdc) | -| **`SCO.21`** | Get Machine Accounts | [stakingCollection/scripts/get_machine_accounts.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_machine_accounts.cdc) | +| **`SCO.16`** | Get All Delegator Info | [stakingCollection/scripts/get_all_delegator_info.cdc] | +| **`SCO.15`** | Get All Node Info | [stakingCollection/scripts/get_all_node_info.cdc] | +| **`SCO.22`** | Get Delegator Ids | [stakingCollection/scripts/get_delegator_ids.cdc] | +| **`SCO.17`** | Get Node Ids | [stakingCollection/scripts/get_node_ids.cdc] | +| **`SCO.18`** | Get Does Stake Exist | [stakingCollection/scripts/get_does_stake_exist.cdc] | +| **`SCO.19`** | Get Locked Tokens Used | [stakingCollection/scripts/get_locked_tokens_used.cdc] | +| **`SCO.20`** | Get Unlocked Tokens Used | [stakingCollection/scripts/get_unlocked_tokens_used.cdc] | +| **`SCO.21`** | Get Machine Accounts | [stakingCollection/scripts/get_machine_accounts.cdc] | ## Setup Transaction To setup the Staking Collection for an account, use the `SC.01` transaction. -The setup process finds any node or delegator records already stored in the main account's storage, -as well as any in the associated locked account if an associated locked account exists. -It connects these node and delegator records with the new Staking Collection, allowing them -to be interacted with using the Staking Collection API. +The setup process finds any node or delegator records already stored in the main account's storage, as well as any in the associated locked account if an associated locked account exists. It connects these node and delegator records with the new Staking Collection, and you ue the Staking Collection API to interact with them. ## Events @@ -108,3 +101,32 @@ The `StakingCollection` contract emits an event whenever an important action occ access(all) event MachineAccountCreated(nodeID: String, role: UInt8, address: Address) ``` + + + +[Staking Collection Docs]: ../../../protocol/staking/14-staking-collection.md +[FlowStakingCollection.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/contracts/FlowStakingCollection.cdc +[stakingCollection/setup_staking_collection.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/setup_staking_collection.cdc +[stakingCollection/register_delegator.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/register_delegator.cdc +[stakingCollection/register_node.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/register_node.cdc +[stakingCollection/request_unstaking.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/request_unstaking.cdc +[stakingCollection/stake_new_tokens.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_new_tokens.cdc +[stakingCollection/stake_rewarded_tokens.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_rewarded_tokens.cdc +[stakingCollection/stake_unstaked_tokens.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/stake_unstaked_tokens.cdc +[stakingCollection/unstake_all.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/unstake_all.cdc +[stakingCollection/withdraw_rewarded_tokens.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_rewarded_tokens.cdc +[stakingCollection/withdraw_unstaked_tokens.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_unstaked_tokens.cdc +[stakingCollection/close_stake.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/close_stake.cdc +[stakingCollection/transfer_node.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/transfer_node.cdc +[stakingCollection/transfer_delegator.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/transfer_delegator.cdc +[stakingCollection/withdraw_from_machine_account.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/withdraw_from_machine_account.cdc +[stakingCollection/update_networking_address.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/update_networking_address.cdc +[stakingCollection/scripts/get_all_delegator_info.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_all_delegator_info.cdc +[stakingCollection/scripts/get_all_node_info.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_all_node_info.cdc +[stakingCollection/scripts/get_delegator_ids.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_delegator_ids.cdc +[stakingCollection/scripts/get_node_ids.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_node_ids.cdc +[stakingCollection/scripts/get_does_stake_exist.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_does_stake_exist.cdc +[stakingCollection/scripts/get_locked_tokens_used.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_locked_tokens_used.cdc +[stakingCollection/scripts/get_unlocked_tokens_used.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_unlocked_tokens_used.cdc +[stakingCollection/scripts/get_machine_accounts.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/scripts/get_machine_accounts.cdc +[stakingCollection/create_machine_account.cdc]: https://github.com/onflow/flow-core-contracts/blob/master/transactions/stakingCollection/create_machine_account.cdc \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/12-hybrid-custody.md b/docs/build/cadence/core-contracts/12-hybrid-custody.md index b449c32143..49ae7fca38 100644 --- a/docs/build/cadence/core-contracts/12-hybrid-custody.md +++ b/docs/build/cadence/core-contracts/12-hybrid-custody.md @@ -21,13 +21,19 @@ keywords: - custody model --- -# Contract +# Flow Account Linking Contract Address The Account Linking contracts manage ChildAccounts to permit hybrid custody in scenarios where apps only want to share a subset of resources on their accounts with various parents. In many cases, this will be a user's primary wallet outside of the application a child account came from. -You can see the docs for account linking [here](https://developers.flow.com/build/cadence/advanced-concepts/account-linking) +You can see the docs for account linking [here] | Network | Contract Address | | ------- | ------------------------------------------------------------------------------ | -| Testnet | [`0x294e44e1ec6993c6`](https://contractbrowser.com/account/0x294e44e1ec6993c6) | -| Mainnet | [`0xd8a7e05a7ac670c0`](https://contractbrowser.com/account/0xd8a7e05a7ac670c0) | +| Testnet | [`0x294e44e1ec6993c6`] | +| Mainnet | [`0xd8a7e05a7ac670c0`] | + + + +[here]: https://developers.flow.com/build/cadence/advanced-concepts/account-linking +[`0x294e44e1ec6993c6`]: https://contractbrowser.com/account/0x294e44e1ec6993c6 +[`0xd8a7e05a7ac670c0`]: https://contractbrowser.com/account/0xd8a7e05a7ac670c0 \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/13-evm.md b/docs/build/cadence/core-contracts/13-evm.md index 6efeeced59..d6465fabde 100644 --- a/docs/build/cadence/core-contracts/13-evm.md +++ b/docs/build/cadence/core-contracts/13-evm.md @@ -21,21 +21,25 @@ keywords: - FLIP 223 --- -# Contract +# Flow EVM -The `EVM` contract is the entrypoint from Cadence to Flow EVM. While many developers may choose to interact with EVM -via [EVM-equivalent tooling paths](../../../build/evm/using.mdx), all access to Flow EVM ultimately interfaces via Cadence at -some level. +The `EVM` contract is the entrypoint from Cadence to Flow EVM. While many developers may choose to interact with EVM via [EVM-equivalent tooling paths], all access to Flow EVM ultimately interfaces via Cadence at some level. -If you would like to interact with EVM directly from Cadence, you can use the `EVM` contract and it's constructs. Read -more about the EVM contract and its role in Flow's EVM equivalence in [FLIP -#223](https://github.com/onflow/flips/blob/main/protocol/20231116-evm-support.md). +If you would like to interact with EVM directly from Cadence, you can use the `EVM` contract and it's constructs. Read more about the EVM contract and its role in Flow's EVM equivalence in [FLIP #223]. -Mainnet/Testnet Source: [`EVM.cdc`](https://github.com/onflow/flow-go/blob/master/fvm/evm/stdlib/contract.cdc) +Mainnet/Testnet Source: [`EVM.cdc`] | Network | Contract Address | | ------------------------- | -------------------------------------------------------------------------- | | Emulator | `0xf8d6e0586b0a20c7` | | Cadence Testing Framework | `0x0000000000000001` | -| Testnet | [`0x8c5303eaa26202d6`](https://contractbrowser.com/A.8c5303eaa26202d6.EVM) | -| Mainnet | [`0xe467b9dd11fa00df`](https://contractbrowser.com/A.e467b9dd11fa00df.EVM) | +| Testnet | [`0x8c5303eaa26202d6`] | +| Mainnet | [`0xe467b9dd11fa00df`] | + + + +[EVM-equivalent tooling paths]: ../../../build/evm/using.mdx +[FLIP #223]: https://github.com/onflow/flips/blob/main/protocol/20231116-evm-support.md +[`EVM.cdc`]: https://github.com/onflow/flow-go/blob/master/fvm/evm/stdlib/contract.cdc +[`0x8c5303eaa26202d6`]: https://contractbrowser.com/A.8c5303eaa26202d6.EVM +[`0xe467b9dd11fa00df`]: https://contractbrowser.com/A.e467b9dd11fa00df.EVM \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/14-burner.md b/docs/build/cadence/core-contracts/14-burner.md index 585fe57f2f..0936727e24 100644 --- a/docs/build/cadence/core-contracts/14-burner.md +++ b/docs/build/cadence/core-contracts/14-burner.md @@ -21,20 +21,21 @@ keywords: - burn operations --- -# Contract +# Flow Burner Contract Address -The [Burner](https://github.com/onflow/flow-ft/blob/master/contracts/utility/Burner.cdc) contract provides a way for resources to define -custom logic that is executed when the resource is destroyed. -Resources that want to utilize this functionality should implement -the `Burner.Burnable` interface which requires that they include -a `burnCallback()` function that includes the custom logic. +The [Burner](https://github.com/onflow/flow-ft/blob/master/contracts/utility/Burner.cdc) contract provides a way for resources to define custom logic that is executed when the resource is destroyed. Resources that want to use this functionality should implement the `Burner.Burnable` interface which requires that they include a `burnCallback()` function that includes the custom logic. -It is recommended that regardless of the resource, all users and developers -should use `Burner.burn()` when destroying a resource instead of `destroy`. +We recommend that, regardless of the resource, all users and developers should use `Burner.burn()` when they destroy a resource instead of `destroy`. | Network | Contract Address | | ------- | ------------------------------------------------------------------------------ | | Cadence Testing Framework | `0x0000000000000001` | | Emulator | `0xee82856bf20e2aa6` | -| Testnet | [`0x294e44e1ec6993c6`](https://contractbrowser.com/account/0x294e44e1ec6993c6) | -| Mainnet | [`0xd8a7e05a7ac670c0`](https://contractbrowser.com/account/0xd8a7e05a7ac670c0) | \ No newline at end of file +| Testnet | [`0x294e44e1ec6993c6`] | +| Mainnet | [`0xd8a7e05a7ac670c0`] | + + + +[Burner]: https://github.com/onflow/flow-ft/blob/master/contracts/utility/Burner.cdc +[`0x294e44e1ec6993c6`]: https://contractbrowser.com/account/0x294e44e1ec6993c6 +[`0xd8a7e05a7ac670c0`]: https://contractbrowser.com/account/0xd8a7e05a7ac670c0 \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/15-bridge.md b/docs/build/cadence/core-contracts/15-bridge.md index 211c8ce8e7..8b28e87242 100644 --- a/docs/build/cadence/core-contracts/15-bridge.md +++ b/docs/build/cadence/core-contracts/15-bridge.md @@ -13,8 +13,9 @@ keywords: - nft --- -The Flow VM bridge is the account and series of smart contracts that manage how -assets are safely bridged between the Cadence and EVM Flow Environments. +# VM Bridge Contracts + +The Flow VM bridge is the account and series of smart contracts that manage how assets are safely bridged between the Cadence and EVM Flow Environments. | Network | Contract Address | | ------------------------- | -------------------- | @@ -25,57 +26,70 @@ assets are safely bridged between the Cadence and EVM Flow Environments. # Contracts -There are many important contracts deployed to the bridge account. -You should refer to [the bridge repo](https://github.com/onflow/flow-evm-bridge) -and [the bridge guides](../../../blockchain-development-tutorials/cross-vm-apps/vm-bridge.md) -for more detailed information about the bridge and tutorials for how to use the bridge properly. +There are many important contracts deployed to the bridge account. You should refer to [the bridge repo] and [the bridge guides] for more detailed information about the bridge and tutorials for how to use the bridge properly. Here is a list of each Cadence contract used for the bridge: | Contract | Purpose | | ------------------------------------- | --------------------------------------------------------------------------------------------------------- | -| `CrossVMNFT` | Contract defining cross-VM NFT-related interfaces | -| `CrossVMToken` | Contract defining cross-VM Fungible Token Vault interface | -| `FlowEVMBridgeHandlerInterfaces` | Defines interface for custom bridged token handlers | -| `IBridgePermissions` | Defines an interface to prevent bridging for a specific token | -| `ICrossVM` | Defines an interface to get EVM contract addresses | -| `ICrossVMAsset` | Defines an interface to represent a Cadence bridged version of an EVM asset | -| `IEVMBridgeNFTMinter` | Defines an interface that allows the bridge to mint NFTs | -| `IEVMBridgeTokenMinter` | Defines an interface that allows the bridge to mint FTs | -| `IFlowEVMNFTBridge` | Defines core methods for bridging NFTs | -| `IFlowEVMTokenBridge` | Defines core methods for bridging FTs | -| `FlowEVMBridge` | The main entrypoint for briding tokens across Flow VMs | -| `FlowEVMBridgeAccessor` | Defines methods to route bridge requests from the EVM contract to the Flow-EVM bridge contract | -| `FlowEVMBridgeConfig` | Used to store configuration options for the VM Bridge | -| `FlowEVMBridgeCustomAssociations` | Stores configuration information about custom bridged asset configurations | -| `FlowEVMBridgeCustomAssociationTypes` | Defines interfaces used to specify custom bridged asset associations | -| `FlowEVMBridgeHandlers` | Defines mechanisms for handling assets with custom associations (Deprecated) | -| `FlowEVMBridgeNFTEscrow` | Handles locking of NFTs that are bridged from Flow to EVM and back | -| `FlowEVMBridgeResolver` | Defines methods to resolve Metadata Views for bridged assets | -| `FlowEVMBridgeTemplates` | Serves Cadence code from chunked templates for bridge-deployed assets | -| `FlowEVMBridgeTokenEscrow` | Handles locking of FTs that are bridged from Flow to EVM and back | -| `FlowEVMBridgeUtils` | Defines many different utility methods that are used by bridge contracts | -| `ArrayUtils` | Provides useful utility functions for manipulating arrays | -| `ScopedFTProviders` | Provides utilities for creating provider capabilities for tokens that are restricted to a specific amount | -| `Serialize` | Provides utilities for serializing common types to json-compatible strings | -| `SerializeMetadata` | Provides methods for serializing NFT metadata as a JSON compatible string | -| `StringUtils` | Provides useful utility functions for manipulating strings | +| `CrossVMNFT` | Contract that defines cross-VM NFT-related interfaces. | +| `CrossVMToken` | Contract that defines cross-VM Fungible Token Vault interfaces. | +| `FlowEVMBridgeHandlerInterfaces` | Defines interface for custom bridged token handlers. | +| `IBridgePermissions` | Defines an interface to prevent bridging for a specific token. | +| `ICrossVM` | Defines an interface to get EVM contract addresses. | +| `ICrossVMAsset` | Defines an interface to represent a Cadence bridged version of an EVM asset. | +| `IEVMBridgeNFTMinter` | Defines an interface that allows the bridge to mint NFTs. | +| `IEVMBridgeTokenMinter` | Defines an interface that allows the bridge to mint FTs. | +| `IFlowEVMNFTBridge` | Defines core methods for bridging NFTs. | +| `IFlowEVMTokenBridge` | Defines core methods for bridging FTs. | +| `FlowEVMBridge` | The main entrypoint for briding tokens across Flow VMs. | +| `FlowEVMBridgeAccessor` | Defines methods to route bridge requests from the EVM contract to the Flow-EVM bridge contract. | +| `FlowEVMBridgeConfig` | Used to store configuration options for the VM Bridge. | +| `FlowEVMBridgeCustomAssociations` | Stores configuration information about custom bridged asset configurations. | +| `FlowEVMBridgeCustomAssociationTypes` | Defines interfaces used to specify custom bridged asset associations. | +| `FlowEVMBridgeHandlers` | Defines mechanisms to handle assets with custom associations (Deprecated). | +| `FlowEVMBridgeNFTEscrow` | Handles locking of NFTs that are bridged from Flow to EVM and back. | +| `FlowEVMBridgeResolver` | Defines methods to resolve Metadata Views for bridged assets. | +| `FlowEVMBridgeTemplates` | Serves Cadence code from chunked templates for bridge-deployed assets. | +| `FlowEVMBridgeTokenEscrow` | Handles locking of FTs that are bridged from Flow to EVM and back. | +| `FlowEVMBridgeUtils` | Defines many different utility methods that are used by bridge contracts. | +| `ArrayUtils` | Provides useful utility functions for array manipulation. | +| `ScopedFTProviders` | Provides utilities to create provider capabilities for tokens that are restricted to a specific amount. | +| `Serialize` | Provides utilities to serialize common types to JSON compatible strings. | +| `SerializeMetadata` | Provides methods to serialize NFT metadata as a JSON compatible string. | +| `StringUtils` | Provides useful utility functions for string manipulation. | -# EVM Bridge Solidity Contracts +# EVM bridge Solidity contracts There are also Solidity contracts that are deployed in Flow EVM that are needed for the bridge. Here are their addresses: | Contracts | Testnet | Mainnet | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -| `FlowEVMBridgeFactory.sol` | [`0xf8146b4aef631853f0eb98dbe28706d029e52c52`](https://evm-testnet.flowscan.io/address/0xF8146B4aEF631853F0eB98DBE28706d029e52c52) | [`0x1c6dea788ee774cf15bcd3d7a07ede892ef0be40`](https://evm.flowscan.io/address/0x1C6dEa788Ee774CF15bCd3d7A07ede892ef0bE40) | -| `FlowEVMBridgeDeploymentRegistry.sol` | [`0x8781d15904d7e161f421400571dea24cc0db6938`](https://evm-testnet.flowscan.io/address/0x8781d15904d7e161f421400571dea24cc0db6938) | [`0x8fdec2058535a2cb25c2f8cec65e8e0d0691f7b0`](https://evm.flowscan.io/address/0x8FDEc2058535A2Cb25C2f8ceC65e8e0D0691f7B0) | -| `FlowEVMBridgedERC20Deployer.sol` | [`0x4d45CaD104A71D19991DE3489ddC5C7B284cf263`](https://evm-testnet.flowscan.io/address/0x4d45CaD104A71D19991DE3489ddC5C7B284cf263) | [`0x49631Eac7e67c417D036a4d114AD9359c93491e7`](https://evm.flowscan.io/address/0x49631Eac7e67c417D036a4d114AD9359c93491e7) | -| `FlowEVMBridgedERC721Deployer.sol` | [`0x1B852d242F9c4C4E9Bb91115276f659D1D1f7c56`](https://evm-testnet.flowscan.io/address/0x1B852d242F9c4C4E9Bb91115276f659D1D1f7c56) | [`0xe7c2B80a9de81340AE375B3a53940E9aeEAd79Df`](https://evm.flowscan.io/address/0xe7c2B80a9de81340AE375B3a53940E9aeEAd79Df) | +| `FlowEVMBridgeFactory.sol` | [`0xf8146b4aef631853f0eb98dbe28706d029e52c52`] | [`0x1c6dea788ee774cf15bcd3d7a07ede892ef0be40`] | +| `FlowEVMBridgeDeploymentRegistry.sol` | [`0x8781d15904d7e161f421400571dea24cc0db6938`] | [`0x8fdec2058535a2cb25c2f8cec65e8e0d0691f7b0`] | +| `FlowEVMBridgedERC20Deployer.sol` | [`0x4d45CaD104A71D19991DE3489ddC5C7B284cf263`] | [`0x49631Eac7e67c417D036a4d114AD9359c93491e7`] | +| `FlowEVMBridgedERC721Deployer.sol` | [`0x1B852d242F9c4C4E9Bb91115276f659D1D1f7c56`] | [`0xe7c2B80a9de81340AE375B3a53940E9aeEAd79Df`] | -And below are the bridge escrow's EVM addresses. These addresses are [`CadenceOwnedAccount`s (COA)](https://developers.flow.com/blockchain-development-tutorials/cross-vm-apps/interacting-with-coa#coa-interface) and they are stored stored in the same Flow account as you'll find the Cadence contracts (see above). +And below are the bridge escrow's EVM addresses. These addresses are [`CadenceOwnedAccount`s (COA)] and they are stored in the same Flow account as you'll find the Cadence contracts (see above). | Network | Address | | ------- | ---------------------------------------------------------------------------------------------------------------------------------- | -| Testnet | [`0x0000000000000000000000023f946ffbc8829bfd`](https://evm-testnet.flowscan.io/address/0x0000000000000000000000023f946FFbc8829BFD) | -| Mainnet | [`0x00000000000000000000000249250a5c27ecab3b`](https://evm.flowscan.io/address/0x00000000000000000000000249250a5C27Ecab3B) | +| Testnet | [`0x0000000000000000000000023f946ffbc8829bfd`] | +| Mainnet | [`0x00000000000000000000000249250a5c27ecab3b`] | + + + +[the bridge repo]: https://github.com/onflow/flow-evm-bridge +[the bridge guides]: ../../../blockchain-development-tutorials/cross-vm-apps/vm-bridge.md +[`0xf8146b4aef631853f0eb98dbe28706d029e52c52`]: https://evm-testnet.flowscan.io/address/0xF8146B4aEF631853F0eB98DBE28706d029e52c52) +[`0x1c6dea788ee774cf15bcd3d7a07ede892ef0be40`]: https://evm.flowscan.io/address/0x1C6dEa788Ee774CF15bCd3d7A07ede892ef0bE40 +[`0x8781d15904d7e161f421400571dea24cc0db6938`]: https://evm-testnet.flowscan.io/address/0x8781d15904d7e161f421400571dea24cc0db6938 +[`0x8fdec2058535a2cb25c2f8cec65e8e0d0691f7b0`]: https://evm.flowscan.io/address/0x8FDEc2058535A2Cb25C2f8ceC65e8e0D0691f7B0 +[`0x4d45CaD104A71D19991DE3489ddC5C7B284cf263`]: https://evm-testnet.flowscan.io/address/0x4d45CaD104A71D19991DE3489ddC5C7B284cf263 +[`0x49631Eac7e67c417D036a4d114AD9359c93491e7`]: https://evm.flowscan.io/address/0x49631Eac7e67c417D036a4d114AD9359c93491e7 +[`0x1B852d242F9c4C4E9Bb91115276f659D1D1f7c56`]: https://evm-testnet.flowscan.io/address/0x1B852d242F9c4C4E9Bb91115276f659D1D1f7c56 +[`0xe7c2B80a9de81340AE375B3a53940E9aeEAd79Df`]: https://evm.flowscan.io/address/0xe7c2B80a9de81340AE375B3a53940E9aeEAd79Df +[`CadenceOwnedAccount`s (COA)]: https://developers.flow.com/blockchain-development-tutorials/cross-vm-apps/interacting-with-coa#coa-interface +[`0x0000000000000000000000023f946ffbc8829bfd`]: https://evm-testnet.flowscan.io/address/0x0000000000000000000000023f946FFbc8829BFD +[`0x00000000000000000000000249250a5c27ecab3b`]: https://evm.flowscan.io/address/0x00000000000000000000000249250a5C27Ecab3B) \ No newline at end of file diff --git a/docs/build/cadence/core-contracts/index.md b/docs/build/cadence/core-contracts/index.md index 0b8ffb0828..f542254114 100644 --- a/docs/build/cadence/core-contracts/index.md +++ b/docs/build/cadence/core-contracts/index.md @@ -27,24 +27,41 @@ keywords: - contract standards --- +# Flow Core Contracts + Flow relies on a set of core contracts that define key portions of the Flow protocol. These contracts control the following: -- Standard fungible token behavior. ([FungibleToken, FungibleTokenMetadataViews, FungibleTokenSwitchboard, Burner](./02-fungible-token.md)) +- Standard fungible token behavior. ([FungibleToken, FungibleTokenMetadataViews, FungibleTokenSwitchboard, Burner]) - Flow Protocol Token. ([FlowToken](./03-flow-token.md)) -- Flow Service Account. ([ServiceAccount, NodeVersionBeacon, RandomBeaconHistory](./04-service-account.md)) -- Account, transaction and storage fee payments. ([FlowFees and FlowStorageFees](./05-flow-fees.md)) -- Staking and delegation ([FlowIDTableStaking](./06-staking-contract-reference.md)) -- Epochs ([FlowEpoch, FlowClusterQC, FlowDKG](./07-epoch-contract-reference.md)) +- Flow Service Account. ([ServiceAccount, NodeVersionBeacon, RandomBeaconHistory]) +- Account, transaction and storage fee payments. ([FlowFees and FlowStorageFees]) +- Staking and delegation ([FlowIDTableStaking]) +- Epochs ([FlowEpoch, FlowClusterQC, FlowDKG]) There are other important contracts that aren't part of the core protocol but are nevertheless important to developers on Flow: -- Standard Non-Fungible Token Behavior. ([NonFungibleToken](./08-non-fungible-token.md)) -- NFT Metadata Standard. ([MetadataViews, ViewResolver](./09-nft-metadata.md)) -- Staking Collection. ([StakingCollection](./11-staking-collection.md)) -- NFT Storefronts. ([NFTStorefront](./10-nft-storefront.md)) -- Account linking and Hybrid Custody. ([AccountLinking](./12-hybrid-custody.md)) -- EVM interfacing contract. ([EVM](./13-evm.md)) +- Standard Non-Fungible Token Behavior. ([NonFungibleToken]) +- NFT Metadata Standard. ([MetadataViews, ViewResolver]) +- Staking Collection. ([StakingCollection]) +- NFT Storefronts. ([NFTStorefront]) +- Account linking and Hybrid Custody. ([AccountLinking]) +- EVM interfacing contract. ([EVM]) + + + +[FungibleToken, FungibleTokenMetadataViews, FungibleTokenSwitchboard, Burner]: ./02-fungible-token.md +[FlowToken]: ./03-flow-token.md +[ServiceAccount, NodeVersionBeacon, RandomBeaconHistory]: ./04-service-account.md +[FlowFees and FlowStorageFees]: ./05-flow-fees.md +[FlowIDTableStaking]: ./06-staking-contract-reference.md +[FlowEpoch, FlowClusterQC, FlowDKG]: ./07-epoch-contract-reference.md +[NonFungibleToken]: ./08-non-fungible-token.md)) +[MetadataViews, ViewResolver]: ./09-nft-metadata.md)) +[StakingCollection]: ./11-staking-collection.md +[NFTStorefront]: ./10-nft-storefront.md +[AccountLinking]: ./12-hybrid-custody.md +[EVM]: ./13-evm.md) \ No newline at end of file diff --git a/docs/build/cadence/differences-vs-evm/index.md b/docs/build/cadence/differences-vs-evm/index.md index 9e98e16ef5..8797e2462b 100644 --- a/docs/build/cadence/differences-vs-evm/index.md +++ b/docs/build/cadence/differences-vs-evm/index.md @@ -22,29 +22,31 @@ keywords: - developer tools --- +# Differences vs. EVM + Flow [Cadence] is designed with many improvements over prior blockchain networks. As a result, you'll notice many differences between Flow vs. other blockchains, especially Ethereum. This document will be most useful to developers who are already familiar with building on the EVM, but contains details useful to all developers. Check out [Why Flow] for a more general overview of the Flow blockchain. :::tip -Remember, Flow also supports full [EVM] equivalence! You can start by moving over your existing contracts, then start building new features that take advantage of the power of Cadence. +Remember, Flow also supports full [EVM] equivalence! To start, you can move over your current contracts, then start to build new features that take advantage of the power of Cadence. ::: -## The Flow Cadence Account Model +## The Flow Cadence account model -Key pairs establish ownership on blockchains. In other blockchains (e.g. Bitcoin and Ethereum), the user's address is also calculated based on their public key, making a unique one-to-one relationship between accounts (addresses) and public keys. This also means there is no concrete "account creation" process other than generating a valid key pair. +Key pairs establish ownership on blockchains. In other blockchains (such as Bitcoin and Ethereum), the user's address is also calculated based on their public key, which establishes a unique one-to-one relationship between accounts (addresses) and public keys. This also means there is no concrete "account creation" process other than to generate a valid key pair. -With the advent of smart contracts, Ethereum introduced a new account type for deploying contracts that can use storage space (i.e., to store contract bytecode). You can learn more about the distinction between EOA and Contract [accounts on Ethereum]. +With the advent of smart contracts, Ethereum introduced a new account type to deploy contracts that can use storage space (for example, to store contract bytecode). You can learn more about the distinction between EOA and Contract [accounts on Ethereum]. -The [Flow account model] combines the concepts of EOAs and Contract Accounts into a single account model and decouples accounts and public keys. Flow accounts are associated with one or more public keys of varying weights that specify interested parties that need to produce valid cryptographic signatures for each transaction authorized by that account. +The [Flow account model] combines the concepts of EOAs and Contract Accounts into a single account model and decouples accounts and public keys. Flow accounts are associated with one or more public keys of various weights that specify interested parties that need to produce valid cryptographic signatures for each transaction authorized by that account. ![Screenshot 2023-08-16 at 16.43.07.png](../basics/_accounts_images/Screenshot_2023-08-16_at_16.43.07.png) -This natively enables interesting use cases, like key revocation, rotation, and multi-signature transactions. All Flow accounts can use network storage (e.g., for deploying contracts and storing resources like NFTs) based on the number of FLOW tokens they hold. +This natively allows interesting use cases, like key revocation, rotation, and multi-signature transactions. All Flow accounts can use network storage (for example, to deploy contracts and store resources like NFTs) based on the number of FLOW tokens they hold. :::warning -You must run an explicit account creation transaction on Flow to create a new account. [Flow CLI] can create an account on any network with a given public key. Doing so requires a [very small fee] to be paid in FLOW. +You must run an explicit account creation transaction on Flow to create a new account. [Flow CLI] can create an account on any network with a given public key. This requires a [very small fee] to be paid in FLOW. ::: @@ -52,12 +54,12 @@ Another key difference is that [storage] for data and assets related to an accou Check out the [Accounts] concept document to learn more about Flow accounts. -## Smart Contracts +## Smart contracts On Flow, smart contracts can be written in [Cadence], or Solidity. Cadence syntax is user-friendly and inspired by modern languages like Swift. Notable features of Cadence that make it unique and the key power of the Flow blockchain are: - **Resource-oriented**: Cadence introduces a new type called Resources. Resources enable onchain representation of digital assets natively and securely. Resources can only exist in one location at a time and are strictly controlled by the execution environment to avoid common mishandling mistakes. Each resource has a unique `uuid` associated with it on the blockchain. Examples of usage are fungible tokens, NFTs, or any custom data structure representing a real-world asset. Check out [Resources] to learn more. -- **Capability-based**: Cadence offers a [Capability-based Security] model. This also enables the use of Resources as structures to build access control. Capabilities and [Entitlements] can provide fine-grained access to the underlying objects for better security. For example, when users list an NFT on a Flow marketplace, they create a new Capability to the stored NFT in their account so the buyer can withdraw the asset when they provide the tokens. Check out [Capability-based Access Control] to learn more about Capabilities on Cadence. +- **Capability-based**: Cadence offers a [Capability-based Security] model. This also allows the use of Resources as structures to build access control. Capabilities and [Entitlements] can provide fine-grained access to the underlying objects for better security. For example, when users list an NFT on a Flow marketplace, they create a new Capability to the stored NFT in their account so the buyer can withdraw the asset when they provide the tokens. Check out [Capability-based Access Control] to learn more about Capabilities on Cadence. :::warning @@ -73,18 +75,18 @@ Here are some additional resources that can help you get started with Cadence: - [The Cadence tutorial] - ERC-20 equivalent on Flow is the Flow Fungible Token Standard - - [Repository](https://github.com/onflow/flow-ft) - - [Tutorial](https://cadence-lang.org/docs/tutorial/fungible-tokens) + - [Flow FT Repository] + - [FT Tutorial] - ERC-721 equivalent on Flow is the Flow Non-Fungible Token Standard - - [Repository](https://github.com/onflow/flow-nft) - - [Tutorial](https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1) + - [Flow NFT Repository] + - [NFT Tutorial] - Asset marketplaces with Cadence - - [Tutorial](https://cadence-lang.org/docs/tutorial/marketplace-setup) - - [NFT Storefront](https://github.com/onflow/nft-storefront/) is an example marketplace standard + - [Marketplace Setup Tutorial] + - [NFT Storefront] is an example marketplace standard -## Transactions and Scripts +## Transactions and scripts -You can interact with the state on most other blockchains by cryptographically authorizing smart contract function calls. On Flow, transactions offer rich functionality through Cadence code. This allows you to seamlessly combine multiple contracts and function calls into a single transaction that updates the blockchain state - all executing together as one unified operation. +To interact with the state on most other blockchains, you can cryptographically authorize smart contract function calls. On Flow, transactions offer rich functionality through Cadence code. This allows you to seamlessly combine multiple contracts and function calls into a single transaction that updates the blockchain state - which all execute together as one unified operation. Here is a sample transaction that mints an NFT from `ExampleNFT` contract on Testnet: @@ -138,17 +140,17 @@ transaction(recipient: Address) { } ``` -### Authorizing Transactions +### Authorize transactions The process to authorize a transaction on Flow Cadence is more complex, but also much more powerful than an EVM transaction: -- [Accounts] can have multiple keys with varying weights -- Multiple accounts can sign a single transaction (`prepare` takes any number of arguments) +- [Accounts] can have multiple keys with different weights. +- Multiple accounts can sign a single transaction (`prepare` takes any number of arguments). - Transaction computation fees can be paid by a different account, called the `Payer` account. - The [transaction nonce] is provided by the `Proposer` account. This enables rate control and order to be dictated by a different party if needed. - All of the above roles can be the same account. -The same powerful concept also exists for querying the blockchain state using Scripts. Here is a sample script that fetches the `ExampleNFT` IDs owned by a given account on Testnet: +The same powerful concept also exists to query the blockchain state with Scripts. Here is a sample script that fetches the `ExampleNFT` IDs owned by a given account on Testnet: ```cadence /// Script to get NFT IDs in an account's collection @@ -176,32 +178,32 @@ access(all) fun main(address: Address, collectionPublicPath: PublicPath): [UInt6 Check out [Transactions] and [Scripts] to learn more about the concepts. You can also read the Cadence language reference on [Transactions] to dive deeper. -## Flow Nodes +## Flow nodes Developers need a blockchain node to send transactions and fetch state. Flow is based on a multi-node architecture that separates tasks like consensus and computation into separate nodes. You can learn more about the Flow architecture in the [Flow Primer]. Access Nodes are the node type that are most useful for developers, as they provide access to the Flow network [via an API]. -## SDKs and Tools +## SDKs and tools If you're already familiar with blockchain development, here's a comparison between popular software packages and Flow's tooling: -- [Hardhat](https://hardhat.org/) / [Truffle](https://trufflesuite.com/) / [Foundry](https://getfoundry.sh/) - - [Flow CLI](https://github.com/onflow/flow-cli/) provides local development tools and the [Flow Emulator](https://github.com/onflow/flow-emulator) -- [OpenZeppelin](https://www.openzeppelin.com/) - - [Emerald OZ](https://oz.ecdao.org/overview) -- [go-ethereum](https://geth.ethereum.org/) - - [Flow Go SDK](https://github.com/onflow/flow-go-sdk/) - - [FCL](https://github.com/onflow/fcl-js/) also provides Backend API for Flow in JS -- [web3.js](https://github.com/web3/web3.js) - - [FCL](https://github.com/onflow/fcl-js/) - - [flow-cadut](https://github.com/onflow/flow-cadut) provides more utilities for using Flow on Web -- [Remix](https://remix.ethereum.org/) - - [Flow Playground](https://play.flow.com/) provides basic experimentation on the web - - [Cadence VSCode Extension](https://marketplace.visualstudio.com/items?itemName=onflow.cadence) is strongly suggested to install for local development -- [Testing Smart Contracts](https://ethereum.org/en/developers/docs/smart-contracts/testing/) - - [Cadence testing framework](https://cadence-lang.org/docs/testing-framework) enables native tests in Cadence. - - [overflow](https://github.com/bjartek/overflow) for testing in Go. +- [Hardhat] / [Truffle] / [Foundry] + - [Flow CLI] provides local development tools and the [Flow Emulator]. +- [OpenZeppelin] + - [Emerald OZ] +- [go-ethereum] + - [Flow Go SDK] + - [FCL] also provides Backend API for Flow in JS. +- [web3.js] + - [FCL] + - [flow-cadut] provides more utilities to use Flow on Web. +- [Remix] + - [Flow Playground] provides basic experimentation on the web + - [Cadence VSCode Extension] is strongly suggested to install for local development. +- [Testing Smart Contracts] + - [Cadence testing framework] allows native tests in Cadence. + - [overflow] for testing in Go. @@ -226,3 +228,27 @@ If you're already familiar with blockchain development, here's a comparison betw [Transactions]: https://cadence-lang.org/docs/language/transactions [Flow Primer]: https://flow.com/primer#primer-how-flow-works [via an API]: ../../../protocol/flow-networks/index.md +[Flow FT Repository]: https://github.com/onflow/flow-ft +[FT Tutorial]: https://cadence-lang.org/docs/tutorial/fungible-tokens +[Flow NFT Repository]: https://github.com/onflow/flow-nft +[NFT Tutorial]: https://cadence-lang.org/docs/tutorial/non-fungible-tokens-1 +[Marketplace Setup Tutorial]: https://cadence-lang.org/docs/tutorial/marketplace-setup +[NFT Storefront]: https://github.com/onflow/nft-storefront/ +[Hardhat]: https://hardhat.org/) +[Truffle]: https://trufflesuite.com/) +[Foundry]: https://getfoundry.sh/) +[Flow CLI]: https://github.com/onflow/flow-cli/) +[Flow Emulator]: https://github.com/onflow/flow-emulator) +[OpenZeppelin]: https://www.openzeppelin.com/) +[Emerald OZ]: https://oz.ecdao.org/overview) +[go-ethereum]: https://geth.ethereum.org/) +[Flow Go SDK]: https://github.com/onflow/flow-go-sdk/) +[FCL]: https://github.com/onflow/fcl-js/) +[web3.js]: https://github.com/web3/web3.js) +[flow-cadut]: https://github.com/onflow/flow-cadut) +[Remix]: https://remix.ethereum.org/) +[Flow Playground]: https://play.flow.com/) +[Cadence VSCode Extension]: https://marketplace.visualstudio.com/items?itemName=onflow.cadence) +[Testing Smart Contracts]: https://ethereum.org/en/developers/docs/smart-contracts/testing/) +[Cadence testing framework]: https://cadence-lang.org/docs/testing-framework) +[overflow]: https://github.com/bjartek/overflow) \ No newline at end of file