# Other Collection Models

## Other Sigil Collection Models

### <mark style="color:green;">**Non-Fungible Runes (NFR)**</mark>

The NFR model has been used out in the wild and Sigil formally supports this. Essentially, Runes are used for 1 of 1 art pieces by etching a Rune with a supply of only 1 token and a Runescription attached for the art content. The single token is usually premined with no mintable tokens but this is not a requirement and the creator could choose to let the first to mint the token successfully be the owner.

The NFR model has been used to create large collections and etching a unique Rune for each unique piece in the collection. This is not the most efficient method but Sigil does support this as a wrapper protocol in order to take advantage of other features and benefits that creators may want to leverage.

NFR items can be supported within the Sigil Protocol by adding the following **metaprotocol** field value:

<mark style="color:green;">**`SIGIL:NFR:<RUNE_NAME>`**</mark>

A benefit of using Sigil for NFRs is mainly for indexing and tooling purposes since the metaprotocol field acts as a filter against the many thousands of other Runes that are etched. The NFR model can also be expanded upon further and add requirements in the same way as the RTC model, such as requiring additional Runes to be able to purchase the NFR.&#x20;

#### NFR Rune Names

The naming convention for NFR Rune Names is up to the creator and not dictated by the Sigil Protocol. There are various reasons for choosing a pattern to use which are unknown on the protocol level. it is common for all NFRs to begin with the same text string and have a unique suffix that denotes the uniqueness of the item. This suffix is usually just a number spelled out (actual numeric characters are disallowed in Rune Names). &#x20;

#### Semi-fungible Runes (SFR)

If the creator wants to stretch the notion of non-fungibility (semi-fungibility/hybrid) and use a supply of more than 1, they are free to do so. This is a way to essentially provide multiple prints or editions of the art and effectively fractionalize "NFTs".&#x20;

This is a known model on other blockchains such as Ethereum with the ERC-404 token standard proposal. In that implementation using smart contracts, the original "NFT" is burned and minted based on the fractionalized state. In other words, to own the whole NFT you must own all the fractional tokens. It is either in a whole state (minted) or a fractionalized state (burned).&#x20;

There is no obvious way to do this on Bitcoin without adding such definitions, rules and logic to a metaprotocol. It is unclear if this would have the same effect as an Ethereum SFT that is enforced by onchain smart contracts. Perhaps with covenants on Bitcoin in the future there could be an elegant way to do onchain enforcement.

&#x20;For the time being, NFR/SFR within Sigil will just rely on the decicions of the artist/creator to either release a piece as a 1 of 1 non-fungible or a fractionalized semi-fungible with or without the original asset being burned.

### <mark style="color:green;">**Hash-First Release (HFR)**</mark>

The HFR model offloads the cost of inscriptions to the buyer while the artist only inscribes the collection item as a checksum file hash (SHA-256) while holding back the actual art file (a watermarked and/or lower quality (small file size) preview can be published anywhere such as social media or official artist website or even inscribed onchain in a "preview collection").&#x20;

The artist sets a price in btc/satoshis and/or Rune tokens and the artist and buyer directly transact in a preferred way. Once payment is received, the actual art file matching the inscribed public file hash is sent to the buyer over a secure channel.&#x20;

**Note:** There could be new infrastructure that makes this process seamless and utilize things like PSBTs for p2p transactions.

At this point, **ONLY** the artist and buyer should possess the authentic file. The buyer can then choose when to inscribe it themselves (based on fee rates) and once the transaction is confirmed into a block, and assuming this is the first and only hash matching file inscribed, the asset is validated and correlated with the artist's file hash inscription.&#x20;

Effectively, the unique file hash now only exists onchain as the artist's inscription (specified in the metaprotocol field) and the actual inscribed file (buyer txn). This is enough to prove that the artist and buyer settled their deal and the two inscriptions have a clear association with each other, ultimately providing the necessary provenance. It is trivial for marketplaces, explorers, wallets etc to validate and display the authentic art inscription with provenance to the artist or artist's specific collection.&#x20;

The required Sigil transaction **metaprotocol** configuration for these inscriptions must include the following:

* Artist's file hash inscription metaprotocol field
  * <mark style="color:green;">**`SIGIL:HFR:<SHA256_FILE_HASH>`**</mark>
* Buyer's file inscription metaprotocol field
  * <mark style="color:green;">**`SIGIL:HFR:<PURCHASED_INSCRIPTION_ID>`**</mark>

The Sigil transaction **metadata** configuration for these inscriptions could also include the following:

* Artist's file hash inscription metadata field (optional)
  * <mark style="color:green;">**`{ "protocol": "SIGIL", "hash": "<SHA256_FILE_HASH>", "preview_url": "https://artists.website", "price": { "sats:<amount_in_sats>", "runes:<rune_id>:<amount_in_runes>" }}`**</mark>
  * Other Sigil metadata as appropriate. See [metadata](#sigil-metadata) section.
* Buyer's file inscription metadata field (optional)
  * <mark style="color:green;">**`{ "protocol": "SIGIL", "receipt": "<payment_txid>" }`**</mark>

Using HFR allows for artists to not take on the burden of covering upfront inscription costs and instead *test the market* to see if there is even interest in any specific piece of art. Collectors can view offchain previews of the art and in interested, contact the artist to begin a purchase or negotiation process. The buyer is not required to inscribe the file but they may prefer to especially if the purchase price was reasonable (assume inscription cost estimate was removed from price).&#x20;

There is a perception and narrative that onchain art is worth more than art hosted elsewhere such as typical NFTs which point to URLs (websites, IPFS, Arweave etc). These decisions are left to the artists and collectors. The Sigil Protocol only provides optional models to allow for proper and adequate provenance.&#x20;

An alternative HFR settlement approach is for the artist to inscribe the file after payment which would cover the costs to inscribe. This is akin to how some centralized inscription services that offer collection launchpads work as they act as middleware on behalf of the artist/seller and collector/buyer. Instead of trusting the convenient services, the artist and collector are trusting each other.
