The Universal Protocol & Simplicity Indexer

The best protocol is the one we build together—block by block.

Introduction

In early 2023, the Bitcoin ecosystem witnessed an explosion of innovation, sparked by the Ordinals theory. From this movement, the BRC-20 standard emerged, unleashing a wave of creativity and participation unlike anything seen before. Its success was rooted in a radical simplicity: a straightforward set of JSON operations—deploy, mint, transfer—inscribed into witness data, made it accessible to all. For the first time, a fungible token protocol on Bitcoin achieved massive, grassroots adoption.

Yet, the very simplicity that fueled BRC-20's meteoric rise also revealed its inherent limitations. As the ecosystem matured, these growing pains became apparent: transfer logic was ambiguous, creating vulnerabilities; on-chain data was stored inefficiently; and the protocol lacked a clear path for extension without introducing breaking changes. For the past years, the community has grappled with these challenges, understanding that the question was not if BRC-20 should evolve, but how.

The Universal Protocol emerges as the answer to that question. It is not a replacement, but a profound extension—one that honors the original BRC-20 syntax while resolving its foundational flaws. The core architectural decision is a migration of operational logic from witness inscriptions to OP_RETURN outputs. This choice is deliberate and profound. As Bitcoin’s native, on-chain data carrier, OP_RETURN provides a surface-level, easily interpretable canvas for protocol logic. Crucially, unlike witness data, OP_RETURN outputs are prunable, meaning they do not contribute to the permanent UTXO set bloat that full nodes must maintain forever. This "Satoshi-faithful" approach prioritizes the long-term health and decentralization of the Bitcoin network.

By building upon this foundation, the Universal Protocol establishes the most robust accountability system in existence for a token protocol on Bitcoin. It maintains full backward compatibility with the original BRC-20 shared namespace and offers a tribute to Satoshi through its OPI-000 no return mechanism. The intent, the action, and the outcome are explicitly and immutably linked on-chain. This document specifies that evolution.

Welcome to the Universal Protocol.

1. Fundamental Concepts

The Universal Protocol achieves BRC-20 functionality through a lean and explicit transaction structure, interpreted by the Simplicity Indexer.

A Universal transaction is composed of four key elements:

Inputs (UTXOs): Standard Bitcoin UTXOs that provide the necessary BTC for network fees. For transfer operations, the Simplicity Indexer associates a specific address from input UTXOs with token balances, thereby authorizing the transaction.
OP_RETURN Output(s): The core of the protocol. These are non-spendable outputs containing a BRC-20 operation as a compact JSON payload (≤ 80 bytes). (SOON) A single Bitcoin transaction can contain multiple OP_RETURN outputs to enable batch processing.
Recipient Output(s): Standard Bitcoin outputs (P2PKH, P2SH, Taproot). The protocol's central design principle is that each BRC-20 OP_RETURN operation is explicitly bound to the first valid, non-OP_RETURN output that immediately follows it. The address of this subsequent output is the sole recipient of the tokens for that operation.
Change Output: A standard output returning any remaining BTC to the sender's address.

The Account-Based Model: A Foundation of Safety

The Universal Protocol employs a robust account-based model, a design choice that fundamentally distinguishes it from many UTXO-based token systems. In this model:

A user's token balance is tied directly to their Bitcoin address, not to a specific, fragile UTXO.
This eliminates the risk of accidental token loss. Spending a UTXO from an address that holds tokens for a standard BTC transaction will not affect the token balance. The tokens remain securely associated with the address.

An explicit Universal transfer operation is the only way to debit tokens from an address's balance. This provides a safe, intuitive, and forgiving user experience.

2. Operation Specifications

All operations are defined by a JSON payload within an OP_RETURN output. Each operation has a specific, mandatory transaction structure that the Simplicity Indexer validates.

Deploy

The deploy operation registers a new BRC-20 token and its properties.

{
  "p": "brc-20",
  "op": "deploy",
  "tick": "OPQT",
  "max": "21000000",
  "lim": "1000"
}

