We are thrilled to finally usher in the DMT ecosystems next phase of non-arbitrary value production with the introduction of DMT Blockdrops!
So much has been said about blockdrops through twitter posts and other media channels, but the understanding is definitely not 100% clear on what a blockdrop is and how this new protocol tool can be utilized. This article outlines the protocol updates to the NAT (Non Arbitrary Token) framework and Mscribe features that will be implemented to support blockdrops.
TLDR;
- DMT protocol updated with new blockdrop distribution format which allows newly generated NATs to be exclusively minted by owners of existing DMT assets.
- Blockdrop validation is fully supported and indexed by Trac at block 861,576.
- Elements can use new data fields supported by Trac (Field 10 and 4).
- Blockdrops can be deployed to all existing NATs and Bitmaps.
- Mscribe is building new features to support the deployment, exploring, and claiming of blockdrops.
Blockdrop “Provenance” NAT Distribution Method
Blockdrops are not a new concept, as a matter of fact, the concept was introduced along with NATs in the initial DMT gitbook. Within the NAT framework are three proposed asset distribution methods under the Use Cases section.
Method 1 is the traditional token deployment method enabling open and fair distribution with no preset conditions needing to be met in order to mint. The $NAT token is a perfect example of this method in application.
Method 2 incorporates “authorities” into the distribution process which enables custom parameters to be set by the deployer that introduce conditional requirements to mint. This is done by granting authority to minting platforms that execute this logic in the form of child-auths.
Method 3 is the “provenance” route which anchors NAT child mints to existing projects giving owners of the parent asset the exclusive ability to claim ownership of blockdrop assets.
Why is it called blockdrops as opposed to airdrops? This is due to the nature of DMT assets (NATs and UNATs) claiming block ownership in the context provided by NAT deployment inscriptions.
When minting NATs, you are owning blocks that represent the dmt-deploy inscription. When you own a block, you own all the fungible tokens of the pattern set from the dmt-deploy inscription. When minting a UNAT from a deployment with "id" as part of the JSON, your mint inscription represents a ownership of unique content generated from the "id" inscription ID.
Through parent-child, the provenance association of DMT asset ownership can be utilized to properly verify rights to a new subset of non-arbitrary creations that can be claimed and minted as child inscriptions of the parent asset. This introduces several token distribution benefits and eliminates the need for trusting the maintenance and honest distribution of ecosystem tokens in other existing models. The blockdrop model is open to any NAT deployer wanting to purpose a token for the digital commodities market native to the Bitmap ecosystem, or to any already deployed NAT.
How It Works
In the above NAT Distribution (Method 3) graphic, the flow from blockdrop NAT deployment → minting is outlined for a hypothetical scenario where a fungible token is being blockdropped to Bitmaps. To fully understand how this process works, lets outline steps on how to execute a Bitmap blockdrop deployment.
Step 1: First refer to the DMT gitbook “Non Arbitrary Tokens” section in order to understand the “how” and “why” of NATs. NATs operate through on-chain instructions embedded into the Bitcoin blockchain in the form Ordinal inscriptions that act as pointers for off-chain indexer reference and execution.
Step 2: To begin a deployment, choose a pattern element either already registered and indexed, or register your own. As of block 861,576, Bitcoin data fields 11 (bits), and newly supported field 10 (nonce) and 4 (block height) are available for element pattern registration.
Step 3: Prepare the below JSON to inscribe to Bitcoin.
{
"p": "tap",
"op": "dmt-deploy",
"elem": "",
"tick": "",
"prj": ""
}- Paste in the “elem” field the inscription ID of your chosen element between the parentheses after the colon mark.
- Input your token ticker that fits within the ticker length bounds of the TAP token protocol in the “tick” field between the parentheses after the colon mark.
- In the case of blockdrops, the deployment JSON incorporates a new “prj” field which is where the NAT deployment inscription ID is needed
- In Bitmap’s case, there is no deployment inscription ID to retrieve due to Bitmap deployment occurring outside the NAT framework. However, blockdrops can still be directed toward Bitmaps by inputting the Ordinal inscription ID below which references 0.bitmap inscribed by Bitoshi Blockamoto (June 1st 2023).
86539aff946c437af8088955827b7e6ff48fc6192836d4071b697b5359b7a732i0
The above steps are the “required” inputs into the deployment inscription in order to fulfill a blockdrop. Other optional fields can be included as additional lines within the deployment JSON dependent on the complexity of the pattern being referenced, or if the deployer intends to issue a UNAT.
With the above prepared deployment inscription, it is now ready to be inscribed on-chain by copy and pasting (including the curly brackets) the completed JSON above into any text based inscription tool or service.
Minting
With the blockdrop deployment inscribed, eligible minters who own the parent asset that the deployment “prj” field references, and whose block contains the pattern referenced in the “elem” field can claim and inscribe a child mint that is validated by Trac’s decentralized indexer network. This child inscription will contain the on-chain data references needed to render a UNAT or assign a fungible token balance (in some cases both).
The manual process to mint a child of the parent asset you own is outlined below;
To mint your blockdropped token as a child inscription from your Bitmap requires 2 on-chain transactions.
{
"p": "tap",
"op": "dmt-mint",
"tick": "<name>",
"blk": "#"
}First Transaction
- Visit your favorite parent-child inscription site (Chisel.xyz or other).
- Chose “Text” inscription.
- Copy and paste the above JSON data in the field (including the curly brackets).
- Be sure to include the proper ticker in the “tick” field between the parentheses after the colon mark.
- Specify a parent inscriptionID for your Bitmap that will be the parent for the transaction.
- Paste in your destination bitcoin wallet address.
- Pay the network fee.
Second Transaction
- Send your Bitmap to the address provided by the platform for the on-chain provenance.
- Pay the 2nd network fee.
- Your Bitmap and the child inscription should arrive at your desired wallet.
***Privilege Authority blockdrop mints have some added complexities and will require a future Mscribe update to abstract that complexity away. Stay tuned for more details released in the coming days***
Mscribe Support for Blockdrops
Now that an activation block height is set (block 861,576), we can now prepare to deploy new features to Mscribe which will support creators looking to take advantage of blockdrops such as;
- Deploy Blockdrops without the need to manually generate JSON instructions.
- Explore newly deployed Blockdrops.
- Claim Blockdrops from Bitmaps or NATs that you own.
These UI/UX updates are already in the works and will be usable in the coming days.
FAQ
Can I blockdrop to blockdrops?
- Yes, those are grandchildren.
Will blockdrops inscribed pre block 861,576 be valid?
- No, indexer will only recognize deployments from block 861,576 and onward.
Are all blockdrops free mints?
- No, deployers can distribute free mints or they can use priv-auth to authorize Mscribe or any other minting platform to enable a mint cost per claim (more details coming soon).
When I sell a parent asset, does the blockdrop claim travel to the new owner?
- Yes, the blockdropped assets travels with the parent asset until the owner of the parent inscribes the child. Then they become separate assets.
