Goldinals: A minimal-trust fungible token standard on Bitcoin
TechFlow Selected TechFlow Selected
Goldinals: A minimal-trust fungible token standard on Bitcoin
Bitcoin needs real programmability, not chaos.
Navigating Web3 tides with focused insightsAuthor: Techub Exclusive Analysis
Article by: Tia, Techub News
"Bitcoin needs real programmability, not chaos."
Currently, asset standards within the Bitcoin ecosystem are highly fragmented. Protocols such as BRC-20, Ordinals, and Runes operate independently with no interoperability. This situation forces users and wallet developers to handle complex formats and execution models.
Moreover, due to Bitcoin’s UTXO model involving locking and unlocking scripts—and the lack of a global state or Turing-complete programming environment like Ethereum—these protocols often rely on off-chain indexers to maintain state. For example, BRC-20, which emerged from the Ordinals protocol leveraging SegWit and Taproot to permanently store data without exceeding size limits, still fully depends on external indexers to maintain global token balance states. This increases operational costs and introduces trust risks. Goldinals, introduced by Nubit, was designed specifically to address these pain points.
Goldinals is a minimally trusted fungible token standard on Bitcoin, aiming to resolve the current lack of standardization in the Bitcoin asset ecosystem while preserving Bitcoin's decentralization and security. Through innovative technology and design, Goldinals offers Bitcoin users and developers an efficient and flexible method for token management. To achieve this goal, it makes significant technical and functional innovations, with its core requiring the construction of a zkOracle verified via BitVM.
On June 5, 2024, Nubit, the protocol behind Goldinals, raised $8 million in seed funding led by Polychain Capital, with participation from Nomad Capital, Spartan Group, L2IV, Big Brain Holdings, GCR, Protagonist, Gate Ventures, Animoca, and Mask Network. This latest round brings Nubit’s total funding to $12 million.
Ordinals, BRC-20, Runes, and Their Interoperability Issues
Ordinals
Ordinals allow users to inscribe arbitrary data—such as text, images, or other metadata—onto individual satoshis (sats), the smallest unit of Bitcoin, by leveraging SegWit and Taproot.
BRC-20
BRC-20 is a stateless Bitcoin token standard enabling token minting, transfers, and burning. Unlike Ethereum’s ERC-20, which is embedded in blockchain logic, BRC-20 is an “add-on” token standard implemented using Ordinals’ data storage capabilities. BRC-20 token operations (e.g., minting and transferring) use the Ordinals protocol to inscribe state information into Bitcoin transactions as JSON files. These JSON data define the token name, supply, and holder addresses.
Unlike Ethereum’s ERC-20, BRC-20 does not rely on a global blockchain state. Instead, it requires off-chain indexers to scan all relevant transactions and reconstruct the current token state. For instance, to query a specific address’s token balance, the indexer must read all historical transactions and calculate the balance accordingly.
Runes
Runes is a Bitcoin token protocol similar to BRC-20. Its core idea is embedding token states and operations directly into Bitcoin transactions, maintaining token state through analysis of Bitcoin’s UTXO (Unspent Transaction Output) model. Runes uses the OP_RETURN field or other standard fields in Bitcoin transactions to record token transfer and operation details. Each Rune token operation is completed via ordinary Bitcoin transactions.
Interoperability Issues
The implementation methods of these protocols differ significantly. Ordinals store information using data formats embedded in Bitcoin transactions, BRC-20 defines token states using JSON format, while Runes relies more heavily on Bitcoin’s UTXO model. These formats are mutually incompatible, meaning data stored under one protocol cannot be directly recognized or parsed by another.
Additionally, BRC-20 is a stateless implementation where all token states depend on external indexers for reconstruction, whereas Runes stores state directly on-chain via the UTXO model, and Ordinals focuses on tagging individual satoshis. These mechanisms lack a unified state management approach.
Different protocols define their own token formats and rules, making direct interaction or mutual support impossible. Goldinals resolves this interoperability dilemma by introducing a new standard compatible with Ordinals/Runes/BRC-20 that eliminates the need for off-chain indexers to maintain state.
Goldinals Core Design and Technical Implementation
Core functions of Goldinals include:
Deploy: Initialize protocol parameters and create a new token instance.
Mint: Mint new tokens and allocate them to designated addresses.
Transfer: Transfer tokens between addresses.
Burn: Destroy tokens and reduce supply.
Although functionally similar to ERC-20 and BRC-20, Goldinals' implementation is more complex due to Bitcoin’s stateless architecture and Turing-incomplete scripting language. Unlike Ethereum’s seamless atomic calls, Goldinals must carefully manage state updates and validation across multiple steps, ensuring all operations inherit Bitcoin’s security guarantees.
Goldinals State Machine and State Update Process
The Goldinals state machine consists of three main phases: Prepare, Kickoff, and Challenge.
Prepare Phase: Recording Operation Intent
In this phase, the sender submits their operation intent (e.g., transfer or mint) via a Bitcoin transaction, embedding relevant metadata into the transaction. The sender uses Bitcoin’s OP_RETURN field to record token operation parameters such as recipient address, amount, and operation type. This transaction is recorded on Bitcoin, ensuring transparency and immutability of the operation intent. A ZKOracle (a zero-knowledge proof-based state machine) scans Bitcoin blocks, extracts, and records Prepare transactions related to the Goldinals protocol, incorporating them into the global state.
Kickoff Phase: Validation and Operation Initiation
After the Prepare phase, the sender must submit a transaction containing a zero-knowledge proof (ZKP) to verify the operation’s legitimacy. The sender generates the ZKP off-chain, proving that the operation complies with protocol rules (e.g., sufficient balance, valid parameters). This proof is submitted to the Bitcoin network via a Kickoff transaction and validated by the ZKOracle. Successful completion of the Kickoff phase indicates the operation’s validity has been proven, but final confirmation awaits completion of the Challenge phase.
Challenge Phase: Review and Dispute
The Challenge phase is the core of the state machine design, providing a decentralized review mechanism to ensure operation legitimacy. During the challenge period, any participant (challenger) can dispute the submitted operation. For example, if the submitted ZKP violates protocol rules, the challenger can provide counter-evidence. Using BitVM’s interactive proof mechanism, the challenger engages in verification with the sender. If a flaw is detected, the challenger may submit an on-chain transaction to block confirmation. If no challenges arise during the challenge window, the operation is permanently confirmed, and the ZKOracle updates the global state of Goldinals accordingly.
Implementation Details: Transfers & Minting
Transfers
In a transfer operation, the sender first submits a Bitcoin transaction during the Prepare phase to record the transfer intent on-chain. The ZKOracle records and verifies this transaction. In the Kickoff phase, the sender submits a zero-knowledge proof demonstrating sufficient balance and rule compliance. During the Challenge phase, challengers verify whether the submitted proof and transaction adhere to protocol rules. If no disputes occur, the transfer is finalized, and the recipient’s balance is updated.
Minting
The minting process mirrors transfers. The sender submits a transaction containing minting parameters during the Prepare phase. In the Kickoff phase, they must provide a zero-knowledge proof verifying that the minting operation follows protocol rules (e.g., supply cap, allocation limits). During the Challenge phase, challengers assess whether the operation meets requirements. If unchallenged, the minting is confirmed.
Balance Queries
Users can utilize Bitcoin Core’s scanblocks command to scan all Prepare transactions associated with their address and check the final status of these transactions. This method allows users to verify their balances without relying on external indexers.
Conclusion
Compared to other protocols like BRC-20, Goldinals offers significant advantages. It eliminates reliance on external indexers—every validation is performed directly on the Bitcoin network—enhancing decentralization and freeing users from trusting third-party services. Furthermore, Goldinals streamlines transaction workflows, avoiding the cumbersome multi-transaction processes required by BRC-20 for single operations, thereby significantly reducing complexity and fees. Additionally, the integration of zero-knowledge proofs enables strong programmability, supporting multisig wallets, conditional transfers, and complex logic triggered by external events, greatly expanding the protocol’s applicability.
Equally important, Goldinals introduces a unified asset standard that integrates the functionalities and logics of existing protocols. Nubit is also building a specialized compiler that translates user-friendly code into optimized Bitcoin scripts, performing formal verification to mathematically ensure the integrity of each program.
Hanzhi, co-founder of Nubit, stated: "Bitcoin needs real programmability, not chaos." With robust foundations and standardized frameworks, the Bitcoin ecosystem can evolve from fragmentation toward interoperable, positive-sum innovation.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@News_Techub
