Batch

The format for Operations mentioned in this document has not been updated yet. Please refer to the latest indexer and official inscription tools of B137.

In the Core Concept and Operations sections, we have gained an understanding of the core operations of B137. Through these operations, we can create B137-DID and B137-TLD.

You can assign a name to your B137-DID using the DID_UPDATE operation or bind a TLD to your held B137-DID through the DID_BIND operation. While this may seem sufficient, there is an undeniable issue – transactions on the Bitcoin network are slow and expensive. If you simply want to set a name for your B137-DID, you may need to pay transaction fees amounting to tens of dollars. For some users, this cost is prohibitive, potentially hindering the widespread adoption of B137.

To address this, we have introduced Batch operations and the Delegator role to the B137 protocol.

Delegator

Users holding BRC137-DELEGATOR assets ( #brc137-delegator) will become Delegators.

Delegators have the capability to gather user transactions and batch them for on-chain submission. In this process:

1. Users must sign the operations they wish to execute with their private keys and submit them to the Delegator.

2. The Delegator collects the signed transactions from users. During this process, the Delegator may charge a certain fee to the users submitting transactions.

3. After collecting a sufficient number of transactions, the Delegator submits them to the Bitcoin blockchain network.

The B137 indexer monitors transactions on the network and, upon identifying aggregated transactions from BRC137 Delegators, sequentially executes the relevant operations within them.

Operations

DELEGATE_BATCH

The Delegator submits aggregated transactions through the DELEGATE_BATCH operation. At the Bitcoin script level, it can be represented as follows:

OP_0
OP_IF
    OP_PUSH "ord"
    OP_PUSH 01
    OP_PUSH "text/plain;charset=utf-8"
    OP_PUSH 07
    # it specifies that the B137 protocol is used, version v1, for the DELEGATE_BATCH operation.
    OP_PUSH "b137:v1:DELEGATE_BATCH"
    OP_0
    # Mint operation compatible with the BRC20 protocol.
    OP_PUSH <DATA>
OP_ENDIF

In this context, <DATA> adopts the following data structure and is encoded using the cbor format:

[
    {
        "version": "v1",
        "operation": "DID_UPDATE",
        "timestamp": <UINT64>,
        "timeout": <UINT64>,
        "data": {
            "name": "<STRING>",
            "inscription_did":"<SAT_NUMBER>/<INDEX>"
        },
        "signature": "<STRING>"
    },
    {
        "version": "v1",
        "operation": "DID_UPDATE",
        "timestamp": <UINT64>,
        "timeout": <UINT64>,
        "data": {
            "name": "<STRING>",
            "inscription_did":"<SAT_NUMBER>/<INDEX>"
        },
        "signature": "<STRING>"
    }
]

The Delegator has the discretion to determine how many data entries to include in <DATA>. However, it is important to note that records with timeout values in the array smaller than the current transaction timestamp will be ignored.

When collecting transactions, the Delegator needs to guide users to perform ECDSA signatures on the following data structure:

{
    "version": "v1",
    "operation": "<OPERATION>",
    "timestamp": <UINT64>,
    "timeout": <UINT64>,
    "data": <OPERATION_DATA>
}

For the current v1 version, only the DID_UPDATE and DID_BIND operations are supported.