What is BATHRON?

BATHRON is a settlement kernel for Bitcoin.

It provides a shared settlement state anchored to Bitcoin.

• Bitcoin remains the source of truth. The chain reads Bitcoin — headers, payments, difficulty — inside consensus, with no oracle and no federation.
• Consensus maintains the settlement state. Deterministic block production, BFT finality in about a minute, private transfers.
• An open market provides native BTC liquidity. Settlement Providers compete on fees. The protocol never sells anything.

BATHRON is infrastructure. Applications are built on top of it.

Where to go next

• Getting Started — run a node, run a wallet, build on the chain.
• Learn — how the pieces fit together, starting with the architecture. No code.
• Build — the SDK and RPC API for developers.
• Reference — the details: transaction types, opcodes, invariants.

Status: experimental. A private testnet is running; a public testnet is next. Consensus additions are frozen before any mainnet.

Run a node

The network currently runs as a private testnet. You can build and run the node today; published peers, genesis and a faucet ship with the public testnet — the next milestone. Contact us if you want early access.

Build from source

On Debian/Ubuntu:

sudo apt-get install -y build-essential libtool autotools-dev automake pkg-config \
    libssl-dev libevent-dev bsdmainutils python3 libboost-all-dev libsodium-dev libzmq3-dev

./autogen.sh
./configure --without-gui --disable-tests --disable-bench
make -j$(nproc)

This produces two binaries:

Run

bathrond -testnet -daemon

The node stores its data in ~/.bathron/. Configuration goes in ~/.bathron/bathron.conf (peers, RPC credentials).

Verify

bathron-cli -testnet getblockcount        # chain height
bathron-cli -testnet getstate             # global settlement state + invariants
bathron-cli -testnet getfinalitystatus    # finality lag (healthy = 0)
bathron-cli -testnet getbtcheadersstatus  # in-consensus Bitcoin header chain

A healthy node produces a new block every 60 seconds network-wide, finalizes with lag 0, and tracks the Bitcoin header chain inside consensus.

Run a wallet

The wallet is built into the node — there is no separate wallet binary. As a user you send and hold satoshis; the internal M0/M1 mechanics are an implementation detail (how the money works).

Addresses

bathron-cli -testnet getnewaddress          # transparent address
bathron-cli -testnet getnewshieldaddress    # shielded address (private)

Sending

# transparent
bathron-cli -testnet sendmany "" '{"<address>": 10000}'

# shielded — amounts and balances hidden
bathron-cli -testnet shieldsendmany "<from>" '[{"address":"<shield-addr>","amount":10000}]'

Inspecting

bathron-cli -testnet getwalletstate true    # balances, including settlement receipts

Getting funds

Every circulating unit originates from provably burned Bitcoin — there is no faucet key, no premine, no issuer. On the public testnet, funds come from burning testnet BTC (Bitcoin integration) or receiving them from someone who did.

Run a Settlement Provider

A Settlement Provider (SP) sells native BTC liquidity to users of the settlement state, competing on fees in an open market. The protocol never sells anything — SPs do. If you understand market making, you understand the role. Details: Settlement Providers.

What an SP operates

The lifecycle of a quote

1. You publish a price for BTC ⇄ settlement-state value.
2. A user takes the quote.
3. The trustless machinery does the rest: the user's Bitcoin payment is proven inside consensus (SPV), a covenant releases the counter-payment, and the return leg settles as an atomic swap. You never custody user funds — and users never custody yours.

Your earnings are the spread. Your risk is inventory and pricing — not counterparty default: an unfinished swap refunds, it does not lose money.

Reference implementation

A reference SP implementation (quoting service, swap API, dashboard) is running on the private testnet and will be published with the public testnet.

Interested in running one? Contact us.

Build your first application

An application on BATHRON is not a smart contract in the EVM sense. It is a covenant: a script that constrains how value can move, enforced by every node. You compose it from a small set of strong primitives.

The shape of every application

