Propose new BIP for Programmable Bitcoin Token Standard (PBTS) #1787
Conversation
| ``` | ||
| BIP: XXXX | ||
| Layer: Applications | ||
| Title: Programmable Bitcoin Token Standard (PBTS) |
There was a problem hiding this comment.
This title clashes with "PSBTs" and will lead to confusion should this BIP get adopted. Would you be open to considering a different name?
There was a problem hiding this comment.
Agree, it is too similar in naming to PSBTs.
There was a problem hiding this comment.
Thank you for your feedback! We recognize the potential confusion with PSBT (Partially Signed Bitcoin Transactions). To avoid this, we have renamed PBTS to TSB (Token Standard on Bitcoin). This ensures clarity and better represents the proposal's goal: establishing a unified standard for Bitcoin-native tokens.
|
|
||
| Bitcoin adheres to the principles of **minimalism and security**, which have made it the most robust and decentralized blockchain. PBTS aligns with this philosophy by introducing **programmability without complexity**, ensuring that Bitcoin's core remains unchanged while extending its utility in a predictable and efficient way. | ||
|
|
||
| Bitcoin currently lacks a **native** token standard that enables **flexible** and **fully Layer 1** token issuance with programmable conditions. Existing solutions such as **Ordinals, RGB, and Runes** either rely on **external tracking mechanisms** or **Layer 2 solutions** that introduce centralization risks. PBTS provides a **UTXO-based**, predefined, and non-intrusive method for issuing tokens that remain completely **verifiable on Bitcoin's base layer** with advanced programmable features like time-locked vesting and milestone-based escrow. |
There was a problem hiding this comment.
In the Motivation, could you please expand on the issue this proposal addresses and how this proposal improves Bitcoin? It’s not obvious to me how a token standard improves Bitcoin.
It is an open question whether colored coin protocols and other token schemes are on-topic for this repository.
There was a problem hiding this comment.
The Token Standard on Bitcoin (TSB) directly improves Bitcoin in several ways:
First, TSB addresses existing blockchain bloat and efficiency issues. Token activities already occur on Bitcoin through methods like Ordinals/BRC-20, which store excessive data and consume block space inefficiently. By implementing an optimized standard with Taproot-optimized transactions and efficient UTXO management, TSB reduces this bloat, decreasing overall transaction costs and resource requirements for running full nodes—benefiting all Bitcoin users.
Second, TSB strengthens Bitcoin's security model. Current token implementations often require centralized indexers or off-chain validation, introducing new trust assumptions into Bitcoin's ecosystem. TSB ensures all token validation occurs on-chain using Bitcoin Script, making tokens fully verifiable by any Bitcoin node without specialized software or external dependencies. This preserves Bitcoin's trustless nature even as token usage grows.
Third, TSB expands Bitcoin's utility without requiring consensus changes. By enabling programmable token functionality through existing Bitcoin Script capabilities, TSB increases Bitcoin's relevance and competitiveness against alternative blockchains that offer token functionality. This helps preserve Bitcoin's network effects and value proposition in the broader cryptocurrency ecosystem.
Regarding repository relevance: TSB standardizes how Bitcoin transactions are structured and validated for token operations, similar to how other BIPs standardize transaction formats and script execution. As token activity already exists on Bitcoin, providing a standard implementation path for wallets, exchanges, and nodes aligns with the BIP process's goal of improving Bitcoin's protocol-level standards and interoperability.
There was a problem hiding this comment.
for additional information to expand on the Bip
-
Ecosystem Fragmentation
The Bitcoin token ecosystem is currently highly fragmented with multiple competing standards:
Ordinals/BRC-20 use inscription-based approaches that are inefficient and difficult to scale
RGB utilizes client-side validation that's hard to integrate with existing Bitcoin infrastructure
Runes and similar proposals use different methodologies for tracking ownership
Colored Coins introduced early approaches that lacked standardization
This fragmentation creates several critical problems:
Developers must build separate infrastructure for each token standard
Wallets need custom implementations to support different token types
Token interoperability is nearly impossible between standards
Users face a confusing experience with inconsistent token behaviors
Liquidity becomes fragmented across multiple token ecosystems -
Limited Expressivity and Programmability
Current Bitcoin token solutions offer extremely limited programmability:
Most existing token standards can only perform simple transfers
Complex conditional logic (vesting schedules, escrow, etc.) is difficult or impossible
Business logic requiring multi-stage releases can't be encoded on-chain
Token behaviors can't adapt to external conditions or time-based parameters
Developers are forced to implement business logic off-chain, reducing security -
Off-Chain Dependency Risks
Many token standards require external systems for validation:
Reliance on centralized indexers creates single points of failure
External validation layers introduce additional trust assumptions
Potential for censorship or manipulation by indexer operators
Scaling challenges when indexers must process high transaction volumes
Token validity can't be independently verified by standard Bitcoin nodes
How PBTS Improves Bitcoin -
Enhanced Utility Through Expressivity
PBTS dramatically increases what's possible with Bitcoin tokens:
Programmable token behavior
Time-locked vesting
Milestone-based releases
Oracle integration
Multi-signature governance
All this additional expressivity remains within Bitcoin's secure, deterministic execution environment - providing predictability without the risks of Turing-complete smart contracts. -
Unifying the Token Ecosystem
PBTS creates a universal foundation for Bitcoin-based tokens:
Provides a common language and interface for all token applications
Creates consistent standards for wallet integration and user experience
Enables interoperability between different token implementations
Consolidates development resources around a single robust standard
Encourages ecosystem-wide innovations rather than siloed development
Similar to how ERC-20 standardized Ethereum's token ecosystem in its early days, PBTS could create a coherent framework for Bitcoin's token economy. -
True Layer 1 Security and Validation
PBTS ensures that tokens benefit from Bitcoin's full security model:
Complete validation directly through Bitcoin Script execution
No external dependencies for determining token validity or ownership
Token rules enforced by standard Bitcoin consensus mechanisms
Fully verifiable by any Bitcoin node without specialized software
Resistant to censorship or manipulation by indexer operators -
Efficiency and Scalability Optimizations
The proposal emphasizes Bitcoin-compatible efficiency:
Taproot optimization significantly reduces transaction sizes
Structured script templates minimize blockchain bloat
Compatibility with future Bitcoin scaling solutions
Efficient batching capabilities for token operations -
Future-Proof Design
Applications built on a well-designed standard would remain compatible with future Bitcoin protocol improvements.
By providing a standardized, expressive, and secure token framework that operates entirely within Bitcoin's existing security model, PBTS creates a foundation for a robust token ecosystem that enhances Bitcoin's utility without compromising its core principles or requiring consensus changes.
| 1. **Token Issuance Format**: | ||
| * The output script is a Taproot output that contains: | ||
| * Token ID: A 32-byte identifier (Hash of Issuer's Public Key + Script Hash) | ||
| * Total Supply: Fixed integer representing the maximum possible supply | ||
| * Decimals: Integer representing the decimal places (typically 8 to match satoshis) | ||
| * Metadata Commitment: Optional hash of off-chain metadata (name, symbol, description) |
There was a problem hiding this comment.
You claim that no consensus change is necessary, but it is not clear to me how the special meaning of this new output type is supposed to be enforced without new consensus rules. Could you perhaps clarify this point?
There was a problem hiding this comment.
How TSB Functions Without Consensus Changes
TSB leverages existing Bitcoin protocol features—specifically Taproot and Bitcoin Script—to create and enforce token rules without requiring any modifications to Bitcoin's consensus layer:
-
Script-Based Enforcement Rather Than Protocol-Level Rules
TSB tokens are encoded and validated entirely through standard Bitcoin transactions and scripts:
Token Creation: Tokens are created by crafting Taproot outputs with specific script structures that encode token metadata and rules.
Token Transfer: When transferring tokens, spending conditions are enforced through script execution during regular transaction validation.
Supply Constraints: Total supply rules are maintained through carefully structured scripts that prevent unauthorized token creation. -
Commitment-Based Verification
TSB uses Taproot's commitment structure to enforce token rules:
When a token is created, its properties (ID, supply, metadata) are committed to in the Taproot output.
Any future transfers must adhere to these commitments to be considered valid token transactions.
These commitments are verified using standard Bitcoin Script operations that already exist. -
Wallet-Level Implementation
Like other application-layer protocols on Bitcoin:
Specialized wallets recognize TSB token patterns and create compliant transactions
Token validation occurs within standard Bitcoin Script execution
No changes to Bitcoin nodes or mining software are required -
Why This Isn't A Consensus Change
Bitcoin nodes will continue to validate transactions using existing rules:
No new opcodes are required
No changes to transaction validation logic
No modifications to block validation
The key insight is that TSB doesn't require the Bitcoin protocol to "understand" tokens specifically. It just requires that Bitcoin continues to enforce its existing script validation rules, which TSB leverages to create token-like behavior through carefully designed transaction patterns.
| 1. **Standard Transfer**: | ||
| * Spends from a token UTXO | ||
| * Creates new outputs with token metadata preserved | ||
| * May split tokens across multiple outputs (for partial transfers) |
There was a problem hiding this comment.
I seem to be missing something. How are these transactions fashioned to enforce adherence to the token supply limit?
There was a problem hiding this comment.
How TSB Enforces Adherence to the Token Supply Limit
TSB ensures strict token supply limits by leveraging Taproot script commitments and UTXO-based validation. Since Bitcoin enforces its own transaction rules at the protocol level, TSB integrates supply constraints directly into Bitcoin’s consensus layer, preventing unauthorized token creation.
- Fixed Supply Commitment at Issuance
The total token supply is permanently committed at the time of issuance. This is embedded in the Taproot output, ensuring that no additional tokens can ever be created.
Token Issuance Script (Genesis Commitment)
TSB Token Genesis Script
<token_metadata_hash> OP_DROP
<issuer_pubkey> OP_CHECKSIG
How this enforces the supply limit:
The token’s metadata hash includes the total supply, ensuring it is fixed and immutable.
The issuer’s public key controls initial distribution, preventing unauthorized issuance.
The supply limit is enforced within the Taproot output, making it part of Bitcoin’s consensus rules.
- Enforcing Supply Conservation in Transfers
TSB tokens must originate from an existing UTXO that references the original issuance, ensuring that no new tokens can be introduced.
Token Transfer Validation Script
TSB Token Transfer Script (Preserving Supply)
<token_metadata_hash> OP_DROP
<prev_utxo_commitment> OP_CHECKSIGVERIFY
<receiver_pubkey> OP_CHECKSIG
How this maintains supply integrity:
Tokens can only be spent if they reference a valid prior UTXO, preventing unauthorized creation.
The script ensures that ownership is transferred while preserving the original issuance constraints.
Bitcoin’s UTXO model inherently prevents overspending, enforcing a strict conservation principle.
- Preventing Inflation in Multi-Output Transactions
When splitting tokens across multiple recipients, TSB scripts ensure that the sum of the outputs exactly matches the input, preventing supply inflation.
Multi-Output Conservation Script
Ensuring Token Outputs Sum to Input
<token_metadata_hash> OP_DROP
<input_utxo_amount>
<output1_amount> <output2_amount> OP_ADD
OP_EQUALVERIFY # Ensures total outputs = inputs
<receiver_pubkey> OP_CHECKSIG
Why this prevents excess token creation:
The sum of all token outputs must always match the input amount.
Any attempt to create excess tokens fails validation before confirmation.
Bitcoin’s consensus rules reject transactions that do not satisfy these conditions, ensuring strict supply enforcement.
- Leveraging Taproot for Efficient Supply Enforcement
TSB utilizes Taproot’s Merkleized script structure to ensure supply constraints remain intact while allowing flexible spending conditions.
Taproot Spending Paths for TSB Tokens
{
Path 1: Standard Transfer
<token_metadata_hash> <prev_utxo_commitment> OP_CHECKSIGVERIFY <receiver_pubkey> OP_CHECKSIG,
Path 2: Expiry Condition (Reclaim Unspent Tokens)
OP_CHECKLOCKTIMEVERIFY OP_DROP <sender_pubkey> OP_CHECKSIG
}
How Taproot optimizes enforcement:
Only authorized transactions can modify token ownership, ensuring strict adherence to supply constraints.
Unused tokens can be reclaimed if they remain unspent for a predefined period.
All transactions inherit issuance rules cryptographically, preventing supply violations.
TSB ensures token supply limits are enforced natively within Bitcoin’s consensus rules. By embedding constraints in Taproot commitments, Bitcoin Script validation, and the UTXO model, TSB eliminates the need for external tracking. Every transaction must reference prior UTXOs, enforcing strict supply conservation at the protocol level.
This guarantees a fully Bitcoin-native token system where supply constraints cannot be bypassed, altered, or inflated, ensuring long-term security and stability.
|
As I read it, this proposal is either a client-side validation scheme or requires a consensus change (or both), while claiming to be neither. The latter contradiction makes the comparison with existing schemes seem skewed. Especially, it is not at all obvious why this n-th standard for tokens is supposed to obsolete all others. This proposal should be improved to clarify what it is trying to achieve and how it is achieving that. There seems to be an underlying misunderstanding either about how consensus works or what mechanisms are necessary to achieve enforcement and validation as described in this document. I would appreciate it if future responses to questions were more to the point. The prior responses mostly repeat claims from the proposal, but barely appear address the main gist of my questions. Just because other networks have allowed themselves to be fully cannibalized by tokenization and the ensuing speculation and gambling, it is by no means obvious to me how tokens improve Bitcoin. |
This pull request introduces a new Bitcoin Improvement Proposal (BIP):
Programmable Bitcoin Token Standard (PBTS)
PBTS provides a Layer 1 token standard leveraging Bitcoin Script and Taproot to enable the creation, transfer, and verification of native programmable tokens directly on Bitcoin. It introduces structured programmability without requiring changes to Bitcoin’s consensus rules.
Key Highlights:
Full details are available in the proposed BIP markdown file:
Feedback, suggestions, and discussion are welcome.