3.3 Ordinals Inscription

Introduction

You will have the opportunity to inscribe your Handle/Sub-Handle placeholder on the Bitcoin blockchain for the purpose of showcasing your ownership.

Our solution for integrating Rootstock and Ordinals is as follows:

  1. The user must first possess the Handle/Sub-Handle on the Rootstock sidechain.

  2. Within the manage handle section, the user can select the "Inscribe Placeholder" function.

  3. They will then be prompted to connect their Bitcoin native wallet while maintaining their connection to their Rootstock wallet. This is to confirm ownership of the handle and to record the address used for inscribing the Placeholder and paying for gas fees.

  4. Before inscribing, the user will be given a preview of the Placeholder and the option to inscribe it with a specific Rare Satoshi (such as block 9s, uncommons, palindromes, etc.) This is entirely optional.

  5. After confirming the transaction, the inscription will be added as a child inscription under the official HNDL inscription, which serves as the parent for the entire project/collection.

The inscribed placeholder will contain dynamic metadata that pulls information from the HNDL smart contract on Rootstock. This includes the contract address, the Rootstock ownership address, token bound account address, the validity of the user's handle (valid, expired, burned), and tokenURI.

The Placeholder will be permanently stored on the Bitcoin layer 1 chain. However, the functionality of the inscription is dependent on its validity. For instance, if the handle is expired or burned from the Rootstock chain, the Placeholder on the mainchain will retrieve that information from the Rootstock network and lose all its functionalities, effectively removing it from the collection.

Notably, there is no need for Layer 1 <> Layer 2 bridging, as the Placeholders will retrieve its data from the HNDL smart contract on Rootstock. However, users are responsible for managing both assets on both chains. If a user loses access to their Placeholder, they can either forget about using Layer 1 or reinscribe their Placeholder. When reinscribing, the previous placeholder metadata will be updated as invalid, and the new Placeholder metadata will fetch from the HNDL smart contract. However, if a user loses access to their Rootstock Handle, they will lose access to everything.

Selling Handle Assets on Layer 1

To sell your Handle asset on Layer 1, you'll need to connect your Rootstock wallet to a complex marketplace that handles both Layer 1 and Layer 2 assets. Before listing, you'll be asked to connect your Rootstock wallet, which contains the Handle, to grant permission to transfer the handle from Layer 1 when it's sold. Note that this can only be done through the marketplace and not through peer-to-peer trades, which are not recommended anyway.

Important Exception

However, there is one exception to this rule. If the handle on the Rootstock chain is being held by a Smart Contract on the user's behalf, then it is possible to sell the Layer 1 asset independently. In this scenario, the Smart Contract will continue to hold the handle until they decide to redeem it, at which point they'll need to connect a Rootstock wallet to complete the process.

Renewals

Users can renew Handles and Sub-Handles ownership on layer 1 using Rootstock's Flyover protocol. The flyover protocol allows smart contracts to accept native BTC which converts it to rBTC dynamically.

Conclusion

The Handle system enables users to seamlessly use their Layer 1 Bitcoin assets in Layer 2 projects, with metadata being stored on Layer 1. Selling Handle assets on Layer 1 is possible through a complex marketplace that handles both Layer 1 and Layer 2 assets. Users must connect their Rootstock wallet to the marketplace and grant permission to transfer the handle when it's sold.

Disclaimer

Before making any decisions involving Bitcoin or Layer 2 technologies, it is advisable to conduct your own research. The development of HNDL into ordinals is purely theoretical, but not impossible, and subject to change as part of our roadmap.

Last updated