---
title: "BTX: A Peer-to-Peer Computational Settlement System"
description: "Specifications document for the BTX protocol covering settlement objects, shielded settlement wind-down, proof-of-useful-work, network relay, incentive design, layered bridges, governance, and security model"
date: 2026-08-05
type: specifications-document
author: BTX Developers
contact: team@btx.dev
---

# BTX: A Peer-to-Peer Computational Settlement System

**BTX Developers**
team@btx.dev

---

## Release addendum -- 5 August 2026

The historical sections below remain part of the BTX design record. The current published implementation is [BTX v0.33.2](https://github.com/btxchain/btx/releases/tag/v0.33.2), source commit `b4671ec28bb24e2fcbdd8252576119d54fd95238`. Its mainnet consensus schedule keeps MatMul v3 below height 185,000 and atomically activates MatMul v4.7 Epoch A at height 185,000. The v4, BMX4C, and Resident Curriculum selectors change together. Testnet and signet leave the v4.7 heights disabled.

Epoch A uses Profile 1 ExactReplay with four sequential rounds, 16 FFN layers per round, consensus MatMul dimension 4,096, batch-sequence 16,384, 1,024-byte Merkle leaves, and 141,149,805,215,744 exact MACs per episode. The header remains a fixed 182-byte digest-only object. Complete deterministic replay is the authority for every claimed Epoch-A block. Production mining, winner reseal, and independent consensus validation require a qualified strict-device CUDA or Metal provider with zero CPU GEMM fallback. CPU replay is retained only for explicit pre-activation testing and operator-led diagnosis.

The release installs a one-time Resident Curriculum ASERT policy coefficient of 6,931,159,304 / 1 at the transition; the v4 and BMX4C ratios remain 1/1. Profile 2, Coupled-V3, HeaderPoW/DRLT, and unfinished Stage-3 succinct-proof authority are not activated by v0.33.2. Profile 2 remains a future height-versioned direction: eight rounds, 24 FFN layers, batch-sequence 87,552, 4,096-byte leaves, and roughly 16 times the Profile-1 episode work.

v0.33.2 also introduces explicit trusted RPC/archive mirrors. A trusted mirror validates headers, full block bodies, transactions, scripts, and state but accepts an M-of-N quorum of context-bound ExactReplay attestations instead of replaying MatMul locally. It is not an independently validating MatMul full node. Two distinct signers with threshold 2 are strongly recommended; the supported 1-of-1 mainnet mode starts with a prominent warning. The canonical implementation and operator documents under the v0.33.2 source tag are authoritative where this older paper differs.

---

## Abstract

Computational finance is the execution and settlement of financial obligations among participants that may not share an operator, a jurisdiction, or a prior trust relationship. In that environment, settlement rules must be machine-verifiable, spend authority must be delegable without discretionary approval at execution time, and the settlement surface must remain stable across participant classes. BTX is a peer-to-peer settlement system designed for that environment. The protocol combines matrix-multiplication proof-of-work, post-quantum spend policies, shielded-state exit and recovery support, privacy-preserving relay, and a bridge-first layered architecture. The base layer is intentionally narrow: it orders settlement instructions, enforces spend conditions, maintains transparent settlement state plus supported shielded wind-down state, and publishes a public work benchmark through its difficulty process. Higher-layer systems such as bank ledgers, exchanges, bridge operators, and agent coordination services settle against that base without sharing a global runtime. This paper specifies the principal settlement model and transaction format, shielded wind-down model, work construction, relay and admission interfaces, incentive surface, layered-settlement design, and inherited longest-chain security assumptions. Context and motivating use cases are described separately in the companion BTX Context Document [1].

---

## 1. Introduction

Administrator-dependent financial systems fail predictably at the margin. Access conditions vary by participant, institution, and jurisdiction, and those variations accumulate into architecture. BTX removes that discretionary layer at the point of final settlement. Whether submitted value reaches final settlement depends on protocol-valid spend conditions and accumulated work, not on administrative preference.

Existing digital-asset systems broadly follow one of two models. The first retains a narrow base-layer settlement model and leaves disclosure boundaries, key evolution, and application design to adjacent systems. The second exposes a broad shared runtime and asks applications to share a global fee market and execution environment. BTX adopts a third model: the base layer remains narrow, but bounded authority, post-quantum spend control, supported shielded exits, and layered settlement interfaces are treated as first-class protocol concerns.

The protocol components used by BTX predate BTX individually. Matrix-multiplication useful work, post-quantum signatures, confidential-transaction techniques, stem-and-fluff relay, covenant-style constraints, and oracle-signature conditions each exist as prior research results, standards, or implementation families [2--6]. BTX assembles them into one public settlement layer with a specific operating profile:

- final settlement remains on a longest-work chain;
- spend authority is expressed through constrained post-quantum output policies;
- confidential-settlement machinery exists in consensus, with current production use limited to wind-down exits and recovery;
- the relay layer reduces passive origin inference;
- higher-layer operators settle above the chain rather than inside one shared runtime.

This architecture is aimed at participants crossing trust, accounting, or jurisdictional boundaries: institutions, exchanges, bridge operators, market-makers, software services, and autonomous agents. The protocol makes one commitment that applies to all of them: the rules of settlement are identical for every participant. Any participant satisfying the spend conditions can settle. Any participant not satisfying them cannot.

## 2. Settlement Objects and Spend Policies

A BTX transaction is the encoded form of a settlement instruction under a constrained, machine-readable spend policy. Public BTX networks standardise on witness-version-2 Pay-to-Merkle-Root (P2MR) outputs. A P2MR output commits to a compact Merkle tree of authorised spend paths. The default profile contains an ML-DSA primary leaf for routine use and an SLH-DSA backup leaf with independent cryptographic assumptions. Optional leaves encode template-constrained or oracle-assisted conditions. The grammar is intentionally narrow.

The narrowness of the grammar is a security property. At the point where value moves, both human and machine implementations benefit from a small set of explicit spend forms rather than an open-ended execution environment. Output meaning is committed at creation time. Counterparties, operators, and validating nodes can evaluate the same object without importing application-specific semantics.

The current default leaf roles are:

| Leaf | Role |
|------|------|
| ML-DSA-44 | Primary spend path; routine and agent use |
| SLH-DSA-128s | Recovery path; independent assumptions |
| CTV leaf | Template-constrained vault or bridge path |
| CSFS leaf | Oracle-verified conditional close |
| Threshold | Multi-party coordinated custody |

Both signature algorithms are post-quantum standards: ML-DSA per FIPS 204 and SLH-DSA per FIPS 205 [5, 6]. BTX adopts them from genesis rather than treating quantum migration as a later upgrade problem. Operators subject to quantum-readiness requirements therefore build on a system whose spend surface is already aligned with the current standards trajectory.

To receive funds, a participant generates a post-quantum key pair and derives an address. To spend, the participant satisfies one of the committed leaf conditions. Validation does not consult an operator, registry, or institutional approval surface. Either the path is valid under consensus or it is not.

The spend policy is therefore the unit of economic authority. It is delegated in advance, bounded in advance, and verified at spend time by consensus. This matters for autonomous participants in particular. A principal can commit a financial scope before deployment; counterparties can verify that scope at settlement time; no one needs to rely on out-of-band approval in the middle of execution.

## 3. Shielded Settlement Wind-Down and Selective Disclosure

BTX included a SMILE v2 shielded settlement pool from genesis. In the current production deployment, the shielded pool is in sunset and wind-down. Shielded pool credits and new appends are disabled at height 125000. Public-flow shielding is disabled at height 128000. The velocity quota ends at height 135000. Strict z-to-transparent exits and shielded-state recovery remain supported.

The historical shielded design covered three surfaces:

- public entry into the shielded pool;
- private transfer inside the pool;
- shielded-to-transparent unshielding.

The first two surfaces are not active production paths in the v0.33 release line. New public entries into the shielded pool, private transfers inside the pool, additional shielding of already-shielded value, bridge-scale shielded inflows, and shielded block-reward flows must not be treated as available production paths. The active production claim is narrower: existing shielded state can be recovered and exited to transparent settlement under strict validation.

The original public-entry design was a proofless path. That design remains part of the historical model, but public-flow shielding is disabled after height 128000. Any software or public documentation describing shielded operation should therefore distinguish the archived design from the current production rules.

The shielded state model is designed so that recovery depends on chain data rather than permanent wallet retention of full note history. An account registry commits shielded account-leaf payloads into consensus state. Witnesses are compact: leaf index, commitment, and sibling path. Full nodes reconstruct authenticated public account state from consensus-visible data. The aim is to make shielded state recoverable from the chain alone, subject to possession of the relevant viewing or spending material.

Selective disclosure remains a property of the shielded model where shielded state exists. A participant may disclose to a particular auditor, regulator, or counterparty the specific view material required for that relationship without disclosing the full transaction history to the network at large. This is not a claim of absolute invisibility, and it is not a claim that current production settlement uses private settlement as its ordinary mode. Endpoint compromise, physical coercion, and privileged observation remain outside the protocol's control.

Transparent settlement is the current production path for new ordinary activity. Supported shielded operations are strict exits and recovery for shielded state during wind-down.

## 4. Timestamp Server and Chain of Work

Transactions are timestamped by inclusion in blocks. Blocks form a chain in which rewriting history requires redoing all subsequent work. The authoritative chain is the one with the greatest accumulated valid work, not the one with the greatest block count [2].

A BTX block header commits to the previous block hash, the transaction Merkle root, timestamp, target, nonce, and the fields binding the matrix-multiplication work transcript to the candidate block. Target spacing is 90 seconds. After the 50,000-block bootstrap boundary, difficulty adjusts per block using ASERT rather than coarse retarget epochs.

The operational consequence is standard longest-chain settlement. A transaction's place in history depends on a public sequence of work, not on an institution's internal record. The arbiter is the chain itself.

## 5. Proof-of-Useful-Work

Below mainnet height 185,000, BTX implements MatMul v3 proof-of-work as matrix multiplication over the finite field F_(2^31 - 1) [3]. At and above height 185,000, the v0.33.2 release addendum above is authoritative: MatMul v4.7 Profile 1 ExactReplay replaces this legacy construction. The retained v3 work function is chosen to satisfy two requirements simultaneously:

1. a valid proof must remain cheap to reject and tractable to verify by the network; and
2. producing a valid proof must require present computation tied to current chain state.

The second property is what BTX refers to as *computational liveness*: a valid proof of work is simultaneously evidence that the prover is actively computing now, against a current challenge, rather than replaying a credential or expending value from a pre-funded balance.

Let p = 2^31 - 1. Base matrices A, B in F_p^(n x n) are derived deterministically from chain state. Rank-r perturbation matrices E, F in F_p^(n x n), derived from the candidate header and nonce, prevent selection of favourable instances and precomputation. The miner computes:

> C' = (A + E)(B + F)

A candidate block is valid only if:

> H(A + E || B + F || C') < target

where H is the block hash function and || denotes serialised concatenation. Because E and F depend on the candidate header and nonce, the full transcript cannot be prepared independently of present chain state.

Full product verification uses Freivalds' algorithm. The verifier chooses a random vector **r** and checks:

> (A + E)((B + F)**r**) = C'**r**

This reduces full verification cost from cubic to quadratic time, with soundness error approximately 1/p per check; repeated independent checks drive the error to negligible levels.

The validation pipeline is split deliberately:

- header-level rejection is cheap;
- full transcript verification is more expensive but bounded;
- expensive verification is rate-limited as part of the node-security model.

Legacy MatMul v3 network parameters are:

| Parameter | Mainnet | Testnet | Regtest |
|---|---|---|---|
| Matrix dimension *n* | 512 | 256 | 64 |
| Noise rank *r* | 8 | 4 | 4 |
| Transcript block *b* | 16 | 8 | 8 |
| Validation window | 1000 | 500 | 10 |

The work function has an additional economic consequence. Hardware securing BTX remains useful outside mining in AI and numerical-compute markets. The protocol does not claim that all mining hardware is interchangeable with all productive workloads; the narrower point is that the dominant computation class overlaps materially with productive compute markets, so mining capital need not be economically stranded when mining conditions change.

This same work function is reusable above the chain. A service can require a participant to present a fresh work proof tied to current network conditions. Unlike a pure fee gate, such a proof cannot be prepaid in bulk and amortised across requests without performing the actual computation. Difficulty can therefore be calibrated to the resource being requested.

## 6. The Difficulty Commons: Network Utility Without Token Ownership

BTX publishes, through its live chain state, a continuously updated measure of the work required to produce a valid proof under current network conditions. The chain exposes current target difficulty, recent timing, and derived work metrics to any participant operating a node.

This public benchmark is what BTX refers to as the *difficulty commons*: a tamper-evident, permissionless measure of the current cost of computation as expressed through the network's work market. It is not a price oracle, and it is not a complete market-clearing cost model for all compute markets. It is a public benchmark derived from open competition in proof production.

That benchmark is useful even to participants who never hold or transfer BTX:

- an API service can calibrate work-ticket difficulty against the live chain rather than a static threshold;
- a relay operator can tie anti-spam requirements to current network work conditions;
- two autonomous parties can use the same public benchmark when evaluating one another's liveness tickets;
- researchers and auditors can read the full historical record of the network's work difficulty directly from the chain.

The protocol therefore produces utility for non-holders as well as holders. Any participant can read the benchmark without account creation, operator permission, or token ownership.

## 7. Network, Relay, and Admission Control

At the base layer, BTX follows standard longest-chain network behaviour:

1. new transactions are broadcast to the network;
2. nodes collect transactions into candidate blocks;
3. miners search for valid work on those candidates;
4. a node finding valid work broadcasts the new block;
5. peers validate the block's transactions, spend conditions, supported shielded-exit proofs when present, and work transcript;
6. accepted blocks are extended by later blocks.

Nodes always treat the chain with the greatest accumulated valid work as authoritative. Competing branches resolve when subsequent blocks extend one branch and not the other.

BTX uses Dandelion++-style stem-and-fluff transaction propagation [4]. This is a relay-layer privacy measure, not a consensus rule. In the current public-network deployment profile, Dandelion++ activates at block 250,000 after the network has established more stable peer relationships. The purpose is modest and specific: to reduce the ease with which passive observers can correlate a transaction with its originating node. It does not claim perfect origin anonymity.

Above the base layer, BTX work proofs can be reused as admission tickets. A bridge, relay, or service can require a proof of current work before accepting a request. This differs from fee-gated or balance-gated admission in one key respect: a valid ticket proves not only that the requester holds an identity key, but also that the requester has expended fresh computation now, against current network conditions. That raises the marginal cost of nuisance traffic in direct proportion to request volume.

This admission model is an application-layer use of the chain's work primitive. It is not required for ordinary transaction validation, but it is a designed interface enabled by the proof-of-useful-work construction.

## 8. Incentive and Distribution

BTX has a fixed maximum supply of 21 million units, an initial subsidy of 20 BTX, and halvings every 525,000 blocks. Transaction fees supplement the subsidy. These monetary rules are consensus rules enforced by full nodes; changing them requires a public fork adopted by participants [2].

All ordinary issuance occurs through valid work. Units are not created by administrative allocation at the protocol layer. A participant with a connected node and valid work competes on the same issuance surface as every other participant.

The initial 50,000 blocks are produced at compressed cadence to establish chain depth and seed the network into active use. Units produced during this phase are held in a genesis multisig designated for network formation, including bridge seeding, relay infrastructure, and early market depth. The chain records both production and subsequent disbursement activity. The intended distinction from a conventional protocol-level pre-allocation is that these units are produced by open work and then managed through explicit on-chain holdings rather than being created outside the issuance process. Because this bootstrap mechanism is economically material, its operating policy should be documented separately and precisely for operators evaluating governance risk.

BTX is intended to function as settlement currency. Its supply is fixed, its issuance is work-based, and its work surface is tied to productive computation rather than to a purely synthetic hash race. That does not make BTX price-stable in the managed-currency sense. The narrower claim is that the unit is scarce by rule, issuable only by work, and economically anchored to computation markets.

## 9. Layered Settlement and Bridges

BTX is a settlement base layer, not a monolithic application environment. The base layer timestamps and orders commitments, enforces spend rules, maintains transparent settlement state and supported shielded wind-down state, and exposes interfaces on which higher-layer systems can rely. Matching engines, local ledgers, bank liabilities, exchange internals, and high-frequency logic remain above the chain.

Layer-2 bridges are therefore expected rather than exceptional. A bridge operator can maintain a specialised local environment with its own throughput, privacy, risk controls, and user surface, then settle net obligations against BTX when balances cross trust or accounting boundaries. Different operators need not share one runtime, one codebase, or one governance surface in order to interoperate at final settlement.

Current consensus-visible bridge commitments include `BridgeBatchStatement` (version 5) and `BridgeBatchCommitment` (version 3), carrying authenticated roots such as:

- `action_root`
- `data_availability_root`
- `recovery_or_exit_root`
- `policy_commitment`
- `extension_digest`

These fields are committed from genesis. Their presence is a current protocol fact. Not all higher-level semantics against those fields are active today. In particular, future soft forks may further define the semantics of recovery and individual exit claims against `recovery_or_exit_root` without changing the fact that the authenticated commitment surface already exists.

Transaction data is bounded from genesis by fixed envelope limits. The design objective is to keep bridge settlement data explicit and authenticated without converting the base layer into a general-purpose execution environment.

### Mass exit capacity

Layered systems fail most severely when entry is easy but exit becomes slow, discretionary, or operator-gated under stress. BTX is designed to avoid turning exit into a purely operator-dependent event. The current architecture supports three distinct egress modes:

- cooperative batch settlement;
- refund issuance without requiring the bridge to remain solvent or continuously available;
- timeout-triggered refund paths that allow users to claim against the base chain after a protocol-defined interval.

The current v2 egress proof is compact and fast to verify. Exit capacity is therefore constrained primarily by blockspace and batching policy rather than by an inherently long proof-verification bottleneck. The protocol does not impose an optimistic-rollup-style multi-day fraud window by design.

This is a core layered-settlement claim of BTX: operator efficiency and credible user exit are not treated as mutually exclusive design goals.

## 10. Development Model and Governance

BTX adopts a narrow-core governance philosophy. Changes to the reserve layer are intentionally difficult, explicit, and reviewable. Higher-layer systems are expected to evolve more quickly. The protocol design rejects the idea that application demand should routinely rewrite consensus.

This governance posture follows from the settlement role of the base layer. Institutions, operators, and autonomous systems can build above a chain only if the chain's fundamental monetary and settlement surface is predictable. A system whose core rules are continuously contestable under ordinary political or market pressure is a poor settlement base, regardless of how flexible it appears in the short term.

The development model is correspondingly test-driven and specification-oriented. A small number of output types, disclosure mechanisms, work rules, and bridge interfaces is easier to specify, test, audit, and refine than a platform whose behaviour expands through an unbounded runtime surface.

BTX also adopts a constrained understanding of technical claims. Confirmation remains probabilistic. Privacy is tactical and bounded, not metaphysical. Decentralisation is a distribution of verification and control, not a slogan. These are engineering properties and should be evaluated as such.

### Neutral incentive structure

The issuance rules are uniform. No participant receives units outside the work process by protocol privilege. No operator can redirect subsidy by administrative decision. Any post-hoc change to supply or issuance would require a visible public fork. That neutrality matters for human and non-human participants alike: no one can gain by persuading an administrator to alter the issuance surface in their favour.

### AI alignment at the economic layer

BTX does not solve inner alignment. It does not determine an autonomous system's goals. The narrower and more defensible claim is that BTX provides conditions for *AI alignment at the economic layer*: a participant's financial scope can be bounded before action, its on-chain financial behaviour can be audited afterward, and the rules governing its participation are the same rules governing everyone else. For autonomous systems expected to operate under externally reviewable financial constraints, that is a meaningful infrastructure property.

## 11. Security Model and Confirmations

BTX inherits Bitcoin's longest-chain security model [2]. An attacker controlling less work than the honest network cannot cause honest nodes to accept invalid transactions or create value from nothing. The standard Nakamoto random-walk assumptions apply: honest and attacker block-production processes are modelled as Poisson processes with rates proportional to their share of total work.

Let *p* be the probability that the honest network finds the next block, *q* the probability that the attacker finds it, and *q_z* the probability that the attacker catches up from *z* blocks behind:

> q_z = 1, if p <= q
>
> q_z = (q/p)^z, if p > q

If the recipient waits for *z* confirmations and the attacker's expected progress is lambda = z(q/p), the remaining probability of a successful attack is:

> 1 - sum(k=0..z) [ (lambda^k * e^(-lambda)) / k! ] * (1 - (q/p)^(z-k))

At 90 seconds per block, confirmation waiting times are shorter than in Bitcoin while preserving the same logic of risk reduction through accumulated work.

| q | z | Wait (90 s) | Attack prob. |
|---|---|---|---|
| 0.10 | 6 | 9 min | ~2.4 x 10^-4 |
| 0.20 | 11 | 16.5 min | < 10^-3 |
| 0.30 | 24 | 36 min | < 10^-3 |
| 0.40 | 52 | 78 min | < 10^-3 |

The 50,000-block bootstrap phase increases early history depth and therefore the cost of wholesale reordering. Ordinary settlement security thereafter depends on standard confirmation accumulation. Participants choose depth according to value at risk: short machine-to-machine flows may tolerate shallow depth; large institutional transfers may require substantially more.

BTX isolates many higher-layer failures but does not deny them. A bridge can become insolvent. A venue can misprice risk. A local operator can fail. The chain's role is narrower: it provides a neutral settlement layer beneath those failures so they remain local rather than corrupting final settlement itself.

## 12. Conclusion

BTX is a constrained public settlement layer for institutions, operators, and autonomous agents that require final settlement under fixed rules rather than administrative discretion. It retains longest-chain settlement while combining four principal design choices: matrix multiplication replaces hash-only work; post-quantum spend paths replace legacy signature assumptions; supported shielded exits and selective disclosure preserve an explicit privacy boundary during wind-down while current new ordinary activity uses transparent settlement; and bridges and local ledgers replace the assumption that all application logic must share one global runtime.

The base layer is narrow by design. It orders settlement instructions, enforces spend conditions, maintains transparent settlement state plus supported shielded wind-down state, and publishes a public work benchmark. Higher-layer systems remain free to specialise above it without surrendering to one shared execution environment.

The resulting network provides a settlement surface with three notable operational properties. First, the work function is economically meaningful outside mining, reducing the degree to which security expenditure is isolated from productive compute markets. Second, valid work is tied to present chain state, making proof of work usable as evidence of current computation. Third, layered systems can settle against a neutral base while preserving harder exit rights than operator-dependent financial stacks typically offer.

The barrier to participation remains minimal: a node, keys, and a use for final settlement. The rest is built above.

## References

1. BTX Developers, "BTX: The Protocol of Record -- Context Document," March 2026.
2. S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008.
3. I. Komargodski and O. Weinstein, "Proofs of Useful Work from Arbitrary Matrix Multiplication," *arXiv preprint arXiv:2504.09971*, 2025.
4. G. Fanti, S. B. Venkatakrishnan, S. Bakshi, B. Denby, S. Bhargava, A. Miller, and P. Viswanath, "Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees," *Proc. ACM Meas. Anal. Comput. Syst.*, vol. 2, no. 2, article 29, 2018.
5. National Institute of Standards and Technology, "FIPS 204: Module-Lattice-Based Digital Signature Standard," 2024.
6. National Institute of Standards and Technology, "FIPS 205: Stateless Hash-Based Digital Signature Standard," 2024.
7. W. Feller, *An Introduction to Probability Theory and Its Applications*, vol. 1, 2nd ed. Wiley, 1957.