ord

Ordinals use several notation systems to identify specific satoshis. Developers and collectors can use these formats to reference or track individual satoshis:

• Integer notation: The raw ordinal number assigned by mining order (e.g., 2099994106992659).
• Decimal notation: Represents the block height and the offset within that block (e.g., 3891094.16797).
• Degree notation: A hierarchical notation that shows rarity at a glance (e.g., 3°111094′214″16797‴).
• Percentile notation: The satoshi's position in the total Bitcoin supply as a percentage (e.g., 99.99971949060254%).
• Name: An encoding of the ordinal number using characters a through z (e.g., satoshi).

Ordinal theory is a protocol for assigning unique serial numbers to satoshis (the smallest unit of Bitcoin) and tracking them as they are spent. This allows individual satoshis to be identified, tracked, and traded as unique digital artifacts.

Key concepts:

• Serial Numbers: Every satoshi is assigned a large unique number based on its mining order.
• No Sidechains: Ordinal theory works directly on the Bitcoin blockchain without requiring sidechains, separate tokens, or changes to the Bitcoin protocol.
• Inscriptions: A protocol enabled by ordinal theory that allows attaching arbitrary content (using MIME types) to individual satoshis, turning them into bitcoin-native digital artifacts.

Inscriptions use a web-based content model consisting of a MIME type (content type) and a byte string. Content is stored on-chain within Taproot script-path spend scripts using "envelopes" (OP_FALSE OP_IF ... OP_ENDIF).

To disambiguate inscriptions, the first data push in an envelope must be the string ord. The second push (OP_PUSH 1) indicates the content type follows, and the third push (OP_PUSH 0) indicates the actual content follows. Large inscriptions must be split into multiple data pushes, as individual pushes are limited to 520 bytes.

Runes are Bitcoin-native digital commodities that allow for the etching, minting, and transferring of interchangeable tokens. Unlike inscriptions, which are unique, every unit of a specific rune is identical.

Runestones are the protocol messages that enable rune functionality. They are stored in Bitcoin transaction outputs using a specific script pubkey format:

1. OP_RETURN
2. OP_13
3. Zero or more data pushes (concatenated and decoded into 128-bit integers).

A single transaction may contain at most one runestone. A runestone can simultaneously etch a new rune, mint an existing one, and transfer runes from inputs to outputs.

Inscriptions allow attaching arbitrary content to satoshis, creating Bitcoin-native digital artifacts.

Process:

1. A satoshi is selected to be inscribed.
2. A transaction is created that sends the satoshi while revealing the inscription content on-chain.
3. The content becomes inextricably linked to that specific satoshi, creating an immutable digital artifact that can be tracked, transferred, or sold like any other Bitcoin asset.

The ord wallet is currently the only wallet that supports sat-control and sat-selection. These features are required to safely store and send rare sats and inscriptions (ordinals).

Risks of using unsupported wallets:

• Receiving: Receiving ordinals in an unsupported wallet is generally safe as long as the UTXO containing them is not spent.
• Sending: If an unsupported wallet is used to send Bitcoin, it may automatically select the UTXO containing the ordinal as an input, causing the inscription to be sent or spent as transaction fees.

If you use an alternative wallet (like Sparrow Wallet) to manage ordinals, you must perform manual coin-selection when sending BTC to ensure you do not accidentally spend the UTXO containing the ordinal.

After receiving an inscription, it will appear in the Transactions tab and the UTXOs tab.

1. Track Status: If the transaction is unconfirmed, right-click it, select Copy Transaction ID, and paste it into mempool.space.
2. Verify Inscription: Once confirmed, go to the UTXOs tab, right-click the specific output, and select Copy Transaction Output. Paste this ID into the search on ordinals.com to view the inscription.

Teleburn addresses allow you to burn assets on other blockchains (like Ethereum) to point back to a Bitcoin inscription. Because these addresses are derived from inscription IDs and have no corresponding private key, any assets sent to them are effectively burned.

To derive an Ethereum teleburn address, the process involves:

1. Taking the SHA-256 hash of the inscription ID.
2. Serializing it as 36 bytes (where the first 32 bytes are the transaction ID and the last 4 bytes are the big-endian inscription index).
3. Taking the first 20 bytes of that hash and interpreting it as an Ethereum address.

Recursion allows an inscription to call other inscriptions (or itself) to render content. Common patterns include:

• PFP Art: Using recursion to generate profile picture art.
• Generative Collections: Using metadata or specific endpoints (like the recursive blockheight endpoint) as seeds for generative art.
• Library Integration: Recursively loading libraries like threeJS or React 3 Fiber within the inscription.
• Super-recursion: Transforming recursive content before rendering.
• Functional Tools: Using recursive calls to implement complex logic, such as pixel art drawing programs or music generation.

Recursive endpoints provide backwards-compatibility guarantees: they will not be removed, and object fields will not be renamed or change types. However, developers must design inscriptions to be resilient to the following changes:

• Additional fields: New object fields may be added to the response.
• Field ordering: Fields may be reordered.

Inscriptions must be able to handle unexpected fields and must not rely on a specific field order in the returned JSON objects.