p: Protocol identifier; must be "brc-20".
op: Operation type; must be "deploy".
tick: The unique ticker symbol for the token.
max (or m): A string representing the maximum total supply.
lim (or l): An optional string representing the maximum amount per mint operation.

Validation: The Simplicity Indexer will only validate a deploy if the tick has not been previously registered by any valid BRC-20 deployment (Ordinals or Universal), enforcing a shared global namespace. The JSON payload must not exceed the 80-byte OP_RETURN data limit.

A valid deploy transaction must adhere to the following structure:

Component	Description	Notes / Rules
Input(s)	Standard UTXO(s)	Provides the BTC required for transaction fees.
Output 0	`OP_RETURN`	Payload: `{"p":"brc-20","op":"deploy",...}` MUST be the first output (vout=0).
Output 1	"Dummy" Recipient	Address: Sender's own change address (recommended). Value: ≥ Dust Limit (e.g., 546 sats). This output is structurally required but semantically null.
Output 2	Change (Optional)	Address: Sender's change address. Value: Remaining BTC.

Mint

The mint operation creates new units of an existing token. This operation credits the amt of the specified tick to the address of the Bitcoin output that immediately follows this OP_RETURN output.

{ "p": "brc-20", "op": "mint", "tick": "OPQT", "amt": "1000" }

The structure of a mint transaction is as follows:

Component	Description	Notes / Rules
Input(s)	Standard UTXO(s)	Provides the BTC required for transaction fees.
Output 0	`OP_RETURN`	Payload: `{"p":"brc-20","op":"mint",...}` MUST be the first output (vout=0).
Output 1	Token Recipient	Address: The address receiving the newly minted tokens. Value: ≥ Dust Limit (e.g., 546 sats).
Output 2	Change (Optional)	Address: Sender's change address. Value: Remaining BTC.

Transfer

The transfer operation moves existing tokens from a sender to a recipient. This operation debits the amt from the sender's balance (as identified by the transaction inputs) and credits it to the address of the Bitcoin output that immediately follows this OP_RETURN.

{ "p": "brc-20", "op": "transfer", "tick": "OPQT", "amt": "100" }

A transfer transaction requires the following specific structure:

Component	Description	Notes / Rules
Input(s)	Sender's UTXO(s)	Crucial: The inputs serve to authorize the transaction and identify the sender's address. The indexer then verifies the token balance of the entire address, not a specific UTXO.
Output 0	`OP_RETURN`	Payload: `{"p":"brc-20","op":"transfer",...}` MUST be the first output (vout=0).
Output 1	Token Recipient	Address: The address receiving the transferred tokens. Value: ≥ Dust Limit (e.g., 546 sats).
Output 2	Change (Optional)	Address: Sender's change address. Value: Remaining BTC.

3. Multi-Operation Transactions (SOON)

A core feature of the Universal protocol is the ability to batch multiple, distinct operations within a single atomic Bitcoin transaction. This is achieved by sequencing OP_RETURN and recipient outputs, leading to significant reductions in network fees and enabling powerful, trust-minimized functionalities.

The Simplicity Indexer processes the outputs of a transaction sequentially. This guarantees that operations within a single transaction are resolved in a precise order, allowing the outcome of one operation (like a deploy) to be the prerequisite for the next (like a mint).

Example 1: Standard Multi-Transfer (SOON)

This is the most straightforward batching use case, where a single sender distributes multiple tokens to various recipients.

Scenario: A user wants to transfer 100 "OPQT" tokens to Alice and 10 "ORDI" tokens to Bob in one transaction.

Transaction Output Structure:

Input(s): From the sender, containing at least 100 OPQT, 10 ORDI, and BTC for fees.
Output 0 (OP_RETURN): {"p":"brc-20","op":"transfer","tick":"OPQT","amt":"100"}
Output 1 (Recipient): A standard output to Alice's address.
Output 2 (OP_RETURN): {"p":"brc-20","op":"transfer","tick":"ORDI","amt":"10"}
Output 3 (Recipient): A standard output to Bob's address.
Output 4 (Change): A standard output returning remaining BTC to the sender.

