Batch

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

You can assign a name to your BRC137-DID using the DID_UPDATE operation or bind a TLD to your held BRC137-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 BRC137-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 BRC137.

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

Delegator

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 BRC137 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 BRC137 protocol is used, version v1, for the DELEGATE_BATCH operation.
    OP_PUSH "brc137: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.

Last updated