|
| 1 | +# Self-Governed NFTs Protocol Notes |
| 2 | + |
| 3 | +This document is my notes on the paper "Self-Governed NFTs on Cardano: Meta-Standard for Standards with Vertical and Horizontal Version Travel for a Decentralized Future" by Maksymilian Brodowicz, which describes the protocol used by the Seabug NFT marketplace. I wrote this because I found the paper hard to understand; this document is meant to be referenced alongside the paper to aid understanding. Also see the code [here](https://github.com/mlabs-haskell/plutus-use-cases/tree/main/mlabs/src/Mlabs/EfficientNFT) for a reference implementation of the protocol. |
| 4 | + |
| 5 | +- Protocol involves two separate NFTs: |
| 6 | + - "Collection NFT" aka "underlying NFT": this is created as an nft of the image to be sold |
| 7 | + - CNFT stands for collection nft |
| 8 | + - There could be multiple images in the same collection, i.e. multiple tokens under the same currency symbol |
| 9 | + - Note that there can also be different nfts for the same image |
| 10 | + - "Self-governing NFT": this is minted by "the minting policy" (section 2.1 in the paper) parameterized by the collection nft's currency symbol (as well as some other things) |
| 11 | + - sgNFT stands for self-governing nft |
| 12 | + - The sgNft's token name is a hash of the current price, owner, and the CNFT's token name |
| 13 | + - For each image nft in a collection, there can be only one sgNft corresponding to it (assuming the image token is actually an nft, i.e. it wasn't minted with multiple values and can't be minted again) |
| 14 | +- Collection nft gets sent to the "locking script" aka "locking policy" |
| 15 | +- Self-governing nft can be sent anywhere |
| 16 | + - It will most likely be sent to a validator of the nft marketplace; when it is locked by such a validator, the nft is "on the marketplace", so to speak |
| 17 | + - The sgNft can also be locked at the owner's address, which will then require their signature for any actions |
| 18 | +- The minting policy (aka "the CurrencyScript") is used not only to mint/burn the sgNft but also to change ownership and price |
| 19 | + - Ownership and price are changed by burning the current sgNft and minting a new one with an updated token name |
| 20 | + - The minting policy must account for the possibility that the sgNft is not locked at the owner's address: |
| 21 | + - In the case of an nft marketplace, the nft will likely be locked at the marketplace script address |
| 22 | + - Burning and changing price must explicitly require the owner's signature, so that people can't change the price of or destroy the owner's property while it is on the marketplace |
| 23 | + - Changing ownership (a purchase) does not require the owner's signature because it is assumed that the owner already gave permission for the nft to be sold when they put it on the marketplace |
| 24 | +- The locking script (section 2.2) looks complicated at first but it just has some extra cases to handle due to the lockup and lockupEnd1 complication |
| 25 | + - Note: CO stands for continuing output, i.e. a utxo at this script's address |
| 26 | + - This script on its own doesn't do much, it essentially just tracks whether its corresponding sgNft is currently staked or not, and allows it to be staked/unstaked |
| 27 | + - The purpose of this script is to allow nft owners to "stake" their nfts for some externally decided rewards program, and also to allow changing protocol versions for the nft |
| 28 | + - Nfts are staked for a given "lockup" period, during which they cannot be unstaked or restaked |
| 29 | + - The lockup period is determined in two ways |
| 30 | + - If the last time the nft was staked ("entered") is before lockupEnd1, the lockup period lasts until lockupEnd1 |
| 31 | + - Otherwise, the lockup period lasts until "lockup" slots after the last time the nft was staked |
| 32 | + - Restaking doesn't do anything except update the "entered" field of the datum |
| 33 | + - Unstaking deletes the NFT (sgNft and cnft) |
| 34 | +- Transaction metadata is used to store various information required for recreating things like the sgNft token name and currency symbol |
| 35 | + - This helps with decentralization, as users of the protocol do not need to rely on a third-party's database to hold the information needed to interact with their nfts |
| 36 | + - The `mintPolicy` field contains the version name for the minting policy used for the transaction |
| 37 | + - The version name is an arbitrarily decided string marking the script version, for example `"myscriptv1"` |
| 38 | + - This field is used to sync the scripts used, before applying parameters |
| 39 | + - This field can be used to lookup the relevant script, apply the parameters specified by the rest of the metadata fields, and verify that the metadata is correct |
| 40 | + - The `<policy_id>` is the currency symbol of the underlying nft |
| 41 | + - This same currency symbol is also included in the `collectionNftCS` field |
| 42 | + - `marketplaceScript/Share` corresponds to the `daoScript/Share` parameters used for the minting policy |
0 commit comments