What's New in RGB v0.12

100x Faster • 75% Less Code • Forward Compatible

The complete protocol redesign with stability guarantees

Breaking Changes

RGB v0.12 includes consensus-breaking changes. All v0.11 contracts must be re-issued. See Migration Guide below.

🔒 Forward Compatibility Guarantee

All contracts issued with v0.12 will work with future RGB versions.

This is the first RGB version with this guarantee. Test on testnet first.

🚨 Breaking Changes

Contracts Not Compatible

CRITICAL: Contracts issued before v0.12 are NOT compatible due to consensus-level changes. All contracts must be re-issued.

Migration Required

If you're upgrading from RGB v0.11 or earlier:

1. Export all asset data
2. Upgrade to v0.12
3. Re-issue all contracts
4. Re-distribute assets

🎯 Major Features

1. zk-STARK Readiness

RGB v0.12 was completely re-architected to support zero-knowledge STARK proofs:

• State Unification: All state types unified into finite field elements
• Circuit-Compatible: Validation logic representable as arithmetic circuits
• Future-Proof: Ready for zk-compression when zk-STARKs mature

2. zk-AluVM Virtual Machine

Introduced a revolutionary VM with just 40 instructions:

// AluVM characteristics
- Non-von-Neumann architecture
- Read-once memory model
- Turing-complete
- Exception-less execution
- Formally verifiable

3. Enhanced Invoicing System

Invoices now support more flexible seal types and better integration with payment workflows:

# Generate invoice for receiving tokens
rgb invoice --wallet my-wallet <CONTRACT_ID> 100

# The invoice encodes: contract, amount, and destination seal

4. Payment Scripts

New support for multi-beneficiary, multi-contract transactions:

// Multiple recipients, multiple contracts
const paymentScript = await rgb.createPaymentScript({
  payments: [
    { beneficiary: 'alice', contract: tokenA, amount: 100n },
    { beneficiary: 'bob', contract: tokenB, amount: 50n },
    { beneficiary: 'charlie', contract: nft, tokenId: 5n },
  ]
});

5. Contractum Language

New functional declarative language for smart contracts:

// Example Contractum contract
contract StableCoin {
  global supply: Amount
  owned balance: Amount

  transition transfer(amount: Amount) {
    require(balance >= amount)
    balance -= amount
  }
}

Compiles to AluVM bytecode for execution.

🚀 Performance: Orders of Magnitude Better

100x

Faster Validation

5ms vs 500ms

75%

Less Code

40k → 10k LOC

250x

Less Memory

50MB → 200 bytes

5x

Fewer Instructions

200 → 40 opcodes

📊 Before & After Comparison

// ❌ v0.11: Load entire consignment into memory
let consignment = Consignment::load("transfer.rgb")?;
// Memory usage: 50MB+
// Time: ~500ms
// Code: 40,000 lines

// ✅ v0.12: Stream-based validation
let stream = ConsignmentStream::new("transfer.rgb")?;
stream.validate()?;
// Memory usage: 200 bytes
// Time: ~5ms
// Code: 10,000 lines

Why So Much Faster?

Optimization	Impact
State Unification	Single field element type → 10x faster computation
Stream Processing	No memory allocation → 250x less RAM
AluVM Redesign	40 instructions vs 200 → 5x smaller VM
NoSQL Backend	Append-only database → Zero fragmentation
Type System Simplification	Removed abstractions → Compiler optimizations

🔧 API Changes

Simplified State Types

Before (v0.11):

enum StateType {
    Fungible(PedersenCommitment),
    Structured(Data),
    Attachment(Binary),
}

After (v0.12):

struct State {
    data: FieldElement  // Single unified type
}

Unified Seals

Before: Separate Tapret and Opret seal types After: Single seal type with method selection

// v0.12 unified seal
let seal = Seal::new(txid, vout, method);

Enhanced Interfaces

Standard interfaces (RGB20, RGB21) now support:

• Multiple token types per contract
• Richer metadata
• Complex state management