1. Lock value under a script. Funds go to a script hash whose spending conditions you wrote.
2. State the release conditions. The script can require signatures, preimages, timeouts (CSV/CLTV), a forced destination (CTV), an oracle signature (CSFS) — or a proven Bitcoin fact (TX_CONFIRMED): release when this Bitcoin payment is confirmed.
3. Anyone can trigger settlement. When conditions are met, the spend is valid; consensus enforces the outcome. No server, no operator.

A minimal example — conditional payment on a Bitcoin fact

"Pay Bob as soon as Alice's Bitcoin transaction is confirmed; refund me after 24 hours otherwise."

• One path: proof that the Bitcoin transaction is buried under the in-consensus header chain (TX_CONFIRMED) + a CTV template that forces the payout to Bob.
• Other path: a CSV relative timelock returning funds to you.

This one pattern — a proven Bitcoin fact releases a covenant — is the engine under escrow, DvP and OTC settlement.

Tooling

Today the developer surface is the node's RPC API plus the script engine (opcodes). A higher-level SDK is in development and ships with the public testnet.

Architecture

The whole system is one vertical flow:

        Bitcoin
           │
           ▼
         Burn
           │
           ▼
  Shared settlement state
           │
           ▼
      Applications
           │
           ▼
  Settlement Providers
           │
           ▼
     Native Bitcoin

Bitcoin

The source of truth. BATHRON carries the Bitcoin header chain inside its own consensus: every node validates Bitcoin proof-of-work and chainwork, and scripts can verify Merkle proofs against it. No oracle reports Bitcoin facts — the chain checks them itself. → Bitcoin integration

Burn

The only way value enters. Bitcoin is sent to a provably unspendable output; after enough confirmations, an SPV proof of that burn mints the same amount on BATHRON, satoshi for satoshi. Irreversible, verifiable by everyone, with no issuer. → Monetary invariants

Shared settlement state

The kernel itself: one state, maintained by consensus, that all applications read and write. Deterministic block production every 60 seconds, BFT finality in about a minute, shielded transfers for privacy. → Consensus, Privacy

Applications

Covenants written against the settlement state: payments, escrow, DvP, vaults, OTC. They are scripts enforced by every node — not services run by anyone. → Applications

Settlement Providers

The exit to native BTC. An open market of providers quotes prices and supplies Bitcoin liquidity, competing on fees. The protocol never custodies and never sells. → Settlement Providers

Native Bitcoin

Where users end up. Bitcoin sees two transactions — one in, one out. BATHRON executes everything in between.

Consensus

Two separate layers, deliberately kept apart:

Validator selection

Validators are masternodes backed by collateral in burned BTC — Sybil resistance is an up-front, real-world cost. One operator can run several masternodes but counts once: the unit of consensus is the operator key, not the machine.

Block production

A deterministic pseudo-random draw designates each block's producer — every node computes the same result from the previous block hash, with no communication and no mining. One block every 60 seconds. If the designated producer is absent, a fallback schedule lets the next in line produce: the chain never stalls on a missing node.

Finality

Finality comes from a per-operator committee, redrawn at every block by verifiable random function (ECVRF). Each selected operator publishes a VRF proof with its signature; everyone verifies the draw. The committee input is public, but the output depends on each operator's secret key — so nobody, including the block producer, can predict or grind the committee.

The threshold is ⌈2/3 · min(E, N)⌉ where N is the operator count and E a fixed committee cap — the same rule scales from a handful of operators to hundreds without retuning. One round of signatures, ~1 minute to irreversibility. Once final, a block cannot be reorganized — finality overrides the longest chain.

State transition

Finality sits on top of full block validation, never instead of it. Every node fully validates every transaction; a quorum — even a hypothetically malicious one — cannot mint value, break the monetary invariants, or confirm an invalid transaction. What the signers control is ordering, never the money.

Script engine

Bitcoin Script, extended with the covenant opcodes Bitcoin has debated for a decade — templates, introspection, oracle signatures, Bitcoin-fact verification. → Script & opcodes

Issuance

There is none. block_reward = 0, no treasury, no premine. The coinbase pays exactly the block's fees — the fee-only security regime Bitcoin reaches around 2140, running today. All value originates from verified BTC burns.

Design choices

