---
description: protocol detail specification
---

# brc-20c

## Deployment&#x20;

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.

{% code title="" overflow="wrap" lineNumbers="true" %}
```json
{
    "p":"brc-20c",
    "tick":"oicp",
    "op":"deploy",
    "code": {
        "engine": "trino | mysql | ...",
        "version": "386",
        "body": "with oicp as (...)"
    },
    "oops": {
        "mint": "select * from oicp"
    },
    ...
}
```
{% endcode %}



<table><thead><tr><th width="97">Key</th><th width="108.33333333333331">required</th><th width="221">value</th><th>description</th></tr></thead><tbody><tr><td>p</td><td>Yes</td><td>any entity layer protocol + c</td><td>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.</td></tr><tr><td>tick</td><td>Yes</td><td>any string</td><td>any length string (over written brc-x protocol)</td></tr><tr><td>op</td><td>Yes</td><td>any valid operation code</td><td>"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.</td></tr><tr><td>code</td><td>Yes</td><td>object</td><td>check <a data-mention href="#code">#code</a></td></tr><tr><td>oops</td><td>No</td><td>object</td><td>check <a data-mention href="#oops">#oops</a></td></tr><tr><td>...</td><td>No</td><td>any</td><td>any other fields</td></tr></tbody></table>

#### 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.

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

<table><thead><tr><th width="111">Key</th><th width="95.33333333333331">required</th><th width="304">value</th><th>description</th></tr></thead><tbody><tr><td>engine</td><td>Yes</td><td>any valid engine name</td><td>~</td></tr><tr><td>version</td><td>Yes</td><td>any valid version number</td><td>~</td></tr><tr><td>body</td><td>Yes</td><td>a compressed sql script that removed all unnecessary spaces, line breaks and tabs.</td><td>The SQL statements define here are primarily for preparing the data or views required for the "operations" defined in the "oops" field. </td></tr></tbody></table>

#### 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.

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

<table><thead><tr><th width="148">Key</th><th width="99.33333333333331">required</th><th width="275">value</th><th>description</th></tr></thead><tbody><tr><td>{{op_name}}</td><td>Yes</td><td>a compressed sql script that removed all unnecessary spaces, line breaks and tabs.</td><td>each row returned by the execution of this SQL should be considered a valid mint operation.</td></tr><tr><td>...</td><td>NO</td><td>~</td><td>any other operations</td></tr></tbody></table>

### 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](https://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

<figure><img src="https://1364652276-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FgQ2iYEQa99ImX4RU5sbC%2Fuploads%2FaI4MZPyt1pB43JmFHTLa%2Fimage.png?alt=media&#x26;token=998f23a3-e663-4c92-a763-ebdf6f51d865" alt=""><figcaption></figcaption></figure>
