🟩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.

Sigil - Traditional Meaning

A sigil is a symbol used in magic and ritual practices, often created to represent a specific intention or desire. The term originates from the Latin word "sigillum," meaning "seal." Historically, sigils have been used as pictorial signatures of deities, spirits, or magical entities, believed to hold supernatural power. In modern usage, especially within chaos magic, a sigil is a symbolic representation of the practitioner's desired outcome, charged with personal energy and intention to manifest changes in reality. Sigils are considered powerful conduits for channeling and amplifying one's intent, making them essential tools in various metaphysical and spiritual practices.

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.

Recursive Inscriptions

In some cases, art inscriptions may use recursion which pulls in data from other inscriptions. This is done for both functional and artistic reasons, depending on the type of art and media format. These external inscriptions that are called in and referenced, such as javascript libraries, css, html, audio or image layers, are scattered onchain and not necessarily a part of an organized collection. These dependencies do not need to be within a Sigil collection tree. The Ordinal Public Goods Github repo is a quality resource of commonly used libraries that have been inscribed on Bitcoin since Ordinals was launched.

https://github.com/jokie88/ordinalpublicgoods

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)

• Non-Fungible Runes (NFR)

• Hash-First Release (HFR)

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:

1. 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>:PAUSE

     • SIGIL:RTC:<RUNE_NAME>:<ITEM_NUMBER>

     • SIGIL:RTC:<RUNE_NAME>:CLOSE

2. 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.

RTC Collection Model

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)

{
  "protocol": "SIGIL",
  "rune_name": "XXXXXXXXXXXXX", // Collection name and default Rune
  "rune_id": "842069:420",
  "min_rune_amt": 1, // Quantity required to make claims for the default Rune
  "mints_only": true, // Tokens that were minted, not from secondary market
  "rune_action": "hold|burn|spend", // Action required for Rune tokens
  "claim_mode": "multi", // single-use or multi-use claims per address per item
  "block_range": { // Optional block range for wrapping reinscriptions
    "start_block": 840000,
    "end_block": 850000
  },
  "extra_runes": [ // Require additional rune tokens to claim collection items
    {
      "rune_name": "ARTISTHETICKER",
      "rune_id": "840697:454",
      "amount": 1000
    },
    {
      "rune_name": "UNCOMMONGOODS",
      "rune_id": "840000:0",
      "amount": 21
    }
  ],
  "collection_info": { // any metadata that the collection owner wants to add
    "rune_short_ticker": "$XXXX", // A shorter secondary ticker, uniqueness not enforced
    "artist_name": "...",
    "description": "A collection of 21 unique digital art pieces...",
    "total_items": 21,
    "website": "https://example.com",
    "etc": "etc etc"
  }
}

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).

{
  "protocol": "SIGIL",
  "allowlist": { // Granular level of control for who can claim a particular item
    "address": "bc1..."
  },
  "extra_runes": [ // Require additional rune tokens to claim specific collection items
    {
      "rune_name": "ARTISTHETICKER",
      "rune_id": "840697:454",
      "amount": 5000
    }
  ],
  "rune_chargers": [ // Require specific rune tokens to trigger code used in specific collection items
    {
      "rune_name": "SIGILCHARGERONE",
      "rune_id": "850420:111",
      "amount": 1,
      "label": "BACKGROUND-1"
    },
    {
      "rune_name": "SIGILCHARGERTWO",
      "rune_id": "850420:112",
      "amount": 1,
      "label": "SUNGLASSES"
    }
  ],
  "item_info": { // any extra metadata the collection owner wants to include
    "artist_name": "...",
    "title": "Title of art piece",
    "description": "...",
    "number_of": "8 of 21", //optional number of piece in collection
    "website": "https://example.com"
  }
}

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.

Other Collection Models

Curation

Sigil will be expanded to encompass curatorial transactions soon.