• ECDSA on secp256k1 only. No BLS, no aggregated signatures — explicit signatures are simpler to audit at these committee sizes.
• No slashing. Deliberate: a slashing bug can destroy honest operators' funds. Deterrence is the burned-BTC collateral (paid up front) plus proof-of-service bans (loss of future fees).

Bitcoin integration

This is the load-bearing chapter. Everything BATHRON claims — no oracle, no federation, honest issuance — reduces to one capability: the chain sees Bitcoin, inside consensus.

Headers

Bitcoin block headers are carried onto BATHRON in ordinary transactions and stored in an in-consensus header database. Every node independently validates each header's proof-of-work, difficulty adjustment and accumulated chainwork — exactly like a Bitcoin SPV client, except the client is the consensus. Reorgs on Bitcoin are followed by chainwork, like any Bitcoin node would.

SPV

With the header chain in consensus, any Bitcoin transaction can be proven with a Merkle branch: the proof shows the transaction is included in a block buried under the accumulated work of the real Bitcoin chain. No one attests to this — every node checks it.

Burn

The entry point for all value. Bitcoin is sent to a provably unspendable output, tagged with a destination on BATHRON. After enough confirmations, an SPV proof of the burn mints the same amount — one burned satoshi becomes one satoshi, with no issuer and no discretion. → Monetary invariants

Proofs in scripts

The same machinery is exposed to programs. A covenant can require proof that a specific Bitcoin payment is confirmed — and release funds the moment it is:

Alice pays on Bitcoin ──▶ proof lands on BATHRON ──▶ covenant releases
                         (Merkle proof, checked
                          by every node)

This is the primitive under the flagship use case: a Bitcoin fact unlocks a contract, verified by consensus, with no operator, oracle or custodian.

Difficulty, time, chainwork

Scripts can also read Bitcoin's difficulty, timestamps and accumulated work from the in-consensus header chain. This is what makes an oracle-free miner hedge possible: the settlement condition is Bitcoin's own difficulty, not anyone's price feed. → Miner hedging

What the link is — and is not

The link is one-directional and honest. BATHRON can read Bitcoin (headers, proofs) and consume Bitcoin (burns, irreversible). It cannot move native BTC or trigger a Bitcoin transaction. The only fully-trustless direction is BTC → BATHRON; the return to native BTC goes through an open market of Settlement Providers, atomically. BATHRON settles against Bitcoin; it does not command it.

Settlement Providers

Ten seconds of mechanism first:

        Alice                          Settlement Provider
          │                                     │
          │  wants native BTC                   │  quotes a price
          │                                     │
          ▼                                     ▼
          ────────────  the swap  ───────────────
          │                                     │
   Alice pays on the                   SP pays native BTC
   settlement state                    on Bitcoin
          │                                     │
          └────────── one shared secret ────────┘
                 claiming either leg reveals it —
                 both legs settle, or neither does

No custody, no credit, no counterparty risk: an unfinished swap refunds, it does not lose money.

Who are Settlement Providers?

Market makers. Anyone holding native BTC who wants to earn a spread can quote prices for moving value between Bitcoin and the settlement state. There is no license, no whitelist, no protocol-blessed operator.

Why do they exist?

Because the protocol refuses to do their job. BATHRON can read and consume Bitcoin but cannot move it — so native BTC liquidity must come from someone who has it. Making that someone an open, competing market (rather than a federation, a bridge, or the protocol itself) is a design decision: liquidity is an economic problem, and markets solve economic problems.

How do they earn fees?

The spread between their quoted price and par. Competition between SPs compresses it. The protocol takes nothing.

Liquidity and inventory

An SP manages two inventories — native BTC on one side, settlement-state value on the other — and rebalances via burns (in) and its own swaps (out). Pricing that inventory is the SP's actual craft; the protocol guarantees only that settlement is atomic.

API and reference implementation

A reference SP — quoting service, swap API, dashboard — runs on the private testnet and will be published with the public testnet. The API surface is small: publish quotes, accept a swap, settle the legs.

Want to run one? Contact us.

Privacy

BATHRON has private cash at the base layer: shielded transfers using the Sapling protocol (zero-knowledge proofs), not a mixer bolted on top.