Indexer Logic: The Simplicity Indexer processes this sequence atomically. It first validates and executes the transfer to Alice, then validates and executes the transfer to Bob. Both operations are bound to the fate of the parent Bitcoin transaction.

Example 2: Atomic Deploy and Full-Supply Mint (SOON)

This pattern allows a token creator to deploy a new token and mint its entire supply to a specific address in a single, front-run-proof transaction.

Scenario: A project wants to launch "NEW" with a total supply of 1,000,000 and immediately secure all tokens in a treasury address.

Transaction Output Structure:

Input(s): From the creator, containing BTC for fees.
Output 0 (OP_RETURN): {"p":"brc-20","op":"deploy","tick":"NEW","max":"1000000","lim":"1000000"}
Output 1 (OP_RETURN): {"p":"brc-20","op":"mint","tick":"NEW","amt":"1000000"}
Output 2 (Recipient): The project's treasury address, which will receive all 1,000,000 tokens.
Output 3 (Change): (Optional) A final change output.

Indexer Logic:

The indexer processes Output 0, validating the deploy operation and registering "NEW" in its database. It consumes Input 0 as the deploy's structural partner.
It then immediately processes Output 1. Because the deploy operation was successfully processed just moments before in the same atomic context, the mint for "NEW" is now valid.
The 1,000,000 tokens are credited to the treasury address specified in Output 2.

Example 3: Two-Party Atomic Swap (PSBT) (SOON)

This advanced use case demonstrates how the Universal protocol can facilitate trust-minimized, peer-to-peer trades without a centralized intermediary.

Scenario: Alice agrees to trade 100 "OPQT" for 10 "ORDI" from Bob. They construct a single transaction that requires both of their signatures to be valid.

Transaction & PSBT Signing Flow:

Construction: A single Partially Signed Bitcoin Transaction (PSBT) is created with inputs from both parties and outputs reflecting the swap.
Alice's Action: Alice adds her input and signs only that input. She then sends the partially-signed PSBT to Bob.
Bob's Action: Bob inspects the PSBT. He verifies that he is receiving 100 OPQT and that the transaction correctly sends 10 ORDI from his account. He then adds his input and applies his signature.
Broadcast: The transaction now has all required signatures and can be broadcast to the network.

Transaction Structure:

Input 0: Alice's UTXO.
Input 1: Bob's UTXO.
Output 0 (OP_RETURN): Alice's transfer instruction: {"p":"brc-20","op":"transfer","tick":"OPQT","amt":"100"}
Output 1 (Recipient): Bob's address, receiving the 100 OPQT.
Output 2 (OP_RETURN): Bob's transfer instruction: {"p":"brc-20","op":"transfer","tick":"ORDI","amt":"10"}
Output 3 (Recipient): Alice's address, receiving the 10 ORDI.

Indexer Logic: The Simplicity Indexer sees a valid, fully-signed Bitcoin transaction with multiple inputs. It processes the sequenced transfers as normal, debiting and crediting each party according to the OP_RETURN instructions. The swap's atomicity is cryptographically guaranteed by Bitcoin itself—the entire transaction either succeeds or fails, ensuring neither party can be cheated.

4. Operation Proposal Improvements (OPIs)

The Universal protocol is designed for structured evolution through a community-driven governance process known as Operation Proposal Improvements (OPIs). Inspired by established standards-track processes like Bitcoin Improvement Proposals (BIPs), OPIs provide a formal framework for proposing, debating, and integrating new features into the protocol.

An OPI defines a new operation ("op") or extends the interpretation of an existing one. This ensures the Universal protocol can adapt to new use cases without sacrificing its core principles of simplicity and security.

Purpose and Vision

The OPI process is designed to enable a rich ecosystem of functionalities directly on Bitcoin's base layer, including:

