8. Marketplace
In this tutorial, we're going to create a marketplace that uses both the fungible and non-fungible token (NFTs) contracts that we have learned about in previous tutorials. This is only for educational purposes and is not meant to be used in production See a production-ready marketplace in the NFT storefront repo. This contract is already deployed to testnet and mainnet and can be used by anyone for any generic NFT sale!
Open the starter code for this tutorial in the Flow Playground:
https://play.onflow.org/49ec2856-1258-4675-bac3-850b4bae1929
The tutorial will be asking you to take various actions to interact with this code. The marketplace setup guide shows you how to get the playground set up to do this tutorial.
The code in this tutorial and in the playground uses Cadence 0.42. The link will still work with the current version of the playground, but when the playground is updated to Cadence 1.0, the link will be replaced with a 1.0-compatible version. It is recommended that since Flow is so close to upgrading to Cadence 1.0, that you learn Cadence 1.0 features and syntax.
Instructions that require you to take action are always included in a callout box like this one. These highlighted actions are all that you need to do to get your code running, but reading the rest is necessary to understand the language's design.
Marketplaces are a popular application of blockchain technology and smart contracts. When there are NFTs in existence, users usually want to be able to buy and sell them with their fungible tokens.
Now that there is an example for both fungible and non-fungible tokens, we can build a marketplace that uses both. This is referred to as composability: the ability for developers to leverage shared resources, such as code or userbases, and use them as building blocks for new applications.
Flow is designed to enable composability because of the way that interfaces, resources and capabilities are designed.
- Interfaces allow projects to support any generic type as long as it supports a standard set of functionality specified by an interface.
- Resources can be passed around and owned by accounts, contracts or even other resources, unlocking different use cases depending on where the resource is stored.
- Capabilities allow exposing user-defined sets of functionality through special objects that enforce strict security with Cadence's type system.
The combination of these allows developers to do more with less, re-using known safe code and design patterns to create new, powerful, and unique interactions!
At some point before or after this tutorial, you should definitely check out the formal documentation linked above about interfaces, resources, and capabilities. It will help complete your understanding of these complex, but powerful features.
To create a marketplace, we need to integrate the functionality of both fungible and non-fungible tokens into a single contract that gives users control over their money and assets. To accomplish this, we're going to take you through these steps to create a composable smart contract and get comfortable with the marketplace:
- Ensure that your fungible token and non-fungible token contracts are deployed and set up correctly.
- Deploy the marketplace type declarations to account
0x03. - Create a marketplace object and store it in your account storage, putting an NFT up for sale and publishing a public capability for your sale.
- Use a different account to purchase the NFT from the sale.
- Run a script to verify that the NFT was purchased.
Before proceeding with this tutorial, you need to complete the Fungible Tokens and Non-Fungible Token tutorials to understand the building blocks of this smart contract.
Marketplace Design
One way to implement a marketplace is to have a central smart contract that users deposit their NFTs and their price into, and have anyone come by and be able to buy the token for that price. This approach is reasonable, but it centralizes the process and takes away options from the owners. We want users to be able to maintain ownership of the NFTs that they are trying to sell while they are trying to sell them.
Instead of taking this centralized approach, each user can list a sale from within their own account.
Then, users could either provide a link to their sale to an application that can list it centrally on a website, or to a central sale aggregator smart contract if they want the entire transaction to stay on-chain. This way, the owner of the token keeps custody of their token while it is on sale.
Before we start, we need to confirm the state of your accounts.
If you haven't already, please perform the steps in the marketplace setup guide
to ensure that the Fungible Token and Non-Fungible Token contracts are deployed to account 1 and 2 and own some tokens.
Your accounts should look like this:
You can run the 1. CheckSetupScript.cdc script to ensure that your accounts are correctly set up:
You should see something similar to this output if your accounts are set up correctly. They are in the same state that they would have been in if you followed the Fungible Tokens and Non-Fungible Tokens tutorials in succession:
_10"Account 1 Balance"_1040.00000000_10"Account 2 Balance"_1020.00000000_10"Account 1 NFTs"_10[1]_10"Account 2 NFTs"_10[]
Now that your accounts are in the correct state, we can build a marketplace that enables the sale of NFT's between accounts.
Setting up an NFT Marketplace
Every user who wants to sell an NFT will store an instance of a SaleCollection resource in their account storage.
Time to deploy the marketplace contract:
- Switch to the ExampleMarketplace contract (Contract 3).
- With
ExampleMarketplace.cdcopen, select account0x03from the deployment modal in the bottom right and deploy.
ExampleMarketplace.cdc should contain the following contract definition:
This marketplace contract has resources that function similarly to the NFT Collection
that was explained in Non-Fungible Tokens, with a few differences and additions:
- This marketplace contract has methods to add and remove NFTs, but instead of storing the NFT resource object in the sale collection,
the user provides a capability to their main collection that allows the listed NFT to be withdrawn and transferred when it is purchased.
When a user wants to put their NFT up for sale, they do so by providing the ID and the price to the
listForSalefunction. Then, another user can call thepurchasemethod, sending theirExampleToken.Vaultthat contains the currency they are using to make the purchase. The buyer also includes a capability to their NFTExampleNFT.Collectionso that the purchased token can be immediately deposited into their collection when the purchase is made. - This marketplace contract stores a capability:
access(all) let ownerVault: Capability<&AnyResource{FungibleToken.Receiver}>. The owner of the sale saves a capability to their Fungible TokenReceiverwithin the sale. This allows the sale resource to be able to immediately deposit the currency that was used to buy the NFT into the ownersVaultwhen a purchase is made. - This marketplace contract includes events. Cadence supports defining events within contracts that can be emitted when important actions happen. External apps can monitor these events to know the state of the smart contract.
_15 // Event that is emitted when a new NFT is put up for sale_15 access(all)_15 event ForSale(id: UInt64, price: UFix64, owner: Address?)_15_15 // Event that is emitted when the price of an NFT changes_15 access(all)_15 event PriceChanged(id: UInt64, newPrice: UFix64, owner: Address?)_15_15 // Event that is emitted when a token is purchased_15 access(all)_15 event TokenPurchased(id: UInt64, price: UFix64, seller: Address?, buyer: Address?)_15_15 // Event that is emitted when a seller withdraws their NFT from the sale_15 access(all)_15 event SaleCanceled(id: UInt64, seller: Address?)
This contract has a few new features and concepts that are important to cover:
Events
Events are special values that can be emitted during the execution of a program. They usually contain information to indicate that some important action has happened in a smart contract, such as an NFT transfer, a permission change, or many other different things. Off-chain applications can monitor events using a Flow SDK to know what is happening on-chain without having to query a smart contract directly.
Many applications want to maintain an off-chain record of what is happening on-chain so they can have faster performance when getting information about their users' accounts or generating analytics.
Events are declared by indicating the access level, event,
and the name and parameters of the event, like a function declaration:
_10access(all)_10event ForSale(id: UInt64, price: UFix64, owner: Address?)
Events cannot modify state at all; they indicate when important actions happen in the smart contract.
Events are emitted with the emit keyword followed by the invocation of the event as if it were a function call.
_10emit ForSale(id: tokenID, price: price, owner: self.owner?.address)
External applications can monitor the blockchain to take action when certain events are emitted.
Resource-Owned Capabilities
We have covered capabilities in previous tutorials, but only the basics. Capabilities can be used for so much more!
As you hopefully understand, capabilites are links to private objects in account storage that specify and expose a subset in the public or private namespace of public or private paths where the Capability is linked.
To create a capability, a user typically uses the AuthAccount.link
method to create a link to a resource in their private storage, specifying a type to link the capability as:
_10// Create a public Receiver + Balance capability to the Vault_10// acct is an `AuthAccount`_10// The object being linked to has to be an `ExampleToken.Vault`,_10// and the link only exposes the fields in the `ExampleToken.Receiver` and `ExampleToken.Balance` interfaces._10acct.link<&ExampleToken.Vault{ExampleToken.Receiver, ExampleToken.Balance}>_10 (/public/CadenceFungibleTokenTutorialReceiver, target: /storage/CadenceFungibleTokenTutorialVault)
Then, users can get that capability if it was created in a public path, borrow it, and access the functionality that the owner specified.
_14// Get account 0x01's PublicAccount object_14let publicAccount = getAccount(0x01)_14_14// Retrieve a Vault Receiver Capability from the account's public storage_14let acct1Capability = acct.getCapability<&AnyResource{ExampleToken.Receiver}>(_14 /public/CadenceFungibleTokenTutorialReceiver_14 )_14_14// Borrow a reference_14let acct1ReceiverRef = acct1Capability.borrow()_14 ?? panic("Could not borrow a receiver reference to the vault")_14_14// Deposit tokens_14acct1ReceiverRef.deposit(from: <-tokens)
With the marketplace contract, we are utilizing a new feature of capabilities. Capabilities can be stored anywhere! Lots of functionality is contained within resources, and developers will sometimes want to be able to access some of the functionality of resources from within different resources or contracts.
We store two different capabilities in the marketplace sale collection:
_10/// A capability for the owner's collection_10access(self)_10var ownerCollection: Capability<&ExampleNFT.Collection>_10_10// The fungible token vault of the owner of this sale._10// When someone buys a token, this resource can deposit_10// tokens into their account._10access(account)_10let ownerVault: Capability<&AnyResource{ExampleToken.Receiver}>
If an object like a contract or resource owns a capability, they can borrow a reference to that capability at any time to access that functionality without having to get it from the owner's account every time.
This is especially important if the owner wants to expose some functionality that is only intended for one person,
meaning that the link for the capability is not stored in a public path.
We do that in this example, because the sale collection stores a capability that can access all of the functionality
of the ExampleNFT.Collection. It needs this because it withdraws the specified NFT in the purchase() method to send to the buyer.
It is important to remember that control of a capability does not equal ownership of the underlying resource.
You can use the capability to access that resource's functionality, but you can't use it to fake ownership.
You need the actual resource (identified by the prefixed @ symbol) to prove ownership.
Additionally, these capabilities can be stored anywhere, but if a user decides that they no longer want the capability
to be used, they can revoke it with the AuthAccount.unlink() method so any capabilities that use that link are rendered invalid.
One last piece to consider about capabilities is the decision about when to use them instead of storing the resource directly.
This tutorial used to have the SaleCollection directly store the NFTs that were for sale, like so:
_10access(all)_10resource SaleCollection: SalePublic {_10_10 /// Dictionary of NFT objects for sale_10 /// Maps ID to NFT resource object_10 /// Not recommended_10 access(self)_10 var forSale: @{UInt64: ExampleNFT.NFT}_10}
This is a logical way to do it, and illustrates another important concept in Cadence, that resources can own other resources! Check out the Kitty Hats tutorial for a little more exploration of this concept.
In this case however, nesting resources doesn't make sense. If a user decides to store their for-sale NFTs in a separate place from their main collection, then those NFTs are not available to be shown to any app or smart contract that queries the main collection, so it is as if the owner doesn't actually own the NFT!
In cases like this, we usually recommend using a capability to the main collection so that the main collection can remain unchanged and fully usable by other smart contracts and apps. This also means that if a for-sale NFT gets transferred by some means other than a purchase, then you need a way to get rid of the stale listing. That is out of the scope of this tutorial though.
Enough explaining! Lets execute some code!
Using the Marketplace
At this point, we should have an ExampleToken.Vault and an Example.NFT.Collection in both accounts' storage.
Account 0x01 should have an NFT in their collection and the ExampleMarketplace contract should be deployed to 0x03.
You can create a SaleCollection and list account 0x01's token for sale by following these steps:
- Open Transaction 4,
CreateSale.cdc - Select account
0x01as the only signer and click theSendbutton to submit the transaction.
This transaction:
- Gets a
Receivercapability on the ownersVault. - Gets a private
ExampleNFT.CollectionCapability from the owner. - Creates the
SaleCollection, which stores theirVaultandExampleNFT.Collectioncapabilities. - Lists the token with
ID = 1for sale and sets its price as 10.0. - Stores the
SaleCollectionin their account storage and links a public capability that allows others to purchase any NFTs for sale.
Let's run a script to ensure that the sale was created correctly.
- Open Script 2:
GetSaleIDs.cdc - Click the
Executebutton to print the ID and price of the NFT that account0x01has for sale.
This script should complete and print something like this:
_10"Account 1 NFTs for sale"_10[1]_10"Price"_1010
Purchasing an NFT
The buyer can now purchase the seller's NFT by using the transaction in Transaction2.cdc:
- Open Transaction 5:
PurchaseSale.cdcfile - Select account
0x02as the only signer and click theSendbutton
This transaction:
- Gets the capability to the buyer's NFT receiver
- Get a reference to their token vault and withdraws the sale purchase amount
- Gets the public account object for account
0x01 - Gets the reference to the seller's public sale
- Calls the
purchasefunction, passing in the tokens and theCollectionreference. Thenpurchasedeposits the bought NFT directly into the buyer's collection.
Verifying the NFT Was Purchased Correctly
You can run now run a script to verify that the NFT was purchased correctly because:
- account
0x01has 50 tokens and does not have any NFTs for sale or in their collection and account - account
0x02has 10 tokens and an NFT with id=1
To run a script that verifies the NFT was purchased correctly, follow these steps:
- Open Script 3:
VerifyAfterPurchase.cdc - Click the
Executebutton
VerifyAfterPurchase.cdc should contain the following code:
If you did everything correctly, the transaction should succeed and it should print something similar to this:
_10"Account 1 Vault Balance"_1050_10"Account 2 Vault Balance"_1010_10"Account 1 NFTs"_10[]_10"Account 2 NFTs"_10[1]_10"Account 1 NFTs for Sale"_10[]
Congratulations, you have successfully implemented a simple marketplace in Cadence and used it to allow one account to buy an NFT from another!
Scaling the Marketplace
A user can hold a sale in their account with these resources and transactions. Support for a central marketplace where users can discover sales is relatively easy to implement and can build on what we already have. If we wanted to build a central marketplace on-chain, we could use a contract that looks something like this:
This contract isn't meant to be a working or production-ready contract, but it could be extended to make a complete central marketplace by having:
- Sellers list a capability to their
SaleCollectionin this contract - Other functions that buyers could call to get info about all the different sales and to make purchases.
A central marketplace in an off-chain application is easier to implement because:
- The app could host the marketplace and a user would simply log in to the app and give the app its account address.
- The app could read the user's public storage and find their sale reference.
- With the sale reference, the app could get all the information they need about how to display the sales on their website.
- Any buyer could discover the sale in the app and login with their account, which gives the app access to their public references.
- When the buyer wants to buy a specific NFT, the app would automatically generate the proper transaction to purchase the NFT from the seller.
Creating a Marketplace for Any Generic NFT
The previous examples show how a simple marketplace could be created for a specific class of NFTs. However, users will want to have a marketplace where they can buy and sell any NFT they want, regardless of its type. There are a few good examples of generic marketplaces on Flow right now.
- The Flow team has created a completely decentralized example of a generic marketplace in the NFT storefront repo. This contract is already deployed to testnet and mainnet and can be used by anyone for any generic NFT sale!
- VIV3 is a company that has a generic NFT marketplace.
Composable Resources on Flow
Now that you have an understanding of how composable smart contracts and the marketplace work on Flow, you're ready to play with composable resources! Check out the Kitty Hats tutorial!