What is private

• Amounts and balances of shielded funds.
• Linkage: a shield → unshield hop breaks the on-chain connection between sender and recipient. In the flagship swap, the intermediate value crosses this private hop — so the two Bitcoin transactions at the edges cannot be linked through the middle.

What is public

• The total supply and the monetary invariants — privacy never hides whether the money is sound. Consensus verifies that shielded operations conserve value; it just doesn't see who holds what.
• Settlement transactions (locks, burns, header proofs) are transparent by design: they are the auditable skeleton of the system.

What we do not claim

BATHRON does not compete with Monero on anonymity-set size, and privacy is not the product — non-custodial settlement is. Privacy is what makes settlement commercially usable: no business wants its counterparties, volumes and treasury readable by competitors.

For builders

Shielded funds are ordinary funds: receive to a shielded address, send with a shielded transaction (wallet). Applications can route value through the shielded pool wherever confidentiality matters, and settle transparently where auditability matters.

Applications

These pages show ideas, not code. Each application is a composition of the same few primitives — covenants, timelocks, oracle signatures, proven Bitcoin facts, private transfers — enforced by consensus rather than operated by anyone.

One discipline governs all of them: the protocol ships primitives, builders ship applications. One working application justifies the whole network.

Payments

The base case: move satoshis, privately, final in about a minute.

  Alice ──── shielded transfer ────▶ Bob
             amount hidden
             balances hidden
             final in ~1 min

What you get

• The unit is the satoshi. No volatile gas token between you and your money — every unit is backed by provably burned Bitcoin.
• Privacy by default is available. Shielded transfers hide amounts and balances; a business can pay suppliers without publishing its treasury.
• Finality in about a minute, irreversible — not probabilistic confirmation.

What it is not

Not a Lightning competitor: no channels, no routing, no liquidity management — but also no per-hop capacity limits and no requirement to be online. A plain on-chain payment, private, final in a minute.

Primitives: shielded transfers (Sapling) · BFT finality

Escrow

Escrow without an escrow agent: the funds are locked under a covenant, and the release condition is a fact, not a decision.

  Buyer locks funds ──▶ covenant coffer
                            │
        condition met?      │        timeout?
   (proven Bitcoin payment, │   (CSV timelock)
    oracle signature, ...)  │
            │               │            │
            ▼               │            ▼
     pays the seller ◀──────┴──────▶ refunds the buyer

How it works

1. The buyer locks funds under a script with two paths.
2. Release path — proof that the agreed condition happened: a specific Bitcoin payment confirmed (TX_CONFIRMED), or a designated third party's signature over an agreed message (CSFS). A covenant template (CTV) forces the payout to the seller — the buyer cannot redirect it.
3. Refund path — a relative timelock (CSV) returns the funds if the condition never occurs.

No agent holds the money. The "escrow service" is a script that every node enforces.

Primitives: TX_CONFIRMED · CTV · CSV · CSFS

Delivery versus payment

The settlement problem in one line: neither side should be able to take delivery without paying, or pay without taking delivery. Traditional finance solves it with a clearing house. A covenant solves it with atomicity.

  Leg A: payment                Leg B: delivery
        │                             │
        └────── one shared secret ────┘
                       │
        claiming either leg reveals it —
        the other leg becomes claimable
                       │
        both settle, or both refund

How it works

Both legs are locked under scripts keyed to the same hash. Claiming one leg requires revealing the preimage — which is exactly what the counterparty needs to claim the other. Timeouts (CSV) guarantee that an abandoned trade refunds both sides.

The legs don't need to live on the same chain: one can be a native Bitcoin transaction, proven by SPV or settled as a cross-chain atomic swap. That is how the flagship BTC↔BTC settlement works — DvP where both deliverables are bitcoin.

Why here

Atomic settlement needs programmability (Bitcoin refuses it) plus Bitcoin-fact verification (nobody else has it without an oracle). The combination is the niche.

Primitives: hashlocks (HTLC) · CSV · TX_CONFIRMED · atomic swaps

Vaults

