Core Concept

This chapter will provide a detailed description of the core concepts in BRC137.

BRC137-DID

The BRC137-DID is based on the Ordinals protocol. Anyone can mint a BRC137-DID inscription in a permissionless and decentralized manner.

When naming, the following rules are followed:

• Names can be up to 42 characters long, composed of letters, numbers, hyphens or underscores.

• Names are unique across the entire BTC chain, FCFS.

• Names are case-insensitive.

• Names are NOT modifiable

It is worth noting that before being inscribed with a string as a name, the BRC137-DID is also a fungible BRC20 token. BRC137-DIDs that have already been engraved with a name can also be modified. These allow it to circulate as a highly liquid DID asset.

BRC137-DID inscriptions can be bound to any number of BRC137-TLD inscriptions, as detailed in the TLD-BIND section.

BRC137-TLD

Anyone can mint a BRC137-TLD inscription in a completely permissionless and decentralized manner, following the BTC-NFT protocol, with a total supply of 21,000.

The holder of a BRC137-TLD inscription can name their BRC137-TLD NFT, following these rules:

• Names can be up to 42 characters long, composed of letters, numbers, or underscores.

• Names are unique across the entire BTC chain, FCFS.

• Names are case-insensitive.

• Names are NOT modifiable.

As with BRC137-DID, if you have a collision when engraving a name on the BRC137-TLD, don't worry; this will not cause your inscription to be lost, but the naming operation will be considered invalid, and this invalidity will not change even if the previous name is released.

Names of BRC137-TLD and BRC137-DID do not conflict with each other, for example, there can exist a BRC137-DID named ABC and also a BRC137-TLD named ABC, and they work well together.

When setting a name for the inscription, the owner of the BRC137-TLD can specify a fixed royalty , which is in satoshis. When a BRC137-DID wants to bind with a BRC137-TLD, the holder of the BRC137-DID inscription needs to pay the specified royalty to the holder of the BRC137-TLD inscription, as detailed in the TLD-BIND section.

It should be noted that the names inscribed on BRC137-TLD are not modifiable.

BRC137-DELEGATOR

BRC137-DELEGATOR is a set of on-chain assets compatible with the BTC-NFT protocol, with a limited issuance of 21. Those holding BRC137-DELEGATOR assets qualify to become Delegators within the BRC137 ecosystem.

Delegators play a crucial role in the BRC137 ecosystem. They can collect user operations, aggregate them, and batch them onto the blockchain, thereby reducing transaction fees for users during the transaction process. Delegators can profit by charging users lower fees than bitcoin transaction fees, earning a margin in the process. For more details, please refer to Batch

TLD-BIND

A BRC137-DID can be bound to ANY number of BRC137-TLDs. After binding, no new inscription is created, but a new resolvable name is generated.

For example, suppose there is a BRC137-DID named "test", and there are two BRC137-TLDs, each inscribed with "a" and "b" respectively. Before binding, "test" would be resolved to the holder's address of the "test" inscription through the BRC137 protocol. After the BRC137-DID is bound to these two BRC137-TLDs:

• test

• test.a

• test.b

All three names can be resolved to the holder's address of the "test" inscription.

If a BRC137-DID binds with a BRC137-TLD that has not yet set a name, the binding will be considered invalid, and this invalidity will not change even if the BRC137-TLD subsequently sets a name.

As described in BRC137-TLD, the holder of a BRC137-TLD inscription can set a royalty amount in satoshis. When the holder of a BRC137-DID inscription wants to bind with a TLD, they must pay the specified royalty amount in a Bitcoin transfer as part of the binding transaction (the payment of the royalty and the binding operation of the inscription must be completed in the same transaction). The amount transferred must be greater than or equal to the set royalty value, otherwise, it will be considered an invalid binding, and the transferred amount will not be refunded.

Metaprotocol

The Metaprotocol corresponds strictly to the Metaprotocol in the Ordinal protocol and is supported starting from version v0.10.0 of the Ordinal protocol. We define the Metaprotocol with the following specification:

<PROTOCOL>:<VERSION>:<OP>

For the BRC137 protocol, it is always the string "brc137", which is case-insensitive but is recommended to use lowercase characters. The field defines which version of the BRC137 protocol is being used for the current operation, and it is currently always v1.

For detailed definitions of <OP> , please refer to the Operations section.

Metadata

The Metadata corresponds strictly to the Metadata in the Ordinal protocol. If you are not familiar with this concept, you can check inscriptions/metadata.

The definition of Metadata varies for different operations, and detailed definitions should be specifically referred to in the Operations section.

The Metadata is encoded in cBOR overall to improve storage efficiency and reduce storage costs.