ByteStream: A Non-Custodial Bitcoin Account Layer

Version: 0.95 (MVP Design with PSBT Settlements)

Author: ByteStream Network

Status: Draft for review

1. Abstract

ByteStream is a Bitcoin-native Layer 2 protocol that provides instant, low-fee, account-style payments while preserving non-custodial control of user funds on Bitcoin Layer 1 (L1).

Each user account in ByteStream is backed 1:1 by a dedicated Taproot UTXO (a shard). A central Hub (or future federation) maintains an off-chain ledger of balances and processes signed payment intents between users. For each off-chain state, the payer also contributes to a pre-signed PSBT that encodes a precise settlement transaction. This allows:

User-initiated cooperative settlement (user asks to settle; Hub co-signs and broadcasts),
Recipient/Hub-initiated cooperative settlement (Hub finalises and broadcasts pre-signed PSBTs, even if the payer is offline), and
Unilateral CSV self-exit (user alone exits via a Taproot script path).

These three spend paths are all anchored in a single Taproot shard UTXO per user.

The MVP focuses on:

One Hub cluster acting as a single logical writer for the ledger and commitment state.
Per-user Taproot shard accounts with CSV escape hatches and PSBT-based cooperative commitments.
A well-specified shard state machine and append-only event log.
A Watchtower/Indexer that monitors Bitcoin for deposits, settlements, exits, and stale commitments.
A Wallet SDK and investor-facing demo application.

Future work includes Merkle-root anchoring of the ledger, multi-recipient batching, stake-backed Hubs, and federated multi-Hub deployments.

2. Motivation

Bitcoin is an excellent settlement layer but a poor UX for day-to-day transactions:

Limited throughput and variable fees. On-chain payments are slow and often expensive, especially during fee spikes.
UTXO complexity. Users must contend with addresses and discrete UTXOs, not simple account balances.
Lightning complexity. Lightning Network improves latency and fees but introduces:
- Per-peer channels with fixed capacities,
- Inbound/outbound liquidity management,
- Operational complexity and nuanced failure modes.

Centralised custodial services offer a familiar "account balance" UX but introduce custodial risk and regulatory exposure.

ByteStream aims to occupy the middle ground:

Account-style UX: one balance per user, instant off-chain payments.
Non-custodial security: funds are always recoverable via Bitcoin L1 scripts.
Operational simplicity: no channel graphs, no inbound capacity, no per-peer channels.

3. Design Goals

The MVP design is guided by the following goals:

Non-custodial safety
- The Hub must never be able to steal user funds.
- Users must be able to unilaterally reclaim their BTC via a CSV-based script path on L1.
Instant off-chain payments
- Payments between ByteStream users confirm immediately in the off-chain ledger.
- L1 is used only for deposits, periodic settlements, and exit.
Simple mental model
- Users see a single account balance and transaction history per account.
- No channels or liquidity management concepts exposed.
Bitcoin-native cryptography & tools
- Taproot, MuSig2, CSV, CPFP, PSBT.
- No novel consensus layer in MVP.
Upgrade path to decentralisation
- MVP: a single Hub cluster with independent observers.
- Future: multi-Hub federation, stake-backed validators, cross-Hub routing.

4. System Overview

4.1 Actors

User / Payer / Recipient

Holds keys controlling their shard and interacts via a Wallet SDK and applications.
Hub

A server cluster that:
- Maintains the canonical off-chain ledger and shard state machine.
- Validates payment intents and PSBT contributions.
- Produces and co-signs settlement transactions.
- Exposes APIs to wallets and observers.
Watchtower / Indexer

A component that:
- Monitors Bitcoin via a full node.
- Detects deposits, settlements, CSV exits, and stale commitments.
- Updates the ledger and flags anomalous behaviour.
Observer / Replica Node (future)

A node run by third parties that:
- Replays the ByteStream event log,
- Verifies ledger correctness against Bitcoin commitments,
- Provides independent read APIs for users/auditors.

4.2 High-Level Flow

User creates a ByteStream account and associated Taproot shard address.
User deposits BTC to that address; after confirmations, the Hub credits the off-chain ledger.
Users send instant off-chain payments via signed payment intents.

At the same time, they also contribute PSBT partial signatures for the corresponding on-chain commitments.
The Hub or recipient can later trigger cooperative settlement:
- Either with fresh user interaction, or
- Using stored pre-signed PSBTs (payer offline).
At any time after a CSV delay, a user can execute a unilateral CSV self-exit to reclaim funds if the Hub is unavailable or malicious.

5. Cryptographic Account Model