Cold storage with rules instead of promises: a covenant that makes theft slow and recovery fast.

  vault ──── withdraw ────▶ staging (CSV delay)
    ▲                            │
    │      recovery key,         │  delay elapsed
    │      any time during       ▼
    └────── the delay      destination

How it works

1. Funds sit under a vault covenant. The only permitted spend (CTV template) moves them to a staging output — never directly out.
2. The staging output enforces a delay (CSV). During it, a recovery key can sweep the funds back — this is the theft alarm: a thief must announce the withdrawal on-chain and then wait, in full view.
3. After the delay, funds move to the destination.

Bitcoin has debated exactly this construction for years (it is the canonical CTV use case). Here it runs.

Variants

Recursion — a covenant that re-creates itself — allows vaults with standing rules: rate-limited spending (at most X per period), or a vault that always returns change to itself.

Primitives: CTV · CSV · output introspection (recursion)

OTC settlement

Large trades have two enemies: counterparty risk and information leakage. OTC on BATHRON addresses both — settlement is atomic, and size is invisible.

  quote agreed off-chain
          │
          ▼
  both legs locked (HTLC, same hash)
          │
          ▼
  atomic settlement ── amounts shielded
          │
          ▼
  no one saw the size; no one held the funds

How it works

1. Two parties agree on a price off-chain — the protocol doesn't care how.
2. Each locks its leg under a hashlock keyed to the same secret; one leg can be native Bitcoin (proven by SPV or swapped atomically).
3. Settlement is atomic — both legs or neither — and the settlement-state side moves shielded: the market never learns the size.

Why it matters

On a transparent chain, a large settlement is a public event that moves the market against you. Here, Bitcoin sees two unremarkable transactions; the trade itself is invisible.

Primitives: HTLC · shielded transfers · TX_CONFIRMED · atomic swaps

Inheritance

The problem: pass funds to heirs without trusting a custodian while alive, and without losing them at death. A covenant expresses this directly.

  funds ── owner key ─────────▶ spendable any time (normal life)
    │
    ├── heir key + CSV delay ─▶ claimable after N months of inactivity
    │
    └── owner key during delay ▶ sweeps back (proof of life)

How it works

1. The owner spends freely; every spend restarts the clock.
2. If the funds sit untouched for the timeout (CSV), the heir's path becomes valid.
3. Refinements compose naturally: multiple heirs with a forced split (CTV template), a notary co-signature (CSFS) required alongside the heir key, or a staged claim the owner can still veto.

No lawyer holds the key. No exchange decides who inherits. The estate plan is a script, verified by consensus, private in amount.

Primitives: CSV · CTV · CSFS · shielded balances

Miner hedging

A miner's revenue is a bet on Bitcoin's difficulty. Hedging that bet normally requires a broker and a price feed — a counterparty and an oracle. Here, the settlement condition is Bitcoin's own difficulty, read by consensus.

  miner ─────┐                       ┌───── counterparty
             ▼                       ▼
        both lock margin in a covenant
                       │
                       ▼
   at expiry: consensus reads Bitcoin difficulty
        from the in-consensus header chain
                       │
          difficulty rose        difficulty fell
                │                       │
                ▼                       ▼
         pays the miner        pays the counterparty

Why this is different

Every difficulty derivative elsewhere trusts someone to report difficulty. On BATHRON the header chain — with its difficulty adjustments — is consensus state: the covenant reads the fact itself. No oracle to bribe, no publisher to go offline.

The honest caveat

Difficulty is hedgeable oracle-free because Bitcoin publishes it. A full hashprice hedge also involves the BTC price — which is not an on-chain fact and needs a signed input (CSFS), with the trust that implies. The difficulty leg is the trustless core.

Primitives: in-consensus Bitcoin headers · difficulty introspection · covenants · CSFS (price leg only)

Stable value

The discipline first: BATHRON will never mint a stablecoin. No global debt, no protocol-issued dollar, no peg to defend. What the primitives allow is different — and sounder: stability as a position, between two consenting parties.

  party A (wants dollar stability)     party B (wants BTC exposure)
              │                                   │
              └────── both lock sats in a covenant ──────┘
                               │
                               ▼
              at expiry, a signed price (CSFS)
              splits the pot so that A receives
              the dollar value of A's deposit

