├── oip-05-renewable-lists.md ├── SUMMARY.md ├── README.md ├── oip-01-inscription-metadata.md ├── oip-04-chunking-of-inscriptions-for-larger-files.md ├── oip-06-ordinals-royalty-standard.md ├── oip-03-recoverable-commits.md ├── oip-05-on-chain-renewable-list.md └── oip-02-verifiable-ordinal-collection.md /oip-05-renewable-lists.md: -------------------------------------------------------------------------------- 1 | # OIP-05: Renewable Lists 2 | 3 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [Ordinal Theory Improvement Proposals](README.md) 4 | * [OIP-01: Inscription Metadata](oip-01-inscription-metadata.md) 5 | * [OIP-02: Verifiable Ordinal Collection](oip-02-verifiable-ordinal-collection.md) 6 | * [OIP-03: Recoverable Commits](oip-03-recoverable-commits.md) 7 | * [OIP-04: Chunking Large File](oip-04-chunking-of-inscriptions-for-larger-files.md) 8 | * [OIP-05: Renewable Lists](oip-05-on-chain-renewable-list.md) 9 | * [OIP-06: Ordinals Royalty Standard](oip-06-ordinals-royalty-standard.md) 10 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Proposals that adhere strongly to Ordinal Theory. 3 | --- 4 | 5 | # Ordinal Theory Improvement Proposals 6 | 7 | This is a collection of proposed improvements to [Ordinal Theory](https://docs.ordinals.com/). 8 | 9 | Ordinal Theory Improvement Proposals, can also be appreviated to OIP. 10 | 11 | ### Guidelines and boundaries 12 | 13 | 1. Proposals MUST be fully compatible with original Ordinal Theory. 14 | 2. Inscriptions MUST be on-chain, adhering to the standards of Ordinal Theory, which means that they MUST NOT be stored external off of Bitcoin blockchain. 15 | 16 | ### Proposals 17 | 18 | * [OIP-01: Inscription Metadata](oip-01-inscription-metadata.md) 19 | * [OIP-02: Verifiable Ordinal Collection](oip-02-verifiable-ordinal-collection.md) 20 | * [OIP-03: Recoverable Commits](oip-03-recoverable-commits.md) 21 | * [OIP-04: Chunking Large File](oip-04-chunking-of-inscriptions-for-larger-files.md) 22 | * [OIP-05: Renewable Lists](oip-05-on-chain-renewable-list.md) 23 | * [OIP-06: Ordinals Royalty Standard](oip-06-ordinals-royalty-standard.md) 24 | 25 | ### Friends of OIPs 26 | 27 | * [Sado Protocol](https://sado.space) 28 | * [Unisat](https://unisat.io) 29 | * [Ordlify](https://ordlify.com/) 30 | * [Ordzaar](https://ordzaar.com) 31 | 32 | ### About 33 | 34 | This initiative is initially proposed by the core developers of [Sado Protocol](https://sado.space) – an open protocol and SDK for all things Ordinals. It is intended to be fully open and therefore allowing open contributions by all, for the benefits of making ordinals protocol more user and developer-friendly. 35 | 36 | Pull requests, suggestions and discussions are greatly welcomed. Participate at the open repository at the [GitHub repo](https://github.com/oipsio/oips) 37 | -------------------------------------------------------------------------------- /oip-01-inscription-metadata.md: -------------------------------------------------------------------------------- 1 | # OIP-01: Inscription Metadata 2 | 3 | **Status:** RFC (Request for Comment) 4 | 5 | ### Overview 6 | 7 | Inscriptions are done using "envelopes" as described on the [Ordinal Theory Handbook](https://docs.ordinals.com/inscriptions.html). While it supports multiple media types, it leaves no rooms for metadata. 8 | 9 | Some workarounds potentials: 10 | 11 | * Separate coupled inscription for metadata. 12 | * Linkage of metadata on external storage, e.g. IPFS. 13 | 14 | However, the above come with its own sets of challenges: 15 | 16 | 1. Inscriptions cannot be linked together purely on-chain without metadata. 17 | 2. Linkage via external storage involves an external media, which may not be available universally alongside the Bitcoin blockchain. 18 | 3. Linkage via external storage is one-way only, external to ordinal. This may result in multiple metadata pointing to the main one, not knowing which is the canonical one. 19 | 20 | Therefore, the ideal solution is to have metadata not only fully on-chain, also ideally attached with the same ordinal. 21 | 22 | ### Solution 23 | 24 | A safe way to do that would be to have two inscriptions on the same ordinal. First one being the actual payload, second one being the metadata as follows: 25 | 26 | ``` 27 | OP_FALSE 28 | OP_IF 29 | OP_PUSH "ord" 30 | OP_PUSH 1 31 | OP_PUSH "text/plain;charset=utf-8" 32 | OP_PUSH 0 33 | OP_PUSH "Hello, world!" 34 | OP_ENDIF 35 | 36 | OP_FALSE 37 | OP_IF 38 | OP_PUSH "ord" 39 | OP_PUSH 1 40 | OP_PUSH "application/json;charset=utf-8" 41 | OP_PUSH 0 42 | OP_PUSH "{\"p\":\"oip-01\"}" 43 | OP_ENDIF 44 | ``` 45 | 46 | This is compatible with the current version of Ordinals and is[ fully covered with a unit test](https://github.com/ordinals/ord/blob/master/src/inscription.rs#L474), ignoring further inscriptions after the first one, but treating the first one as a valid inscription. 47 | 48 | Note that the content in the metadata example above is merely meant as an arbitrary example and not a mandated format, i.e. that it has to has the header `{"p":"oip-01"}`. This document covers how metadata can be carried as part of OIP-01. Format of metadata is out of scope for the intents and purposes of OIP-01. 49 | 50 | ### FAQ 51 | 52 | #### 1. What tools are available to parse on-chain ordinal metadata (OIP-01)? 53 | 54 | Tools 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. 55 | 56 | #### 2. Would this break Ordinals for other users/tools/sites that are not aware of OIP-01? 57 | 58 | Absolutely not. OIP-01 is backward-compatible. Services that are not aware of OIP-01 will simply be showing only the first inscription, [just as intended](https://github.com/ordinals/ord/blob/master/src/inscription.rs#L474). Metadata will be ignored. 59 | -------------------------------------------------------------------------------- /oip-04-chunking-of-inscriptions-for-larger-files.md: -------------------------------------------------------------------------------- 1 | # OIP-04: Chunking of Inscriptions for Larger Files 2 | 3 | oip-04-chunking-of-inscriptions-for-larger-files 4 | 5 | **Status:** Draft 6 | 7 | ## Overview 8 | 9 | Given that Bitcoin's block size limitation stands at a maximum of 4MBs, users aiming to inscribe files larger than this limit are compelled to utilize recursive techniques. However, the present-day scenario lacks a uniform standard for identifying inscriptions with recursives. 10 | 11 | The enhancement underlined in this proposal aims to establish a standard for embedding instructions with the recursive inscription. These instructions will aid in the "stitching" of recursive inscriptions, ensuring proper reassembly. 12 | 13 | ## Objectives 14 | 15 | 1. Implement a universally-accepted standard for identifying inscriptions using recursives. 16 | 2. Ensure proper reassembly of inscriptions by embedding comprehensive instructions. 17 | 18 | ## Proposed Solution 19 | 20 | The solution encompasses metadata detailing the recursive inscriptions, and this metadata is inscribed following the OIP-01 standard. 21 | 22 | ### Flow: 23 | 24 | 1. The creator divides the file and inscribes these partial files. 25 | 2. The creator embeds the recursive inscription together with relevant metadata. 26 | 3. Viewers interpret and reconstruct the full inscription based on the provided metadata. 27 | 28 | ## Metadata Format for Recursive Inscription of Large Files 29 | 30 | Outlined below is the JSON format employed for Metadata concerning large file inscriptions: 31 | 32 | ```json 33 | { 34 | "p": "chunks", 35 | "v": 1, 36 | "mt": "", 37 | "iids": [ 38 | // Array of inscription identifiers 39 | ], 40 | "meta": { 41 | // Meta data for the inscription 42 | } 43 | } 44 | ``` 45 | ### Notes: 46 | 47 | 1. Fields `p` (protocol) and `v` (version) are mandatory. 48 | 2. `mt` denotes the file type (eg: image/webp) 49 | 3. `iids` is an array storing identifiers of inscriptions used as recursives. 50 | 4. `meta` encapsulates metadata for the inscription. Eg: grid, width, height can be applied for images. 51 | 52 | ## Example of metadata of Large Images Inscription using recursives 53 | 54 | The following example is a recursive inscription of 4 webp images in a grid of 2x2 55 | 56 | ```json 57 | { 58 | "p": "chunks", 59 | "v": 1, 60 | "mt": "image/webp", 61 | "iids": [ 62 | "c16889125e190eb170d54c66144826f4b72c113a9fe6c371c70e54b75841fde3i0", 63 | "b62a24a148d05dbe369e44a17567739c9c7ec4000bad9256b1551f641a17a27fi0", 64 | "79db8d3030fd594e4154aeb23417ce8e695ca0fac3d1d1c2e08adbe096ee5075i0", 65 | "e18aeeb16c55fdde73bd6b07ccdbe725fe2954b6ed18705a362f12b1bc5c3a5ei0" 66 | ], 67 | "meta": { 68 | "grid": "2x2", 69 | "width": 1024, 70 | "height": 1024 71 | } 72 | } 73 | ``` 74 | 75 | 76 | ### Tools Incorporating OIP-4 77 | 78 | #### 1. Large Images Inscription: 79 | 80 | The [Ordlify Large Image Inscriptions tool](https://ordlify.com/recursives/image) is designed to inscribe sizable images by segmenting and then reassembling them per the OIP-04 standard. 81 | 82 | ### Support & Inquiries 83 | For additional insights and support, do reach out on Twitter via [@afxal](https://x.com/afxal) or [@shafiu](https://x.com/shafiu). -------------------------------------------------------------------------------- /oip-06-ordinals-royalty-standard.md: -------------------------------------------------------------------------------- 1 | # OIP-06: Ordinals Royalty Standard 2 | 3 | Proposer: [U-Zyn Chua](https://twitter.com/uzyn) 4 | 5 | **Status:** WIP (Draft: Work-in-progress) 6 | 7 | #### Overview 8 | 9 | Ordinals collections have been successful. Many creators coming from the Ethereum NFT space are wishing for Royalty support similar to that of [EIP 2981](https://eips.ethereum.org/EIPS/eip-2981) available on the Ordinals. 10 | 11 | Royalty can be useful in rewarding creators and to encourage further creation of utilities. Rather than just making only a one-time minting fee during first-mint as implemented at many exchanges, some creators would wish to continue to gain from Ordinals sale that they authored. This could potentially help in encouraging creation of further utilities on Ordinals. 12 | 13 | #### Solution 14 | 15 | Similar to [EIP 2981](https://eips.ethereum.org/EIPS/eip-2981), royalty on Ordinals would be an honor-based system implemented by marketplaces. The inability to enforce it entirely on-chain are due to the following reasons: 16 | 17 | 1. The fact that Ordinals Protocol is a social consensus on Bitcoin blockchain, unenforceable by Blockchain consensus. 18 | 2. Even if it is technically possible, it is not possible to differentiate between ordinals trading (should warrant payment of royalty) and ordinals transfer (should not warrant payment of royalty). 19 | 20 | **Definition** 21 | 22 | Royalty is to be defined in percentage of the sale price and in non-negative number format. 23 | 24 | * `0` for no royalty 25 | * `0.05` for 5% royalty 26 | * `1` for 100% royalty 27 | * `1.5` for 150% royalty 28 | 29 | Definition could be defined via either [OIP-02: Verifiable Ordinal Collections](oip-02-verifiable-ordinal-collection.md) or Ordinal Theory's metadata. 30 | 31 | Definition via OIP-02: Verifiable Ordinal Collections: 32 | 33 | ```json 34 | { 35 | "p": "vord", 36 | "v": 1, 37 | "ty": "col", 38 | "title": "Wizards", 39 | "desc": "Description of the collection (optional)", 40 | "url": "URL to collection (optional)", 41 | "slug": "wizards_(optional)", 42 | "creator": { 43 | "name": "Artist #1", 44 | "email": "artist@example.org", 45 | "address": "1BitcoinAddress" 46 | }, 47 | "royalty": { 48 | "address": "1RoyaltyReceivingAddress", 49 | "pct": 0.03 50 | } 51 | } 52 | ``` 53 | 54 | Definition via Ordinals Protocol metadata to be added soon. 55 | 56 | **Payment** 57 | 58 | UTXO-model of Bitcoin makes it possible to make royalty payment in a single trade transaction. 59 | 60 | An Ordinal trade with royalty should consist minimally of the following: 61 | 62 | Inputs: 63 | 64 | 1. Cardinal, from the buyer, minimally sale price + royalty + transaction fee. 65 | 2. Ordinal, from the seller. 66 | 67 | Outputs: 68 | 69 | 1. Ordinal, to the buyer. 70 | 2. Cardinal, sale price, to the seller. 71 | 3. Cardinal, royalty, to the creator. 72 | 73 | Royalty should be computed as sale price \* royalty percentage. 74 | 75 | Marketplaces supporting Ordinals Royalty Standard should prepare partially-signed Bitcoin transaction (PSBT) as above. 76 | 77 | #### FAQ 78 | 79 | **1. What about previously defined OIP-02 collections? Can their creator adds royalty?** 80 | 81 | It is out of scope of this document. Updating of collection definition should be a separate specification. 82 | 83 | **2. Any marketplaces supporting it yet?** 84 | 85 | Not that I know of at this moment. [Ordzaar](https://ordzaar.com) and [Sado SDK](https://sado.space) are planning support. 86 | -------------------------------------------------------------------------------- /oip-03-recoverable-commits.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Adding a recovery witness script to the Taproot ScriptTree 3 | --- 4 | 5 | # OIP-03: Recoverable Commits 6 | 7 | ### Problem 8 | 9 | Known issue - [https://github.com/ordinals/ord/issues/904](https://github.com/ordinals/ord/issues/904) 10 | 11 | Bitcoin Ordinal Inscriptions are created using taproot addresses. Not a standard taproot address, but rather a segregated witness (script) based taproot address. Unlike the traditional legacy based addresses, which can be spent using the corresponding “private” key, SegWit addresses allow you to create non-key based accounts that can be unlocked using scripts. Both native and nested SegWit accounts in both legacy and Bech32 formats can only be linked to a single script. However, the most exciting thing about taproot addresses is that they utilize a ScriptTree, which enables you to have multiple TapLeafs, where each leaf can be linked to a different script, enabling for an array of redemption methods to be applied to a single address. 12 | 13 | Unfortunately, despite utilizing ScriptTrees, the original implementation of inscriptions only uses a single TapLeaf, with a single method of redemption, which is the ORD inscription commit and reveal witness script. This script includes the full content of the item being inscribed, which is the attribute that causes the high fee for spending from that address. In order to create the inscription by spending from the address, the total fees required must be covered by a single unspent transaction output (UTXO). Any other funds sent to that address that are less than the required amount can rarely be recovered and are often lost forever. 14 | 15 | A simplified version of the original implementation of the bitcoin inscription commit and reveal address creation flow (in BitcoinJS format) can be seen below: 16 | 17 | ``` 18 | var witness_script = bitcoin.script.compile([ 19 | tweaked_public_key, 20 | bitcoin.opcodes.OP_CHECKSIG, 21 | bitcoin.opcodes.OP_FALSE, // referred to as an ENVELOPE 22 | bitcoin.opcodes.OP_IF, // adding false first enables prunable content 23 | OP_PUSH("ord"), // specifies its an ordinal inscription 24 | OP_PUSH("text/plain;charset=utf-8"), // defines media type 25 | OP_PUSH("Hello World"), // media content 26 | bitcoin.opcodes.OP_ENDIF // end of ENVELOPE 27 | ]); 28 | var script_tree = [{output: witness_script}]; 29 | var redeem_script = {output: witness_script, redeemVersion: 192}; 30 | var inscription = bitcoin.payments.p2tr({ 31 | internalPubkey: sliced_public_key, 32 | scriptTree: script_tree, 33 | redeem: redeem_script, 34 | network: network 35 | }); 36 | var commit_and_reveal_address = inscription.address; 37 | ``` 38 | 39 | ### **Solution** 40 | 41 | By introducing a second TapLeaf with a simplified “recovery” script that does not include the content that is trying to be inscribed, the fees can - when needed; be reduced and have the potential to then enable unsuitable UTXOs to be recovered. Since redeem scripts do not affect the address, when it comes to spending from the address at the reveal phase, it is possible to use either of the redeem scripts that match those found in the initial commit ScriptTree. 42 | 43 | However, it is important to note that the initial commit address must have used the same ScriptTree that includes both options initially. You cannot change the ScriptTree between the commit (deposit) and reveal (inscription) phases without affecting the address. 44 | 45 | Our proposed ScriptTree for recoverable commits is as follows: 46 | 47 | ``` 48 | var inscribe_script = bitcoin.script.compile([ 49 | tweaked_public_key, 50 | bitcoin.opcodes.OP_CHECKSIG, 51 | bitcoin.opcodes.OP_FALSE, // referred to as an ENVELOPE 52 | bitcoin.opcodes.OP_IF, // adding false first enables prunable content 53 | OP_PUSH("ord"), // specifies its an ordinal inscription 54 | OP_PUSH("text/plain;charset=utf-8"), // defines media type 55 | OP_PUSH("Hello World"), // media content 56 | bitcoin.opcodes.OP_ENDIF // end of ENVELOPE 57 | ]); 58 | var recover_script = bitcoin.script.compile([ 59 | tweaked_public_key, 60 | bitcoin.opcodes.OP_CHECKSIG 61 | ]); 62 | var script_tree = [{output: inscribe_script}, {output: recover_script}]; 63 | var inscribe = {output: inscribe_script, redeemVersion: 192}; 64 | var recover = {output: recover_script, redeemVersion: 192}; 65 | var inscription = bitcoin.payments.p2tr({ 66 | internalPubkey: sliced_public_key, 67 | scriptTree: script_tree, 68 | redeem: inscribe, // this can be either inscribe or recover 69 | network: network 70 | }); 71 | var recoverable_commit_and_reveal_address = inscription.address; 72 | ``` 73 | 74 | ### Support 75 | 76 | This feature is already supported by the [ORDIT SDK](https://sado.space/docs/ordit-introduction) - but do reach out if you know of any other tools or services that implement this standard whilst we wait for changes to ORD itself. 77 | 78 | Please reach out on Twitter (@[m\_smalley](http://twitter.com/m\_smalley)) or visit [Sado Labs](https://sado.space/blog/taproot-recoverable-commits) for more details. 79 | -------------------------------------------------------------------------------- /oip-05-on-chain-renewable-list.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Enable a method for users to create and update their inscription lists 3 | --- 4 | 5 | # OIP-05: On-Chain Renewable List (ORL) 6 | 7 | ### Overview & Motivation 8 | 9 | Most marketplaces manage Ordinals collections through offline JSON files. Several on-chain collection protocols like brc-721, gbrc-721, brc69, etc., also exist, but they are mainly influenced by erc-721 and are not compatible with the existing Ordinals inscription system. 10 | 11 | Our goal is to establish an open on-chain renewable collection protocol that seamlessly integrates with the existing Ordinals system. Creating and maintaining collections should not require any reliance on trusted third parties or place excessive burdens on maintainers. 12 | 13 | ### How It Works 14 | 15 | Users can deploy and create collections, with the option to add or remove inscriptions as desired. It's also possible to reference inscriptions from other collections within a collection. The owner of deployed inscriptions is the only one authorized to modify the collection's contents, with ownership transfer functionality. 16 | 17 | #### Deploy the Collection 18 | 19 | - Inscribe the deploy inscription and transfer it to a Ordinals-compatible wallet with the desired parameters. 20 | 21 | ``` 22 | { 23 | "p": "ORL", 24 | "op": "deploy", 25 | "slug": "ordinals", 26 | "name": "Ordinals", 27 | "desc": "All Ordinals inscriptions on Bitcoin", 28 | "icon": "765cf24db22df4d7bae1cd12e5ee4780dc263486e426d8d1758eaa0515fa6fcei0", 29 | "max": "2100000000000000" 30 | } 31 | ``` 32 | 33 | | Key | Required? | Description | 34 | | ---- | --------- | ---------------------------------------------------------------------- | 35 | | p | Yes | Protocol: Helps other systems identify and process ORL events | 36 | | op | Yes | Operation: Type of event (Deploy, Add, Remove) | 37 | | slug | Yes | Slug: 1-256 letter identifier of the ORL (valid letter: `-_0-9a-zA-Z`) | 38 | | name | Yes | Name of this ORL collection | 39 | | desc | Yes | Description of this ORL collection | 40 | | icon | Yes | Icon's inscription ID of this ORL collection | 41 | | max | No | Max supply: set max supply of the ORL, default to 2100000000000000 | 42 | 43 | 44 | #### Modify the Collection 45 | 46 | - Inscribe the add/remove function to your Ordinals compatible wallet with the desired parameters. 47 | - Once received, send the inscription to yourself to enact the changes. 48 | 49 | ##### Add Inscriptions or Collections to ORL 50 | 51 | Careful when using inscription service. Some tools first inscribe to themselves then forward it to the customer, potentially wasting the add/remove function. Some Ordinals wallets generate a new address each time, so ensure the inscription is sent to the address holding the deploy-inscription. 52 | 53 | ``` 54 | { 55 | "p": "ORL", 56 | "op": "add", 57 | "slug": "ordinals", 58 | "items": ["765cf24db22df4d7bae1cd12e5ee4780dc263486e426d8d1758eaa0515fa6fcei0", "tick2", ...] 59 | } 60 | ``` 61 | 62 | | Key | Required? | Description | 63 | | ----- | --------- | ---------------------------------------------------------------------- | 64 | | p | Yes | Protocol: Helps other systems identify and process ORL events | 65 | | op | Yes | Operation: Type of event (Deploy, Add, Remove) | 66 | | slug | Yes | Slug: 1-256 letter identifier of the ORL (valid letter: `-_0-9a-zA-Z`) | 67 | | items | Yes | List of inscription ID of this ORL collection, or list of other tick | 68 | 69 | ##### Remove Inscriptions or Collections from ORL 70 | 71 | ``` 72 | { 73 | "p": "ORL", 74 | "op": "remove", 75 | "slug": "ordinals", 76 | "items": ["765cf24db22df4d7bae1cd12e5ee4780dc263486e426d8d1758eaa0515fa6fcei0", "tick2", ...] 77 | } 78 | ``` 79 | 80 | | Key | Required? | Description | 81 | | ----- | --------- | ---------------------------------------------------------------------- | 82 | | p | Yes | Protocol: Helps other systems identify and process ORL events | 83 | | op | Yes | Operation: Type of event (Deploy, Add, Remove) | 84 | | slug | Yes | Slug: 1-256 letter identifier of the ORL (valid letter: `-_0-9a-zA-Z`) | 85 | | items | Yes | List of inscription ID of this ORL collection, or list of other tick | 86 | 87 | ### Notes 88 | 89 | - Only the first deployer of a ticker can claim that ticker. 90 | - The valid ticker must match the regexp pattern `[-_0-9a-zA-Z]{3,8}`. 91 | - In case of events occurring in the same block, prioritization is determined by their confirmation order in the block (first to last). 92 | - Similar to brc-20's transfer function, the add/remove function, once inscribed to the collection maintainer's address, needs to be sent to oneself to take effect. 93 | - Each add/remove inscription can be used only once. 94 | - The objects managed by the add/remove functions can be other inscriptions or even other collections. This implies that a collection includes not only directly added inscriptions but also real-time complete references to other collections. 95 | - When adding or removing inscriptions or collections, the operations are independent. Changes to inscriptions do not affect the internal state of referenced collections. Referenced collections are always fully and instantly referenced. 96 | 97 | ### Contact Us 98 | 99 | Please contact UniSat Team on our Discord / X(Twitter) to help us improve the proposal. 100 | 101 | 102 | 103 | -------------------------------------------------------------------------------- /oip-02-verifiable-ordinal-collection.md: -------------------------------------------------------------------------------- 1 | # OIP-02: Verifiable Ordinal Collection 2 | 3 | **Status:** RFC (Request for Comment) 4 | 5 | This is also commonly known as **Verifiable Ordinals**. 6 | 7 | ### Overview 8 | 9 | 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: 10 | 11 | 1. Low costs to NFT artists to get started in launching their collections and arts on Ethereum. 12 | 2. Buyer pays for gas (transaction fees) while allowing creators and artists to profit from it. 13 | 3. Parentage links, allowing NFTs to be traces to its parent smart contract, therefore knowing that its legitimacy as part of a collection. 14 | 15 | 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](broken-reference) set out for Ordinal Theory Improvements. 16 | 17 | ### Roles 18 | 19 | The following roles are defined to align on the understanding: 20 | 21 | 1. Creator 22 | * Usually the artist. 23 | * Initiates collection of ordinal inscriptions. 24 | * Usually, intends to be paid, especially from the first sale of an ordinal in the said collection. 25 | 2. Publisher 26 | * Service, or website, that provides minting service of ordinals that belong to the said collection. 27 | * Usually also provides collection creation service to the Creator. 28 | 3. Purchaser 29 | * First-hand buyer, and therefore owner, of an ordinal from a collection. 30 | * Pays the purchase price, of which the bulk of it should go to the Creator. 31 | 32 | ### Objectives 33 | 34 | 1. 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. 35 | 2. Allows first-hand buyers to take ownership of inscribing, and therefore pay for inscription fee. 36 | 3. 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. 37 | 4. Inscriptions trading must be carried out on-chain, just like other ordinals. Off-chain trading of ordinals must not be possible. 38 | 5. 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. 39 | 40 | ### Solution 41 | 42 | 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. 43 | 44 | #### Flow 45 | 46 | 1. Creator initiates a collection, usually a series of ordinal inscriptions with a theme. 47 | 2. Creator defines and publishes the collection via the service of a Publisher. 48 | 3. Purchaser browses the collection, at this stage uninscribed, at Publisher's site, and decides to purchase a specific item from the collection. 49 | 4. 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. 50 | 1. Creator receives the bulk of the purchase fees. 51 | 5. Purchaser can choose for the right moment to inscribe based on factors such as Bitcoin network fees. 52 | 1. Purchaser, however, would not be able to trade/resell the purchased ordinal without first inscribing them as doing so would invalidate the verifiable ordinal. 53 | 54 | ### Collection 55 | 56 | Collection is to be inscribed as a `text/plain` inscription with the following: 57 | 58 | ```json 59 | { 60 | "p": "vord", 61 | "v": 1, 62 | "ty": "col", 63 | "title": "Wizards", 64 | "desc": "Description of the collection (optional)", 65 | "url": "URL to collection (optional)", 66 | "slug": "wizards_(optional)", 67 | "creator": { 68 | "name": "Artist #1", 69 | "email": "artist@example.org", 70 | "address": "1BitcoinAddress" 71 | }, 72 | "publ": ["1PublisherBitcoinAddress1", "1PublisherPublicKey1"], 73 | "insc": [ 74 | { 75 | "iid": "wiz-01", 76 | "lim": 10, 77 | "sri": "sha256-Ujac9y464/qlFmtfLDxORaUtIDH8wrHgv8L9bpPeb28=" 78 | }, 79 | { 80 | "iid": "IDs as Titles #2", 81 | "lim": 1, 82 | "sri": "sha256-zjQXDuk++5sICrObmfWqAM5EibidXd2emZoUcU2l5Pg=" 83 | }, 84 | { 85 | "iid": "common", 86 | "lim": 1000 87 | } 88 | ] 89 | } 90 | ``` 91 | 92 | Notes: 93 | 94 | 1. `p` and `v` are required. They refer to protocol and version. 95 | 2. `ty` refers to `type`. Only `col` and `insc` are 2 valid values. `col` is used here for collection. 96 | 3. `slug` is a suggestion and not a guarantee that the slug would be reserved for the specific collection. Even if `slug` has already taken by other collections before this one, this collection remains valid. 97 | 4. `publ` refers to an array of public Bitcoin addresses from publisher. This is intended to be used for verification of inscribed Ordinals. 98 | * 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](https://bitcoin.design/guide/glossary/address/#legacy-address---p2pkh) type, usually starting with `1`. 99 | * 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. 100 | 5. `insc` refers to an array of inscription collections. 101 | * `iid` refers to inscription ID. It must be unique within a collection. Collision of `iid` invalidates the collection definition. 102 | * `lim` defines the maximum number of times that an inscription can be sold or inscribed. Further inscriptions beyond `lim` count will be deemed invalid. 103 | * `sri` is an optional field and refers to subresource integrity. It adds resource integrity to inscriptions. 104 | 1. SRI is defined in accordance to [W3C's SRI specifications](https://www.w3.org/TR/SRI/) 105 | 2. If `sri` is present, validation must check for resource integrity. Otherwise, resource integrity check is not needed. 106 | 6. 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 as `COLLECTION_ID` throughout this OIP. 107 | 108 | ### Verifiable Ordinal Inscription 109 | 110 | Verifiable ordinal inscription is to be inscribed as a valid inscription with an attached metadata, following [Inscription Metadata](oip-01-inscription-metadata.md) recommendations. 111 | 112 | Metadata for inscription: 113 | 114 | ```json 115 | { 116 | "p": "vord", 117 | "v": 1, 118 | "ty": "insc", 119 | "col": "eb9d4726a7caaaf5a7fe082059cb37b97b188845b70f476fa9833ec3079f5600:0", 120 | "iid": "wiz-01", 121 | "publ": "1PublisherBitcoinAddress1", 122 | "nonce": 0, 123 | "sig": "HzXmUa2mXuu7kCog7B7NqSR61Oa/Tr13IixoJG6C3e3qCdKptNL0pT0wxQ8oZGz9hvgjnq4WL+pMSjsqV+lVv94=" 124 | } 125 | ``` 126 | 127 | Notes: 128 | 129 | 1. `p` and `v` are required. They refer to protocol and version. 130 | 2. `ty` refers to `type`. Only `col` and `insc` are 2 valid values. `insc` is used here for inscription. 131 | 3. `col` refers to either a genesis txid or current outpoint where the collection inscription can be located. 132 | * 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. 133 | 4. `col` and `iid` as a tuple refers specifically to an inscription. 134 | * There could be multiple of the same `col` and `iid` up to the `lim` that's defined at collection. 135 | * Further inscriptions beyond `lim` must not validate. 136 | 5. `publ` refers to either one of the publisher's Bitcoin addresses or public keys as defined when creating the collection. 137 | * `publ` is the key that is being used to sign the message and produce `sig` 138 | 6. `nonce` is an incremental integer, starting from 0 to `lim-1`. 139 | * This is to ensure that there will only be `lim` number of inscriptions per `iid` as specified in the collection definition. 140 | * `nonce` does not have to be published in order, if `nonce=4` is published before `nonce=3` it is still a valid inscription as long as: 141 | * `nonce < lim`, and 142 | * `nonce` is the only one on chain. If nonce collides for the same `iid`, 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. 143 | 7. `sig` refers to the signature generated by the publisher using the address referred in `publ` with the payload being `COLLECTION_ID INSCRIPTION_ID NONCE` where each value is separated by a single whitespace. 144 | * `sig` generated by publisher using a standard `signmessage` command of Bitcoin Core or an equivalent method in any Bitcoin library. 145 | * `sig` can be independently verified by anyone using `verifymessage` command of Bitcoin Core or any Bitcoin library. 146 | 147 | #### Inscription and UX 148 | 149 | 1. Publisher MUST provide the purchaser with the following: 150 | * Raw unsigned inscription payload with the content, wrapped in the first inscription envelope. 151 | * Metadata for verification, wrapped in the second inscription envelope, as defined in [Inscription Metadata](oip-01-inscription-metadata.md). 152 | 2. Publisher SHOULD provide the purchaser with the following: 153 | * 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. 154 | * Instructions to inscribe using the purchased address, and not any other addresses. 155 | 3. Purchaser CAN inscribe the purchased inscription at any time. 156 | 4. Publisher SHOULD take note of sold inscriptions and not oversell. 157 | 5. Publisher SHOULD forward the commission collected from the fee paid by Purchaser, based on any contracts that the Publisher have with the Creator. 158 | 6. 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. 159 | * If it fails, reason(s) of the failure SHOULD be provided. 160 | 161 | #### Signature and Verification 162 | 163 | Referring to the example above, signature generation, by the publisher, can be generated as follows, using the standard `signmessage` command of Bitcoin Core: 164 | 165 | ```bash 166 | $ bitcoin-cli signmessage 13fh1atRp7rV2qdGuxhFabGkmKAnRia9Kq "eb9d4726a7caaaf5a7fe082059cb37b97b188845b70f476fa9833ec3079f5600 wiz-01 0" 167 | H+i8FyNiLVvCqcjOqluKzU+lvy2RY8AGBqlFEgFGgaLALQ3zamtnxo6XzuPuyFD0sKd+5Tz2Q552sbNPb2A0kjo= 168 | ``` 169 | 170 | Verification can be done by anyone using `verifymessage` as follows: 171 | 172 | ```bash 173 | $ bitcoin-cli verifymessage 13fh1atRp7rV2qdGuxhFabGkmKAnRia9Kq "H+i8FyNiLVvCqcjOqluKzU+lvy2RY8AGBqlFEgFGgaLALQ3zamtnxo6XzuPuyFD0sKd+5Tz2Q552sbNPb2A0kjo=" "eb9d4726a7caaaf5a7fe082059cb37b97b188845b70f476fa9833ec3079f5600 wiz-01 0" 174 | true 175 | ``` 176 | 177 | 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: 178 | 179 | * [Ordit SDK](https://github.com/sadoprotocol/ordit-sdk) 180 | 181 | If `sri` is defined at collection, content integrity verification should also be carried out in accordance to [W3C's SRI specification](https://www.w3.org/TR/SRI/). 182 | 183 | ### Improvements 184 | 185 | Further improvements to OIP-2: Verifiable Ordinal Collection can include: 186 | 187 | 1. Multi-publisher workflow by allowing Publisher to publish sales on the blockchain. 188 | * This will allow for better tracking of `lim` beyond single Publisher in order not to oversell. 189 | 2. Traits-based inscriptions, where collection is defined as permutations of traits rather than defined as individual inscriptions. 190 | 191 | 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. 192 | 193 | ### Alternatives 194 | 195 | Exploring various alternative proposals that are in the similar space: 196 | 197 | 1. [Generative BRC-721](https://github.com/jerryfane/generative-brc-721) 198 | * This allows for collection defined via traits-based permutations. 199 | * 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. 200 | * 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. 201 | 2. [BRC 721 experimental proposal](https://brc-721.gitbook.io/about-the-brc-721-experimental-proposal/) 202 | * This proposal introduces externally linked (IPFS) images. 203 | * It does not adhere to [Ordinal Theory's definition of digital artifacts](https://docs.ordinals.com/inscriptions.html), which states that inscription content has to be entirely on-chain. 204 | 3. [BRC-721 Ordinals Collection Protocol](https://www.brc721.com) 205 | * This is a protocol that introduces a similar standard with that of ERC-721 of Ethereum. 206 | * Content is not on-chain and is externally linked in the form of `tokenURI`. 207 | 208 | ### FAQ 209 | 210 | #### 1. What tools are available to verify Verifiable Ordinals? 211 | 212 | Verification of verifiable ordinals can be carried out using standard tooling such as Bitcoin Core, using commands such as `verifymessage`. 213 | 214 | 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. 215 | 216 | #### 2. Would this break Ordinals for other users/tools/sites that are not aware of Verifiable Ordinals? 217 | 218 | Absolutely not. Verifiable Ordinals is backward-compatible. Services that are not aware of Verifiable Ordinals will simply be displaying ordinals and their inscriptions fine. 219 | --------------------------------------------------------------------------------