Artificial / Agentic Bitcoin Contract (ABC)

The Artificial / Agentic Bitcoin Contract (ABC) is a simple protocol that simulates smart contracts on Bitcoin layer 1. It uses a JSON structure and contains exactly four fields.

{"p":"abc","ca":"1XX","pt":{"sub":"coinmap","op":"deploy","tick":"ordi"},"sig":"XXX"}

The value of p is always "abc". ca (contract address) is a P2PKH address starting with "1" for single-sig, or a P2SH address starting with "3" for multi-sig. pt (plaintext) is a single-level hash containing all semantic information including the sub-protocol identifier (sub). sig is the signature of the canonical pt using the private key corresponding to ca (Bitcoin Signed Message domain + BIP-137 compact encoding).

Note: sub (sub-protocol identifier) must appear inside pt, not as an outer-layer field. This ensures sub is covered by the signature and cannot be tampered with.

ABC mainly adds two pieces of information, namely, the Contract Address and the signature.

Users can interact with CA through a website/Bot to generate consensus info. The consensus info is stored in pt. ABC uses the private key of CA to sign the canonical pt, and then the user inscribes the JSON on btc network, so that all can verify the consensus message.

Four Principles of ABC

Principle 1: Correct and First.
There is a "First is First" rule when deploying/minting tokens/NFTs in the Bitcoin ecosystem. Because of the introduction of CA and signatures, ABC is only valid for the first inscription that carries a correct signature and a correct birth place.

Principle 2: One address, one contract.
Only the first ABC deployment on an address is valid. ABC uses P2PKH addresses (starting with "1") as CAs for single-sig, and P2SH addresses (starting with "3") for multi-sig. A multi-sig deploy must declare its redeem script (ca_script) inside pt.

Principle 3: More Freedom.
There is no restriction on the tick name and tick length, and there can be tokens with the same name, which are distinguished by CAs. BTW: Tick names are case-insensitive.

Sub-protocols can be designed under the ABC protocol, which increases the flexibility and playability of the protocol even more.

Principle 4: State is a function of the best chain.
All derived state (contract ownership, claim records, supplies, used nonces) must be recomputable from the current best chain. Inscriptions and nonces that only exist on a reorged branch must not affect judgments on the new chain.

Plaintext Processing Rule

ABC's plaintext uses a single-level hash, and to guarantee determinism a series of rules must be applied before signing.
pt cannot be nested. All values in pt must be strings. Keys are treated as lowercase and sorted in ascending UTF-8 byte order. Tick values are uniformly converted to lowercase. The output is compact JSON with no unnecessary spaces. The signature covers exactly these canonical bytes, so any tampering makes the signature invalid. The sub-protocol identifier (sub) must appear inside pt, ensuring it is covered by the signature.

Coinmap Sub-protocol

Coinmap is the first application of ABC. Coinmaps are maps for FTs/NFTs in BTC ecosystem. A Coinmap has 21,000 cells(100*210), as BTC FTs are usually integer multiples of 21,000. For example, the famous BRC20 ORDI has 21,000,000 tokens with 1,000(max limit) multiples of 21,000 ideal mints. It can also be 10,000(100*100), usually the amt of an NFT Collection.

A deploy declares the map name (tick), its size (width, height), and optionally base_axis (numbering axis: width or height), origin and start. The numbering axis defaults to height: numbers run along the height first (row = N % height, col = N / height), so every height cells start a new column. For a 210 x 100 map this means each column is numbered 0 to 99, which is exactly the classic "base 100" Coinmap layout. Declaring base_axis:width switches to row-major numbering instead.

A mint declares tick, start, width, height, target and deadline. The minted area must stay inside the map, must not overlap an already minted area, and must be confirmed before deadline. The inscription must be born in an output paying target; ownership then follows the inscription's output. An all-in-one mint with width*height = 1000 is a 2-dimensional mint equivalent to 1000 traditional mints.

ABC-20 Sub-Protocol Using OP_RETURN

All-in-one minting can drastically reduce gas fees. This approach can also be used for FT token issuance. We plan to launch the ABC-20 sub-protocol in due course. Unlike all current FTs on btc chain, this sub-protocol will use All-in-one minting, which will drastically reduce the gas consumption at the time of minting, lowering the gas price and avoiding network congestion. The protocol could use transfer methods similar to BRC20 or runes. We prefer a runes-like transfer method combined with our unique all-in-one minting.

