Background
The RGB++ protocol significantly enhances Bitcoin’s functionality by introducing Turing-complete scripts for each UTXO, transforming Bitcoin from a simple value transfer system into a dynamic platform for complex financial instruments and digital contracts. This advancement is facilitated through RGB++'s decentralized client-side-validator and an isomorphic binding scheme, enabling seamless interoperability between Bitcoin’s L1 and L2 (CKB and UTXO Stack) solutions.
Unlike Ethereum’s account-based programming model, the RGB++ programming model, which is based on UTXO and isomorphic binding (IB), requires a more nuanced design approach. This article will provide several examples of programming on Bitcoin Layer 1, assisting developers in conceptualizing and constructing native Bitcoin applications. By leveraging RGB++'s unique capabilities, developers can explore innovative ways to harness Bitcoin’s infrastructure for creating complex, decentralized applications that go beyond simple transactions, opening a pathway to a diverse ecosystem of digital assets and smart contracts on Bitcoin’s network.
Native Bitcoin oracle
Within the programmable layer of RGB++, there exists a Bitcoin SPV light client that maintains information about Bitcoin block headers. This light client serves as an oracle to enable greater programming flexibility.
With this SPV oracle, the smart contract could access and verify the information on Bitcoin, which includes historical transaction records, block difficulty, hashrate, block height, time stamp, and details for current transaction. This last piece of information is especially important as it can be used to impose constraints on on-chain payments, enabling scenarios such as exchanging, crowdfunding, and voting.
Example 1: semi-fungible coins
Semi-fungible coins (or SFC/SFT) are a type of digital asset that categorizes similar but not identical tokens as a single “class”. This classification allows for specific interactions between tokens within the same class, such as transfers. Functionally, this means that tokens within a class can undergo mathematical operations like merging, splitting, or fragmenting. Essentially, SFTs provide the versatility of combining the characteristics of both fungible and non-fungible tokens, facilitating more dynamic and flexible asset management in digital environments.
By default, the slot_id is set to zero, which means the coin is non-fungible. Administrators can assign the same or different non-zero slot_id and a default slot_amount for each coin. Assets with the same slot_id can be treated as fungible assets and can be split and merged accordingly.
# semi-fungible coin cell (IB with Bitcoin UTXO)
data:
slot_amount: uint128
slot_id: uint32
type:
code:
semi_fungible_contract_codehash
args:
hash(manager_lock) | issue_id
lock:
code:
rgbpp_lock_codehash
args:
bitcoin_utxo
Here follows a typical merging transaction on L1 for two SFC with the same slot_id (asset type).
# Bitcoin transaction
inputs:
utxo#1
utxo#2
...
outputs:
OP_RETURN: commitment
utxo#3
...
# IB transaction on CKB
inputs:
sfc_cell1:
data:
slot_amount: 1000
slot_id: 11290
lock:
args:
utxo#1
sfc_cell2:
data:
slot_amount: 500
slot_id: 11290
lock:
args:
utxo#2
outputs:
sfc_cell3:
data:
slot_amount: 1500
slot_id: 11290
lock:
args:
utxo#3
Example 2: IBO (initial Bitcoin offering)
During the Ethereum ICO craze of 2017, despite the fact that the majority of fundraising projects were meaningless scams, blockchain developers gained unprecedented direct financial support. This influx of capital gave rise to many significant projects. In contrast, a notable issue with the current Bitcoin inscription system is its inability to provide funding capabilities for project teams. As a result, almost all projects are meme-based and cannot secure direct community funding, preventing them from sustaining professional teams that could continuously work on developing and exploring viable business models for these projects.
Based on the RGB++ protocol, we can develop a secure, decentralized token issuance and fundraising model that enables teams to gather funds for project development and operations. This approach has the potential to attract numerous professional teams to the Bitcoin ecosystem, encouraging ongoing development and sustained investment.
# IBO coin contract pseudocode
bool main() {
(to_address, ratio, block_range) = get_typeargs(self)
amount = uint128(get_data(self))
bitcoin_tx = SPV.get_tx(UTXO(get_lockargs(self)).txid)
payment = bitcoin_tx.find_output(to_address, ratio*amount)
return (bitcoin_tx in block_range) && payment
}
With this contract, users pay their Bitcoin to a specific address within a certain block height range, allowing them to receive tokens from the project in proportion to their payment.
# demo IBO transaction
## Bitcoin tx
inputs:
utxo#1:
amount: 10_000 sats
address: user
outputs:
utxo#2:
amount: DUST_SATS
address: user
utxo#3:
amount: 5_000 sats
address: project
...
## IB tx on CKB
inputs:
...
outputs:
coin_cell:
data: amount = 5_000*ratio
type:
code: IBO_contract_codehash
args: to_address | ratio | block_range
lock:
code: rgbpp_lock_codehash
args: utxo#2
...
Example 3: Staking and rewards
Staking is a method many projects use to enhance system security or provide liquidity for protocols. Typically, staking involves rewarding users with an alternative type of token. Here we present a scheme where B tokens are awarded proportionally based on the amount of A tokens staked and the duration of the stake. This model is designed to facilitate further development by project teams.
There will be two contracts together complete this job. The first contract is the Staking Lock, it helps lock users’ asset and calculate the staking time. The second one is reward udt, it will be automatically minted according to the lock period and amount.
# First step, stake
## Bitcoin tx
inputs:
utxo#1
...
outputs:
utxo#2
...
## IB tx on CKB
inputs:
asset_cell:
data: amount
type: asset_A
lock: utxo#1
outputs:
asset_cell:
data: amount
type: asset_A
lock:
code: staking_lock_codehash
args: owner=utxo#2
# Second step, claim reward, and continue to stake
## Bitcoin tx
inputs:
utxo#2
...
outputs:
utxo#3
utxo#4
...
## IB tx on CKB
inputs:
asset_cell:
data: amount
type: asset_A
lock:
code: staking_lock_codehash
args: owner=utxo#2
outputs:
asset_cell:
data: amount
type: asset_A
lock:
code: staking_lock_codehash
args: owner=utxo#3
asset_cell:
data: amount*lock_period*ratio
type: asset_B
lock: utxo#4
Summary
The RGB++ protocol introduces native Turing-complete programmability to Bitcoin’s Layer 1, significantly enhancing its capabilities. By leveraging this advanced programmability, developers can create more sophisticated applications directly on Bitcoin’s main blockchain. This transformation not only extends the utility of Bitcoin beyond simple transactions but also opens up a myriad of possibilities for complex financial instruments, smart contracts, and decentralized applications. As a result, Bitcoin can evolve into a more versatile and functional platform, comparable in programmability to platforms like Ethereum, but with the robust security and decentralization that Bitcoin is known for.