Goldinals: A Trust-Minimized Fungible Token Standard on Bitcoin

Author: Techub exclusive interpretation

Written by: Tia, Techub News

“Bitcoin needs true programmability, not chaos.”

Currently, asset standards in the Bitcoin ecosystem are highly fragmented, with protocols such as BRC-20, Ordinals, and Runes being independent of each other and lacking interoperability. This situation has caused users and wallet developers to have to deal with complex formats and execution models.

In addition, due to the UTXO operation model of Bitcoin unlocking scripts and to-be-unlocked scripts, and the lack of global state and Turing-complete programming environment like Ethereum, these protocols often rely on offline indexers to maintain the state. For example, the Ordinals protocol uses SegWit and Taproot to permanently store information without exceeding the size limit, resulting in BRC-20, which still needs to rely entirely on off-chain indexers to maintain the global state of token balances. This increases operating costs and trust risks. The original intention of Goldinals launched by Nubit is to solve these pain points.

Goldinals is a trust-minimized homogeneous token standard on Bitcoin, designed to address the lack of standardization in the current Bitcoin asset ecosystem while maintaining Bitcoin's decentralization and security. Through innovative technology and design, Goldinals provides Bitcoin users and developers with an efficient and flexible way to manage tokens. To achieve this goal, it has made important innovations in technology and functional design, the core of which is the need to build a zkOracle for Bitcoin and verify it through BitVM.

On June 5, 2024, Nubit, the development protocol behind Goldinals, completed an $8 million seed round of financing, led by Polychain Capital, with participation from Nomad Capital, Spartan Group, L2IV, Big Brain Holdings, GCR, Protagonist, Gate Ventures, Animoca, Mask Network and others. The latest round of financing brings Nubit's total financing to $12 million.

Ordinals, BRC-20, Runes, and their lack of interoperability

Ordinals

Ordinals uses SegWit and Taproot to allow users to engrave arbitrary data (such as text, images, or other metadata) onto the smallest unit of Bitcoin (satoshis, or sats for short).

BRC-20

BRC-20 is a stateless Bitcoin token standard that implements the minting, transfer, and destruction of tokens. BRC-20 is not embedded in the blockchain logic like Ethereum ERC-20, but is an "external" token standard implemented through the data storage function of Ordinals. BRC-20 token operations (such as minting and transfer) are implemented through the Ordinals protocol, which engraves state information into Bitcoin transactions in the form of JSON files. These JSON data define the name, supply, and holder address of the token.

And unlike Ethereum ERC-20, BRC-20 does not rely on the global state of the blockchain, but requires an off-chain indexer to scan all relevant transactions and reconstruct the current state of the token. For example, to query the token balance of a certain address, the indexer needs to read all historical transactions and calculate the balance.

Runes

Runes is a Bitcoin token protocol similar to BRC-20. Its core idea is to embed the status and operation of tokens into Bitcoin transactions and maintain the status of tokens by analyzing Bitcoin's UTXO (unspent transaction output) model. Runes uses the OP_RETURN field or other standard fields of Bitcoin transactions to record the transfer and operation information of tokens. Each Rune token operation is completed through a normal Bitcoin transaction.

Interoperability issues

The above protocols are implemented in different ways. Ordinals uses the data format embedded in Bitcoin transactions to store information, BRC-20 uses the JSON format to define token status, and Runes relies more on Bitcoin's UTXO model. These formats are incompatible with each other, resulting in data stored in one protocol not being directly recognized and parsed by another protocol.

Moreover, BRC-20 is a stateless implementation, and all token states rely on external indexers to rebuild, while the state of Runes is directly stored on the blockchain through the UTXO model, and Ordinals focuses on the mark of a single satoshi. These mechanisms cannot share a unified state management method.

Different protocols define their own token formats and rules and cannot interact directly or support each other to achieve interoperability.

Goldinals solves the interoperability dilemma of incompatibility between different standards by introducing a new standard that is compatible with Ordinals/Runes/BRC-20 and does not require an off-chain indexer to maintain state.

Goldinals core design and technical implementation

Goldinals' core features include:

• Deploy : Initializes protocol parameters and creates a new token instance.

• Mint : Mint new tokens and distribute them to the specified address.

• Transfer : Transfer tokens between addresses.

• Burn : Destroy tokens and reduce the supply.

