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, and protocols such as BRC-20, Ordinals, and Runes are independent of each other and lack interoperability. This situation results in users and wallet developers needing to deal with complex formats and execution models.

In addition, due to the UTXO operation model of Bitcoin's unlocking script and the script to be unlocked, it lacks the global state and Turing-complete programming environment like Ethereum. These protocols often rely on offline indexers to maintain state. For example, BRC-20, which was created by the Ordinals protocol using SegWit and Taproot to permanently store information without exceeding the size limit, still needs to rely entirely on off-chain indexers to maintain the global state of token balances. This increases operational costs and trust risks. Goldinals launched by Nubit was designed to solve these pain points.

Goldinals is a trust-minimized homogeneous token standard on Bitcoin, aiming to solve the problem of insufficient standardization in the current Bitcoin asset ecosystem while maintaining the decentralization and security of Bitcoin. Through innovative technology and design, Goldinals provides Bitcoin users and developers with an efficient and flexible way to manage tokens. In order 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 a US$8 million seed round of financing, led by Polychain Capital, Nomad Capital, Spartan Group, L2IV, Big Brain Holdings, GCR, Protagonist, Gate Ventures, Animoca, Mask Network, etc. Participating in the investment, the latest round of financing brings Nubit’s total funding to $12 million.

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

Ordinals

By leveraging SegWit and Taproot, Ordinals allows users to imprint arbitrary data (such as text, images, or other metadata) onto one of the smallest units of Bitcoin (satoshis, or sats for short).

BRC-20

BRC-20 is a stateless Bitcoin token standard used to implement the minting, transfer and destruction functions of tokens. BRC-20 is not embedded in the blockchain logic like Ethereum ERC-20, but is a "plug-in" token standard implemented through the data storage function of Ordinals. BRC-20's token operations (such as minting and transfer) use the Ordinals protocol to imprint status information into Bitcoin transactions in the form of JSON files. This JSON data defines the token's name, supply, and holder's address.

And BRC-20 does not rely on the global state of the blockchain like Ethereum ERC-20. Instead, it 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 an 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 operations of tokens into Bitcoin transactions and maintain the token status by analyzing Bitcoin's UTXO (Unspent Transaction Output) model. . Runes uses the OP_RETURN field or other standard fields of Bitcoin transactions to record token transfer and operation information. Every Rune Token operation is completed through a normal Bitcoin transaction.

interoperability issues

The above types of protocols are implemented in different ways. Ordinals use the data format embedded in Bitcoin transactions to store information, BRC-20 uses 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 for reconstruction, while the state of Runes is directly stored on the blockchain through the UTXO model, and Ordinals focus on the token of a single satoshi. These mechanisms cannot share a unified way of managing state.

Different protocols define their own token formats and rules, and cannot directly interact 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 : Initialize protocol parameters and create new token instances.

• Mint : Mint new tokens and distribute them to specified addresses.

• Transfer : Transfer tokens between addresses.

• Burn : Destroy tokens and reduce supply.

Although similar to ERC-20 and BRC-20, the implementation of Goldinals is more complex due to Bitcoin's stateless design and Turing-incomplete scripting language. Unlike Ethereum’s seamless atomic calls, Goldinals requires state updates and verifications to be carefully managed in multiple steps, ensuring that all operations inherit the security of Bitcoin.

Goldens state machine and specific state update process

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

Prepare stage: record operation intention

In this phase, the sender of the operation submits the intent of the operation (such as transferring or minting) via 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, ensuring transparency and immutability of the intent of the operation. ZKOracle (zero-knowledge proof state machine) scans Bitcoin blocks, extracts and records Prepare transactions related to the Goldinals protocol, and incorporates them into the global state.

Kickoff phase: Verify and launch 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 via a Kickoff transaction and verified by ZKOracle. The successful execution of the Kickoff phase indicates that the legality of the operation has been proven, but the operation has not yet been finalized and needs to wait for the Challenge phase to be completed.

Challenge Phase: Review and Objection

The Challenge phase is the core of the state machine design and aims to provide a decentralized review mechanism to ensure the legality of operations. During the challenge period, any participant (challenger) can dispute the submitted operation. For example, if the submitted zero-knowledge proof does not comply with the rules, the challenger can provide counter-evidence. The challenger interacts with the sender for verification based on the interactive proof mechanism provided by BitVM. If a problem is discovered, the challenger can submit an on-chain transaction blocking operation confirmation. If there are no objections 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 & casting

transfer

In the transfer operation, the sender first submits a Bitcoin transaction through the Prepare stage 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 proofs and transactions comply with the protocol rules. If there is no challenge, the transfer is eventually confirmed and the balance of the recipient address is updated.

casting

The minting process is similar to transferring money. The sender submits a transaction containing minting parameters during the Prepare phase. Later 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 distribution limits). In the Challenge phase, the challenger verifies whether the operation meets the conditions. If there is no objection, the casting 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 Bitcoin Core's scanblocks command. With this approach, users do not need to rely on external indexers to verify their balances.

Conclusion

Goldinals has significant advantages compared to other protocols such as BRC-20. It abandons dependence on external indexers and all verification is done directly through the Bitcoin network, which not only improves decentralization but also frees users from trusting third-party services. In addition, Goldinals' transaction process is more efficient, avoiding the cumbersomeness of BRC-20 that requires 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 proof, Goldinals has strong programmability and can support multi-signature wallets, conditional transfers and complex logic triggered by external events, broadening the scope of application of the protocol.

At the same time, it is very important that Goldinals introduces a unified asset standard in the design, integrating the functions and logic of existing protocols. Nubit is also building a special compiler that converts user-friendly code into optimized scripts for Bitcoin, along with 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.