How it works

A discreet-log-contract-style covenant: two parties lock satoshis; at expiry, a published price signature determines the split. Party A gets dollar-stable value; party B gets leveraged BTC exposure. The "stablecoin" is a contract outcome, collateralized in full, expiring on schedule.

Why not a minted dollar?

Minted stablecoins concentrate three risks the design refuses: an issuer (custody), a peg (bank-run dynamics), and a global liability (everyone depends on one balance sheet). A position has none — its risk is bilateral, priced, and expires.

The honest caveat

The price is not an on-chain fact; the oracle signature (CSFS) is a real trust assumption, mitigated — not removed — by choosing and diversifying signers.

Primitives: covenants · CSFS · CSV/CLTV expiry · shielded balances

SDK

Current state, honestly: the developer surface today is the node's RPC API plus the script engine. A higher-level SDK is in development and ships with the public testnet. This page answers the five questions it will cover — with today's answer for each.

How do I write a program?

A program is a script locking funds: you compose spending conditions from the opcode surface (signatures, timelocks, templates, Bitcoin-fact proofs), hash it, and send funds to the script hash. The SDK will provide covenant builders for the common patterns (vault, escrow, HTLC) so you don't hand-assemble script bytes.

How do I submit transactions?

Through the node: wallet RPCs for standard operations (wallet), raw-transaction RPCs for custom scripts. Standard Bitcoin-style flow: construct, sign, broadcast.

How do I verify Bitcoin?

You mostly don't have to — the chain does it. Your program states which Bitcoin fact it needs (TX_CONFIRMED on a payment, a difficulty read); the proof is a Merkle branch that any party can fetch from Bitcoin and submit. The SDK will automate proof construction from a Bitcoin transaction id.

How do I build a covenant?

Start from the patterns in Applications — each lists its primitives. The core trick is CTV: commit to the template of the spending transaction, and the covenant forces where funds go next. Recursion (a covenant that re-creates itself) comes from output introspection.

How do I talk to a Settlement Provider?

SPs expose a small HTTP API: fetch quotes, accept a swap, follow settlement. The reference SP implementation and its API documentation are published with the public testnet. → Settlement Providers

Wallet

The wallet lives in the node; everything is reachable over RPC with bathron-cli or any JSON-RPC client.

Addresses and balances

bathron-cli -testnet getnewaddress            # transparent
bathron-cli -testnet getnewshieldaddress      # shielded
bathron-cli -testnet getwalletstate true      # full balance breakdown

Payments

# transparent payment
bathron-cli -testnet sendmany "" '{"<address>": 25000}'

# shielded payment — amount and balances hidden
bathron-cli -testnet shieldsendmany "<from>" '[{"address":"<shield-addr>","amount":25000}]'

Amounts are satoshis — the unit of account everywhere.

Settlement operations

The vault/receipt mechanics behind the settlement state (invariants) are exposed directly:

bathron-cli -testnet lock 100000       # vault M0, receive an M1 receipt (1:1, free)
bathron-cli -testnet unlock 100000     # redeem the receipt back to M0 (1:1, free)
bathron-cli -testnet transfer_m1 <outpoint> <address>   # transfer a receipt

Most applications never call these directly — the SDK and SP flows wrap them — but they are ordinary RPCs, not privileged operations.

RPC API

The node speaks Bitcoin-style JSON-RPC. Familiar calls (getblockcount, getrawtransaction, sendrawtransaction…) work as expected; this page lists what is BATHRON-specific.

State and consensus

Bitcoin integration

Settlement

Privacy

Full per-command help is available from the node itself: bathron-cli help <command>.

Examples

The flagship, end to end

The canonical example is the flagship itself — settle BTC for BTC, privately, with no custodian — because it exercises every primitive in one flow. Both legs run on the live testnet today:

Leg 1 — BTC in (trustless). A real Bitcoin payment, proven by a Merkle branch against the in-consensus header chain, releases a covenant (TX_CONFIRMED gate) whose CTV template forces the payout to the user. The user then shields the funds — the private hop that breaks linkage — with the monetary invariants provably identical before and after.

