# Streembit Blockchain Protocol Specification v.1.0 ## Table of Contents - [The Streembit blockchain and smart contracts](#the-streembit-blockchain-and-smart-contracts) - [Preface](#preface) --- ## Definitions **Proof of Collaboration (PoC):** the consensus mechanism of the Streembit blockchain, in which identifiable Accountable Nodes produce blocks and validators attest transactions, with accountability enforced through locked deposits. **SBRIT:** the native crypto-asset of the Streembit blockchain, created only as the 1-SBRIT genesis allocation and as automatic rewards under the SBRIT Issuance Schedule. **Accountable Node:** a registered legal entity admitted through an Open Call and recorded as ACTIVE in the on-chain registry, entitled to produce blocks and bearing legal accountability for them. **Validator:** a verified participant admitted through an Open Call and recorded as ACTIVE, who verifies and attests transactions before their inclusion in a block. **ACTIVE:** the registry status of an Accountable Node or validator that has been admitted, registered through M-of-N authorisation and not suspended, exited or blacklisted; only ACTIVE participants may produce blocks or attest transactions. **Attestation:** a validator's signed statement that a transaction is valid, required before an Accountable Node may include the transaction in a block. **Locked deposit (D):** the SBRIT held in a participant's smart-contract deposit, accumulated from rewards or locked by the participant, which backs its conduct and is subject to protocol penalties. **Accountable Node deposit requirement (ADR):** the governance-set minimum locked deposit for an Accountable Node, initially 10,000 SBRIT, accrued from rewards and not a prerequisite for block production. **Validator deposit target:** the locked-deposit level, initially 1,000 SBRIT, up to which a validator's rewards accumulate before being paid out. **Transaction value (TV):** the aggregate value of the ordinary transfers in a block that require collateral coverage; a block is valid only if TV ≤ D / 2 of its producer. **Era:** one of the three periods of the SBRIT Issuance Schedule, each of 365 days counted in 24-hour periods from the genesis timestamp, with a constant issuance rate. **Genesis timestamp:** the time recorded in the genesis block from which days, eras, slots and rounds are counted. **Bootstrap sequence:** the genesis block and the system blocks that follow it, produced by the Foundation deployer key and attested by the Foundation keys, which deploy the genesis contracts, publish the rules and register the admitted Accountable Nodes and genesis validators; it ends at the block in which at least two validators become ACTIVE. **Foundation keys:** the Foundation's authorised signing addresses recorded in the Governance contract, used for Governance operations and for attesting the system transactions of the bootstrap sequence only. **Foundation deployer key:** the Foundation address that holds the 0.2-SBRIT genesis fee reserve, deploys the genesis-era contracts and produces the blocks of the bootstrap sequence. **Governance contract:** the contract created at genesis that records the governance ruleset, the mint rules, the Foundation keys, the capacity ceilings and the on-chain registry of Accountable Nodes and validators. **Governance ruleset:** the published set of parameters and procedures recorded in the Governance contract, including the amendment procedure, the current instances of the Open Call channels and the protocol version in force. **Open Call:** a public, dated invitation issued by the Foundation to apply for a stated number of Accountable Node or validator places, as defined in the *Open Call* section; the only route to admission. **Genesis Open Call:** the Open Call held before genesis that fills the single Accountable Node place and the genesis validator places. **Readiness:** the published technical checks, including a stated period of operation on the test network, that an admitted applicant must pass before registration as ACTIVE. **Verifiable random draw:** the selection method used when qualifying applicants exceed the places in an Open Call, using a seed outside the Foundation's control that is fixed after the window closes, so that anyone can reproduce the result. **Waiting list:** the ordered list of qualifying applicants not drawn in an Open Call, who fill places vacated before the next Open Call. **Capacity ceiling:** the published maximum number of ACTIVE Accountable Nodes or validators, recorded in the Governance contract and changed only as the protocol provides. **Beneficial owner:** a natural person who ultimately owns or controls 25% or more of an applicant, directly or through any entity; the basis of the one-validator-per-owner rule and of the ownership published with each Accountable Node admission. **Slot:** a 60-second period counted from the genesis timestamp during which exactly one Accountable Node is entitled to produce blocks. **Round:** one slot for each ACTIVE Accountable Node, in an order derived from the hash of the last block of the previous round; changes to the set of ACTIVE Accountable Nodes take effect at round boundaries. **Hash distance:** the deterministic measure used to select the validator for a transaction by comparing node identifiers with the relevant hash. **M-of-N authorisation:** approval by a published minimum number M of the Foundation's N authorised officers, required for registration and other Governance operations. **Blacklist:** the on-chain list of participants excluded from the network under the enforcement rules; blacklisted participants are ineligible for admission. **Unbonding period:** the governance-defined period after a participant announces exit before its locked deposit may be released, provided no proceeding remains pending. **Voting body:** all ACTIVE Accountable Nodes and ACTIVE validators, one vote each, as defined in the amendment rules. **Foundation Treasury:** smart contract and wallet addresses together controlled by the Foundation for initial transaction fees and bootstrapping the network. **Foundation Treasury contract:** the contract created at genesis that holds SBRIT. Spending goes through Governance authorisation **Foundation wallet:** the Foundation-controlled user address that receives SBRIT at genesis and submits Foundation transactions. ## The Streembit blockchain and smart contracts ### Preface John Nash argued for “Ideal Money”: money capable of serving as a reliable standard of measurement, while recognising the political difficulty of creating such a system through governments with competing interests. Streembit explores a different approach by combining distributed-ledger technology with cryptographic verification, economic incentives and legally accountable participants. Phase 1 focuses on establishing the SBRIT network and its Proof-of-Collaboration protocol. --- ## Problems in current blockchains and protocols Byzantine Agreement concerns how distributed participants reach a common decision despite faulty or malicious participants. Protocols solve this problem under defined assumptions about network communication and the number or influence of faulty participants they can tolerate. Blockchains require agreement on transaction ordering and ledger state. Long transaction confirmation times and limited throughput can restrict the practicality of blockchains for business applications. Bitcoin, for example, targets an average block interval of approximately ten minutes. A transaction may wait longer for inclusion, and applications requiring additional confirmations face further delays. These waiting times are a significant limitation for payments and other operations requiring prompt settlement. ### Mining. Proof-of-Work (PoW) In Proof-of-Work, a miner’s probability of creating a block increases with its share of the network’s hashing power. Mining requires equipment and electricity, favouring operators able to commit greater resources. Concentration of hashing power can give a small number of operators substantial influence over transaction inclusion and ordering. Recently one pool approached 50% of Bitcoins hashing power. This didn't result in a 51% attack because that would contradict the interests of the pool, it does however provide a glaringly obvious weak point. ### Proof-of-Stake Proof-of-Stake generally weights consensus influence by committed stake, giving participants with more stake greater influence. Unlike mining, it does not require competitive hashing. Some implementations penalise misconduct by confiscating stake; their resistance to attacks depends on the protocol’s selection, validation and penalty rules. ### Developer dictatorship Preferential initial allocations and control over protocol changes can give founders or developers disproportionate influence. These advantages and governance powers should be disclosed so participants can assess who controls the network and under what rules. ### How does Streembit solve these issues? Our blockchain protocol does not favour higher computational power or wallet balances. Streembit’s Proof-of-Collaboration combines cryptographic verification, economic incentives and legal accountability. Accountable Nodes create blocks, while validators verify and attest individual transactions. This division is designed to support efficient transaction processing without competitive mining. Phase 1 begins with Accountable Nodes admitted through the genesis Open Call. Verified individuals and legal entities may become validators under published admission rules, without purchasing SBRIT or providing an upfront deposit. They build deposits from earned validation rewards. The admitted Accountable Nodes earn ordinary block-production rewards without premine rights or preferential founder issuance. Validators verify and digitally sign individual transactions, which the Accountable Node assembles into blocks. The Accountable Node checks the transactions and validator attestations, then signs and broadcasts each block to the network. This collaboration is designed to enable sub-second transaction confirmation. --- # Proof of Collaboration Consensus Protocol (PoC) ## Introduction: The Evolution of Blockchain Consensus Bitcoin, proposed in 2008, introduced a permissionless blockchain operating without a central authority. Its Proof-of-Work (PoW) consensus relies on honest participants controlling a majority of the hashing power. Proof-of-Stake (PoS) provides another approach. Streembit uses Proof-of-Collaboration (PoC). Using PoC, participants agree on the longest valid chain and its blocks, linked through block height identifiers, ordering by block height where the blocks are created sequentially. Streembit draws on Cooperative Game Theory through economic collaboration, binding agreements and existing legal frameworks. Explicit accountability from Accountable Nodes, combined with cryptographic verification and economic penalties, is intended to deter attacks and support faster transaction processing. Validators verify and digitally sign individual transactions. The Accountable Node checks the transactions and validator attestations, assembles and signs the block, and broadcasts it. Receiving nodes independently validate the block before accepting it. ## The Collaborative Framework PoC collaborators have distinct responsibilities: Accountable Nodes create blocks, while validators verify and attest transactions before their inclusion. Phase 1 begins with admitted Accountable Nodes working with admitted validators. This collaboration is designed to enable sub-second transaction confirmation. Collaborators must run software implementing the agreed protocol rules to produce blocks, process transactions, execute smart contracts, communicate with peers and maintain the ledger. The software must be open source and available for public review. Accountable Nodes and validators earn SBRIT through automatic protocol rewards for block production and transaction validation, respectively. Honest nodes reject blocks that violate protocol rules. However, an attacker may attempt censorship or produce a competing history without submitting individually invalid blocks. Attack resistance therefore depends on the protocol’s block-production, validation and chain-selection rules, supported by economic penalties and legal accountability. Running modified software alone does not prove misconduct. ## Foundational Principles and Key Assumptions The PoC protocol operates under several fundamental premises and key assumptions that differentiate it from existing blockchain systems: ### A) Transparent Genesis Allocation The genesis state creates exactly **1 SBRIT**. A fee reserve of **0.2 SBRIT** is allocated to the Foundation deployer key, which deploys and initialises the genesis-era contracts and submits the Foundation multisig transactions. The remaining **0.8 SBRIT** is allocated to the Foundation Treasury. These are the only genesis allocations. All subsequent SBRIT is issued as automatic rewards for genuine block production and transaction validation under the published **SBRIT Issuance Schedule**. Every node independently verifies issuance against the protocol rules. ### B) Open Source Software Agreement Users must agree upon what constitutes valid, commonly adopted, and honest software that produces transactions and blocks. The software must be open source, with source code published in a public repository to allow users to peer review it and build the software application directly from its source. This transparency requirement ensures that no hidden functionalities or backdoors can compromise network security or give certain participants unfair advantages. The open source requirement extends beyond mere code availability to include comprehensive documentation, build instructions, and testing procedures that enable independent verification of software behavior. All participants must use software built from the same verified source code, preventing the introduction of modified versions that could compromise network security or create unfair advantages for certain participants. ### C) Business Entity Accountability Requirements To establish accountability within existing legal frameworks and make users accountable to courts of law, only registered businesses with verifiable and sufficient assets in their accounting books can create blocks in the Streembit blockchain. These are the **Accountable nodes**. **Registered businesses requirements**. The Accountable Node must be a legal person such as Corporations or Limited Liability businesses (LLC or Ltd) operating in jurisdictions with robust legal systems and reliable court processes. **Jurisdiction Requirements:** Accountable nodes must be registered and operating in one of the following approved jurisdictions: United States, United Kingdom, European Union, Japan, Australia. These jurisdictions are selected based on their established legal frameworks, reliable enforcement mechanisms, and strong rule of law that enables meaningful accountability and legal recourse in case of fraudulent behavior or protocol violations. **Asset Requirements:** Accountable nodes must maintain verifiable assets of at least **$5,000,000 USD** (five million US dollars) as demonstrated through audited financial statements. **Deposit Requirements:** In addition to meeting the business registration and asset requirements above, accountable nodes and validators eventually must maintain a minimum deposit in SBRIT to ensure economic security at the protocol level. (See Section J Deposit Requirement to Become a Validator for initial deposit and how the required deposit eventually reached.) The Accountable Node minimum deposit is 10,000 SBRIT (ten thousand). The Validator minimum deposit is 1,000 SBRIT (one thousand). Every Accountable Node starts with no deposit (to allow the node registration). Its block-production rewards accumulate in its locked deposit until the 10,000 SBRIT target is reached; subsequent rewards are paid to the node, while the deposit remains locked. Validators similarly accumulate their validation rewards towards individual locked deposits of 1,000 SBRIT. Ordinary SBRIT transfers remain subject to D ≥ 2 × TV, where D is the creating Accountable Node's locked deposit and TV is the aggregate transaction value requiring collateral coverage in the block. For the accountable node once its deposit reaches ADR, the required deposit is max(ADR, 2 × TV), where ADR is the governance-set minimum, initially 10,000 SBRIT. The minimum deposit is defined by the governance rules smart contract. The initial value of the deposit is **10,000 (ten thousand) SBRIT**. The deposit value requirement is updated regularly by increasing the deposit requirement. As the blockchain matures the accountable nodes must provide more and more deposits. Accountable nodes must ensure their deposit satisfies the dynamic requirement **D ≥ 2×TV** where D is the locked deposit and TV is the total transaction value in each block they create. The complete formula is: **Required_Deposit = max(ADR, 2 × TV)** where ADR is the actual deposit requirement, the governance-set minimum deposit, denominated in SBRIT. **Deposit Asset:** SBRIT only. The deposit is locked in a smart contract and is subject to confiscation and burning in cases of fraudulent behavior, protocol violations, or participation in network attacks. ### D) Deposit Confiscation Mechanism Participation in network attacks, fraud or other protocol violations may result in confiscation of the participant’s accumulated locked SBRIT deposit. This applies to a deposit still being accumulated as well as to a completed one, but confiscation is limited to the deposit actually held. Deposit penalties are separate from any legal consequences. Confiscation follows defined misconduct criteria, supported by automated monitoring and an appeal process for contested decisions. Confiscated SBRIT is permanently burned rather than redistributed. ### G) Whitelist of Honest Collaborators The Whitelist of Honest Collaborators (WHC) identifies collaborators by public key and records their history of successful collaboration, reporting of suspicious activity and compliance with protocol rules. Whitelist reputation does not itself confer increased selection probability or additional rewards. ### H) Blacklist for Malicious Actors Participants who submit fraudulent blocks or transactions, or otherwise commit misconduct warranting exclusion, are recorded by public key in the Blacklist and excluded from consensus participation. Penalties reflect the severity of misconduct, and affected participants may appeal. Enforcement actions are recorded to support transparency and review. ### I) Deterministic Validator Selection Through Hash Distance Streembit selects transaction validators using deterministic hash distance rather than random number generation. Selection follows the protocol’s eligibility rules and is not weighted by wallet balance or deposit size. ### J) Deposit Requirement to Become a Validator Validators may join without holding SBRIT or providing an upfront deposit, subject to admission rules. Validation rewards accumulate in each validator’s locked smart-contract deposit until the **1,000 (one thousand) SBRIT** target is reached. Subsequent rewards are paid to the validator, while the deposit remains locked and subject to confiscation for misconduct. The deposit requirement is published by the governance rules smart contract. ## Technical Implementation and Network Operation PoC uses digital signatures, hash functions and public-key infrastructure, supported by economic incentives and legal accountability. Collaborators register their public keys and required credentials and obtain approval under the applicable admission rules. Transaction validators are selected from eligible participants using deterministic hash distance. Validators verify transaction signatures, sender balances, amounts and compliance with protocol rules, including checks against double spending. They digitally sign transactions that pass validation. The Accountable Node verifies the transactions and attestations, checks that the total transaction value satisfies its applicable deposit requirement, and assembles the block. It must not selectively exclude valid transactions for personal advantage. The Accountable Node includes the transaction attestations, signs the block and broadcasts it. Transaction attestations and the block signature identify the participants responsible for validation and block production. Receiving nodes independently verify the block, its transactions and required signatures before acceptance. They apply the protocol’s longest-valid-chain selection rules to maintain the ledger by accepting validated blocks in sequential height order. Accountable Nodes earn block-production rewards, and validators earn transaction-validation rewards under the published issuance rules. During deposit accumulation, rewards enter each participant’s locked deposit until its required target is reached; subsequent rewards are paid to that participant. Network operation also includes maintaining peer connectivity, serving light clients, operating blockchain explorers and providing application interfaces. Technical participation requirements are intended to remain modest, subject to the operational requirements of each role. ## Legal Framework and Regulatory Integration PoC integrates cryptographic and economic safeguards with accountability under existing legal systems. Accountable Nodes must be registered businesses with verified assets and identified leadership, establishing identifiable parties responsible for network operations. Business, contract and criminal law may provide grounds for legal action arising from misconduct. Liability and enforcement depend on the conduct, applicable law and relevant proceedings; protocol participation alone does not establish a legal outcome. Deposit penalties complement legal accountability. Accumulated locked SBRIT may be confiscated and burned under the protocol’s misconduct and appeal rules. Civil claims or criminal proceedings may arise separately. Officers and directors may also incur personal liability where their conduct and applicable law establish it. Accountable Nodes must operate within the approved jurisdictions: United States, United Kingdom, European Union, Japan and Australia. These requirements are intended to support meaningful legal recourse, without guaranteeing enforcement or recovery. Accountable Nodes must maintain transaction records, implement applicable anti-money-laundering procedures and cooperate with lawful investigations. Protocol approval does not itself establish regulatory compliance. Protocol appeals address contested enforcement decisions within the network. Participants may also pursue remedies through the relevant courts, subject to applicable law. Cross-border operations require consideration of the legal obligations in each relevant jurisdiction. Identifiable operators, documented responsibilities and auditable activity may assist insurance and risk assessment. Insurance availability and coverage depend on insurers’ assessments and policy terms. The Foundation publishes its directors, officers, their affiliations and its funding sources. It also discloses the material terms of contracts with businesses affiliated with Foundation directors, officers, Accountable Nodes or validators. Such contracts require approval by Foundation directors without a conflict of interest. Disclosures are updated within 30 days of any change. ## Economic Model and Sustainability Streembit’s economic model supports network operation through rewards for protocol work and transaction fees that discourage abuse. ### Collaborator Incentives Accountable Nodes and validators earn SBRIT for their respective roles in maintaining the ledger. #### 1. Block Rewards The protocol automatically issues SBRIT for genuine block production and transaction validation under the **SBRIT Issuance Schedule**. Rewards accumulate in each participant’s locked deposit until the required target is reached: **10,000 SBRIT for Accountable Nodes** and **1,000 SBRIT for validators**. Subsequent rewards are paid to the participant, while the deposit remains locked and subject to protocol penalties. Accountable Nodes must also maintain sufficient collateral for the transaction value of the blocks they produce. #### 2. Transaction Fees Each transaction submitted to the network must include a fee in SBRIT. **Purpose:** - Discourage transaction spam. - Provide validators with an additional incentive beyond issuance rewards. **Structure:** - A flat fee of **0.01 SBRIT per transaction** is required. - Fees are distributed to validators under the governance rules. - Protocol quotas and size limits provide additional protection against excessive network use. **Outcome:** - Transaction submission carries a cost, discouraging spam. - Validators receive fee income for their contribution to network operation. Fees are paid directly to the attesting validator as income and do not count towards the locked deposit. Scheduled SBRIT mint transactions carry the same flat fee. The fee is paid by the creating Accountable Node, the signer of the mint transaction, from its spendable balance to the attesting validator. It is not taken from the issued amount. ## Enhanced Byzantine Agreement with Cooperative Game Theory Economics ### The Fundamental Innovation Streembit combines Byzantine Agreement with economic incentives and legal accountability. Cooperative Game Theory provides conceptual motivation for aligning participants’ interests; it does not define a separate consensus mechanism or reward-calculation algorithm in PoC. ### Dual-Layer Consensus Architecture ### Layer 1: Enhanced Byzantine Agreement PoC combines technical validation with accountability for the participants performing it. **Cryptographic Layer:** - Validators verify and digitally sign transactions. - Accountable Nodes assemble and sign blocks. - Receiving nodes validate blocks and apply the longest-valid-chain selection rules by sequential block-height checks. **Legal Accountability Layer:** - Accountable Nodes are identified business entities subject to published admission requirements. - Contracts establish responsibilities under applicable law. - Accumulated locked deposits are subject to protocol penalties. - Legal remedies may be pursued through the relevant courts. ### Layer 2: Cooperative Game Theory Economics Accountable Nodes and validators cooperate in producing valid blocks. Published issuance and fee rules reward their respective work, while deposit penalties discourage misconduct. Rewards are determined by protocol rules, not by coalition formation or game-theoretic calculations. ### Economic Stability Through Legal Enforceability ### The Trust Bridge for Institutions Streembit combines four forms of assurance: 1. **Cryptographic:** signatures and hashes support verification of authenticity and integrity. 2. **Economic:** accumulated deposits place SBRIT at risk for misconduct. 3. **Legal:** identified entities and contractual responsibilities support legal recourse. 4. **Reputational:** recorded conduct affects participants’ standing in the network. These safeguards complement one another. Deposit protection grows during the initial phase as participants accumulate rewards; legal recovery and penalties depend on applicable proceedings. ### Incentive Alignment **For Accountable Nodes:** - Earn rewards for genuine block production. - Build a record of reliable operation. - Face deposit penalties and potential legal and reputational consequences for misconduct. **For Validators:** - Join without an upfront SBRIT deposit, subject to admission rules. - Earn validation rewards towards the required locked deposit. - Receive subsequent rewards after reaching the deposit target. **For Users:** - Submit transactions under the published validation and flat-fee rules. - Verify transaction inclusion and ledger history. - Pursue applicable remedies when disputes arise. ### Institutional Adoption Pathway #### Phase 1: Legal Compliance Foundation Accountable Nodes must satisfy entity, jurisdiction, asset and accountability requirements. Validators may be verified individuals or legal entities. Participation remains subject to the applicable admission and deposit rules. #### Phase 2: Competitive Economics Broader participation and reliable service are development objectives. This does not establish market-driven fees, investment returns or a new reward mechanism. #### Phase 3: Institutional Integration Identifiable operators and auditable activity may support institutional use and risk assessment. Adoption, insurance and regulatory treatment depend on the application and relevant requirements. These later phases describe possible development directions, not additional launch rules. #### Key Advantages Over Pure Byzantine Agreement PoC supplements technical agreement with identified operators, deposits at risk, published penalties and access to legal remedies. These measures are intended to strengthen incentives for honest operation; they do not replace consensus rules or guarantee that misconduct is unprofitable. #### Cooperative vs. Competitive Framework Accountable Nodes and validators perform complementary tasks: validators attest transactions, and Accountable Nodes assemble and publish blocks. Their compensation follows the published protocol rules. Cooperation does not imply proportional benefits for every participant or rewards for transaction submitters. #### Real-World Implementation PoC is intended to support enterprise applications, financial services, government services and individual users requiring auditable transactions and accountable operators. Suitability depends on operational performance and application-specific requirements. Consensus participation requires admission under the protocol rules. #### Secure the consensus with deposit schemes PoC uses locked SBRIT deposits to discourage misconduct. Ordinary transfers require the creating Accountable Node’s deposit to satisfy **D ≥ 2 × TV**, where TV is the aggregate transaction value subject to collateral coverage in the block. Coverage is always measured against the Accountable Node's actual locked deposit. Confiscation and burning follow the protocol's misconduct and appeal rules; legal consequences are determined separately. ### Core Deposit Validation Logic **Primary Deposit Requirement:** ```text D ≥ 2 × TV ``` SBRIT reward minting under the published issuance schedule is exempt from transaction-value collateral coverage. Ordinary transfers remain subject to the deposit rule. **Block Validation Summary:** Block acceptance requires: - An authorised Accountable Node and its valid block signature. - Valid previous-block linkage and compliance with chain-selection rules - both using block height. - Valid transactions, including signatures, balances and replay checks. - At least one valid attestation from an eligible, protocol-selected validator for every ordinary transaction. - Sufficient Accountable Node deposit coverage for the aggregate block value. These checks summarise the requirements; all applicable protocol rules must also be satisfied. **Deposit Resolution Logic:** Deposits remain locked after successful block production. Rewards accumulate towards the applicable deposit target; subsequent rewards are paid to the participant. Transaction fees follow the published fee-distribution rules. Misconduct may result in deposit confiscation, burning and blacklisting under the enforcement and appeal rules. Legal action is not an automatic protocol operation. #### Fraud Detection Criteria Checks identify: 1. Transactions exceeding available balances. 2. Attempts to spend the same funds more than once or replay accepted transactions. 3. Invalid signatures or attestations. 4. Violations of block-production or consensus rules. 5. Transaction ordering that violates protocol rules or enables fraud. Invalid blocks are rejected. Establishing misconduct and applying penalties follow the defined enforcement process. #### Variable Definitions - **D:** Accountable Node’s locked deposit, in SBRIT. - **TV:** Aggregate transaction value requiring collateral coverage, in SBRIT. - **ADR:** Governance-set minimum Accountable Node deposit. The deposit rule provides a deterrent; it does not alone prove that every attack, including misconduct across multiple blocks, is unprofitable. ### Secure the consensus with the Accountability Method Accountable Nodes disclose their identity and required business information and accept responsibility for block production. Identifiable operators support investigation and legal recourse. Deposit penalties, reputational consequences and potential legal liability complement the protocol’s cryptographic checks. --- # SBRIT Streembit Reserve (**SBRIT**) is the sole native asset of the Streembit network in Phase 1. ## The Streembit Reserve coin (SBRIT) SBRIT serves three protocol functions: - **Transaction fees:** Users pay network transaction fees in SBRIT. - **Rewards:** Accountable Nodes and validators earn SBRIT for block production and transaction validation under the published issuance rules. - **Security & Accountability:** Participants lock SBRIT as deposits, which are subject to confiscation and burning under the protocol’s misconduct and appeal rules. ### SBRIT Issuance Schedule ### SBRIT Issuance Schedule | Era | Period (days, inclusive) | Hours | SBRIT issued per hour | Block producer share | Validator share | Total era issuance | |---|---|---:|---:|---:|---:|---:| | 1 | Days 1–365 | 8,760 | 100 | 50% | 50% | 876,000 | | 2 | Days 366–730 | 8,760 | 75 | 50% | 50% | 657,000 | | 3 | Days 731–1,095 | 8,760 | 50 | 50% | 50% | 438,000 | | **Total** | **Days 1–1,095** | **26,280** | | | | **1,971,000** | Participant shares of scheduled issuance are: | Era | Producer share (SBRIT) | Validator share (SBRIT) | |---|---:|---:| | 1 | 438,000 | 438,000 | | 2 | 328,500 | 328,500 | | 3 | 219,000 | 219,000 | | **Total** | **985,500** | **985,500** | Scheduled issuance totals **1,971,000 SBRIT**. Including the **1-SBRIT genesis allocation**, the maximum total supply is **1,971,001 SBRIT**. Scheduled issuance ends after day 1,095; no SBRIT is created thereafter, and producers and validators are compensated from transaction fees. Days are counted from the genesis timestamp in periods of 24 hours, independent of calendar dates. The issuance rate is constant within each era and declines at era boundaries. The genesis rate is the highest rate the network ever has; there is no elevated rate in the first days and no step within an era. Each hour's issuance is divided equally between the block producer share and the validator share. The producer share of each scheduled mint is paid to the producer of the block carrying it. The validator share is paid to ACTIVE validators under the rules in *Validator Requirements → Rewards*. Because at least two ACTIVE validators are required at genesis, the validator share is distributed from the first block. The era schedule is enforced by the mint rules published in the governance contract at genesis. Every node independently rejects any mint transaction that departs from those rules. The schedule may be amended only for eras that have not yet begun, only through the published governance procedure, and **never so as to raise any era's rate above the genesis schedule, raise the producer share above 50%, or increase the maximum supply**. Amendment rules: * An amendment needs a published proposal, a comment period, a supermajority of the then-current voting body, Foundation confirmation that it's lawful, and a delay before it takes effect. * The voting body consists of all ACTIVE Accountable Nodes and ACTIVE validators, with one vote per verified participant; voting rights are not attached to SBRIT holdings. The voting body may be extended to additional classes of participant only through the amendment procedure, and no amendment may remove a class of participant from the voting body or reduce any participant's vote to less than one. ## Genesis Strategy ### SBRIT Genesis Allocations (Treasury Pools) Genesis creates **1 SBRIT**: **0.2 SBRIT** as a fee reserve for the Foundation deployer key and **0.8 SBRIT** to the Foundation Treasury for initial transaction fees and bootstrapping the network. The Treasury funds the admitted Accountable Nodes' identity addresses and the registration fees of the first validators through Governance-authorised transfers. ### Initial Network Operation The network starts with a **bootstrap sequence**: the genesis block, which creates the genesis allocations, followed by the system blocks that deploy the Treasury and Governance contracts, publish the governance ruleset and mint rules, and register the admitted Accountable Nodes and the genesis validators. The deployer Foundation keys produce these blocks and the Foundation keys attest their transactions. No reward is paid to the Foundation keys for attesting it. The bootstrap sequence ends at the block in which at least **2 validators** become ACTIVE. From that block onward every ordinary transaction must carry the required attestation from an eligible ACTIVE validator, and the Foundation keys attest nothing further. Genesis validators are admitted through the genesis Open Call (see *Open Call*) and complete verification and technical readiness testing before genesis, so that they become ACTIVE within the sequence. If the number of ACTIVE validators later falls below the published minimum, ordinary transactions are not processed until the minimum is restored through the registration procedure; the halt is a liveness condition, not a fault of the producer. Rewards accumulate in participants' locked deposits towards **10,000 SBRIT for each Accountable Node** and **1,000 SBRIT per validator**; subsequent rewards are paid out. Every Accountable Node starts at zero and accrues its deposit under this rule, and the target is not a prerequisite for block production. Ordinary transfers require **D ≥ 2 × TV**, using the Accountable Node’s actual locked deposit and aggregate block transaction value. Scheduled reward minting and deposit-establishment transactions remain exempt from this collateral requirement. ### Genesis Contract Security Architecture #### Contract implementation Genesis records the Foundation keys as the Treasury contract's authorised signers. The contract requires M-of-N signatures. It deploys the Treasury contract and sends funds to the Foundation Treasury. Spending from the Foundation Treasury contract passes through the Governance contract's M-of-N authorisation. The Foundation wallet is spent directly by the Foundation with its key. #### Security Mechanism Funds in the Foundation Treasury contract are contract-controlled. The Treasury contract accepts spending instructions only from the authorised Governance contract; individual signers and other callers cannot directly spend from the Foundation Treasury contract. #### Authorized Signers The Governance contract records the Foundation's authorised signing addresses at genesis. These are the Foundation keys. They authorise Governance operations and attest the system transactions of the bootstrap sequence. Once the sequence ends they attest nothing further and have no role in consensus; they retain their Governance authority. ## Open Call ### Definition An Open Call is a public, dated invitation issued by the Foundation to apply for a stated number of Accountable Node or validator places. Every admission of an Accountable Node or validator, at genesis and at each later expansion, is made only through an Open Call. No place is allocated outside one, and no place is reserved for any applicant. An Open Call states: the class of place (Accountable Node or validator) and the number of places; the eligibility requirements and the section of this specification that defines them; the application window with opening and closing times in UTC; the application fee and its published cost basis; the readiness requirements and the period of test-network operation required; the selection rule and, for the draw, the source of the seed; and the date by which results are published. ### Publication Before the application window opens, the Foundation publishes the current protocol specification and the Open Call, at minimum, through: (1) the Foundation website and the public source repository, which hold the canonical dated text and the application form; (2) a public forum of record for blockchain launches; (3) the Foundation's own public social-media accounts; and (4) a press-release distribution service reaching the crypto trade press. The current instance of each channel is listed in the governance ruleset. The Foundation keeps a public record of where and when each posting was made, and publishes it with the results. ### Timing The genesis Open Call opens no later than **30 days** before the planned genesis timestamp and its window remains open for at least **21 days**. Later Open Calls follow the timetable in *Validator Requirements* and *How to become an Accountable Node*, and every window remains open for at least **21 days**. The Foundation may not shorten a window once published; it may extend one, with notice through the same channels. ### Selection rule All complete applications received within the window that pass verification and readiness are admitted up to the number of places. If they exceed the places, admission is decided by a verifiable random draw: the method is published with the Open Call, the seed is taken from a source outside the Foundation's control that is fixed only after the window closes, and anyone can reproduce the result. For the genesis Open Call the seed is the hash of the Bitcoin block at a height stated in the call, chosen so that it is mined after the window closes; for later Open Calls the seed is the hash of the first Streembit block produced after the window closes. The Foundation exercises no discretion between qualifying applicants. Qualifying applicants not drawn form a waiting list, in draw order, for places vacated before the next Open Call. A refusal states the requirement not met and the evidence relied on, and the applicant may appeal under the appeal rules. ### Genesis conditions Genesis proceeds only when at least **1 Accountable Node** and **2 validators** have been admitted through the genesis Open Call and have passed readiness. The genesis Open Call provides **ONE** Accountable Node place. If the genesis Open Call does not produce the required participants, the Foundation extends the window through the same channels and genesis is postponed; no place is filled by any other means. If fewer applicants qualify than there are places, all qualifying applicants are admitted and the remaining places are carried to the next Open Call. ### Record Within **24 hours** of the close of selection the Foundation publishes: the number of applications received, verified and admitted; the draw seed, its source and the method, if a draw was used; the admitted Accountable Nodes by registered name and jurisdiction and the admitted validators by validator ID; the length of the waiting list; the reasons for refusals in summary form; and the publication record. These records remain available for as long as the network operates. ## How to become an Accountable Node Streembit maintains a public, on-chain registry identifying Accountable Nodes. The following requirements govern their admission and continued operation. ### Eligibility requirements 1. **Legal entity.** The applicant must be a registered corporation or limited liability company with publicly identified officers who accept responsibility for fraudulent conduct. Personal liability depends on applicable law. 2. **Jurisdiction.** The entity must be registered and operating in the United States, United Kingdom, European Union, Japan or Australia. The approved list is published in the governance ruleset and may be extended by Foundation officer multisig. 3. **Assets.** The entity must maintain at least **USD 5,000,000 in verifiable assets**, supported by audited financial statements. 4. **Deposit.** No upfront deposit is required. Every Accountable Node starts with a zero locked deposit and accumulates its block-production rewards in a locked smart-contract deposit until the Accountable Node deposit requirement (**ADR**), initially **10,000 SBRIT**, is reached; subsequent rewards are paid out. An Accountable Node may also lock SBRIT it already holds towards the ADR at any time. Reaching the ADR is not a prerequisite for block production. While the locked deposit D is below the ADR, the node may include ordinary transfers only up to **TV ≤ D / 2** per block, where TV is the aggregate transaction value requiring collateral coverage; once the ADR is reached, the node's operating deposit must satisfy **D ≥ max(ADR, 2 × TV)**. The same rule applies to every Accountable Node admitted at any time. Deposits remain locked and subject to protocol penalties. 5. **Software.** The node must run the commonly adopted, open-source Streembit software built from the published source without modification. 6. **Technical operation.** The node must publish its signing public key and reachable endpoint, maintain availability and synchronise its ledger. It must not selectively exclude valid transactions for personal advantage. 7. **Compliance.** The node must maintain transaction records, implement applicable anti-money-laundering procedures and cooperate with lawful investigations. ### Required disclosures The on-chain application must record the company name, registration number, jurisdiction, asset evidence, responsible officers, their statement accepting personal responsibility for fraudulent conduct, and the node’s signing public keys. Disclosures must remain current. ### Claim validation Disclosures must be verified before approval through audited financial statements, business-registration records and jurisdictional compliance checks. Publication through Streembit’s GitHub repository and supplementary checks by accountability providers, relevant authorities or professional associations may support review. Publication alone does not establish accuracy. ### Application lifecycle Admission of an Accountable Node is a compliance gate, not a selection. Every applicant that meets the published eligibility requirements is admitted, up to the published capacity, and the Foundation has no discretion between qualifying applicants. 1. **Open Call.** Accountable Node places, including the places in the genesis producer set, are offered only through an Open Call (see *Open Call*), which states the number of places, the eligibility requirements, the application window, the application fee and the date results are published. Applicants disclose their beneficial owners and directors and any ownership, control, employment or family relationship with the Foundation or its officers; the disclosure is published with the admission results and must be kept current. An admitted node whose disclosure is found to have been false or incomplete is excluded under the enforcement rules. 2. **Apply.** Submit the required disclosures, supporting verification and a declaration of affiliations within the window, together with the application fee. 3. **Application fee.** The application fee equals the Foundation's published cost of verifying an application; the cost basis is published with the Open Call and reviewed annually, the fee is identical for every applicant, it is not refundable on refusal because the cost has been incurred, and it is not a condition of anything beyond the verification itself. No other fee is payable to the Foundation for admission or participation. The order of receipt confers no priority. 4. **Verify.** The Foundation verifies the disclosures against audited financial statements, business-registration records and jurisdictional compliance checks, and verifies key control and technical readiness: each applicant must have operated a node on the public test network continuously for the period stated in the Open Call before the window closes and must pass the published readiness checks. Each requirement is assessed as met or not met against the published criteria. 5. **Admit.** All applicants that meet every requirement are admitted up to the number of places. If they exceed the places, admission is decided by the same verifiable random draw as for validators, and the remainder form a waiting list. A refusal states, in writing, the requirement not met and the evidence relied on, and the applicant may appeal under the appeal rules. Foundation officers register admitted applicants as ACTIVE through M-of-N authorisation; registration is ministerial and may be withheld only on a stated verification or readiness ground. 6. **Publish.** Within 24 hours of registration the Foundation publishes the number of applications received and admitted, the draw seed and method if used, the registered name, jurisdiction and beneficial owners holding 25% or more of each admitted node, and the reasons for any refusal in summary form. 7. **Operate.** Maintain the applicable deposit coverage, operational requirements and current disclosures. 8. **Exit.** Announce withdrawal. The deposit may be released after the governance-defined unbonding period, provided no dispute or fraud proceeding remains pending. A vacated place is offered to the waiting list and, if the list is empty, held for the next Open Call. **Capacity.** The number of ACTIVE Accountable Nodes is initially limited to **1 (one)**. The ceiling may increase to **5 (five)** after multi-producer consensus has been implemented and tested. Expansion requires the published governance procedure and an Open Call. The Foundation reviews the ceiling at least every 180 days and publishes the review; lowering it below the number of ACTIVE nodes is not permitted. ### Consequences of misconduct Fraud, protocol violations or attack participation may result in confiscation and burning of accumulated locked deposits and blacklisting under the enforcement and appeal rules. Recorded evidence may support separate civil or criminal proceedings against the entity or responsible officers. ## Validator Requirements Validators independently verify and attest transactions. Every ordinary transaction requires at least one valid attestation from an eligible validator selected through deterministic hash distance. ### Eligibility requirements 1. **Identity.** Verified individuals and legal entities may participate during Era 1, with one validator per beneficial owner: a person or entity that controls, directly or through any entity, more than one validator is in breach, and all its validators may be excluded. Verification is performed off-chain by the Foundation or its verification provider; only an attestation that the validator is a distinct verified participant is recorded on-chain. Natural persons are identified publicly by validator ID only and their names are not published. Legal entities are listed by registered name. Every applicant declares any ownership, control, employment or family relationship with the Foundation or its officers; the declaration is published as an affiliation flag against the validator ID and must be kept current. A validator whose declaration is found to have been false or incomplete is excluded under the enforcement rules. Each validator has a unique ID and a published secp256k1 signing public key. Blacklisted participants are ineligible. From Era 2, staked validators may participate without identity verification under rule 3. 2. **Jurisdiction.** Approved jurisdictions are the **United States, United Kingdom, European Union, Japan, Australia, Canada, Switzerland, Singapore and New Zealand**. 3. **Capacity.** The number of ACTIVE validators is limited by a published ceiling that rises on a fixed timetable. At genesis the ceiling is **10**. During Era 1, **before the launch of the blockchain** the Foundation issues an Open Call (see *Open Call*) to find the first 10 Validators. Later, during Era 1, the Foundation issues an Open Call for **2 further places at least every 60 days** until the ceiling reaches **20**, so that the **Era 1 ceiling is 20 no later than day 365**. The ceiling is a protocol parameter recorded in the Governance contract; the Foundation may not admit validators above it and may not delay a scheduled Open Call. The initial limit keeps identity verification, application administration, technical support and network coordination manageable during early operation; **it is not a limit on who may apply**. From the start of Era 2 the ceiling rises to no less than **200**. The exact Era 2 ceiling will be set by the governance procedure before Era 2 begins, within these bounds; the governance procedure may raise these minimums but may not lower them. The long-term aim is to permit an unlimited number of validators once network coordination allows it. 4. **Deposit.** No upfront deposit is required. Validation rewards accumulate in a locked smart-contract deposit towards **1,000 SBRIT**. Subsequent rewards are paid out; the deposit remains locked and subject to penalties. 5. **Operation.** Validators run the commonly adopted, open-source software in validator mode, publish reachable endpoints, maintain synchronised ledger state and meet protocol timeouts. Unresponsive validators are excluded from selection until they resume responding. ### Registration lifecycle 1. **Apply.** Places are offered only through an Open Call (see *Open Call*). Applications are submitted off-chain during the Open Call window with the required identity information, a declaration of any relationship with the Foundation or its officers, and the validator's signing public key. The order of receipt confers no priority. An application received outside the window is not considered. 2. **Application Fee.** The application fee equals the Foundation's published cost of verifying a validator application, such as performing identity checks. It is stated separately for natural persons and for legal entities; the cost basis is published with the Open Call and reviewed annually, the fee is identical for every applicant of the same type, it is not refundable on refusal because the cost has been incurred, and it is not a condition of anything beyond the verification itself. 3. **Verify.** The Foundation checks identity, jurisdiction, beneficial ownership, key control and technical eligibility. One validator per beneficial owner; an applicant found to control another applicant or an existing validator is refused. Supporting identity documents remain off-chain; only a verification attestation is recorded on-chain, and natural persons are identified publicly by validator ID only. 4. **Select.** All verified applications received within the window are admitted up to the number of places in the Open Call. If verified applications exceed the places, admission is decided by a verifiable random draw: the seed is the hash of the first block produced after the window closes, the method is published in advance, and anyone can reproduce the result. The Foundation exercises no discretion between verified applicants. Verified applicants not drawn form a waiting list, in draw order, for places vacated before the next Open Call. 5. **Readiness.** Selected applicants run the validator software against the test network and pass the published readiness checks within the stated period. An applicant that fails or does not complete the checks forfeits the place, which passes to the next applicant on the waiting list. 6. **Activate.** Foundation officers register selected and readiness-tested applicants as ACTIVE through M-of-N authorisation, within the ceiling in force at the time of the Open Call. Registration is ministerial: officers may refuse only on a verification or readiness ground, must state the ground in writing, and the applicant may appeal under the appeal rules. During initial operation, when SBRIT is unavailable on the market, the Foundation Treasury may pay an approved applicant's **0.01-SBRIT transaction fee**. 7. **Publish.** Within 24 hours of activation the Foundation publishes the Open Call results: the number of applications received and verified, the draw seed and method, the list of admitted validator IDs with affiliation flags, and the waiting list length. 8. **Exit.** Announce withdrawal. Deposits may be released after the governance-defined unbonding period, provided no dispute or slashing proceeding remains pending. A vacated place is offered to the waiting list and, if the list is empty, held for the next Open Call. ### Duties Validators check transaction signatures, balances, replay rules and applicable Accountable Node deposit coverage before signing. They attest transactions, not blocks. The Accountable Node and receiving nodes separately enforce aggregate block-value collateral coverage. ### Rewards Validators collectively receive **50% of scheduled issuance** for validation work and transaction fees under the published rules. ### Penalties Invalid or conflicting attestations, collusion and other violations may result in confiscation and burning of accumulated deposits and blacklisting under the enforcement and appeal rules. ### Initial participation A minimum of **2 ACTIVE validators** is required from the end of the bootstrap sequence and at all times thereafter. Genesis validators are selected through the genesis Open Call, verified and readiness-tested before genesis, and registered within the bootstrap sequence. Each earns its own deposit from attestation rewards; participation does not require founder-funded deposits. # Streembit Account-Based Transaction Model Streembit uses an account-based ledger rather than Bitcoin’s UTXO model. Users, collaborators and contracts are identified by addresses, with balances recorded in ledger state. Transfers debit the sender and credit the recipient, supporting smart contracts, security deposits and Foundation Treasury operations without UTXO selection. The account model separates internal ledger design from external interfaces. Familiar CLI and RPC operations, including `getbalance` and `sendtoaddress`, support integration without requiring Streembit to reproduce Bitcoin’s transaction structure. **Alignment with PoC Requirements** **Deposit Validation (D ≥ 2 × TV):** Deposit coverage is checked against the Accountable Node’s locked SBRIT deposit recorded in contract state, not its freely spendable wallet balance. Accountable Nodes and receiving nodes enforce coverage for the aggregate transaction value requiring collateral in each block. **SBRIT Account Balances:** Phase 1 uses SBRIT as its sole native asset. The internal balance map retains the structure `(address, assetId) → balance`. Retaining an asset identifier does not introduce additional launch assets. **Legal and Institutional Advantages** **Regulatory Compliance:** Account balances provide familiar records for compliance review. The ledger model itself does not establish regulatory compliance or implement account-freezing and seizure powers. **Audit Trails:** Recorded transactions allow account balances and movements to be traced and reconciled. **Institutional Integration:** Account-to-account transfers and documented interfaces support integration with existing accounting and payment systems. **Performance and Scalability Benefits** **State Management:** Account balances are maintained as keyed state entries, supporting direct balance queries and updates. **Transaction Simplicity:** Transfers update account balances without selecting and consuming UTXOs. Transaction processing must also apply fees, sequence checks and other validity rules. **Smart Contract Efficiency:** Contracts operate through the protocol’s permitted state transitions, supporting transfers, escrow and other contract-controlled balances without UTXO management. **Mint transactions deposit requirement:** Mint transactions executed under the SBRIT Issuance Schedule are exempt from **D ≥ 2 × TV**. They create supply under consensus-enforced rules rather than transfer existing user funds. ### Account Model Technical Summary **Storage Layout:** - User and contract accounts are identified by addresses. - Contract state uses a 32-byte CID internally. - Balances are stored as `(address, assetId) → amount`. **Transaction Model:** - Account-based transfers rather than UTXO inputs and outputs. - Per-account sequence numbers enforced under the transaction and replay rules. - Debit-credit balance updates. - Locked funds are moved under contract control and reported through contract views; they are unavailable for ordinary spending. **Address Unification:** - User addresses use the user version byte and an `S` prefix. - Contract addresses use the contract version byte and a `C` prefix. - Both use Base58Check encoding with a 20-byte payload. - These are Streembit address formats; similar encoding does not establish compatibility with Bitcoin addresses. #### Account Model in Practice The CLI exposes familiar balance and transfer operations. Bitcoin: ```text bitcoin-cli getbalance ``` Streembit: ```text streembit-cli getbalance > 1150.000 ``` Balances are denominated in SBRIT by default. Sending Funds: ```text streembit-cli sendtoaddress 50.0 SBRIT ``` Illustrative Transaction Record: ```text TxID: a7f9c3b8d2e1f4a6... Type: Transfer Sender balance before: 1250.00 SBRIT Sender balance after: 1199.99 SBRIT Recipient balance before: 800.25 SBRIT Recipient balance after: 850.25 SBRIT Amount: 50.00 SBRIT Fee: 0.01 SBRIT Block: #12345 Status: Confirmed ``` Transfer validation checks the sender’s spendable balance, including the fee, and the required account sequence. Contract-controlled deposits and escrow cannot be spent through ordinary transfers. Their balances and release conditions are obtained through the relevant contract interfaces. # Block production PoC combines identifiable block producers, transaction attestations and deposit-backed accountability to support rapid transaction processing. During initial operation, active Accountable Nodes produce blocks sequentially. Block height establishes their order; the longest-chain selection via block height. This arrangement is designed to enable sub-second transaction confirmation. #### Main attributes - Every ordinary transaction requires at least one eligible validator’s attestation. - The Accountable Node signs each block and assigns its next sequential height. - Ordinary transfers require aggregate collateral coverage of **D ≥ 2 × TV**. - Identified participants are subject to protocol penalties and applicable legal accountability. ### Creator responsibility for block production The Accountable Node verifies transactions and validator attestations before assembling a block. It checks balances, account sequences, replay protection and aggregate deposit coverage, then signs and publishes the block. The creator signs the hash of the following data: ```text H(chainId ‖ timestamp ‖ txs_concat_txid ‖ txs_total_value ‖ creator_id) ``` Here, `chainId` identifies the network, `timestamp` records block creation time, `txs_concat_txid` contains the ordered transaction IDs, `txs_total_value` records their total value, and `creator_id` identifies the Accountable Node. The expression defines the signed digest, not the signature itself. Block height accompanies the block for sequential storage and acceptance. ## The genesis block Genesis is block number **1**, predefined by the network software. It establishes the Treasury contract and the genesis allocations: **0.2 SBRIT** to the Foundation deployer key as a fee reserve and **0.8 SBRIT** to the Foundation Treasury. Treasury spending is controlled by the Governance contract under M-of-N authorisation. ## Producing subsequent blocks The Accountable Node assembles transactions carrying the required attestations, applies the protocol checks and publishes successive blocks. It must not selectively exclude valid transactions for personal advantage. Transaction fees are fixed at **0.01 SBRIT** under the published rules. Block-production and validation rewards compensate the respective participants for protocol work, supporting predictable transaction costs without competitive fee bidding. ## The right to create a block Only ACTIVE Accountable Nodes may produce blocks, with one exception: the system blocks of the bootstrap sequence are produced by the Foundation deployer key as described in *Genesis Strategy*, and no reward is paid for them. Admission is through the Open Call procedure in *How to become an Accountable Node* and registration in the on-chain registry; the Foundation applies the published requirements and has no discretion between applicants that meet them. Production among ACTIVE Accountable Nodes is assigned by time slots. Time is divided into slots of **60 seconds** counted from the genesis timestamp. A round is one slot for each ACTIVE Accountable Node in the registry at the start of the round, in an order derived from the hash of the last block of the previous round; changes to the set of ACTIVE Accountable Nodes take effect at the next round boundary. A block is valid only if signed by the Accountable Node holding the slot at the block's timestamp. If the slot holder publishes no block within the first **10 seconds** of its slot while valid transactions are pending, the next node in the round's order may produce for the remainder of the slot, and so on in turn; a slot with no pending transactions is not a missed slot. Missed slots are counted under the unresponsiveness rules. With a single ACTIVE Accountable Node, that node holds every slot. Until multi-producer consensus is implemented and activated, the sole ACTIVE Accountable Node produces all blocks. Additional Accountable Nodes may be activated only after multi-producer consensus has been implemented and tested. ### Adaptive Block Creation Modes #### Mode 1: Instant Blocks (Early Adoption) Mode 1 prioritises prompt processing during initial operation, with a target of **1–10 transactions per second**. Receiving nodes: - Verify the authorised creator and block signature. - Verify transaction validity and required attestations. - Enforce aggregate transaction-value coverage of **TV ≤ D/2**, subject to the defined exemptions. - Accept new blocks only at the next expected height. **Coordinator during Mode 1** During initial operation, the sole ACTIVE Accountable Node produces all blocks. Once multi-producer consensus is activated, production follows the slot-assignment rules. #### Mode 2: Epoch-Based High Throughput (Scale Phase) Epoch-based production is a future scaling proposal, targeting **100–1,000+ transactions per second**. Its scheduling and multi-producer coordination rules require separate specification. #### Shadow Block Publishing System A proposed later arrangement assigns primary and standby Accountable Nodes to production slots. These are block producers, distinct from transaction validators. #### Shadow Operation Protocol Standby publication requires defined failover timing, producer authority and conflict-handling rules. It is not part of initial single-producer operation. ### Additional rules Nodes reject transactions already recorded in the accepted ledger and enforce per-account sequence rules. Matching blocks already stored at a height are treated as duplicates; conflicting blocks at that height are rejected. Nodes missing blocks retrieve the intervening heights before applying later blocks. ## Validator Role and Transaction-Level Validation Process ### Overview Validators independently attest transactions. Accountable Nodes assemble blocks, and receiving nodes verify them before acceptance. This division supports parallel processing while enforcing transaction validity and deposit coverage. ### The Validation Architecture Validators sign transactions, not blocks. Every ordinary transaction requires at least one valid attestation from an eligible validator selected through deterministic hash distance. Identified Accountable Nodes, locked deposits and applicable legal accountability complement these checks; they do not replace independent verification. ### Rationale for Transaction-Level Signatures Transaction-level attestations allow validators to work on different transactions concurrently. Accountable Nodes can assemble already-attested transactions without collecting separate validator signatures on the completed block. Validators still require synchronised ledger state, and processing remains dependent on timely responses. ### Instant Mode Validation (Mode 1) In instant mode, each transaction becomes its own block: 1. The transaction enters the mempool. 2. An eligible validator checks signatures, balances, account sequence, replay protection and applicable deposit coverage. 3. The validator signs an attestation and sends it to the active Accountable Node. 4. The active Accountable Node verifies the transaction and attestation, checks coverage, assembles and signs the block. 5. The block is published at the next sequential height. #### Mathematical Formula for Instant Mode For an ordinary transfer, the collateral check is: ```text V(Tn) ≤ D/2 ``` `V(Tn)` is the transaction value in SBRIT; `D` is the Accountable Node’s locked deposit. Passing this check does not replace the other transaction-validity requirements. ### Epoch Mode Validation (Mode 2) Epoch mode is a future proposal for assembling multiple transactions per block. Aggregate collateral coverage must be checked at both assembly and receipt. #### Division of Responsibilities **Validators:** Verify and attest individual transactions. **Accountable Node:** Verify transactions and attestations, enforce aggregate deposit coverage, and sign the assembled block. **Receiving nodes:** Independently verify the block’s transactions, attestations, creator signature, expected height and aggregate deposit coverage. #### Why Validators Cannot Enforce Global Constraints A validator checking individual transactions does not necessarily see the final block contents. Several individually affordable transactions may collectively exceed the creator’s coverage. The creator and receiving nodes must therefore check the complete block. #### Mathematical Formula for Epoch Mode The collateral condition at assembly and receipt is: ```text TV ≤ D/2 ``` `TV` is the aggregate transaction value requiring collateral coverage; `D` is the creator’s locked SBRIT deposit. This condition is necessary but not sufficient for block acceptance. #### Genesis and Initial Operation Genesis creates **1 SBRIT**: **0.2 SBRIT** to the Foundation deployer key and **0.8 SBRIT** to the Foundation Treasury. Foundation keys attest only the system transactions of the bootstrap sequence. From its end, transaction attestation is performed by ACTIVE validators; no other key may attest an ordinary transaction. Scheduled reward minting and deposit-establishment transactions retain their defined collateral exemptions. Ordinary transfers remain subject to actual deposit coverage. ### Benefits of Transaction-Level Validation - Parallel validation of different transactions. - Prompt assembly once required attestations are available. - Separation of transaction checks from aggregate block checks. - Support for the sub-second confirmation objective. ### Security Analysis Attestations identify validators approving transactions; they do not eliminate receiving-node checks. Deposit penalties apply to accumulated locked funds under the enforcement and appeal rules. Legal consequences depend on applicable proceedings. #### Critical Insight: Network Verification is Essential Receiving nodes reject blocks that exceed permitted aggregate transaction value or otherwise violate protocol rules. Independent verification prevents reliance solely on the creator’s own checks. ### Canonical Transaction Ordering Mempool timestamps support local scheduling but do not guarantee identical arrival order across nodes. Accepted ledger order follows sequential block heights and transaction order within each block. Per-account sequence and replay rules remain mandatory. ### Deposit Management Deposits remain locked under their contract rules. Ordinary transfers must satisfy coverage using the creator’s applicable locked deposit. For the future epoch proposal, deposit reductions would be restricted during an active epoch, with changes applied at epoch boundaries. These are not initial-operation rules. ### Summary: The PoC Validation Architecture Validators attest individual transactions. Accountable Nodes verify them and enforce aggregate coverage during assembly. Receiving nodes independently verify the completed block. This division supports rapid processing without treating signatures, deposits or accountability as substitutes for complete protocol validation. ## Transactions ### Account-based, unified addressing Streembit uses an account-based model with distinct user and contract addresses under a shared addressing scheme. Ordinary user transactions include: - **Value transfer:** debit the sender and credit the recipient. - **Contract call:** invoke contract code with optional value. - **Contract deployment:** publish code and create a contract account. There are no UTXO inputs or outputs. Phase 1 uses SBRIT; spendability depends on available account balances. Deposits and escrow remain under contract control and are queried through contract state. The CLI provides familiar operations such as `getbalance` and `sendtoaddress`. Contract code and storage use the protocol’s CID-based identification and namespacing. ### Replay handling Ordinary account transactions must satisfy the sender’s account-sequence requirement. Timestamps contribute to transaction identification but do not replace sequence enforcement. Transaction identifiers are calculated as: ```text txid = H(chainId ‖ timestamp ‖ payload ‖ signature ‖ salt ‖ sequence) ``` Nodes reject transactions already recorded in the accepted ledger and enforce sequence, signature and balance checks before applying state changes. Genesis and protocol reward transactions follow their separately defined validation rules. During initial operation, the authorised Accountable Node publishes blocks sequentially, and receiving nodes accept new blocks at the next expected height. Block ordering does not replace transaction-level replay protection. --- ## Unified Addressing, Contract Identity & Resolution Streembit presents one **BTC-style address format** for both key-owned (user) accounts and contract accounts to keep exchange and wallet workflows familiar. Under the hood, however, each contract still has a canonical **32-byte Contract ID (CID)** — the deterministic identifier derived as specified in the CID derivation section. The human-readable address shown in CLIs, wallets, and explorers is a **Base58Check address** (“contract address”) that is deterministically derived from the CID using domain-separated HASH160. User accounts retain the standard HASH160(pubkey) form. Different **version bytes** are used so user addresses and contract addresses are unambiguous at a glance. This preserves Streembit’s determinism and content-addressed storage while giving operators a single, Bitcoin-like address convention for all accounts. Storage and consensus continue to rely on **explicit namespaces** keyed by binary identifiers, so human address formatting does not affect on-chain structure or validation. **Resolution model**: The RPC layer resolves address→CID by reading ```acct/
/meta``` (single source of truth). The CID→address display form is derived on the fly from cid32 (domain-separated HASH160); no separate index is stored. Operators and exchanges pass the BTC-like address to standard commands (e.g., getbalance, sendtoaddress); the node resolves it internally to the canonical CID when the target is a contract account. ### CID derivation The canonical 32-byte Contract ID (CID) is derived as: ``` // Pseudo-code for CID derivation (exact formula to be specified) const cid = H( codeHash || // 32 bytes deployerPubKey || // 33 bytes (compressed) chainId // 4 bytes ); // Result: 32-byte value, represented as 64-char hex string ``` ## Smart contracts A smart contract is an agreement whose execution is both automatable and enforceable. Automatable by computers and software, although some parts may require human input and control. ## Smart contracts deployment The smart contracts are deployed and stored at the project source code folder, at the file system in Phase 1. The smart contracts are JavaScript .js files and saved in the source repository /node/smart-contracts folder. The smart contract source code also saved in the blockchain under the code/bytes/ namespace. The ContractAccount remains small and consensus‑focused. The contract file is retrieved by its hash from the local key‑value store. The contract transaction includes a **codeHash** field. Phase 1 codeHash = H(\smart-contracts\folder\contract_file.js) eg. node\smart-contracts\genesis\treasury.js **Addressing clarification**: While addresses are unified externally, internally: - User accounts: Direct balance storage under address - Contract accounts: Balance under address, state under CID **Contract storage keys**. All contract state is stored as cells under ```sc//kv/```, where `````` is the canonical 32-byte contract ID. This ensures instance-scoped, Merkle-provable state that is independent of human address formatting. ### Smart Contract Execution Smart contracts are approved code. Only contracts deployed at genesis or through a Governance-authorised upgrade are executed, and every node verifies the contract code and its service interface against the hashes recorded in the contract's metadata before each execution. Deployment authorisation and this integrity check are the trust model; contracts run inside the node process without process-level isolation. A contract interacts with the node only through a service interface delivered over the node's event bus, which offers: - Read access to the key-value store. - Access to transaction details (sender, value, parameters). - Account balance queries. - Signature verification and hashing. The service interface has no write operation. A contract does not change state; it returns a state change proposal consisting of storage operations and balance changes. The PoC Engine validates every balance change against the current ledger state: the prior balance must match the ledger, the arithmetic must be correct and a debit must be covered. Storage operations are applied as returned; keeping them within the contract's own namespace is a property of the approved code, not an engine check. The engine applies the proposal, the transaction fee and the sender's sequence update as one atomic batch, and a proposal that fails validation fails the transaction. ## Wallet The Streembit wallet manages keys, accounts and transactions on the account-based ledger. User and contract addresses use Base58Check encoding with distinct version bytes. Contracts also retain a 32-byte Contract ID (`cid32`) for identification and storage. #### Scope and goals - Manage SBRIT accounts and transactions. - Provide familiar balance and transfer operations. - Display contract-controlled deposits and escrow separately from spendable balances. - Resolve contract addresses to their corresponding CIDs. #### Key material and derivation The wallet uses hierarchical deterministic keys through BIP32. Sensitive key material is stored locally and encrypted using a passphrase-derived AES-256 key. A usable seed or backup enables recovery after losing the wallet file. Without the required keys or recovery material, access to the corresponding funds cannot be restored. #### Addressing and identity Address payloads are derived as follows: - **User accounts:** `HASH160(pubkey)`. - **Contract accounts:** `HASH160("SB-CID" || chainId || cid32)`. The appropriate user or contract version byte and Base58Check encoding produce the displayed address. Contract details may also display `cid32`; derivation follows the Contract Identity section. #### Balances and encumbrances `getbalance` reports the spendable SBRIT balance. Funds transferred into deposit or escrow contracts are controlled by those contracts and reported through their views. They must not be counted as spendable or subtracted twice. #### Sending and receiving Receive SBRIT by sharing a user address. An illustrative transfer command is: ```text streembit-cli sendtoaddress 50.0 ``` Ordinary transactions require a **0.01-SBRIT fee**. Transfers must satisfy spendable-balance, sequence and other protocol checks. #### Replay handling The wallet constructs transactions with the required account sequence and transaction-identification fields. Nodes reject transactions already recorded in the accepted ledger and enforce sequence validity. Transaction status reflects inclusion in accepted blocks under the sequential block-height model. Automatic reorganisation and re-inclusion are not assumed. #### Developer and explorer integration Account metadata is accessed through `acct/
/meta`, balances through `acct/
/balance/`, and contract state through `sc//kv/*`. Address presentation does not alter the underlying contract identity or validation rules. ## Streembit CLI ### Notes The CLI provides account-balance, transfer and contract operations. Spendable balances exclude funds moved under contract control; deposit and escrow information is obtained through contract queries. Phase 1 examples and operations use SBRIT. ### 1) Error codes Validation errors distinguish unsupported versions, invalid chain identifiers, malformed field lengths or public keys, invalid encoding, missing salts, invalid parameters and unsupported hash algorithms. Exact identifiers and response formats follow the implemented interface reference. Errors must not be interpreted as successful transaction submission or execution. ### 2) Security & ops notes - Explicit deployment parameters, support deterministic CID calculation before deployment. - Including `chainId` binds identifiers to the intended network. - Replay protection additionally requires account-sequence enforcement and duplicate-transaction rejection. ### 3) Conformance Implementations must follow the specified address and CID derivation, serialization and transaction-validation rules. Deterministic inputs must produce consistent identifiers, and malformed inputs must be rejected. Conformance claims require matching test vectors and verified interface behaviour. ### Reputation management on Streembit Reputation management is a system that collects, distributes, and aggregates feedback about past behaviour. A reputation management system maintains trust in online communities. The Streembit reputation system is used by smart contracts to establish trust in smart contract-based trades. ### Private transaction with smart contracts The Streembit private transaction is an attempt in addressing the privacy issues of the blockchain. The Streembit private transaction is always based on a smart contract so that the contract can be enforced outside of the blockchain, and within conventional enforcing frameworks, such as in court or involving other law enforcement methods. --- ## Emergency Response ### Network Attack Nodes reject invalid transactions and blocks. Misconduct may result in blacklisting and confiscation of accumulated locked deposits under the enforcement and appeal rules. Automatic circuit breakers and a Governance-controlled network pause are intended safeguards. Their triggers, scope, authorisation and resumption procedures require specification before implementation. Automatic rollback is not part of the current response model. --- ## Success Metrics & Monitoring - **Performance requirement:** At least **10 TPS** with **sub-second transaction confirmation**, to be verified through testing. - **Reliability:** Monitor availability and processing failures. - **Participation and security:** Monitor ACTIVE validators and deposit coverage. - **Public dashboard:** Intended reporting of SBRIT issuance, block height and operational metrics. --- ## Summary - **SBRIT:** Pays fees, rewards protocol work and secures participation through locked deposits. - **Genesis and issuance:** 1 SBRIT is created at genesis, 0.2 SBRIT as the Foundation deployer fee reserve and 0.8 SBRIT to the Foundation Treasury; scheduled rewards split equally between creators and validators. Maximum total supply: **1,971,001 SBRIT**. - **Participation:** Initially one Accountable Node and 10 ACTIVE validators, rising by Open Calls of 2 places at least every 60 days to 20 during Era 1 and to at least 200 from Era 2, when staked validators are also admitted; Accountable Nodes and validators join through the Open Call procedure. - **Security and operation:** Sequential block-height ordering, independent verification, **D ≥ 2 × TV** coverage for ordinary transfers, and Governance authorisation support accountable network operation. --- ## APPENDIX: Additional Elements Under Consideration Research topics outside Phase 1; no delivery commitments. ### A) Advanced Performance Optimizations - Layer 2 scaling - High-frequency trading state channels - Zero-knowledge proofs: privacy and compliance research ### B) Institutional Integration Features - SWIFT connectivity - CBDC interoperability - Securities settlement (T+0) ## References These sources provide technical background and conceptual context; they do not define Streembit’s protocol rules. 1. Satoshi Nakamoto. [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf). 2. NIST. [Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC](https://doi.org/10.6028/NIST.SP.800-38D). 3. [Algorand](https://arxiv.org/abs/1607.01341). 4. [Smart Contract Templates: foundations, design landscape and research directions](https://arxiv.org/abs/1608.00771). 5. [Smart Contract Templates: essential requirements and design options](https://arxiv.org/abs/1612.04496). 6. Georgios Chalkiadakis, Edith Elkind and Michael Wooldridge. [Computational Aspects of Cooperative Game Theory](https://www.cs.ox.ac.uk/publications/publication7755-abstract.html). 7. Wes Kussmaul. *Quiet Enjoyment*. [PKI Press](https://www.pkipress.com/node/1).