📒brc-20c

protocol detail specification

Deployment

In this chapter, we primarily discuss how to deploy a protocol enhanced by OICP. Basically, the "code" and "oops" fields are specific to the OICP protocol, while the rest of the fields are inherited from the original protocol.

{
    "p":"brc-20c",
    "tick":"oicp",
    "op":"deploy",
    "code": {
        "engine": "trino | mysql | ...",
        "version": "386",
        "body": "with oicp as (...)"
    },
    "oops": {
        "mint": "select * from oicp"
    },
    ...
}

Key	required	value	description
p	Yes	any entity layer protocol + c	The suffix "c" in this context stands for "classification". It indicates that the associated protocol is enhanced by OICP protocol. We also can have brc-721c for instance.
tick	Yes	any string	any length string (over written brc-x protocol)
op	Yes	any valid operation code	"valid" in this context refers to operations that can be categorized as either inherited from the BRC protocol (such as deploy, mint, etc.) or newly defined operations within the "oops" object.
code	Yes	object	check code
oops	No	object	check oops
...	No	any	any other fields

code

This object is used to define a code block that contains all the necessary information for users to recreate the runtime environment and validate the execution result. By specifying the database engine, version, and SQL script, we can ensure that the execution result of the same SQL script is consistent and deterministic.

"code": {
    "engine": "trino",             //String, database engine name
    "version": "386",              //String, database engine version
    "body": "with oicp as (...)"   //compressed sql body
},

Key	required	value	description
engine	Yes	any valid engine name	~
version	Yes	any valid version number	~
body	Yes	a compressed sql script that removed all unnecessary spaces, line breaks and tabs.	The SQL statements define here are primarily for preparing the data or views required for the "operations" defined in the "oops" field.

oops

Oops stands for Observable Operations. This object is used to define new operations or override existing operations. For example, in the following example, by defining a key called "mint" in this object, it overrides the mint behavior defined in the BRC-20 protocol. The new behavior is determined by the execution result of the SQL provided as the value of this key. In other words, each row returned by the execution of this SQL should be considered a valid mint operation.

"oops": {
    "mint": "select * from oicp", //obserable operations
    ...
}

Key	required	value	description
{{op_name}}	Yes	a compressed sql script that removed all unnecessary spaces, line breaks and tabs.	each row returned by the execution of this SQL should be considered a valid mint operation.
...	NO	~	any other operations

Indexer and result verification

The standard validation method requires validators to follow the protocol-defined database and version, import the Bitcoin historical data based on the specified data structure, and then execute the corresponding SQL statements to verify the results. However, this validation method can be resource-intensive and is recommended to be used as a final validation approach. The protocol encourages third-party organizations to develop their own indexers to optimize the verification speed. It also encourages users to use compatible databases, such as Dune, for quick validation. However, if the results obtained from these alternative approaches conflict with the standard validation method, the standard method takes precedence.

Here are the sample steps to quick verify result in dune.com

1. find out protocol deploy inscription (through unisats etc) and open dune

2. click new query

3. copy to dune

4. copy to dune

5. click run

6. verify result