Leg 2 — BTC out (atomic). A cross-chain atomic swap: one hashlock, two HTLCs — one on BATHRON, one on Bitcoin. Claiming either side reveals the preimage that settles the other; both legs were claimed live, and the preimage matched on both chains.

BTC in ──▶ SPV proof ──▶ covenant releases ──▶ shield (private hop)
                                                  │
Bob gets BTC ◀── atomic HTLC swap ◀── settle with SP

Bitcoin saw two transactions. Everything between them was executed — and enforced — by the settlement state.

Where the code lives

The node, tools and application code are published across the BATHRON GitHub organization. Worked examples with the SDK — the patterns from Applications, runnable — ship with the public testnet.

Transaction types

Beyond standard transactions, the settlement state is maintained by a small set of special transaction types, each with its own consensus validation.

An HTLC family of settlement transactions (create / claim / refund, hashlock + timelock) powers atomic swaps and the DvP patterns.

Design notes

• Special transactions cannot carry shielded components. Privacy lives in NORMAL transactions only; the settlement skeleton stays fully auditable — this is consensus-enforced, not convention.
• Receipts are protected at consensus level. An M1 receipt output can only be spent by the settlement types that understand it (TX_UNLOCK, TX_TRANSFER_M1, HTLC) — never accidentally swept by a normal payment.
• Fees are strict. The coinbase must equal the block's fees exactly — a producer can neither inflate nor quietly divert.

Script & opcodes

The script engine is Bitcoin Script plus the programmability Bitcoin has debated for a decade without activating. The additions:

What is deliberately absent

• No general-purpose VM. No gas market, no unbounded loops — scripts terminate, costs are predictable, and the validation surface stays auditable.
• No Taproot/Schnorr. ECDSA on secp256k1 throughout; simplicity over signature aggregation at current scales.

The composition rule

Every application in Learn → Applications is a composition of this table — nothing else. If a use case can't be expressed here, the answer is a better composition, not a new opcode: the surface is frozen before mainnet.

SPV verification

How BATHRON sees Bitcoin without an oracle — the machinery behind Bitcoin integration.

The header database

Bitcoin headers enter via TX_BTC_HEADERS transactions and live in a consensus-maintained database. Every node validates, per header: proof-of-work against the encoded target, the difficulty adjustment schedule, timestamp rules, and accumulated chainwork. Anyone can submit headers; invalid ones are consensus-rejected.

Following the real chain

• Reorgs are handled by chainwork, like a Bitcoin node: a heavier branch replaces a lighter one, with full undo support.
• Canonical checkpoints: headers at fixed anchor heights must match pinned hashes of the real Bitcoin chain — a from-scratch fake chain, even a well-formed one, cannot be grafted in.
• A reorg floor: no reorg is accepted below a pinned checkpoint or below a burn that has already minted — an accepted burn cannot be un-happened.

Proving a transaction

A Bitcoin transaction is proven with a Merkle branch to a block header in the database, plus a burial requirement (confirmations of chainwork on top). Verification is pure computation — hash the branch, compare the root, check the depth — performed by every node.

Two consumers

The same rules serve both — there is no privileged path and no bypass, including at genesis: the very first mint was SPV-verified like every one since.

Consensus parameters

Reading the table

The threshold formula is the part worth internalizing: with few operators (N ≤ E) everyone signs and the threshold follows N; at scale the VRF samples ~E of them. One fixed cap covers a handful of launch operators through hundreds, with no parameter change — and committee size does not affect latency, since collection is a single parallel gossip round.

Once the threshold is met, the block is irreversible: a conflicting chain is rejected regardless of its length. Finality overrides chainwork.

Monetary invariants

The money is protected by consensus rules, not by whoever signs blocks. Two invariants are checked at every block; a block that violates either is invalid everywhere, whatever signatures it carries.

The internal units

Users send and hold satoshis; internally there are two forms:

BTC ──(burn: irreversible, SPV-proven)──▶ M0            base unit
M0  ──(lock, 1:1, free)──▶ M1  ──(unlock, 1:1, free)──▶ M0    settlement receipt

