-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
5837708
commit 43856a8
Showing
2 changed files
with
6 additions
and
22 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,13 +1,5 @@ | ||
When purchasing an NFT, all that is needed from the purchaser is their payment that comes in the form of their vault resource. | ||
When purchasing an NFT, the purchaser needs only to provide their payment in the form of a vault resource. The smart contract then verifies that the listing has not already been purchased, ensuring the fungible token provided matches the required type for the transaction and that the payment amount is correct. | ||
|
||
Once that happens, the smart contract checks to make sure the listing hasn't already been purchased, the fungible token is the right type for this transaction, and that the payment is the correct amount. | ||
If all these conditions are met, the purchase is approved, and the listing status is updated to reflect the purchase. The contract withdraws the NFT from the seller's account and verifies that it is the correct type and ID, ensuring the purchased NFT is the one intended. Once confirmed, the contract calculates the sales cuts and begins depositing the respective amounts into the vault receivers of the designated accounts using pre-established capabilities. Any remaining funds are transferred into a residual receiver, which acts as a container for the leftover payment vault, with its balance reduced to zero by this process. | ||
|
||
If this is the case then the purchase can be approved. We change the details of the listing to purchased. We will then withdraw the NFT from the account that listed it. | ||
|
||
We check to see if the NFT is of the right type and the right ID to make sure that the NFT being purchased is in fact the correct one. | ||
|
||
After that, we take all of the sales cuts and start depositing the amounts into the accounts vault receivers we have capabilities for. | ||
|
||
Then we move the remaining payment vault into the residual receiver local variable. The price of the remaining payment vault should be 0 so we are just moving our resource into there. | ||
|
||
Lastly we emit that the transaction has completed and we return the NFT which can then be deposited into the purchasers collection. | ||
Finally, the transaction is completed by emitting an event signaling its success, and the NFT is returned to the purchaser, allowing them to deposit it into their collection. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,13 +1,5 @@ | ||
Here we are defining initially the types that we are expected to return for each of the listed variables. | ||
This transaction begins by defining the expected types for the variables that will be returned during the process. The first step involves accessing the storefront associated with the account holding the desired listing. This storefront is publicly accessible via a linked capability, enabling others to interact with and purchase listings. | ||
|
||
First we need to get the storefront of the account that the listing is under. You will have linked a public capability to this store front so that others can access it and purchase your listing. | ||
Once the storefront is borrowed, the transaction retrieves the specific listing of interest and assigns it to the listing variable. The price of the listing is then fetched, which allows the purchaser to prepare the appropriate payment. Using the price, the purchaser withdraws the required tokens from their Vault resource, ensuring they have the correct amount for the transaction. Additionally, the purchaser retrieves their Receiver capability, which will be used later to deposit the purchased NFT into their collection. | ||
|
||
Once we borrow that storefront, we then want to borrow the listing that we are interested in buying. We assign that to the listing variable. | ||
|
||
We'll then fetch the price of that listing so that in the next step when we take our Vault resource and withdraw tokens from it, we pass in the price of the NFT because that is how much we would like to withdraw. | ||
|
||
We'll also get our Receiver capability so that we can deposit the NFT into our collection. | ||
|
||
When we're ready to execute, we call the purchase function on our listing and pass in the payment vault we'll be paying for this with. This will return and NFT resource for us that we temporarily store in our item variable. | ||
|
||
We'll then deposit that NFT into our collection, and then we'll cleanup the storefront by deleting our listing, and with that you have created a purchase on an NFT marketplace. | ||
With these preparations complete, the purchaser invokes the purchase function on the listing, passing in their payment vault as the payment method. This action returns the NFT resource, which is temporarily stored in the item variable. The transaction then deposits the NFT into the purchaser's collection using their Receiver capability. Finally, it cleans up the storefront by deleting the completed listing, marking the successful completion of the purchase on the NFT marketplace. |