We have observed that OP_RETURN has recently become a hot topic in the Bitcoin ecosystem. We plan to adopt a Runes-like model to implement the transfer function for ABC-20, which can be achieved within the current OP_RETURN length restrictions. In the future, if OP_RETURN restrictions are removed, ABC-20 could implement deploy function using OP_RETURN instead of Inscription.

All-in-one Minting, High-dimension Minting and Visualized Minting

When you mint tokens of brc-20 or runes, if you want 1000 mints you have to mint 1000 times. These tedious and repeated mints are called 0-dimension minting. In contrast, Coinmap proposes a new way called All-in-one minting. First, you select a start point in the Coinmap, then you set the width and height of your mints. If width*height equals 1000, you have a 2-dimesion mint which matches 1000 times traditional mints.
A website as the service provider offers visualized minting to users. In addition to all-in-one minting, it offers many helpful services such as order locking, inventory checking. The services will significantly reduce the number of mints and high gas fees, avoiding the waste of UTXOs and also avoiding tons of invalid mints in so-called fair launches.

Service Fee

Fair launch has been a cultural phenomenon in the crypto world and especially the Bitcoin ecosystem. It is a systematic revolt against the darkness of traditional VC finance and is generally encouraging. But it also has its share of problems such as proton attacks, sky-high GAS fees, huge amounts of over-limit invalid mints. In Fair launch, only miners can get the revenue, which will not be conducive to the development of the project and the healthy development of the ecosystem.
Through all-in-one minting and other order and inventory management services, ABC applications like Coinmap can provide users with significant Gas savings. In this way, Coinmap-like protocols deserve charging appropriate service fees. ABC is actually a better Fair launch.
Coinmap's current rate is, 6$/0-d-mint.
We would like to establish an industry practice, through a protocol similar to Coinmap. For example, the total number of mints is set to 21,000, and depending on the project, each mint is charged 1-20$, which can provide the project with a revenue ranging from 21000-420,000$. Of course, this is a preliminary initiative and will be modified according to the situation.

Duck Test of ABC

The structure of ABC is very simple, some people may think it is not a genuine smart contract. But according to the Duck Test, if it walks like a duck and quacks like a duck, it's a duck. ABC has a contract address, ABC has a signature that verifies the consensus, and the consensus can be permanently inscribed on the btc blockchain. What’s more, ABC is able to issue tokens on demand like an erc-20 contact does instead of the current quantized 0-dimension minting in brc-20 and runes. This is a real smart contract for users, who don't care about those annoying technical details.

ABC Advantages

1. Saving GAS,
2. Reducing UTXOs waste,
3. Avoiding invalid mints,
4. Ticker freedom,
5. Better security against Bots,
6. Appropriate revenue for developers, good for ecosystem.

Examples of ABC Inscriptions

{
  "p":"abc",
  "ca":"1GujN4ApC4sBkw2WUDhxS6uKGZ6CzKF7uX",
  "pt":{
    "height":"100",
    "op":"deploy",
    "origin":"bottom-left",
    "start":"0",
    "sub":"coinmap",
    "tick":"ordi",
    "width":"210"
  },
  "sig":"H7XsWPrKbErSZ3Gyr3uVT48U9OjWdLu/JRE+cS0L8K7oEnf8FdMwXXC71lut6u5jK31On447rPqC5Alht98h/Bk="
}

Notes：
This is the deployment of a Coinmap named “ordi”.
The ordi Coinmap is 100*210, which has 21000 grids.
The orgin of the map is at the bottom-left.
No base_axis is declared, so the default is height: the 21000 grids are numbered along the height first, every 100 grids start a new column (classic base 100 layout).
“Start is 0” means the ordinal number of the first grid is 0.

{
  "p":"abc",
  "ca":"1GujN4ApC4sBkw2WUDhxS6uKGZ6CzKF7uX",
  "pt":{
    "deadline":"850412",
    "height":"10",
    "op":"mint",
    "start":"0",
    "sub":"coinmap",
    "target":"177P6qM1Va5Cm8TrGVoP6ZDE6mKsnX9PFT",
    "tick":"ordi",
    "width":"5"
  },
  "sig":"IIJ0CBYkvDjuG+9EHU30pRDgOyuGrfYWXuIqS0VdJZCYfz2Jso44OIHCFK3kDjhiS8BdB6z41wxhbo7FR/LYemA="
}

Notes:
1. Target is the birth place and initial owner of this inscription: the reveal output carrying the inscription must pay target, otherwise the mint is invalid.
2. Deadline is the deadline block which you should mint before.
Deadline = JSON generated block + delay
Currently, delay is set to 1000 blocks, so you can choose a low gas block to mint in about a week delay. Delay may vary, so notice the exact number of deadline.