M0 is the base unit; M1 is a receipt for vaulted M0, used by the settlement machinery. A user never touches either — they are implementation details of one thing: satoshis backed by burned Bitcoin.

Invariant A5 — provenance

M0_total == BTC provably burned

Every unit in existence corresponds to satoshis destroyed on Bitcoin, verified by SPV. No premine, no reward, no issuer — no exceptions, including genesis.

Invariant A6 — parity

M0_vaulted == M1_supply

Every receipt is backed by exactly one vaulted unit at all times. Lock and unlock are free and 1:1 in both directions, so no premium or discount can open: parity is enforced by arbitrage and checked by consensus.

Why this matters

The finality quorum orders transactions; it has no authority over the money. A hypothetically malicious quorum could delay or reorder settlement — it could not mint a unit, break parity, or confirm an invalid transaction, because every node fully validates every block against these invariants. The supply is structurally beyond the reach of the signers.

A hard cap completes the picture: the supply can never exceed what Bitcoin's own schedule allows to be burned.

FAQ

Why burn Bitcoin?

Because it is the only way to back a unit with Bitcoin trustlessly. A bridge needs custodians; a federation needs trust; a burn needs neither — it is irreversible, verifiable by SPV, and requires no one's permission or honesty. One burned satoshi backs one unit, forever, with no issuer to default.

Why not Ethereum?

Bridged BTC on Ethereum is custodial (a wrapper someone can freeze or lose), there is no base-layer privacy, and you price everything through a volatile gas token. BATHRON's unit is the satoshi, backing is burned BTC with no bridge, and private cash is built in.

Why not Liquid?

Liquid is a federation: a fixed set of functionaries custodies the peg and can censor. BATHRON has no federation — Bitcoin facts are verified by SPV inside consensus, and the return to native BTC is an open market, not a multisig.

Why no token?

Because nothing needs one. Fees are paid in satoshis, security is funded by fees (block_reward = 0), there is no treasury and no premine. A token would add a speculation layer and a conflict of interest — and remove nothing.

Why Settlement Providers?

Because the protocol cannot move native BTC — nobody can, trustlessly, from another chain. So the design refuses to fake it: native liquidity comes from an open market of providers competing on fees, settling atomically, custodying nothing. → Settlement Providers

Why private?

Settlement is commercially unusable if competitors can read your counterparties, sizes and treasury. Privacy here is a property of good settlement, not an ideology — amounts are shielded; the monetary invariants stay publicly verifiable.

Can I become a Settlement Provider?

Yes — that is the intended path, and there is no whitelist. The reference implementation publishes with the public testnet; contact us to be early.

Can I run a validator?

Yes. Validators are masternodes backed by burned-BTC collateral. On the current private testnet the operator set is closed; it opens progressively with the public testnet. → Consensus

Is it experimental?

Yes. Private testnet running, public testnet next, no mainnet. The consensus surface is frozen before any mainnet, and external audits gate the launch. We would rather under-promise here and let the running system speak.

Roadmap

Three phases, no dates. Each phase gates the next.

Now — private testnet

The full surface runs live on a multi-node network: consensus with VRF finality, the in-consensus Bitcoin header chain, burn → mint, covenants, shielded transfers, and the flagship flow end-to-end — a real Bitcoin payment releasing a covenant, and an atomic BTC-out swap. The consensus surface is frozen: work at this stage is testing, hardening and tooling, not new features.

Next — public testnet

The network opens: published genesis and peers, public explorer, the Settlement Provider reference implementation, the SDK, and runnable examples. The goal of this phase is a simple one: the first builders shipping on the substrate. Disposable-genesis resets remain possible until the network stabilizes.

Then — mainnet

Gated, not scheduled. Hard prerequisites include external security audits (the VRF finality module foremost), operator-set and collateral economics for an open network, and a launch process where genesis itself is SPV-verified like every block after it — no special cases.

The homepage principle applies here too: if this page needs to change often, something is wrong. The substrate is meant to stay small and finished; what should grow is what's built on it.