Digital Matter Theory
  • Introduction
    • Digital Matter Theory
    • Digital Elements
      • .element Registry
      • Example Element
    • Non-Arbitrary Tokens (NATs)
      • Hybrid Token Model
      • NAT Deployment Format
      • NAT Minting
      • NAT Token Transfer
    • NAT Use Cases
      • $NAT (Method 1) - Live
      • $BMT (Method 3)
    • UNAT Use Cases
      • $dmt-natcats
      • $dmt-nat
    • Supported Token Protocols
      • TAP Protocol
    • Resources
      • FAQ
      • Videos
      • Guides
        • $BMT Blockdrop Claim
        • How to convert your NAT deployment into a UNAT (Reinscription Guide)
      • $NAT Mint Process
      • Rendering a UNAT
Powered by GitBook
On this page
  • Element used for $BMT
  • Deploy Inscription for $BMT
  • Bitmap Token
  • Why Not Use The Transaction Count of a Bitmap?
  • Blockdrop
  • Key Differences in Proposed Bitmap Token Distribution Models
  • Official $BMT minting procedure
  1. Introduction
  2. NAT Use Cases

$BMT (Method 3)

First NAT deployment based on provenance purposed for Bitmap

Previous$NAT (Method 1) - LiveNextUNAT Use Cases

Last updated 1 year ago

Blockdrop tokens require indexing update. Please do not inscribe child tokens from your assets (such as Bitmap) until indexing is complete. A block height will be announced when blockdrop minting can begin.

Element used for $BMT

Deploy Inscription for $BMT

Bitmap Token

  • Fair and equitable distribution mechanism

  • Non-arbitrary data roots

  • Future proof - scalable for future onboarding

To uphold these foundational principles, we believe the token distribution model for $BMT needs to be equitably distributed to the existing ecosystem participants while leveraging a non-arbitrary value component rooted in the distributed Bitmap blocks.

dmt.11.element

The dmt-deploy of $BMT can be verified by the following inscription ID:

a2014009b3af54ea0670002f67f6174b42f2098f632e454e9acae119a82efaadi0

Why Not Use The Transaction Count of a Bitmap?

The use of the already existing pre-selected non-arbitrary data root set by Bitoshi for Bitmap (transaction count) would introduce anticipated friction points for ecosystem adoption. If we were to do so, the element format assuming Bitoshi were to use the NAT framework, would look like the following;

bitoshi.14.element

With this Element there would be a discrepancy of token supply between the oldest blocks and newer blocks, resulting in an un-equitable distribution of Bitmap native tokens, failing to uphold the Bitmap ecosystem ethos from our perspective.

Blockdrop

Through parent-child, the provenance association to Bitmap ownership can be utilized to properly verify rights to fungible token minting. 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.

Key Differences in Proposed Bitmap Token Distribution Models

Arb. Token Claim
Arb. Token Mint
Arb. Token Airdrop
Blockdrop

Decentralized Distribution

Non-arbitrary limit

Future Proof

Scalable

Fair Mint

Logic Function

In regards to what has made Bitmap an exceptional showcase of how DMT can be leveraged to underpin new digital value creation, there exist principles that must be upheld to maintain the ethos set forth by Bitoshi Blockamoto and . These principles are as follows;

The above leverages the "bits" field and invokes the value of that field which will be used to determine $BMT account balances when token transferring.

Bitmap Theory
element
Official $BMT minting procedure
Inscription 42405438
Logo
Inscription 42411883
Logo