BRC-20 Harmonization: Standardizing interactions and bridges with other token protocols (e.g., OPI-000: no_return).
and more...

Proposing and ratifying an OPI follows a transparent, community-vetted lifecycle:

Drafting: An author forks the OPI repository, copies the template, and writes a detailed proposal.
Submission: The proposal is submitted as a pull request to the official OPI repository.
Community Review: The proposal undergoes public discussion and technical review from the community and core developers.
Ratification: Once consensus is reached, the OPI is approved, assigned a final number, and merged.
Implementation: The ratified OPI is integrated as a new set of consensus rules into the Simplicity Indexer, making it a live feature of the Universal protocol.

OPI-000: no_return

OPI-000 introduces the no_return operation, a standardized mechanism for migrating BRC-20 tokens from the Ordinals inscription standard to the Universal protocol.

This process functions as a one-way bridge. A user burns their Ordinal-based transfer inscription by sending it to Satoshi's Genesis address. The no_return operation in the same transaction signals this intent to the Simplicity Indexer, which then credits the equivalent token amount to the user's Universal protocol balance.

`no_return` Transaction Structure

Input #0	The user's UTXO containing a valid Ordinals BRC-20 `transfer` inscription.
Output #0	An `OP_RETURN` containing the `no_return` annotation.
Output #1	A standard output sending the Ordinal inscription to Satoshi's Genesis address, thereby burning it.

Upon validating a no_return transaction, the Simplicity Indexer reads the tick and amt from the Ordinal inscription and credits the Universal BRC-20 balance of the address that owned and spent Input #0. This creates a secure, verifiable, and one-way bridge from the Ordinals ledger to the Universal ledger.

5. Consensus Rules

The Simplicity Indexer MUST enforce the following rules to maintain a consistent global state. Any transaction violating these rules will be disregarded at the protocol layer.

Operation Binding: Each OP_RETURN operation is immutably bound to the first valid, non-OP_RETURN output that immediately follows it. The address of this output is the operation's recipient.
Payload Integrity: The OP_RETURN payload must be a valid, minified JSON object starting with {"p":"brc-20"}.
Size Constraint: The JSON payload must not exceed the 80-byte OP_RETURN data limit.
Namespace Uniqueness: A deploy operation is valid only if its tick has not been previously claimed on any valid BRC-20 standard (Ordinals or Universal).
Flexible Keys: The indexer must recognize "max" as an alias for "m" and "lim" as an alias for "l" in deploy operations.
Token Existence: mint and transfer operations must reference a validly deployed tick.
Supply & Limits: Operations must not violate the max supply or per-operation lim defined at deployment.
Sufficient Balance: A transfer is valid only if the sender's address, as identified by the input UTXOs, holds a sufficient balance according to the indexer's state.
Dust Limit: All standard Bitcoin outputs intended as recipients must meet the network's dust limit.

6. Security Considerations

Indexer Reliance: The Universal protocol state is an interpretation of on-chain data maintained by Simplicity-compliant indexers. The integrity of the system relies on the correctness and consistency of its indexers.
Critical Output Ordering: This is the most critical security consideration. The validity and destination of a token transfer are entirely dependent on the correct ordering of outputs. An OP_RETURN followed by the wrong output will result in tokens being sent to an unintended recipient. Wallet software and users must rigorously validate transaction structures.
Irreversible Operations: All valid Universal operations confirmed on the Bitcoin timechain are final. There is no mechanism to reverse a transaction sent to the wrong address or with an incorrect amount.

7. Best Practices & Optimization

Protection Against Accidental Burns: The Universal protocol's account-based model is its strongest safety feature. Balances are tied to addresses, not UTXOs. You cannot accidentally destroy your tokens by spending a UTXO for a normal Bitcoin transaction. As long as you control the private keys to an address, you retain full control of its tokens. A valid transfer operation is always required to move them.
Leverage Batching: For any scenario involving multiple recipients (e.g., exchange withdrawals, airdrops), use the multi-operation feature to dramatically reduce transaction fees and network load.
Minimize Payload Size: When deploying a token, use the shorter JSON keys (m, l) and a concise ticker to conserve bytes. This can be critical for fitting complex operations within the 80-byte limit.
Validate Before Signing: Always use a tool to decode and inspect the raw transaction before signing. Programmatically and manually verify that the OP_RETURN payloads and output ordering are exactly as intended.