Although similar to ERC-20 and BRC-20, Goldinals is more complex to implement due to Bitcoin’s stateless design and Turing-incomplete scripting language. Unlike Ethereum’s seamless atomic calls, Goldinals requires careful management of state updates and verifications in multiple steps to ensure that all operations inherit Bitcoin’s security.

Goldinals state machine and specific state update process

The Goldinals state machine consists of three major phases: Prepare, Kickoff, and Challenge.

Prepare phase: record the operation intention

At this stage, the sender of the operation submits the operation intention (such as transfer or minting) through a Bitcoin transaction and embeds the relevant metadata into the transaction. The sender uses Bitcoin's OP_RETURN field to record the parameters of the token operation, such as the receiving address, amount, and operation type. This transaction is recorded in Bitcoin to ensure the transparency and immutability of the operation intention. ZKOracle (zero-knowledge proof state machine) scans the Bitcoin block, extracts and records the Prepare transaction related to the Goldinals protocol, and incorporates it into the global state.

Kickoff Phase: Verification and Startup Operations

After the Prepare phase is completed, the sender needs to submit a transaction containing a zero-knowledge proof to verify the legitimacy of the operation. The sender generates a zero-knowledge proof (ZKP) off-chain to prove that its operation complies with the protocol rules (such as sufficient balance and legal operation parameters). This proof is submitted to the Bitcoin network through a Kickoff transaction and verified by the ZKOracle. The successful execution of the Kickoff phase indicates that the legitimacy of the operation has been proven, but the operation has not yet been finalized and needs to wait for the Challenge phase to complete.

Challenge Phase: Review and Objection

The Challenge phase is the core of the state machine design, which aims to provide a decentralized review mechanism to ensure the legitimacy of the operation. During the challenge period, any participant (challenger) can raise objections to the submitted operation. For example, if the submitted zero-knowledge proof does not comply with the rules, the challenger can provide counter-proof. The challenger conducts verification interaction with the sender based on the interactive proof mechanism provided by BitVM. If a problem is found, the challenger can submit an on-chain transaction to block the operation confirmation. If there is no objection during the challenge period, the operation will be permanently confirmed and updated to the global state of Goldinals by ZKOracle.

Implementation details such as transfer & minting

transfer

In the transfer operation, the sender first submits a Bitcoin transaction through the Prepare phase to record the token transfer intention on the chain. ZKOracle records and verifies the transaction. In the Kickoff phase, the sender submits a zero-knowledge proof to prove that its balance is sufficient and the operation complies with the rules. In the Challenge phase, the challenger can verify whether the submitted proof and transaction comply with the protocol rules. If there is no challenge, the transfer is finally confirmed and the balance of the recipient's address is updated.

Casting

The minting process is similar to transferring money. The sender submits a transaction containing minting parameters in the Prepare phase. Then in the Kickoff phase, the sender needs to provide a zero-knowledge proof to verify that the minting operation complies with the rules set by the protocol (such as supply caps and allocation restrictions). In the Challenge phase, the challenger verifies whether the operation meets the conditions. If there is no objection, the minting operation is finally confirmed.

Balance Inquiry

Users can scan all Prepare transactions related to their addresses and check the final status of these transactions through the Bitcoin Core scanblocks command. In this way, users can verify their balances without relying on external indexers.

Conclusion

Compared with other protocols such as BRC-20, Goldinals has significant advantages. It abandons the reliance on external indexers, and all verifications are completed directly through the Bitcoin network, which not only improves the degree of decentralization, but also frees users from trusting third-party services. In addition, Goldinals' transaction process is more efficient, avoiding the tediousness of BRC-20 requiring multiple Bitcoin transactions to complete a single operation, thereby significantly reducing complexity and transaction fees. At the same time, through the introduction of zero-knowledge proofs, Goldinals has extremely strong programmability, can support multi-signature wallets, conditional transfers, and complex logic based on external event triggers, broadening the scope of application of the protocol.

At the same time, it is very important that Goldinals introduces a unified asset standard in its design, integrating the functionality and logic of existing protocols. Nubit is also building a special compiler that converts user-friendly code into optimized scripts for Bitcoin, while performing formal verification to mathematically check the integrity of each program.

Nubit co-founder Hanzhi said: "Bitcoin needs true programmability, not chaos." With a strong foundation and standards, the Bitcoin ecosystem will move from chaos to interoperable positive-sum innovation.