SB Chain: The Immutable Ledger

4.1 Foundation: BitShares Graphene

SB Chain is forked from BitShares, one of the oldest continuously operating blockchain codebases in existence, having run without a single day of downtime since its launch in 2015. BitShares is built on the Graphene framework, a high-performance C++ blockchain toolkit that also underlies EOS and Hive, and has been subject to more than a decade of real-world adversarial testing.

From BitShares, SB Chain inherits:

• A proven on-chain order book DEX with limit orders, stop orders, and fill-or-kill execution
• A flexible asset issuance system supporting user-defined assets with configurable fee structures
• A three-tier referral and governance system for on-chain committee management
• A battle-tested database and consensus layer with extensive production history

SB Chain extends this foundation with three major additions: the RDPoS randomisation layer (sourced from the R-Squared protocol), the sBridge integration, and the SBT token economy.

4.2 Immutability Guarantee

The immutability of SB Chain is not a policy statement; it is an architectural property enforced at the consensus level. Once a block is finalised under RDPoS and appended to the chain, no mechanism exists within the protocol to alter, delete, or reverse it.

This applies to every category of transaction recorded on SB Chain:

• Bridge deposit confirmations (wrapped asset minting events)
• Bridge withdrawal confirmations (wrapped asset burn events)
• AMM swap executions
• Order book placements, cancellations, and fills
• Liquidity pool deposits and withdrawals
• LP fee accumulation and claim events
• SBT transfers and burns
• Governance votes and witness elections
• Fee schedule updates

No administrator key, no emergency pause, no governance vote can rewrite historical state. The chain itself is the log: a complete, permanent, independently verifiable record of every action ever taken on the protocol.

4.3 RDPoS: Randomised Delegated Proof of Stake

SB Chain operates under Randomised Delegated Proof of Stake (RDPoS), a consensus mechanism that extends BitShares' original Delegated Proof of Stake (DPoS) with a cryptographic randomisation layer derived from the R-Squared protocol.

The foundational problem with standard DPoS. In original BitShares DPoS, the set of active block producers is known in advance and their production schedule is deterministic. This creates predictability: a sophisticated adversary can identify which witness will produce the next block and attempt to target it. It also creates the possibility of coordinated censorship by a known, static set of producers.

RDPoS eliminates predictability at two levels: which witnesses are active (randomised selection from a larger pool), and in what order they produce blocks (randomised slot scheduling).

Core parameters defined in config.hpp:

RSQUARED_WITNESSES_TOP_MAX    = 63   // standing elected candidate pool
RSQUARED_WITNESSES_ACTIVE_MAX = 21   // block producers active in any round
Block interval                = 5 seconds

The protocol operates in three stages per maintenance window.

4.4 The Election Stage

SBT holders cast votes continuously for witness candidates. Any account may register as a witness candidate by posting a bond and publishing a signing key. Voting power is proportional to SBT holdings: one SBT equals one unit of vote weight.

At each maintenance interval, votes are tallied across all accounts using a stake-weighted algorithm (update_active_witnesses() in db_maint.cpp). The top 63 candidates by total vote weight form the standing candidate pool, the universe from which active block producers are selected.

Missed block production is tracked publicly in witness_object::total_missed. Token holders can observe the reliability record of any candidate and adjust votes accordingly. A witness that consistently misses blocks will lose votes and eventually drop out of the top 63. This creates a continuous accountability loop enforced by economic incentive rather than authority.

4.5 The Commit-Reveal Randomisation Scheme

From the 63-candidate standing pool, 21 active block producers are selected each maintenance window through a commit-reveal scheme (db_commit_reveal.cpp:33–50). This scheme generates unpredictable, tamper-resistant randomness from the collective input of the candidate pool itself.

Phase 1: Commit. Each of the 63 candidates submits a cryptographic commitment to the chain:

commitment = Hash(secret_value)

The hash locks the candidate's secret into the chain's state without revealing its content. Once committed, it cannot be changed.

Phase 2: Reveal. After the maintenance window's midpoint, the reveal phase opens. Each candidate publishes their original secret_value. SB Chain verifies that Hash(secret_value) matches the previously committed hash.

Seed generation. All verified reveals are summed to produce a single PRNG seed:

seed = sum(secret_value_1, secret_value_2, ..., secret_value_n)

Withholding protection. Any candidate that fails to reveal their secret_value by the reveal deadline is excluded from selection entirely. Withholding is not neutral; it costs the witness their chance of selection for that round.

Why this prevents manipulation. To bias the seed, an adversary would need to know the secret values of all other candidates before committing their own. Because commitments are submitted first and revealed second, this is cryptographically impossible. Controlling the seed would require controlling the majority of 63 independently operated nodes simultaneously, not merely a majority of the 21 active producers.

This design means no entity, including the SwapBlok Foundation, can predict or influence which 21 witnesses will produce blocks in the next round.

4.6 Block Production and Slot Scheduling

The 21 selected witnesses are shuffled into a block production schedule using an XOR-shift PRNG seeded from the commit-reveal output. Each witness is assigned specific time slots within the round.

Block production is enforced at the protocol level:

FC_ASSERT(scheduled_witness == signing_witness,
    "Witness producing block at wrong time slot");

A block signed by the wrong witness for a given slot is cryptographically rejected. A witness that misses their slot has the slot skipped; the chain continues with the next scheduled producer. Missed blocks are permanently recorded on-chain.

Witness rewards, paid in SBT, are distributed only for successfully produced blocks, creating a direct financial incentive for consistent uptime and correct behaviour.

4.7 On-Chain Governance

SB Chain inherits BitShares' three-body governance system:

Witnesses produce blocks and earn SBT rewards. They are elected by SBT holders and can be voted out at any time.

Committee members govern network parameters: operation fee schedules, network fee percentages, block size limits, and other chain-wide configuration. Committee decisions are made through on-chain proposals requiring majority approval, with all proposals and votes permanently recorded.

Worker proposals allow any participant to propose funded development work. SBT holders vote on worker budgets, and approved workers receive SBT from the protocol reserve on a schedule tied to milestone completion.

Every governance action (vote cast, proposal submitted, parameter changed) is permanently recorded on the immutable ledger.