// v0.12 RGB20 with multiple tokens
const contract = await RGB20.issue({
  tokens: [
    { name: 'Token A', ticker: 'TKNA', supply: 1000000n },
    { name: 'Token B', ticker: 'TKNB', supply: 500000n },
  ]
});

🔐 Security Enhancements

Comprehensive Test Coverage

First RGB version with extensive testing:

• >66.7% overall code coverage
• >75% consensus library coverage
• Unit, integration, and security tests
• Attack scenario coverage

Re-org Protection

Formal mathematical model for blockchain reorganization attacks:

// Configurable re-org depth protection
// Set via --min-confirmations global option
rgb --min-confirmations 6 <command>

Deterministic Bitcoin Commitments (DBC)

Enhanced commitment verification:

Rule: Exactly ONE valid commitment per transaction
- First DBC-compatible output wins
- Subsequent outputs ignored
- Prevents ambiguity attacks

📦 Architectural Removals

Removed Features

To achieve simplification, these were removed:

• ❌ Pedersen Commitments: Replaced by zk-STARK preparation
• ❌ Bulletproofs: No longer needed with new architecture
• ❌ Blank State Transitions: Eliminated entirely
• ❌ Multi-Blockchain Support: Each chain gets dedicated contracts
• ❌ Schema Complexity: Replaced by Contractum

Deprecated APIs

// Removed in v0.12
pub fn create_blank_transition() // Removed
pub fn bulletproof_verify()     // Removed
pub struct PedersenCommitment   // Removed

🌟 New Capabilities

Lightning Network Integration

Enhanced Lightning Network support for RGB assets:

• RGB-enabled Lightning channels
• Multi-hop routing for RGB assets
• Atomic swaps between Bitcoin and RGB assets
• Instant settlement with minimal fees

RGB Lightning integration is provided through compatible Lightning node implementations. See RGB Lightning guide for details.

Multiple Token Standards

Single contract can expose multiple interacting tokens:

// DeFi pair contract
const dexPair = await RGB.createContract({
  interface: 'DexPair',
  tokens: {
    tokenA: RGB20Contract,
    tokenB: RGB20Contract,
    lpToken: RGB20Contract
  },
  logic: poolLogic
});

Enhanced Privacy

Additional privacy features:

• Blinded UTXO allocations in invoices
• Optional clear allocations for specific use cases
• Entropy leaves in MPC trees

📊 Comparison Table

Feature	v0.11	v0.12
State Types	3 distinct types	1 unified type
VM Instructions	~200	40
Code Size	~40k LOC	~10k LOC
Validation Speed	500ms	5ms
Memory Usage	50MB+	200 bytes
Test Coverage	Less than 30%	Greater than 66.7%
zk-Ready	No	Yes
Lightning	Experimental	Production

🔄 Migration Guide

For Contract Issuers

# 1. Export v0.11 contract data
rgb-v0.11 export --contract <ID> --output old-data.json

# 2. Upgrade to v0.12
cargo install rgb-cli@0.12

# 3. Re-issue contract
# Create new params file with your token specs
rgb issue --wallet my-wallet token-params.yaml

# 4. Announce to users

For Wallet Developers

Update your integration:

// Old (v0.11)
import { RGB } from 'rgbjs@0.11';

// New (v0.12)
import { RGB } from 'rgbjs@0.12';

// Update API calls
const transfer = await rgb.transfer({
  // New payment script format
  payments: [...]  // Changed from single invoice
});

For Users

1. Backup wallet data
2. Upgrade wallet software
3. Re-sync RGB contracts
4. Verify balances

🎓 Learning Path

If you're new to v0.12:

1. Core Concepts - Understand the new architecture
2. AluVM Guide - Learn the new VM
3. State Management - Understand unified state
4. Migration Guide - Update existing projects

📚 Additional Resources

• v0.12 Release Notes
• Breaking Changes Details
• Migration Examples

Forward Compatibility Guarantee

Important: All contracts issued with RGB v0.12 will remain compatible with future versions. This is the first version with this guarantee.

RGB v0.12+ = Stable consensus layer
Future versions will be backward compatible

---

Ready to build with v0.12? Start with the Quick Start Guide.