8. Comparative Analysis: Universal vs. Ordinals

Criterion	Universal Protocol (OP_RETURN)	Ordinals Inscription Standard
Data Location	Compact JSON in `OP_RETURN` outputs	Data inscribed in SegWit witness scripts
State Tracking	Off-chain by Simplicity Indexer	Off-chain by an Ordinals-aware indexer
Multi-Recipient	Native support via sequenced `OP_RETURN`s	Complex; requires multiple, separate transfers
On-chain Footprint	Prunable; extremely efficient per operation	Larger due to witness data and script overhead
Transaction Cost	Significantly lower, especially for batch operations	Higher
Logic	Explicit: operation and destination are linked pairs	Implicit: logic is tied to the satoshi itself

9. Reference Implementation: The Simplicity Indexer

Simplicity is the official, production-ready reference implementation of the Universal Protocol. The source code and complete technical documentation are available in the project's GitHub repository.

Simplicity Indexer Repository: https://github.com/The-Universal-BRC-20-Extension/simplicity

10. Developer and Ecosystem Resources

The development of the protocol and its associated tools is managed openly within the main GitHub organization.

Main GitHub Organization: https://github.com/The-Universal-BRC-20-Extension

For indexing solutions, deployment guides, and comprehensive API documentation, developers can refer to resources provided by key infrastructure partners such as Blacknode.

Blacknode Technical Documentation: https://www.blacknode.co/docs

To follow the latest announcements, protocol updates, and participate in the community, please refer to the official communication channels.

Updates on X: https://x.com/theblacknode

Name		Name	Last commit message	Last commit date
Latest commit History 2 Commits
README.md		README.md

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Repository files navigation

The Universal Protocol & Simplicity Indexer

Introduction

Welcome to the Universal Protocol.

Table of Contents

1. Fundamental Concepts

The Account-Based Model: A Foundation of Safety

2. Operation Specifications

Deploy

Mint

Transfer

3. Multi-Operation Transactions (SOON)

Example 1: Standard Multi-Transfer (SOON)

Example 2: Atomic Deploy and Full-Supply Mint (SOON)

Example 3: Two-Party Atomic Swap (PSBT) (SOON)

4. Operation Proposal Improvements (OPIs)

Purpose and Vision

OPI-000: no_return

`no_return` Transaction Structure

5. Consensus Rules

6. Security Considerations

7. Best Practices & Optimization

8. Comparative Analysis: Universal vs. Ordinals

9. Reference Implementation: The Simplicity Indexer

10. Developer and Ecosystem Resources

About

Uh oh!

Releases

Packages

The-Universal-BRC-20-Extension/Protocol

Folders and files

Latest commit

History

Repository files navigation

The Universal Protocol & Simplicity Indexer

Introduction

Welcome to the Universal Protocol.

Table of Contents

1. Fundamental Concepts

The Account-Based Model: A Foundation of Safety

2. Operation Specifications

Deploy

Mint

Transfer

3. Multi-Operation Transactions (SOON)

Example 1: Standard Multi-Transfer (SOON)

Example 2: Atomic Deploy and Full-Supply Mint (SOON)

Example 3: Two-Party Atomic Swap (PSBT) (SOON)

4. Operation Proposal Improvements (OPIs)

Purpose and Vision

OPI-000: no_return

no_return Transaction Structure

5. Consensus Rules

6. Security Considerations

7. Best Practices & Optimization

8. Comparative Analysis: Universal vs. Ordinals

9. Reference Implementation: The Simplicity Indexer

10. Developer and Ecosystem Resources

About

Resources

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

`no_return` Transaction Structure

Packages