ByteStream's on-chain behaviour is defined by how each shard UTXO can be spent. Each shard has a single Taproot output Acct(U) with three effective spend modes:

User-initiated cooperative settlement (key-path spend with both user & Hub signing at settlement time).
Recipient/Hub-initiated cooperative settlement (key-path spend via pre-signed PSBTs containing the user's partial signature).
Unilateral CSV self-exit (script-path spend by the user alone after a timelock).

All three are rooted in the same Taproot output.

5.1 Shard UTXO:

Acct(U)

Each user U has a shard UTXO representing their ByteStream account:

On Bitcoin, it is a P2TR (Taproot) output:
- Internal key: aggregate key
  
  Q = \text{MuSig2}(P_\text{user}, P_\text{hub})
- Script tree (Taptree): at minimum a CSV self-exit leaf for P_user.

Shard UTXO attributes:

funding_outpoint = txid_fund:vout_fund
Value: V_shard sats
scriptPubKey = P2TR(Q, Taptree), with:

Leaf 0: <csv_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <P_user> OP_CHECKSIG

Semantics:

Key-path spend via Q → cooperative settlement: requires user+hub aggregate signature.
Script-path spend via Leaf 0 → CSV self-exit: user-only, no hub signature.

5.2 Cooperative Settlement Mode 1: User-Initiated

In Mode 1, the user explicitly decides to settle:

User triggers settlement
- Wallet calls "Settle shard".
Hub constructs settlement tx C_k
- Input: Acct(U) spent via key path Q.
- Outputs:
  - New shard UTXO Acct'(U) with updated value,
  - Hub anchor output for CPFP,
  - Optional external payout outputs.
Signing
- User provides a MuSig2 partial signature for C_k's input.
- Hub adds its partial signature; the combined signature authorises the key-path spend.
Broadcast
- Hub broadcasts C_k; uses anchor/CPFP if needed to ensure confirmation.

This is the straightforward cooperative spend where user and Hub both actively participate at settlement time.

5.3 Cooperative Settlement Mode 2: Recipient/Hub-Initiated via Pre-Signed PSBT

Mode 2 enables the recipient or Hub to finalise settlement later without requiring the payer to be online, while keeping the payer's consent cryptographically bound to the exact settlement transaction.

Key idea: at payment time, the user not only sends an off-chain payment intent but also contributes a partial signature to a PSBT encoding the matching on-chain commitment C_k.

Off-chain payment + PSBT preparation

When Alice pays Bob:
- The Hub builds or updates a PSBT template for C_k that:
  - Spends Acct(Alice) via key path Q,
  - Specifies the exact outputs (new shard, anchor, any external payout),
  - Corresponds to a specific shard nonce k.
- Alice's wallet:
  - Verifies the PSBT (input, outputs, amounts),
  - Produces a MuSig2 partial signature for this input,
  - Returns the signed PSBT (or partial sig) to the Hub.
This effectively means: "I, Alice, consent to this specific settlement transaction for state k."
Hub/recipient-initiated settlement

At some later time (e.g., end of day, risk-based triggers):
- Hub decides to settle C_k:
  - Marks shard as SETTLEMENT_PENDING at nonce k.
- Hub retrieves the stored PSBT for C_k, which already contains Alice's partial signature.
- Hub adds its own MuSig2 contribution, finalises the aggregate signature for input Acct(Alice), and transforms the PSBT into a valid Bitcoin transaction.
Broadcast & confirm
- Hub broadcasts the finalised transaction.
- From Bitcoin's perspective, this is indistinguishable from Mode 1: it is a cooperative key-path spend.
Security properties
- The user's partial signature is bound to:
  - A specific input (the current shard UTXO),
  - A specific set of outputs and values,
  - A specific shard state / nonce k.
- The Hub cannot repurpose the signature for any other transaction or state.
- The ledger + watchtower enforce latest-commitment-only policy:
  - Only C_k with k = nonce_latest is considered valid to broadcast.
  - Attempting to broadcast older C_j (j < k_latest) is detectable and treated as misbehaviour.

This mode is what enables:

Merchant- or Hub-driven settlement policies ("settle my inflows daily"),
Payers being offline when settlement actually hits the chain,
Without giving the Hub arbitrary spending power.

5.4 Unilateral CSV Self-Exit: User-Only Path

The third settlement mode allows the user to bypass the Hub entirely:

CSV timelock
- After csv_blocks have elapsed (relative to Acct(U)'s confirmation), the CSV script leaf becomes spendable.
Exit transaction
- Wallet constructs a transaction:
  - Input: Acct(U), spending via the CSV script:
```
<csv_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <P_user> OP_CHECKSIG
```
  - Output: a standard address controlled solely by the user.

User signs with P_user and broadcasts.

Post-exit
- Once confirmed, the shard is retired from ByteStream.
- Watchtower/Indexer marks the shard as CLOSED.
- Off-chain ByteStream balance for this shard becomes zero.

This path guarantees that no Hub behaviour (offline, malicious, or otherwise) can permanently lock or steal a user's funds.

5.5 Summary of Spend Modes

For each shard UTXO Acct(U):

Cooperative, user-initiated settlement – user online, co-signs; Hub co-signs; broadcast.
Cooperative, hub/recipient-initiated settlement – user pre-signed via PSBT at payment time; Hub finalises and broadcasts.
Unilateral CSV exit – user-only, no Hub involvement, after timelock.

All three are anchored in the same Taproot output and enforced by standard Bitcoin script semantics.

6. Off-Chain Ledger and State Machine

6.1 Ledger Model

The Hub maintains a strictly-controlled off-chain ledger built around:

Shards table (Acct(U) view):
- shard_id, user_id,
- funding_outpoint,
- state (e.g., UNFUNDED, OPEN, SETTLEMENT_PENDING, CSV_EXIT_PENDING, CLOSED, FROZEN),
- balance_sats,
- nonce_latest,
- current_commitment_id.
Commitments table:
- commitment_id,
- shard_id,
- nonce,
- psbt_template / tx_template,
- payer_partial_sig (if pre-signed),
- status (draft, ready, broadcast, confirmed),
- bitcoin_txid (if broadcast).
Event log (append-only):
- DEPOSIT_CONFIRMED,
- PAYMENT_INTENT_ACCEPTED,
- PSBT_PARTIAL_SIG_ATTACHED,
- SETTLEMENT_REQUESTED,
- COMMITMENT_BROADCAST,
- SETTLEMENT_CONFIRMED,
- CSV_EXIT_BROADCAST,
- CSV_EXIT_CONFIRMED,
- STALE_COMMITMENT_DETECTED, etc.

Shard state is a materialised view derived from replaying events through a deterministic state machine.

6.2 Shard State Machine (Overview)

Representative states:

UNFUNDED – shard address derived; no L1 funds confirmed.
OPEN – deposit confirmed; payments allowed.
OPEN_WITH_Cₖ – latest commitment Cₖ is recorded and PSBT partially signed.
SETTLEMENT_PENDING – latest Cₖ is selected for settlement; shard frozen.
SETTLED – Cₖ confirmed; new shard UTXO created; balances rebased.
CSV_EXIT_PENDING – CSV exit broadcast; awaiting confirmation.
CLOSED – exit confirmed; shard no longer used.
FROZEN/COMPROMISED – stale commitment or anomaly detected; further off-chain activity blocked.

Key invariants:

Nonce monotonicity per shard:

nonce_latest is strictly increasing and uniquely enforced by DB constraints.
Single live commitment per shard:

At any time, only one commitment_id per shard is considered "latest and valid".
Balance conservation:

Sum of off-chain balances + shard UTXO values (minus fees) is conserved.
Freeze-on-settlement:

Once SETTLEMENT_PENDING, no new payments are accepted for that shard until the settlement is resolved.

7. Payment Lifecycle (with PSBT Integration)

7.1 Funding a Shard

Shard creation
- Wallet+Hub derive Taproot construction for Acct(U):
  - Aggregate key Q,
  - CSV self-exit leaf.
- Shard address is generated and associated with shard_id.
Deposit
- User sends BTC to the shard address.
Confirmation & credit
- Watchtower detects confirmation.
- Event: DEPOSIT_CONFIRMED(shard_id, txid, amount, block_height).
- Hub applies:
  - state: UNFUNDED → OPEN,
  - balance_sats += amount.
UI
- Wallet displays updated ByteStream balance as available.

7.2 Off-Chain Payment + PSBT Pre-Signing

Example: Alice pays Bob amount sats.

Payment intent (client)
- SDK constructs:
  - sender_shard_id, recipient_shard_id,
  - amount,
  - nonce = nonce_latest_sender + 1,
  - Optional metadata (memo, ref).
- Alice signs the intent with her private key.
Hub validation
- Verify user signature and basic constraints:
  - Shard state is OPEN/OPEN_WITH_Cₖ,
  - nonce = nonce_latest + 1,
  - balance_sats_sender >= amount + reserves.
Ledger update
- Event: PAYMENT_INTENT_ACCEPTED.
- Hub atomically:
  - Debits Alice's off-chain balance,
  - Credits Bob's off-chain balance,
  - Sets nonce_latest_sender = nonce,
  - Creates or updates commitment Cₖ metadata in commitments.
PSBT preparation
- Hub constructs/updates a PSBT template for Cₖ:
  - Input: Acct(Alice) (key-path spend),
  - Outputs:
    - Acct'(Alice) with appropriate value,
    - Hub anchor output,
    - Optional external payout for this payment.
- Hub sends this PSBT (or a minimal subset) to Alice's wallet via the SDK.
Payer partial signing
- Alice's wallet:
  - Verifies the PSBT structure (input, outputs, amounts),
  - Produces a MuSig2 partial signature for the PSBT input,
  - Returns the partial sig (or updated PSBT) to the Hub.
- Hub stores:
  - psbt_template,
  - payer_partial_sig,
  - Marks commitment as status = ready.
Instant UX
- This entire flow is off-chain; no L1 transaction is broadcast.
- Alice sees her balance reduced, Bob sees his increased, instantly.

Result: For each payment state Cₖ, there now exists:

Off-chain ledger state, and
A fully defined on-chain settlement transaction template with the payer's partial signature already attached.

7.3 Cooperative Settlement (User- or Hub-Initiated)

Case A: User-initiated

User clicks "Settle" for their shard.
Hub:
- Emits SETTLEMENT_REQUESTED(shard_id, nonce_latest),
- Sets shard state to SETTLEMENT_PENDING,
- Retrieves the PSBT for Cₖ (already having payer_partial_sig or obtains it now if not yet cached).
Hub finalises:
- Adds its MuSig2 partial signature,
- Combines into final signature for input Acct(U),
- Finalises PSBT into a Bitcoin transaction.
Broadcast & CPFP as needed.
On confirmation:
- Watchtower emits SETTLEMENT_CONFIRMED.
- Hub updates:
  - funding_outpoint := outpoint(Acct'(U)),
  - state: SETTLEMENT_PENDING → OPEN,
  - status: Cₖ → confirmed.

Case B: Hub/recipient-initiated

Hub (or policies on behalf of recipient) decides to settle Cₖ:
- Conditions might be:
  - Cₖ above certain amount,
  - Time-based (end-of-day),
  - Risk-based thresholds.
Hub freezes shard:
- state: OPEN/OPEN_WITH_Cₖ → SETTLEMENT_PENDING.
Hub retrieves stored PSBT with payer_partial_sig, adds its contribution, finalises, and broadcasts as above.
Confirmation & rebasing proceed identically.

In both cases, settlement is a cooperative key-path spend; the only difference is who decides when to pull the trigger.

8. CSV Exit and Non-Custodial Guarantee

8.1 CSV Conditions

The CSV script leaf defines a relative timelock csv_blocks. After that many blocks since the shard's confirmation, the CSV path is valid.

8.2 Exit Procedure

Trigger conditions
- Hub offline or non-responsive,
- Stale commitment detected by watchtower,
- User chooses to fully exit ByteStream.
Wallet constructs exit transaction
- Input: Acct(U) spent via script path Leaf 0.
- Output: user-controlled address (P2TR/P2WPKH/etc.).
Signing & broadcast
- User signs with P_user.
- Broadcasts to Bitcoin.
Post-confirmation
- Watchtower emits CSV_EXIT_CONFIRMED.
- Hub transitions shard state to CLOSED and zeroes the ByteStream balance.

8.3 Security Properties

Hub cannot block CSV exits.
Users can always rely on L1 as long as they retain keys and Taproot script information.
The PSBT-based cooperative modes only allow more flexible settlement timing, not loss of control.

9. Threat Model & Security Considerations

9.1 Threats

Malicious Hub
- Attempts to broadcast stale commitments C_j with j < nonce_latest.
- Misreports off-chain balances or hides events.
- Goes offline indefinitely.
Malicious user
- Attempts double-spend by racing multiple payment requests.
- Attempts to broadcast a stale PSBT or commitment template.
Compromised watchtower
- Fails to report suspicious on-chain activity.
- Falsely flags or misses stale commitments.
Adverse network / L1 conditions
- High fees, full mempool, delayed confirmations.
- Blockchain reorgs affecting deposits/settlements/exits.

9.2 PSBT-Specific Risks

Signature misuse:

Payer's PSBT partial signature could be misused if it were not bound tightly to inputs/outputs.

Mitigation:
- Wallet signs PSBTs only after validating:
  - Input UTXO = current shard Acct(U) with expected script.
  - Outputs = expected new shard and expected payouts.
- PSBT fields are fully specified; no "blank outputs" that Hub can later modify.
- Payer's partial signature is stored alongside ledger state and tied to a specific nonce.
Stale PSBT broadcast:

Hub (or attacker) tries to broadcast C_j for j < nonce_latest.

Mitigation:
- Watchtower parses on-chain tx, extracts nonce, compares to nonce_latest.
- If stale, shard is marked FROZEN/COMPROMISED, alerts fired, CSV exit recommended.
- Post-MVP: revocation/penalty trees can allow on-chain slashing.

9.3 Ledger Integrity & Crash Recovery

Ledger uses an append-only event log:
- All events (payments, PSBT attachments, settlements, exits) recorded in order.
On restart:
- Events are replayed to rebuild shard state.
- Watchtower/Indexer replays L1 to cross-check:
  - Deposits confirmed,
  - Settlements confirmed/rolled back by reorg,
  - CSV exits.

Guarantees:

nonce_latest is never rolled back in a way that re-enables old commitments.
Any discrepancy between ledger and chain (e.g., settling tx reorged) is surfaced and resolved by deterministic reconciliation.

10. Implementation Architecture

10.1 Components

Hub / Ledger Service
- Language: Go/Rust/Typescript (implementation choice).
- DB: Postgres with single logical writer and synchronous replicas.
- Responsible for:
  - Event application, shard state machine,
  - Payment validation and PSBT handling,
  - Commitment construction & finalisation.
Watchtower / Indexer
- Connected to Bitcoin Core (RPC + ZMQ).
- Filters for shard scripts and settlement transactions.
- Publishes relevant events (deposits, settlements, exits, stale detection).
Wallet SDK
- Key management for users.
- Shard address derivation, payment intent signing.
- PSBT validation and partial signing.
- CSV exit construction.
Demo Web App
- Connects to Wallet SDK + Hub APIs.
- Exposes:
  - Deposit, send, settle, exit,
  - Balance breakdown: available / pending / settled.

10.2 Database Schema Sketch

events(id, type, shard_id, payload, prev_event_hash, event_hash, created_at)
shards(shard_id, user_id, funding_outpoint, state, balance_sats, nonce_latest, current_commitment_id)
commitments(commitment_id, shard_id, nonce, psbt_template, payer_partial_sig, status, bitcoin_txid)

Constraints:

Unique (shard_id, nonce) index.
Transactions ensure event, shard update, and commitment status change are atomic.

11. Comparison to Lightning and Other L2s

11.1 Lightning Network

Similarities:

Non-custodial design using Bitcoin scripts and timelocks.
Off-chain state updates with occasional on-chain settlement.
Use of CSV and penalty/detection ideas.

Differences:

Channel vs account model:

Lightning = per-peer channels with fixed capacity.

ByteStream = per-user shard + shared ledger.
Liquidity:

Lightning requires inbound/outbound capacity per channel; ByteStream uses a single account-style balance.
Routing:

Lightning has a decentralised payment routing graph.

ByteStream MVP uses a central Hub (with roadmap to federation).
PSBT-based settlement:

ByteStream builds per-state PSBTs with payer partial signatures so Hubs/recipients can settle on L1 without user being online.

11.2 Other Approaches

Statechains / Ark / Sidechains:

Conceptually related in that they keep off-chain state about ownership and only occasionally touch L1. ByteStream emphasises a simple account model and standard Bitcoin tooling (Taproot, PSBT, CSV).
Rollups / Validiums:

ByteStream is not a general-purpose smart contract rollup; it is a specialised payment/account L2 with a narrow, auditable state machine.

12. Roadmap & Extensions

Post-MVP features include:

Merkle-root anchoring of the event log or shard snapshots in Bitcoin for cryptographic auditability.
Multi-recipient batching of settlements to reduce per-user fee overhead.
BST token + stake-backed Hubs with slashing conditions tied to on-chain behaviour.
Federated Hubs running BFT consensus over the event log and jointly signing commitments (threshold MuSig2).
Cross-Hub routing for interoperability across independent Hub clusters.
Advanced revocation trees for automatic on-chain penalties on stale commitments.

13. Conclusion

ByteStream proposes a Bitcoin-native account layer where:

Users enjoy instant, account-style payments,
Funds are protected by Taproot shard UTXOs with CSV exits, and
Cooperative settlement is flexible thanks to PSBT-based pre-signing, giving Hubs/recipients the ability to settle without sacrificing non-custodial guarantees.

By grounding the design in standard Bitcoin primitives and a clear shard state machine, ByteStream offers a realistic path from a single Hub MVP to a more decentralised, resilient payment network without ever straying from Bitcoin's trust model.