🟩Introduction
The Grimoire of sigils, rune etchings and inscriptions for art collections on Bitcoin
SIGIL IS NOT LIVE UNTIL AN ACTIVATION BLOCK IS RELEASED
Sigil - Runescription Enchantments
Sigil leverages the Ordinals and Runes Protocols to form a standard framework and sub-protocol/meta-protocol allowing artists to have direct management and control of their art collections by defining how collectors can participate in attaining and claiming art pieces in these collections.
Sigil works as an overlay logic standard and an extension to the inherent capabilities of Ordinals and Runes that the ecosystem of wallets, explorers and marketplaces can opt-in to support. Runes can have incantations via their Runescriptions by way of standardized instructions, conditions and rules for art project collections in addition to extra custom and standard descriptive metadata.
HyperSigils are additional experimental extensions to the Sigil Protocol that can introduce more broad powerful features that go beyond purposeful art collection models to explore the creative ideas of the community. Some initial areas of focus are Digital Matter Theory (DMT), Colored Coins, Cenotaph Runes use cases and Ordinal Theory applied to Rune Tokens.
The Sigil Rune is associated with the Sigil Protocol but is not required to use the protocol. However, collection creators can opt-in to using the $SIGIL Rune by requiring a certain balance amount in order to claim their art pieces (plus their own Rune and any other Rune). $SIGIL can be seen as a community currency that co-exists with the protocol but is not needed. This puts the onus on the community. More info on $SIGIL here.
Sigil collections can use one of many models. The main model referred to as Rune + Time Claim (RTC) is primarily based on Reinscriptions, which are multiple inscriptions on the same ordinal satoshi, and the notion of the Runescription, which is the inscription included in a Rune etch transaction.
The Ordinals Protocol provides a foundation for parent-child provenance/collections but does not offer opinionated standards for metadata or interplay dynamics across various features of Ordinals and Runes. This is why there exists a metaprotocol field together with a metadata field, which Sigil leverages, so that overlay models can be defined external to the core protocols and Ord reference code.
Technical Overview
This section of the technical documentation focuses on the Sigil Rune + Time Claim (RTC) model. The next section provides an overview of other proposed collection models.
Sigil RTC collections use reinscriptions as the primary organizing factor for items in collections and secondarily uses parent-child provenance to create a hierachical tree containing each of the individual collections. Sigil collections are like decks or packs as all art pieces are stacked onto a single satoshi. These parent decks can then have children decks as additional sub-collections.
Typically and thus far, art collections using the Ordinals Protocol do not make use of reinscriptions to represent each piece in the collection and instead each inscription is itself an individual child inscription under a parent inscription. As noted, Sigil uses both collection methods together by default but can support both separately as well.
In either case, some basic tooling and infrastructure is needed to track the Sigil Protocol activity onchain and provide an inscription tool with a "Sigil Mode" for a friendly UX for constructing Sigil transactions. Etching and inscribing with the necessary Sigil configuration or access to both metaprotocol and metadata fields is not something all Ordinals and Runes services provide at this time.
Original Art Asset - Ownership Retainment or Burn Asset
In certain Sigil models, the creator can retain the ownership of the original piece (the runescription on a satoshi) and make a copy or multiple copies represented as the rune supply or the sigil delegate claim inscriptions. Alternatively, the artist/creator can provably burn the runescription satoshi if preferred. This should be communicated to collectors as it may factor in to purchase decisions and market valuation. The choice to retain or burn the digital artifact asset goes beyond the scope of the Sigil Protocol.
Runescriptions - Collections as Rune Etchings + Rune Inscription
Runescriptions, as noted, are simply regular inscriptions that are included within the same transaction as an etched Rune. This is an onchain direct association between Runes and Ordinals inscriptions. In order to distinguish between inscriptions not anchored to a Rune and those that are, we use the term "Runescription".
Using the Sigil Protocol, an etched Rune represents either an art collection (RTC) or specific art piece (NFR). The Rune is etched with an attached Runescription (such as the art file) which contains metadata and the SIGIL metaprotocol identifier with parameters that are required by the Sigil Protocol.
The Rune token supply and other native Rune Protocol configurations is totally up to the collection owner. The Sigil Protocol extends this configuration with more contextual info and instructions via the runescription metadata field.
There are multiple art collection models that are proposed for Sigil to support. These are currently:
Rune + Time Claim (RTC)
Creating an RTC Collection
The RTC model is considered the primary way to launch a collection with Sigil whereas the other models are meant to encapsulate existing usage patterns (i.e. NFR) or alternative proposals that are seen as useful and beneficial (i.e. HFR).
RTC requires etching a Rune with a Runescription that adheres to the Sigil Protocol. This Runescription will then be reinscribed for each collection item release using whatever time span and intervals that the collection owner chooses. This can be explicitly defined or open-ended and requiring collectors to monitor the ordinal satoshi for activity (new runescription transactions) in the mempool and onchain.
The Runescription must first use the metaprotocol field and include SIGIL:RTC as the base field value which signals the type of inscription transaction this is to supporting tools and services that index and monitor Sigil related transactions. The collection name is inferred since the Rune is etched in same transaction but it should also be included in the metaprotocol field value as:
SIGIL:RTC:<RUNE_NAME>
Using the Rune ID as an alternative is also acceptable. Rune IDs are represented in text as BLOCK:TX. For example the Rune ID of DECENTRALIZED is 840000:2. So, this example would look like:
Using Rune Name
SIGIL:RTC:DECENTRALIZED
Using Rune ID
SIGIL:RTC:840000:2
The content payload of the first original Runescription (before reinscriptions) can be anything the collection owner wants. For example:
The first art piece in the collection.
A text notice about the forthcoming art collection that acts as a pending start status and can later be reinscribed for use as a pause state in between art reinscriptions.
A manifesto or artist's statement.
A delegate inscription of the artist's primary parent inscription that is used to contain the body of work beneath as children inscriptions.
Anything else...
Sigil Casting (Claims)
The Sigil RTC model introduces claim validation controls in the form of the time in between reinscriptions and owning the collection Rune tokens and/or other Runes. A claim for art is known as sigil casting and is actually a delegate inscription transaction referencing the art collection item's runescription ID. This transaction also requires that the metaprotocol field contains:
SIGIL:RTC:<RUNE_NAME>:CLAIM
Valid Sigils Claims
The two factors that determine whether or not a sigil cast is valid are:
A period of time in between reinscriptions is when a valid sigil can be casted for each specific collection piece (runescription ID).
The collection owner can choose to reinscribe a "pause" signal to end a valid casting phase without immediately proceeding to the next phase representing the next piece of art in the collection. This reinscription would typically be a delegate referencing the original collection runescription or any other designated inscription ID (it should be made clear that it represents a pause). A new inscription could also be used, such as a markdown text file that includes a message with an update to share with collectors/participants. Lastly, the collection can be explicitly closed, thus ending the claim period for the collection. Depending on the type of reinscription, the following metaprotocol field values would be used:
SIGIL:RTC:<RUNE_NAME>:PAUSESIGIL:RTC:<RUNE_NAME>:<ITEM_NUMBER>SIGIL:RTC:<RUNE_NAME>:CLOSE
Rune token(s) associated with the collection or artist that are present in the same wallet address used to cast a sigil.
Rune tokens are used to mimic off-chain allowlists (aka whitelisted addresses). The collection runes can be attained and used in ways that the collection creator prefers. They may choose to sell the tokens (like a presale), allow them to be minted or airdrop/send them based on other conditions.
Additional extra Runes can also be required to be present in the claimant's address such as the official $SIGIL Rune or literally any other Rune that exists.
The collection owner can also choose whether just holding these tokens meets the requirement or if the tokens need to be spent to the collection owner's address or provably burned.
Control, Competition and the Element of Surprise
The RTC model gives artists control over when and how their art is released and made attainable. It fosters interactivity and a level of involvement, attention and strategy from the collector base and artist. True fans, patrons and members of the artist's community have an advantage over broader market and can have a more intimate and direct experience.
The battle in the mempool also plays a factor, adding a layer of strategy and chance when new reinscriptions appear and collectors compete to get valid claims into a block before the next art piece or a pause transaction is confirmed, or the close of the collection. The collection creator can reinscribe with low or high fees thus effecting the length of time in the mempool. Likewise, collectors can set high miner fee rates and use RBF to increase their chances of claiming successfully. There is already a lot of attention on what is referred to as mempool sniping and new services and tools are available to broaden the access to this native bitcoin transaction market.
It is even possible to delay the reveal of art until claimed or until a special Rune token balance exists in the wallet some time in the future (i.e. an airdrop that triggers the reveal). While this is beyond the scope of the Sigil RTC model, it is a complimentary mechanism that can be explored using the Ordinals endpoints and recursion.
Sigil Metadata
The Sigil Protocol offers various configuration options for collection creators, which can be included in the original etched Rune inscription metadata field.
The metadata format is not yet finalized. Some more thought is needed to consider things like using multiple Rune tokens as requirement for claims and various other potentially useful settings. The examples are focused on the primary RTC model.
Example Sigil Collection Metadata (RTC model)
Individual Item Metadata (RTC model)
Each art piece in a collection can contain its own metadata as well. Beyond descriptive metadata, there can be additional rules applied to further control valid claims, such as specifying one or more addresses (a traditional allowlist).
The metaprotocol field would be set as:
SIGIL:RTC:<RUNE_NAME>:<ITEM_NUMBER>
Collaborative Collections
In the case of a multi-artist collaborative art collection, the satoshi can be sent to each contributing artist to do the reinscription transaction. Alternatively, artists can send their art piece plus cost to inscribe to the collection maintainer to do the reinscription.
Other collaborative models are being explored as well such as inviting participants with special Rune tokens and allowing for regular inscriptions on different satoshis to be used with a reference to the collection's Rune name or ID in the metaprotocol field using the ADD parameter.
SIGIL:RTC:<RUNE_NAME>:ADD
Alternatively, the original Runescription ID and/or satoshi serial number or satoshi name as an ID can be referenced.
Closing Collections
A collection can be provably closed by burning the satoshi. There can also be a defined end block in the collection metadata that signifies the end of the collection and is closed according to the Sigil metaprotocol. Lastly, a collection can be closed with a reinscription contaning the following value in the metaprotocol field:
SIGIL:RTC:<RUNE_NAME>:CLOSE
The metadata and content of this reinscription can either be for the final art piece or just a statement that the collection is officially closed.
Specification
The full spec (draft) in condensed form is published on a dedicated page linked below.
Other Sigil Collection Models
Non-Fungible Runes (NFR)
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:
SIGIL:NFR:<RUNE_NAME>
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.
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).
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".
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).
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.
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.
Hash-First Release (HFR)
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").
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.
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.
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.
The required Sigil transaction metaprotocol configuration for these inscriptions must include the following:
Artist's file hash inscription metaprotocol field
SIGIL:HFR:<SHA256_FILE_HASH>
Buyer's file inscription metaprotocol field
SIGIL:HFR:<PURCHASED_INSCRIPTION_ID>
The Sigil transaction metadata configuration for these inscriptions could also include the following:
Artist's file hash inscription metadata field (optional)
{ "protocol": "SIGIL", "hash": "<SHA256_FILE_HASH>", "preview_url": "https://artists.website", "price": { "sats:<amount_in_sats>", "runes:<rune_id>:<amount_in_runes>" }}Other Sigil metadata as appropriate. See metadata section.
Buyer's file inscription metadata field (optional)
{ "protocol": "SIGIL", "receipt": "<payment_txid>" }
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).
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.
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.
Curation
Sigil will be expanded to encompass curatorial transactions soon.
Review the condensed Sigil Protocol Spec.
Last updated
