Navigating the Inscription Ecosystem with Consistent Protocol Practices

Greetings BNBChain community,

As the inscription ecosystem on BNBChain continues to expand, the need for consistent protocol practices becomes increasingly crucial. Currently, the industry is characterized by a fragmented landscape, with different projects employing varying approaches to inscription operations such as minting, transferring, and deploying. This inconsistency, coupled with the absence of standardized protocol guidelines, poses significant challenges for developers, users, and the overall growth of the inscription ecosystem.

To address these challenges and foster a more harmonious and interoperable inscription ecosystem, we propose the adoption of consistent protocol practices. These practices would provide a unified framework for inscription operations, enabling seamless interactions across projects, marketplaces, and user interfaces.

Benefits of Consistent Protocol Practices

Adopting consistent protocol practices would yield a multitude of benefits, including:

  1. Streamlined Developer Experience: Developers would benefit from a clear and consistent set of guidelines, reducing the learning curve and simplifying inscription integration into their applications.

  2. Enhanced User Experience: Users would experience a more consistent and intuitive experience across different inscriptions and marketplaces, simplifying their interactions and reducing the risk of errors.

  3. Greater Interoperability: Consistent protocols would enable seamless compatibility between inscriptions, enabling users to effortlessly transfer and exchange them across platforms.

  4. Strengthened Ecosystem Growth: A unified protocol landscape would foster a stronger and more vibrant inscription ecosystem, attracting developers and users alike.

Call to Action

We invite the entire BNBChain community to actively participate in shaping the future of consistent protocol practices for inscriptions. Your contributions are invaluable in ensuring a unified and interoperable inscription ecosystem on BNBChain.

Please join the forum discussion, share your thoughts and suggestions, and collaborate with us in crafting a standardized protocol framework that will propel the growth and adoption of inscriptions on the BNBChain network.

Together, we can navigate the inscription ecosystem with consistent protocol practices, unlocking its full potential and fostering a thriving innovation hub for blockchain applications and collectibles.


BNBINS: Fungible Token Management Tool


BNBINS is a CLI tool designed for the streamlined management of fungible tokens, referred to as “ticks,” on the BNB Chain. This tool caters to advanced users and developers, offering functionalities for deploying, minting, transferring, and finding tokens.


1. Deploy (Initialization)

Deploy a new fungible token on the BNB Chain.

Command: bnbins init-fungible


# Command structure
bnbins init-fungible <network> <protocol> <tick> <per_mint_amt> <mint_count> <start_height> <metadata.json>

# Example
bnbins init-fungible bsc BRC20 MYTOKEN 1000 5 1500000 ./metadata.json

