OIP-02: Verifiable Ordinal Collection
Status: RFC (Request for Comment)
This is also commonly known as Verifiable Ordinals.
Overview
Non-fungible token (NFT), esp. on Ethereum, takes off massively not only due to the great artists' contribution ot the space, but largely also due to the following factors:
Low costs to NFT artists to get started in launching their collections and arts on Ethereum.
Buyer pays for gas (transaction fees) while allowing creators and artists to profit from it.
Parentage links, allowing NFTs to be traces to its parent smart contract, therefore knowing that its legitimacy as part of a collection.
It would be remarkable if the same can be achieved for Bitcoin-based ordinal, while staying true to the original intents and ethos of Ordinal Theory. This proposal intends to do that while not violating the guidelines & boundaries set out for Ordinal Theory Improvements.
Roles
The following roles are defined to align on the understanding:
Creator
Usually the artist.
Initiates collection of ordinal inscriptions.
Usually, intends to be paid, especially from the first sale of an ordinal in the said collection.
Publisher
Service, or website, that provides minting service of ordinals that belong to the said collection.
Usually also provides collection creation service to the Creator.
Purchaser
First-hand buyer, and therefore owner, of an ordinal from a collection.
Pays the purchase price, of which the bulk of it should go to the Creator.
Objectives
Provide a method where creator, especially artist, who intends to make their artwork available as ordinal inscriptions do not have to start with big capital outlay to cover the inscription costs.
Allows first-hand buyers to take ownership of inscribing, and therefore pay for inscription fee.
Allows ordinals to be independently verified, if they belong to a specific collection, or otherwise. Verification must be able to be carried out in a fully trustless manner, by anyone, including unrelated third-parties, and in an asynchronous way.
Inscriptions trading must be carried out on-chain, just like other ordinals. Off-chain trading of ordinals must not be possible.
Adheres to the ideals of ordinal inscriptions, specifically that inscriptions should be fully on-chain and ideally, maintain backward-compatibility to services that implement only the original Ordinal Theory without support of any further improvements.
Solution
The proposed solution covers the following arbitrary and hopefully general flow of creating, publishing, purchasing, and trading of an ordinal that belongs as part of a collection.
Flow
Creator initiates a collection, usually a series of ordinal inscriptions with a theme.
Creator defines and publishes the collection via the service of a Publisher.
Purchaser browses the collection, at this stage uninscribed, at Publisher's site, and decides to purchase a specific item from the collection.
Purchaser pays for the purchase via Publisher's site and receives the inscription's payload, e.g. an image, and its metadata, delivered in the form of an unsigned transaction.
Creator receives the bulk of the purchase fees.
Purchaser can choose for the right moment to inscribe based on factors such as Bitcoin network fees.
Purchaser, however, would not be able to trade/resell the purchased ordinal without first inscribing them as doing so would invalidate the verifiable ordinal.
Collection
Collection is to be inscribed as a text/plain
inscription with the following:
Notes:
p
andv
are required. They refer to protocol and version.ty
refers totype
. Onlycol
andinsc
are 2 valid values.col
is used here for collection.slug
is a suggestion and not a guarantee that the slug would be reserved for the specific collection. Even ifslug
has already taken by other collections before this one, this collection remains valid.publ
refers to an array of public Bitcoin addresses from publisher. This is intended to be used for verification of inscribed Ordinals.As Bitcoin Core does not support message signing with bech32 address, there are no known standard ways to sign messages with bech32 address today, it is recommended that publisher's address to be of the legacy type, usually starting with
1
.Alternatively, an array of Bitcoin public keys or a mix of addresses and public keys can also be used, which allows for a wider range of message signing and verification processes.
insc
refers to an array of inscription collections.iid
refers to inscription ID. It must be unique within a collection. Collision ofiid
invalidates the collection definition.lim
defines the maximum number of times that an inscription can be sold or inscribed. Further inscriptions beyondlim
count will be deemed invalid.sri
is an optional field and refers to subresource integrity. It adds resource integrity to inscriptions.SRI is defined in accordance to W3C's SRI specifications
If
sri
is present, validation must check for resource integrity. Otherwise, resource integrity check is not needed.
Post-inscription of the collection, take note of the genesis transaction ID, genesis ID (in
i0
format), or genesis outpoint (in:0
format). Either of these formats can be used for inscription verification, with all three collectively referred to asCOLLECTION_ID
throughout this OIP.
Verifiable Ordinal Inscription
Verifiable ordinal inscription is to be inscribed as a valid inscription with an attached metadata, following Inscription Metadata recommendations.
Metadata for inscription:
Notes:
p
andv
are required. They refer to protocol and version.ty
refers totype
. Onlycol
andinsc
are 2 valid values.insc
is used here for inscription.col
refers to either a genesis txid or current outpoint where the collection inscription can be located.If the collection inscription has been moved,
col
, referring to genesis txid and not current location of the collection means that it would remain unchanged.
col
andiid
as a tuple refers specifically to an inscription.There could be multiple of the same
col
andiid
up to thelim
that's defined at collection.Further inscriptions beyond
lim
must not validate.
publ
refers to either one of the publisher's Bitcoin addresses or public keys as defined when creating the collection.publ
is the key that is being used to sign the message and producesig
nonce
is an incremental integer, starting from 0 tolim-1
.This is to ensure that there will only be
lim
number of inscriptions periid
as specified in the collection definition.nonce
does not have to be published in order, ifnonce=4
is published beforenonce=3
it is still a valid inscription as long as:nonce < lim
, andnonce
is the only one on chain. If nonce collides for the sameiid
, only the first one to be mined in a block, or the first one in the list of transactions in a block will be valid.
sig
refers to the signature generated by the publisher using the address referred inpubl
with the payload beingCOLLECTION_ID INSCRIPTION_ID NONCE
where each value is separated by a single whitespace.sig
generated by publisher using a standardsignmessage
command of Bitcoin Core or an equivalent method in any Bitcoin library.sig
can be independently verified by anyone usingverifymessage
command of Bitcoin Core or any Bitcoin library.
Inscription and UX
Publisher MUST provide the purchaser with the following:
Raw unsigned inscription payload with the content, wrapped in the first inscription envelope.
Metadata for verification, wrapped in the second inscription envelope, as defined in Inscription Metadata.
Publisher SHOULD provide the purchaser with the following:
Rendered content of the purchased ordinal. This is typically an image, but may also be any content type supported by Ordinal Theory, including but not limited to text, movie, sound, etc.
Instructions to inscribe using the purchased address, and not any other addresses.
Purchaser CAN inscribe the purchased inscription at any time.
Publisher SHOULD take note of sold inscriptions and not oversell.
Publisher SHOULD forward the commission collected from the fee paid by Purchaser, based on any contracts that the Publisher have with the Creator.
Sites and services or marketplaces that support verifiable ordinal SHOULD provide an indicator if an ordinal is a Verifiable Ordinal and SHOULD provide a checkmark if it passes or fails validation.
If it fails, reason(s) of the failure SHOULD be provided.
Signature and Verification
Referring to the example above, signature generation, by the publisher, can be generated as follows, using the standard signmessage
command of Bitcoin Core:
Verification can be done by anyone using verifymessage
as follows:
Alternatively, for an example of signing and verifying using bitcoin-core standards with taproot addresses, the inclusion of a public key is required, but can only be signed and verified using external libraries, with supporting libraries including:
If sri
is defined at collection, content integrity verification should also be carried out in accordance to W3C's SRI specification.
Improvements
Further improvements to OIP-2: Verifiable Ordinal Collection can include:
Multi-publisher workflow by allowing Publisher to publish sales on the blockchain.
This will allow for better tracking of
lim
beyond single Publisher in order not to oversell.
Traits-based inscriptions, where collection is defined as permutations of traits rather than defined as individual inscriptions.
The above may be further published as separate proposals and is intended to not be included as part of this proposal for better focus and clarity.
Alternatives
Exploring various alternative proposals that are in the similar space:
This allows for collection defined via traits-based permutations.
While the traits are stored on-chain in a form of stringified data, the resulting artefact is a metadata with instructions on how to recreate the image.
This, however, would render on ordinals.com as text but not image and would require sites to specifically support the standard to generate the desired image.
This proposal introduces externally linked (IPFS) images.
It does not adhere to Ordinal Theory's definition of digital artifacts, which states that inscription content has to be entirely on-chain.
BRC-721 Ordinals Collection Protocol
This is a protocol that introduces a similar standard with that of ERC-721 of Ethereum.
Content is not on-chain and is externally linked in the form of
tokenURI
.
FAQ
1. What tools are available to verify Verifiable Ordinals?
Verification of verifiable ordinals can be carried out using standard tooling such as Bitcoin Core, using commands such as verifymessage
.
Programming-language specific toolings and libraries are still being developed and will be updated as tools and libraries are known or available. If you have developed a tool, please submit a pull request to update this document with a link to your tools.
2. Would this break Ordinals for other users/tools/sites that are not aware of Verifiable Ordinals?
Absolutely not. Verifiable Ordinals is backward-compatible. Services that are not aware of Verifiable Ordinals will simply be displaying ordinals and their inscriptions fine.
Last updated