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
  • Formal Pattern Registration
  • Field Parameter
  1. Introduction
  2. Digital Elements

.element Registry

Formal recognition and registration of discovered patterns from Bitcoin data

Formal Pattern Registration

Inscribing a .element inscription using the following format:

<name>.<pattern>.<field>.element

The first deployment of an element is the only one that has claim to the name. Names are not case sensitive (DOGE = doge).

The NAME field (<name>.<pattern>.<field>.element) can not be reused to represent other elements.

Examples:

Valid: dmt.11.element

Valid: vitalik.12.element

Valid: satoshi.1.11.element

Valid: hal.2.11.element

Invalid: dmt.3.11.element

Invalid: gary.11.element

Parameter
Required
Optional
Description

name

Where <name> identifies the title of your element with the following characters excluded, whitespace is also excluded: /.[]{}:;"'

pattern

Where <pattern> is the pattern discovered in the desired <field> of choice. The field consists of the following fields within block data of Bitcoin. We've excluded redundant and non-relevant block data fields such as 'confirmations'.

field

<field> represents a mapped dataset of the block data of Bitcoin. Use the following table as a reference.

Field Parameter

Field
Block Data

0

Block

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

Input

25

Input

26

27

28

29

30

Output

31

Output

32

33

34

35

36

37

Note: If you find fields that need to be supported, new fields will be added to the end of the list.


PreviousDigital ElementsNextExample Element

Last updated 1 year ago

If the <pattern> field is left off, you are invoking the whole field and disregarding the pattern sequence identification within that field, thus treating the value of the field itself as the non-arbitrary root of information. Visit for a live example.

will be providing indexing service of all .element inscriptions will provide platform support and record keeping for registered .element inscriptions and Deployer inscriptions.

"block_hash" : "hex",
"size" : n, 
"strippedsize" : n,             
"weight" : n,                  
"height" : n, 
"version" : n, 
"versionHex" : "hex",
"merkleroot" : "hex", 
"time" : xxx, 
"mediantime" : xxx, 
"nonce" : n, 
"bits" : "hex",
"difficulty" : n, 
"chainwork" : "hex",
"nTx" : n,
"hex" : "hex", 
"txid" : "hex", 
"tx_hash" : "hex", 
"size" : n, 
"vsize" : n,  
"weight" : n,  
"version" : n,
"locktime" : xxx, 
"blocktime" : xxx, 
"asm" : "str",
"hex" : "hex" 
"sequence" : n,
"txinwitness" : "hex",                     
"value" : n, 
"n" : n, 
"asm" : "str",
"hex" : "str", 
"reqSigs" : n,
"type" : "str", 
"witness":boolean,
"btc_fee": n,
"is_coinbase": boolean,
"coinbase":"hex"
Trac Core
Mscribe.io
$NAT