BRC20 Deploy JSON:

  "p": "brc-20",
  "op": "deploy",
  "tick": "Token Name",
  "max": "21000000",
  "lim": "1000",
  "height": "12875017"
    "name": "Token Name",
    "desc": "Token Description",
    "image": "Token Image URL or Path",
    "decimals": Token Decimal Precision,
    "links": {
        "x": {
            "v": "Additional Link"
        "website": {
            "v": "Official Website URL"
        "discord": {
            "v": "Discord Link"
    "legal": {
        "terms": "Legal Terms and Conditions"

2. Mint

Mint new tokens for a specified tick.

Command: bnbins mint-fungible


# Command structure
bnbins mint-fungible <network> <protocol> <tick>

# Example
bnbins mint-fungible bsc BRC20 MYTOKEN

BRC20 Mint JSON:

  "p": "brc-20",
  "op": "mint",
  "tick": "ordi",
  "amt": "1000"

3. Transfer Fungible Tokens

Transfer a specified amount of a tick to another account.

Command: bnbins transfer-fungible


# Command structure
bnbins transfer-fungible <network> <protocol> <tick> <amount>

# Example
bnbins transfer-fungible bsc BRC20 MYTOKEN 500

BRC20 Transfer JSON:

  "p": "brc-20",
  "op": "transfer",
  "tick": "ordi",
  "amt": "100"

4. Find Tick

Search for a specific token ticker across a network and protocol.

Command: bnbins find-tick


# Command structure
bnbins find-tick <network> <protocol> <tick>

# Example
bnbins find-tick bsc BRC20 MYTOKEN

Open Consideration

Token Registry

Decision on whether to maintain the tick registry on-chain using a smart contract or off-chain via an indexer, affecting decentralization, transparency, scalability, and accessibility.


JSON Token Definition


    "name": "Token Name",
    "desc": "Token Description",
    "image": "Token Image URL or Path", // optional
    "decimals": Token Decimal Precision,
    "links": {
        "x": {
            "v": "Additional Link"
        "website": {
            "v": "Official Website URL"
        "discord": {
            "v": "Discord Link"
    "legal": {
        "terms": "Legal Terms and Conditions"

Default Storage: BNB Greenfield (indicates default storage location for JSON definition).


AllinsSwap Protocol Standard

Protocol Background

Due to the lack of common standard of inscription infrastructure in the BNB chain community, especially in bulk operations and operations made by contracts, users face compatibility issues across platforms and feel uncomfortable. Hence, we propose an inscription standard that engages users and applications to operate inscriptions safely. This solves the problem of incompatibility of various protocols in the current community, creating an environment that encourages people to build around and contribute to the ecosystem’s growth.

Operations Standard

In AllinsSwap protocol standard, all inscriptions start with “data:,” then the operation data.

The protocol includes two sections, the basic operations and the extended operations. The basic operations include the minimum set of operations that enable the inscriptions to be created and trade between users, including deploy, mint and transfer.

Basic operations

The deploy operation and mint operation are very common and are similar across different standards, just like in brc-20. For transfer operation, we have unified its format with the other two operations. Instead of using the inscription id(tx id) in calldata, users can explicitly specify the tick and amount they desired. This solves the current problem that inscriptions cannot be split.







Extended operations

Besides the above basic operations, we are proposing to add extended operations to AllinsSwap inscription protocol in order to add functionality. Besides these “atomic operations” like deploy, mint and transfer operations, users often operate inscriptions with high level applications, for example marketplaces and swaps.

Current inscription standards do not support high level operations, hence making these applications not achievable.

We are the first proposing to add the following as our extended operations to support AllinsSwap






Proxied operations

Besides initiating operations by the owner only, we propose a way that operations can be initiated from a proxy on behalf of the owner. The proxied operations can be initiated by an EOA address or Contract address when authorized by the owner, which can be one of the following circumstances

Contains a valid signature from the owner’s address

The owner’s address has previously executed an approval operation to the proxy’s address

Proxied operations initiated from contract can be done by sending an event. The following is an example


address indexed from,

address indexed to,

string indexed tick,

uint256 amt



All the above operations will be executed by AllinsSwap VM. Below shows the flow of how the protocol works.


I would suggest we first address the issue where people transfer op code mints. And how do we keep the system just and fair for all users


How do you think if we implement a shared library to enforce the op operations, like deploy, mint and transfer? just the solution I shared above? I`d like to hear your thoughts? of course, CLI may not be the best option.

1 Like

so when will this be online?

1 Like

personally i think the p shuold be like bsc20, so every thing can be swap here


Decentralized Inscription Indexer Node Network


As the BNBChain and other blockchain ecosystems continue to evolve into inscription, we face some common challenges:

  1. How to effectively manage and index inscription assets with a decentralized manner.
  2. How to improve the liquidity of many inscription assets.
    Currently, the management and liquidity of inscription assets are limited by centralized systems and incompatible protocols. To address these issues, we propose the creation of a decentralized inscription indexer node network and an omnichain inscription protocol.

Network Architecture:

  1. Decentralized and Permissionless: Anyone can join the network by running a node with a standard and same index algorithm, without needing special permission.
  2. Transparency: The operations and data of the network will be open and transparent, enhancing trust and security.
  3. Multi-chain Support: Supports opBNB as the main chain, while allowing the flow of inscription assets from other chains.

How to realize OmniChain Inscription Liquidity Using “Universe”

Establish “Universe” account nodes on different blockchains, which will act as bridges for cross-chain inscription asset transfers. Users simply transfer their inscription assets to the corresponding “Universe” node to execute cross-chain operations. Every cross-bridge asset has a unique token hash to be identified.
The workflow shows in the last section picture because i can only send one media in one post :frowning:

Benefits of the Proposal:

  1. Enhanced Liquidity of Inscription Assets: By supporting multi-chain operations, inscription assets can flow in a broader ecosystem, bringing more traffic and assets into opBNB inscription ecosystem.
  2. Strengthened Decentralization: A decentralized network structure reduces reliance on a single point, increasing the system’s resistance to attacks.
  3. Promoting Ecosystem Growth: By providing a more flexible and compatible solution, we attract more users and developers to the opBNB Chain.


A decentralized inscription protocol on BNB Chain, which can be integrated into the existing EVM ecosystem, with the goal of achieving decentralization and a more efficient trading model.

Inscriptions on EVM

Since the start of the brc-20 Experiment initiated by domo, the Bitcoin eco has begun to have a new narrative. Meanwhile, non-Bitcoin eco have also followed the hype of Inscription. In the past one or two months, similar inscription experiments have also been launched on EVM.

Inscriptions on EVM almost inscribe through call data, there are three conventional inscription formats.

  • Deploy:
  • Mint:
  • Transfer:


  • Over-relying on a centralized indexer, the indexer may have unpredictable errors.
  • Inscriptions are difficult to circulate, as different projects rely on different indexers to issue inscriptions, and there is no unified trading method.
  • The inscriptions are too single in form, and they lack novel issuance methods and trading modes.

Consider it

  • We can still use existing contracts on EVM, which can avoid centralized indexing.
  • Why not continue using ERC721 as a form of inscription? Although it looks a bit silly, it solves the problem of difficult circulation.
  • A more efficient trading model, we can trigger to make NFT-based inscription assets irreversibly converted to ERC20 assets at a certain point in time to improve trading efficiency. This idea is inspired by Atomicals protocol on BTC.

Building on the above, we built Inswap for EVM inscriptions to achieve decentralization and a more efficient trading experience.

How does Inswap work?

Inscription Format & Indexing

  • The operations of deploy, mint, transfer, and burn are all mapped to corresponding contract methods.
  • We will continue to use the conventional inscription format,after calling the contract, inscription logs would be generated through events. This ensures that the inscription can still be indexed in the conventional way.


  • Users can deploy either an Ins721 singleton or a pair of Ins721 and Ins20 binding contracts through the InsRegistry.
  • The fields of the inscription are mapped to the methods of the Ins721 and Ins20.


  • Every time an Ins721 is minted, the corresponding credits are recorded in the Ins20 contract.


  • Burning the Ins721 inscription will also mint the corresponding amount of Ins20 token.

Inscription Trading

  • Since inscriptions are in the form of NFTs, their trading is compatible with the existing NFT trading protocol, such as Seaport. Inswap implements inscription trading by integrating Seaport.
  • The inscription deployer can trigger a process that irreversibly converts NFT inscriptions to ERC20 assets at a certain point in time. These assets can then be traded on DEXes.
  • Displaying inscription content in SVG format is both novel and in line with trading habits for traders

More possibilities of Inswap

  • Recursive Inscriptions
    Ins721 can be repeatedly referenced as a component of any new inscription.

  • Redeploy on Inswap
    Existing EVM inscriptions can be migrated to Inswap using existing indexes.

6 Likes on-chain data platform aggregates token, nft, inscription and other data.
We provide the BSC chain’s inscription market section, support direct access to in the app to trade BSC’s Inscription, and provide BSC’s Inscription telegram bot and other functions.

We are also fortunate to witness the rapid development of BSC’s inscription market, among which has laid the infrastructure for the entire BSC’s inscription market.

Despite this, we think there are still some problems in BSC’s inscription market:

  1. Although has made great contributions, it lacks public event behavior of inscribed market contracts and standard definitions of these events. As a result, other platforms cannot participate in bsc’s inscription market. Whether other inscription market contract events could be included in, or’s own events are in a black box, make this matter very difficult. Lke this event:
  1. At present, bsc inscriptions face the same problem as ethscriptions inscriptions. The market can only transfer one mint inscription, and cannot perform separate transfers for token inscriptions, resulting in some expensive inscriptions being unable to be accepted by more users, such as bnbs, many novice users will find it too expensive per unit

  2. Currently, various BSC inscription protocol names are flying all over the sky, which is not conducive to user promotion and recognition, leading to significant confusion in the inscription market. When users trade, they also need to clearly know the name of the inscription protocol, etc.

From our perspective, we hope to have the following improvements:

  1. we hope that can disclose the event behavior of market contracts and jointly define specifications. We also hope that will also follow this rule so that everyone can be compatible with each other.

  2. Encourage the use of ethscriptions that have been defined and are currently accepted by many other links, including avalanche, polygon and other platforms.

  3. We encourage everyone to use the `bsc-20`` inscription protocol as much as possible, which is also easier to distinguish from other chain inscription markets such as brc20, erc-20, etc.


For your reference, you can view the original white paper content at this link: ZERO Inscription White Paper

We’ve also provided an example for implementing the fungible token asset protocol (zero-20) under this standard, you can find it in our site’s documentation

We have our official multi-chain marketplace launched already:, soon we will implement our inscription protocol on our platform.

ZERO Inscription White Paper

Simple Summary

A universal standard protocol for inscriptions, applicable across all chains, enhancing interoperability and functionality in the blockchain ecosystem.


The landscape of blockchain inscriptions, especially on EVM networks, is currently navigating through a phase of fragmentation and inconsistency. Various projects across these networks have adopted differing methodologies for key inscription activities, including minting, transferring, and deployment. This lack of uniformity, along with the absence of universally accepted protocol standards, presents significant challenges. It hinders not only the ease of development and user experience but also the overall progression and scalability of the inscription ecosystem.

Centralized indexing methods and the absence of a standardized approach to trading have further complicated the effective management and circulation of inscription assets. Furthermore, the current limited diversity in inscription formats not only restricts innovative issuance and trading mechanisms but also constrains the broader potential of decentralized applications (DApps) built on these platforms.

We propose the ZERO Inscription protocol, designed to standardize and unify operations across blockchains and enable on-chain inscription migration, thereby unlocking smart contract capabilities and broadening opportunities. This protocol not only addresses current limitations but also paves the way for innovative DApps, leveraging diverse inscription capabilities for a more dynamic blockchain ecosystem.


This document outlines a standard protocol for blockchain inscriptions, aiming to standardize the process for publishing various types of digital assets across blockchain networks. It seeks to unify fundamental inscription operations, making them universally applicable.


A standard and interoperable protocol that allows inscriptions on all chains to be integrable by various applications, including wallets, exchanges, and decentralized apps (dApps). This will unlock the flexibility by enabling seamless interaction between inscriptions and smart contracts.


To ensure the extendibility of the inscription protocol, we define a standard for the Asset. Under the asset category, multiple Protocols can be published. Each protocol possesses a unique set of Operations.

The advantage of this is to unlock the extendibility of ZERO protocol. For example, under the Non-Fungile Tokens asset category, we can publish ZERO-721 and ZERO-1155 protocols with their certain set of operations.

All inscriptions that follow the community-agreed standard will be interpreted by the indexer, each inscription is fit into some specific operation under a certain Asset type.

FIFO (First-In First-Out) Rule
All protocols under ZERO Inscription must adhere to the FIFO rule. If the sha256 hash value of the UTF-8 content of a ZERO Inscription is duplicated, subsequent inscriptions are deemed invalid. Indexers are advised to adjust the delay in syncing raw data from the chain to prevent misinterpretation due to chain reorg.

Inscription to Smart Contract Migration
All the protocols under ZERO Inscription should have the availability to migrate on-chain. This requires a migration protocol to interconnect inscription and smart contract seamlessly.

  • One can deposit the inscription asset to a unified address
  • The migration protocol should mint the equivalent amount of tokens through the regarding contract once the deposit transaction is confirmed
  • The depositor can withdraw the inscription by invoking the smart contract’s burn method at any time.

Cross Inscription Wrapping
The Cross Inscription Wrapping in the ZERO Inscription protocol enables seamless integration of assets from various blockchain inscription systems into ZERO’s ecosystem (erc-20, prc-20, bsc-20 etc…). This feature facilitates the conversion of external assets into a ZERO-compatible format, maintaining their inherent properties while allowing them to leverage the advantages of the ZERO ecosystem. The process involves a secure wrapping and unwrapping mechanism, ensuring compatibility and compliance with ZERO standards.

Handling Minting Fees in a Permissionless Ecosystem
In the ZERO Inscription protocol, deployment is designed to be both permissionless and free. However, we recognize a potential challenge: the risk of name squatting, where individuals could monopolize desirable names and set their own minting fees, thus undermining the ecosystem’s fairness.

To address this, before the community agrees on a more permanent solution, projects that wish to include minting fees will be subject to a whitelisting process. This will be managed by specific, trusted wallets controlled by the ZERO Inscription team. This interim measure is intended to ensure that only legitimate and value-adding projects are able to implement minting fees, thereby maintaining the integrity of the ecosystem until a more decentralized approach is developed.

Asset Categories
Fungible Tokens
Semi-Fungible Tokens
Non-Fungible Tokens

Operation Standard
Operations in the ZERO Protocol are derived from two blockchain sources: Transaction Data and Transaction Logs.

  • Transaction Data: Sent with transactions by Externally Owned Accounts (EOA), starting with “data:,” followed by operation data in JSON format.
  • Transaction Log: Produced by smart contracts, enhancing functionality like batch operations or advanced features like marketplaces.

The two fields z and p must exist for all protocol operations:

  • Field z: Represents the system scope
  • Field p: Represents the specific protocol

Transaction Data
In the ZERO Inscription protocol, all inscription content transmitted through transaction data should begin with “data:,” followed by the operation data in JSON format.
Each operation must clearly define its data with three key attributes for each field in the JSON data:

  • Key: The specific field key.
  • Required: Indicates whether the field is required for the operation.
  • Desc: Describes the business logic or purpose of the field.

Example - Defining the ZERO-20 Protocol’s Deploy Operation:
The following is an example of how to define the deploy operation for the zero-20 protocol:

data:,{"z": "zero", "p": "zero-20", "op": "deploy", "tick": "zero", "max": "210000000000", "lim": "10000", "ma": "0x0000000000000000000000000000000000000000", "mf": "0.01"}

Each parameter in this JSON structure is defined as follows:

Param isRequired Description
z Y System Scope: Indicates its part of the ZERO Inscription, must be lowercase, strictly to zero
p Y Protocol: zero-20, must be lowercase, strictly to zero-20
tick Y Tick: symbol of zero-20 with max length 20, only 26 alphabet letters and numbers are allowed, case-insensitive.
Eg. ZERO = zero
op Y Operation: deploy
max Y Token total supply (must be divisible by lim), limited to uint256
lim Y Limit Per Mint max%limit=0
ma N Mint Address: If set, only transactions to = ‘ma’ are valid mints. Must be used in conjunction with ‘mf’. If not set, only transactions where ‘txFrom=txTo’ are valid mints.
mf N Mint Fee: If set, only transactions with a value (decimal) = ‘mf’ are valid mints. Must be used in conjunction with ‘ma’. Can be set to 0.

Transaction Log
Incorporating transaction logs emitted by smart contracts can significantly enhance the protocol’s functionality. Each operation through the transaction log must identify the contract event, with detailed specifications required for each event.

Here’s an example of defining the zero-20 protocol contract transfer operation:

event zeroinscription_ftTransferForListing(
    bytes32 indexed z, // zero
    bytes32 indexed p // zero-20
    address indexed from,
    address indexed to,
    bytes32 id,
    uint256 amount


ZERO Inscription works as the layer zero that naturally support all assets for cross-chain transfer.


opBRC Inscription Protocol — An Innovation in Inscription Distribution Mechanisms


As the inscription ecosystem on the BNB Chain progresses, we are confronted with mounting challenges, particularly in the realm of equitable asset distribution. There exists an urgent necessity for a new inscription protocol that bolsters decentralization, enhances efficiency, and upholds fairness. The opBRC protocol emerges as a solution to these challenges, introducing a novel minting strategy—“Fair Mode.” The protocol has successfully deployed its DMT (Deploy, Mint, and Transfer) on the opBNB mainnet and, within a week of launch, reached a staggering total interaction volume of 150 million. For details, visit our [official website].

Evolution of Technology and opBRC Mechanics

  1. Inscription 1.0 (Following the BRC-20 Model): This model is set with a fixed total issuance; once the cap is reached, no additional minting is possible. It operates on a first-come-first-serve basis until the complete supply is minted.
  2. Inscription 2.0 (Resembling the Rune Inscription Model): This version is defined by a fixed minting duration wherein minting ceases at the end of a specified timeline, regardless of whether the total supply is exhausted or not. There is a cap on each mint, and the quantity minted within the period is final.
  • Inscription 1.0 laid the groundwork for standardization but faced efficiency issues when market conditions shifted, leading to an exhausted total supply and insufficient allocation flexibility.
  • Inscription 2.0 introduced a time-limited minting mechanism, offering unprecedented flexibility. However, despite mitigating some supply pressures, it failed to address fair division and equality of opportunity for users.

Inscription 3.0: opBRC Protocol

The core innovation of opBRC Inscription 3.0, shaped by a fixed total and duration, creates equitable minting opportunities. The mechanism fairly allocates the quantity with each mint, invigorating the market while reducing hesitant sentiment.

  • Fairness: Ensures all participants can mint under identical circumstances, thus preventing hoarding and waste of resources.
  • High Efficiency: Streamlines the interaction with the contract, enabling users to mint inscriptions directly within a specified limit without the need to consider market frenzies or resource wastage.

opBRC DMT Reference

opBRC Deploy JSON:

// Deploy
    "tick":"tick name",

opBRC Mint JSON:

    "tick":"tick name"

opBRC Transfer JSON:


opBRC adheres to a fair launch mechanism based on “average distribution,” ensuring no pre-mining or reservations to maintain the integrity of the issuance process. This configuration ensures that every user has an equal opportunity to participate.


OmniSmart — Omni-Chain Inscriptions, Breaking Boundaries


As the inscription ecosystem matures within blockchain ecologies such as the BNB Chain, the brc-20 inscription protocol, despite its popularity within the Bitcoin community, reveals centralized risks due to its inextensibility and reliance on off-chain indexers.

With the evolution of blockchain networks, emerging protocols like arc-20 and rune inscriptions have led to market confusion and asset fragmentation. For example, although Ethereum has seen the birth of various inscription protocols, they still encounter functional limitations and centralization, preventing their full potential in decentralized finance, social finance, and game finance applications.

In current blockchain inscription applications, we adhere to the core values of free minting and fair launches. We believe that in the BNB ecosystem and across the EVM ecosystem, the process of minting and distributing inscriptions should abandon reliance on off-chain indexers and harness the power of smart contracts to achieve true decentralization and fairness.

The OmniSmart protocol thus emerges, offering inscription services across public chains and ecosystems such as BNB Chain, opBNB Chain, Ethereum, Avalanche, Polygon, and Arbitrum. OmniSmart introduces a revolutionary concept of omni-chain intelligent inscriptions, shattering traditional boundaries to enable cross-chain circulation and management of inscriptions.

The Concept of Omni-Chain Intelligent Inscriptions

  1. Free Minting and Fair Launching
    Inscriptions should not be restricted by centralized systems. With current technology, free minting and fair launching can be achieved on BNBChain and other EVM-compatible chains through smart contracts. This removes issues of centralization and inconsistency and enables decentralized custody of assets—enhancing their composability and laying the groundwork for the development of future applications in DeFi, SocialFi, GameFi, and more.

  2. Consensus Building and Value Pursuit
    We recognize that the core value of blockchain is in the formation of consensus—the greater the consensus, the greater the value. However, the varying playstyles of different inscription protocols and their dispersion across various chains have led to market chaos and fragmentation. We aim to unify consensus, standardize practices, and, in doing so, support the interoperability of multi-chain systems and the diversity of playstyles. OmniSmart’s smart contracts are structured hierarchically to manage cross-chain functions, protocol management, and namespaces, ushering in an unprecedented new chapter in inscription minting and asset interaction.


  1. Multi-Chain Consensus Support
    Our omni-chain intelligent inscription strategy enables the same inscription tick to be minted synchronously across different chains, uniting user consensus on specific inscriptions and thereby enhancing their inherent value.

  2. Multi-Protocol Extensibility
    Our architecture and protocol design fosters the continual evolution of play mechanics, aiming to build an ecosystem filled with vitality and long-term growth potential.

  3. Composability of Decentralized Smart Contracts
    Through smart contracts, we endow the inscription ecosystem with unprecedented flexibility and transparency. The seamless interaction between inscriptions, ERC-20, ERC-721, and other asset forms lays a solid foundation for building a more comprehensive range of applications on BNBChain.

Detailed Contract Architecture

  1. Implementing Cross-Chain Inscriptions Using LayerZero or ChainLink’s CCIP Messaging

  2. Three-Layer Smart Contract Structure:
    2.1 Consensus Layer, the Registry Contract, takes charge of cross-chain operations and protocol management, acting as the domain for tick name management and ensuring the integrity and stability of interactions across the chain.
    2.2 Protocol Layer, the Protocol Contract, outlines various inscription play mechanics and minting mechanisms, serving as the metaphorical foundry where assets come into existence. Each playstyle is represented by a distinct smart contract.
    2.3 Application Layer, the Inscription Instance Contract, supports the transformation of inscriptions, ERC-721 NFTs, and ERC-20 Tokens into one another. It is where actual assets are created and interact, skillfully controlling ERC-20 and ERC-721 assets while building new interactive asset instances atop them.

Taking the name “opbn” as an example, the following illustrates the flow of how the OmniSmart protocol works.

OmniSmart, with its structured three-layer architecture, not only unifies standards and consolidates consensus but also achieves extensibility and flexible evolution. It builds upon the advantages of existing inscription contracts while addressing their drawbacks. This layered contract framework allows inscription assets to traverse different chains and is governed by higher-level protocols, offering a grand inscription transaction system—providing flexibility and foundational tech support for the upgrade of the BNB inscription system.


Need more clarification on the InsRegistry contract, please explain why ins721 needs to be mapped to ins20? for which cases? Thanks

1 Like

A best universal standard protocol for inscriptions!!!

1 Like

Please share how the consensus is being built, and any specific logic?

1 Like

InsRegistry contract is used to manage inscriptions on Inswap. The operations of deploying, minting, transferring, and burning inscriptions are all mapped to corresponding methods within the InsRegistry contract.

When deploying inscriptions, you can choose to deploy a single ERC721 contract or a pair of linked ERC721 and ERC20 contracts. To provide a better trading experience for inscriptions, the deployer can set a rule to allow users to burn ERC721 and mint the corresponding amount of ERC20 token at a centain point after minting is complete.

In summary, inscription trading involves two stages. Initially, inscriptions on Inswap, being in NFT form, benefit from existing NFT trading protocols. Inswap facilitates inscription trading by integrating Seaport. Notably, the inscription deployer can trigger an irreversible process that converts NFT inscriptions to ERC20 assets at a predetermined point in time. Once converted, they become tradable on Dexes.

1 Like