Start here — BATHRON in five minutes

Build contracts around facts Bitcoin can prove.

BATHRON is an open programmable settlement protocol for markets, instruments and applications anchored in Bitcoin.

BATHRON is running an experimental public testnet. Application building is open; Consensus-Operator admission is not yet open.

The core

Five things, and they compose:

1. Bitcoin facts, verified in consensus. A script can assert that difficulty at a Bitcoin height was above or below a threshold, that a height was reached, that a median-time-past has passed, or that a Bitcoin transaction paying a given script was confirmed deep enough. Every node checks it. No designated oracle. → Bitcoin-verifiable contracts
2. Programmable settlement. Covenants — including recursive ones — output constraints, hashlocks, timelocks, and signature verification over arbitrary messages. → Programmable settlement
3. A settlement unit that nobody issues. M0 originates from consensus-verified Bitcoin destruction; M1 is obtained through the protocol's M0/M1 conversion and accounting rules, with conservation enforced in consensus. Neither is a redeemable claim on BTC: no peg, no reserve, no redemption promise. → Bitcoin is the final asset
4. Finality in about a minute, one Consensus Operator one vote. → Production and finality
5. Confidential transfers. Values can move without being published.

Who is who

No role is granted by the protocol except the first, and that one is not yet open.

What can be built

• Native to Bitcoin facts, no oracle: difficulty hedges, buried-payment escrows, time-bound agreements, prediction instruments over what Bitcoin proves.
• Programmable settlement: conditional cross-chain flows, covenant-constrained spends, DLC shapes with an external attestation.
• Markets: a pair appears because someone quotes it, not because a committee approved it.
• Needing external components: anything indexed on a price. BATHRON has no price oracle, no margin engine, no liquidation in consensus.

The full table, with what each thing depends on: → Application map

What is true today, and what is not

Anyone can build an application or propose a settlement flow without a listing committee. Native Bitcoin facts require no designated oracle. External prices and real-world events still require external attestations.

The protocol supplies settlement primitives; applications supply product logic, liquidity and interfaces. Markets are one application of the settlement layer, not the protocol itself.

The network being aimed at — several independent Consensus Operators, open admission, several independent providers — is described in The target open network. It is a target, not a description of today.

→ Status & claims prevails over every other page.

What BATHRON is

BATHRON is an open programmable settlement protocol. It supplies a settlement unit, a set of conditions that consensus enforces, and a script engine that can assert facts about the Bitcoin chain. It does not supply products, liquidity, prices or interfaces — those come from independent builders on top.

Markets are one application of this layer. They are not the protocol.

The core, in one list

Each is documented with its code reference and its limits in Bitcoin-verifiable contracts and Programmable settlement.

What it deliberately is not

• Not a virtual machine. The engine is a script engine, not Turing-complete. The Bitcoin facts it can assert are a finite list of five, not an extensible API.
• Not an exchange. No matching engine, no order book, no listing committee in consensus.
• Not an issuer. M0 exists only against burned bitcoin. There is no reserve and no redemption desk — CheckA5Independent, CheckA6P1 and CheckA7 in src/state/settlement_logic.cpp.
• Not an oracle. It can check an attestation; it cannot produce one or judge its truth.
• Not a bridge. Bitcoin moves only through markets, never through a protocol-held reserve.

Reading the status labels

Every capability in this documentation carries one of five labels. They are not decoration:

• ACTIVE IN CONSENSUS — the opcode or rule is enabled on the current public testnet. This says nothing about whether a product uses it.
• TESTED — has a test suite.
• DEMONSTRATED — an end-to-end flow has actually been run.
• AVAILABLE PRIMITIVE — composable with no consensus change; no product exists.
• TARGET NETWORK — the architecture being aimed at; not deployed.

An active opcode is not a product, and this documentation never uses activation to imply one.

The distinction matters most for the network itself: application building is open today, Consensus Operator admission is not. See The target open network and Status & claims, which prevails over any other page.

Bitcoin-verifiable contracts

A BATHRON script can assert a fact about the Bitcoin chain, and every node checks it against headers the protocol already carries in consensus. No designated oracle takes part.

This is the primitive that distinguishes BATHRON. The five predicates are ACTIVE IN CONSENSUS and TESTED. Being active is not the same as being used by a product — no instrument built on them exists today.

The five predicates

Defined in src/script/btcstate.h, evaluated by OP_BTCSTATEVERIFY in src/script/interpreter.cpp:

The limits — read these before designing anything

They are predicates, not readings. A script asserts difficulty(h) >= X. It cannot push the difficulty onto the stack. Binary and barrier payoffs are therefore native; a linear payoff must be decomposed into steps, and each step costs script size.

Only buried history is readable. BTCSTATE_REORG_MARGIN = 144 Bitcoin blocks — roughly a day. Nothing more recent can be queried.

Answers are snapshotted at the previous BATHRON block, so a result never depends on transaction order inside a block or on script-thread scheduling.

Validity is monotone within a bounded domain, not absolutely. Inside the readable region — at least BTCSTATE_REORG_MARGIN blocks below the snapshot tip (src/btcheaders/btcstate_provider.cpp computes the floor as snapTip - BTCSTATE_REORG_MARGIN) — and given the btcheaders max-reorg-depth rule that rejects a header reorganisation as bad-btcheaders-reorg-too-deep, together with the floors below a pinned checkpoint and below a finalized burn (src/btcheaders/btcheaders.cpp), a script that is not yet valid can become valid and not the reverse.

The domain is what makes this true. Monotonicity is a property of BATHRON's accepted header view under those depth rules, not a claim about Bitcoin itself. A reorganisation deeper than the margin lies outside the region these rules protect; the header chain rejects it rather than silently rewriting an answer, which is a different guarantee from "this can never happen".

Fail-closed. With no provider installed, every query evaluates false.

No cumulative-work query exists, and no difficulty variation predicate exists. A variation is composed from two difficulty queries at two heights — that is possible, but it is composition, not a primitive.

What this makes possible without any oracle

• Hedges that settle on mining difficulty itself, at a threshold.
• Payments that open when a Bitcoin payment is buried deep enough.
• Time-bound agreements keyed to Bitcoin's own clock rather than a local one.
• Prediction instruments over facts Bitcoin proves.

What it does not make possible

A price. An outside event. The state of another chain. None of these appears in a Bitcoin header, and no combination of the five predicates produces one. Those need an external attestation — see Programmable settlement.

BTCSTATE_TX_CONFIRMED — read this before relying on it

The most intricate of the five: Merkle proof, strict Bitcoin serialization, and the 64-byte leaf ambiguity of CVE-2017-12842. Its status has three parts, and they must not be collapsed:

• ACTIVE IN CONSENSUS — the query is enabled on this testnet.
• TESTED — covered by the identified public tests in bathron-core@32ca174, src/test/btcstate_script_tests.cpp: field marshalling, shape errors, a full P2SH spend (otc_leg_full_p2sh_spend), multi-output and single-transaction-block sums, an adversarial provider, and segwit_64byte_preimage_rejected for the CVE-2017-12842 leaf ambiguity. Part of the suite runs against the real provider with an in-memory header database rather than a mock.
• No public end-to-end demonstration artifact identified. The DEMONSTRATED label is therefore not applied. Anyone who tells you the path has been walked in production owes you a reference; this documentation does not have one.

Treat it accordingly: the query is enabled and exercised by tests, and no public end-to-end evidence exists.

Programmable settlement

Beyond Bitcoin facts, the script engine constrains what a spend may become. All opcodes below are active on the current public testnet.

Opcodes

Declared in src/script/script.h, implemented in src/script/interpreter.cpp:

OP_CHECKOUTPUTSCRIPT together with OP_PUSHCURRENTSCRIPT form a recursive covenant pair: a script can require its successor to carry the same rules with new state.

Hashlocks and timelocks

Hashlocked, timelocked conditional scripts are the basis of cross-chain settlement. Their components are TESTED with public evidence: src/test/htlc3s_expiry_spec_tests.cpp, src/test/htlc3s_failure_tests.cpp and src/test/htlc_prune_tests.cpp, plus the HTLC SDK under contrib/dex/pna-lp/sdk/htlc/.

Paired-HTLC flows against Bitcoin have been run on a testnet, but no reproducible artifact of such a run is published in the public repository, so this documentation does not carry a DEMONSTRATED label for them. Note also that the SDK above belongs to the decommissioned provider prototypes.

What is not claimed: a general atomicity guarantee. The complete cross-chain state machine, reorganisation handling and timelock ordering still need formal specification and external review.

External attestations (DLC)

For anything Bitcoin cannot prove, the engine can consume a signed attestation. OP_CHECKSIGFROMSTACK verifies a signature over an arbitrary message, and the script engine supports discreet-log-contract shapes with no new opcode: two-of-two funding, multi-branch outcome nodes, an oracle branch where the attestation itself is the private key, and a timelocked refund.

Status: AVAILABLE PRIMITIVE. The script side is covered by tests; no product exists, and the attestation source is entirely outside the protocol. BATHRON checks a signature. It cannot make the attested statement true, nor contest it.

Confidentiality

Sapling shielded transfers are available. Values can move without being published.

Limit, stated plainly: the confidentiality of covenant-bearing settlement — shielded value combined with conditional script — is not demonstrated. Treat it as an open question, not a feature.

Composition

The primitives compose: a covenant can require a Bitcoin fact, a hashlock and a timelock at once; a recursive covenant can carry state forward. The set of useful compositions has not been inventoried, and this documentation does not claim to have enumerated it.

Markets need permission today

If you hold an asset that no exchange lists, you do not have a market. You have a hope. This page describes the problem BATHRON was built for, before any mechanism.

Where a market comes from

Ask why a given trading pair exists today and the answer is always the same: an exchange decided it should. A listing committee reviewed a dossier, a fee was paid, terms were signed, and a market appeared. The reverse is also true: a compliance decision, a volume threshold, a change of jurisdiction — and the market disappears. Holders wake up with an asset and nowhere to settle it.

        TODAY                                   ON BATHRON

  asset  ─►  listing committee  ─►  market     inventory + quotes  ─►  market
                  │                                    │
            can be revoked                    can only be abandoned

Notice the asymmetry. Today a market is born by permission and dies by decision. On an open settlement protocol, a market is born the moment two parties can settle and dies only when nobody cares to quote it any more. Nobody can revoke what nobody granted.

The custody problem underneath

Even two parties who both hold inventory — you have DOGE, I have BTC, we agree on a price — cannot settle against each other today without one of three things: trusting each other, trusting a custodian, or using an exchange that lists the pair. The first does not scale, the second is a single point of failure and seizure, the third is the permission problem again.

What is missing is a neutral place to settle that neither party controls, that holds nobody's funds in custody, and that anyone can use without being admitted.

Why this is a settlement problem, not a trading problem

Trading — discovering a price, matching a buyer and a seller — is well understood and can happen anywhere: a chat, a relay, an order book, an RFQ. What cannot happen "anywhere" is settlement: the moment both legs move, or neither does. That moment needs shared rules that both parties can verify and neither can bend.

BATHRON provides only that moment. It does not discover prices, does not match, does not list. It settles, in a common unit, under rules everyone can check. Everything above — the market itself — belongs to whoever builds it.

Who feels this first

• Communities whose asset was delisted, and who would rather fund a market than buy a listing.
• Providers who hold inventory in several assets and want to quote them against a common numéraire without asking anyone.
• Anyone who wants a conditional settlement — delivery against payment, an escrow, a hedge — that no exchange offers because the pair is too small to list.

The rest of part I explains why Bitcoin alone cannot do this (next page) and why the usual alternatives — an exchange, a bridge, a stablecoin — each give up something BATHRON keeps.

Next: What Bitcoin does, and where it stops

What Bitcoin does, and where it stops

BATHRON does not start from the idea that Bitcoin is deficient. It starts from the opposite: Bitcoin is the best ownership-and-transfer layer that exists, and because it is so good at that one thing, it refuses to do the next thing. This page marks the exact line.

What Bitcoin does very well

A person owns bitcoin because they control a key. They sign, the network records, and after enough confirmations the record becomes extraordinarily hard to change. No bank keeping a private ledger, no operator deciding balances — public rules, verifiable by anyone, upheld for more than fifteen years. That is why Bitcoin is the final asset in everything that follows: the thing you ultimately want to end up holding, and the only thing whose destruction can be verified by anyone.

Where it stops, on purpose

An ordinary payment is simple: Alice sends bitcoin to Bob. A conditional settlement is something else: Bob receives only if a precise condition is met, and if it is not met by a given date, Alice is refunded automatically, without anyone's goodwill.

Bitcoin can express a few conditions — a signature, a revealed secret, a delay. As soon as you want a complete commercial logic (composed conditions, verification of an external event, coordination of several legs, the case where one party disappears), Bitcoin's small language runs out. It was restricted long ago, out of caution, and that restriction is defended by serious people with good arguments: every capability added to a system protecting hundreds of billions is added risk. Proposals to enrich the language have circulated for a decade; none is adopted.

So there are two facts to hold at once:

• Bitcoin will not carry the conditions of a trade — and that is a feature of Bitcoin.
• A market needs those conditions — delivery against payment, refund on timeout, both legs or neither.

What follows

Something has to carry the conditions, and it must satisfy three constraints that most systems give up on the first page:

1. it must never hold the bitcoin for redemption (otherwise it is a custodian, see next page);
2. it must be able to verify Bitcoin facts itself, without a designated oracle;
3. it must be open — anyone can settle, quote or build without being admitted.

BATHRON's answer is a separate settlement state, expressed in a unit (M1) whose only origin is verified Bitcoin destruction, run by a consensus that reads Bitcoin headers inside its own rules. Bitcoin keeps the value; BATHRON keeps the conditions; markets keep the liquidity. The next page explains why the usual alternatives — an exchange, a bridge, a stablecoin — do not satisfy the three constraints together.

Next: Why not an exchange, a bridge, or a stablecoin

Why not an exchange, a bridge, or a stablecoin

Each of the usual answers solves part of the problem by giving up something BATHRON refuses to give up. This page is not a claim of superiority — every system below is useful for someone. It is a map of the trade-offs, so you can see which one BATHRON signs.

The three constraints again

A place to settle a market must (1) hold nobody's funds in custody, (2) verify Bitcoin facts without a designated oracle, and (3) be open — no admission, no listing.

Exchanges: the permission problem itself

An exchange gives you liquidity, custody and customer service — against holding your funds and deciding which markets exist. Its listing committee is not a bug; it is the business. If your problem is "who decides my market exists", an exchange is the problem, not the answer.

Bridges: trusted by whom, for what, for how long

Lock bitcoin on one side, mint a representation on the other, do there what Bitcoin forbids, come back — every bridge raises one question: while you are on the other side, who holds your bitcoin? A custodian is a keeper. A federation is a group of keepers — better, one key is no longer enough, but the reserve still exists and identifiable actors control it. Optimistic designs do better still, and still rest on a setup ceremony and watchers who stay alive and funded.

None of this is absurd. But never call it trustless: say whom the user trusts, for what, for how long — and the answer always contains a keeper, because the original bitcoin still exists and somebody holds it.

BATHRON's choice is radical and has a cost: the bitcoin is destroyed, verifiably, and never held. There is no keeper — and therefore no reserve and no redemption. What brings native BTC back is not a vault but a market: providers holding inventory on both sides, paired with linked hashlocked legs. That is the trade-off you sign. It is stated plainly on Bitcoin is the final asset.

Stablecoins: an issuer by definition

A stablecoin is a claim on an issuer's reserve. It is the fastest way to a dollar balance and the clearest example of what BATHRON is not: BATHRON has no issuer, no reserve, no redemption desk, no freeze list. Value positions can be built on BATHRON (a bilateral, collateralised, fixed-term contract priced by a professional — see Fixed-term value positions) but the protocol mints nothing that promises anything.

Lightning and human arbitration: honest boundaries

Lightning is better for simple, fast payments — no contest, and BATHRON does not compete there. Its subject begins where rich conditions are needed.

A human arbiter can look at photos, read messages, judge whether a product matched its description. No covenant can do that. BATHRON targets objectively verifiable conditions — an elapsed delay, a signature, a confirmed Bitcoin transaction. When the condition needs interpretation, arbitration wins. This is the product's boundary, not a decorative concession.

So what does BATHRON keep

Custody-free, Bitcoin-verifying, open. In exchange it gives up: a recoverable vault (so exit liquidity must come from providers), simplicity (pre-committed transactions are more complex than a database), and any promise about the price of its unit. Part II describes exactly what it provides in return.

Next: The settlement unit: M1

The settlement unit: M1

A market needs a unit to settle in. Not a coin to speculate on — a numéraire: one common measure so that every pair, every escrow and every hedge on the network is expressed the same way and can be netted against every other. That unit is M1. This page says what it is, where it comes from, who touches it, and what it is not.

Why one unit, and not one per market

Without a common unit, N assets need N² pairs, each with its own thin liquidity. With one, they need N pairs around a single hub — the same reason foreign-exchange markets pivot through a few currencies and the same reason a common language beats pairwise translation.

        PIVX/M1        DOGE/M1        LTC/M1
             \            |            /
              \           |           /
                ──────  M1  ──────  ◄── the hub every pair settles through
                          |
                       BTC/M1        ◄── the deepest pair: native BTC in and out

M1 is that hub. Every settlement pattern in part III — DvP, escrow, hedge, fixed-term value — is written in M1 so that a Liquidity Provider can hold one inventory and quote many pairs.

Where M1 comes from

BTC  ──(irreversible, SPV-proven destruction)──►  M0  ──(lock, 1:1)──►  M1
                                                       ◄─(unlock, 1:1)─

• M0 exists only when bitcoin has been provably destroyed on the Bitcoin chain and the proof has been verified inside BATHRON's consensus. One destroyed satoshi permits one M0 unit; there is no premine, no block reward, no treasury, no issuer, no genesis exception.
• M1 is M0 vaulted 1:1: the programmable receipt that covenants can lock and release. Locking and unlocking are free protocol operations; the vaulted M0 always equals the M1 supply.

Both rules are consensus invariants (A5 and A6) that every node checks on every block. A finality quorum can order transactions; it cannot create a unit. → From destroyed BTC to M1

Who touches M1

End users settle in the assets they already hold; market builders and providers settle in M1.

A person swapping DOGE for BTC through a provider sees DOGE go out and BTC come in. The provider, the market builder, the dealer quoting a pair — they hold M1 inventory, because M1 is what the consensus can lock, release, hedge and net. Nobody is asked to "buy M1" as a product; it is the working capital of whoever runs a market.

What M1 is not

• Not a coin with an issuer. Nobody can print it and nobody can freeze it.
• Not pegged. Consensus enforces the internal 1:1 between M0 and M1. It does not enforce, and the protocol never promises, an external price against BTC. The destroyed bitcoin is gone; there is no reserve and no redemption desk. What makes native BTC available again is the market — providers holding inventory on both sides, paired with linked hashlocked legs (→ Native BTC ⇄ M1).
• Not an investment. Anyone can create M1 by destroying bitcoin, so destruction is a permanent reference supply route: when it is accessible, it tends to limit any premium over the cost of creation — there is nothing to speculate up. It is not a hard ceiling (arbitrage has fees, confirmation delay, inclusion risk and illiquidity), and there is no floor: demand for settlement — inventory, collateral, working capital — is what markets built on top must create, and it guarantees no price. The protocol guarantees the unit's integrity, never its value.

The realizable value of M1 for a professional depends on available liquidity and can be heavily discounted; see Status & claims for what is and is not promised.

Next: Settlement guarantees: what consensus enforces

Settlement guarantees: what consensus enforces

A market built on BATHRON relies on one thing from the protocol: that a settlement, once final, happened exactly as its rules said and can never be undone or forged. This page lists what the consensus guarantees — and, just as importantly, what it deliberately does not know.

What every node enforces

Every node fully validates every block; finality is added on top of that validation, never instead of it. Four families of rules:

Confidential transfers keep amounts and linkage hidden while consensus still verifies conservation (→ Confidential settlement).

What consensus deliberately does not know

   CONSENSUS KNOWS                          CONSENSUS DOES NOT KNOW
   ─────────────────                        ────────────────────────
   every balance and receipt                any price
   every verified Bitcoin fact              any order book or quote
   whether a contract's conditions hold     which pairs exist
   who signed finality (1 operator = 1 vote) who is a "good" provider
   the fees of a block                      whether a market is worth listing

This is not a gap to be filled later. Prices, quotes, order books, provider selection and reputation are market-layer facts. Keeping them out of consensus is what makes the protocol neutral: it cannot favour a pair, a provider or a price because it does not see them. → What BATHRON deliberately does not do

What a captured finality threshold could and could not do

The full analysis is on Security model; the short version:

• It cannot create a unit, break the M0↔M1 accounting, spend a client's key or force a Bitcoin transaction — full validation rejects all of that regardless of signatures.
• It can censor an operation, stall finality, or present divergent finalized views across a partition. Settlement is only reversible until it finalizes (~1 minute), so what is at risk is timing, never the money.

Operator admission is not yet open — the current operator set is project-run while the open-admission threat model is worked. → Status & claims

Next: The infrastructure: what you can build on

The infrastructure: what you can build on

The consensus settles; everything a market needs beyond that — conditions, delivery, timeouts, privacy, pairing with other chains — is built from a small set of primitives that every node enforces. This page is the builder's map: what the pieces are, and what each one lets a market do. The opcode-level detail lives in the reference.

Three layers, one boundary

 ┌──────────────────────────────────────────────────────────────────┐
 │  MARKETS  (yours)                                                 │
 │  quotes · relays · order flow · providers · reputation · wallets  │
 ├──────────────────────────────────────────────────────────────────┤  ◄── consensus stops here
 │  BATHRON CONSENSUS                                                │
 │  M1 accounting · Bitcoin facts · covenants · finality             │
 ├──────────────────────────────────────────────────────────────────┤
 │  BITCOIN  (final asset)                                           │
 │  value · one-way origin of M0 · headers read by consensus         │
 └──────────────────────────────────────────────────────────────────┘

Everything above the line is permissionless by construction: the consensus never sees it, so it cannot gate it.

The primitives, by what they let a market do

Every settlement pattern in part III is a composition of this table — nothing else. If a use case cannot be expressed here, the answer is a better composition, not a new opcode: the surface is frozen (→ Why the consensus is frozen).

The shape of every application

1. Lock value under a script whose spending conditions you wrote.
2. State the release conditions — signatures, preimages, timeouts, a forced destination, an oracle signature, or a proven Bitcoin fact.
3. Anyone can trigger settlement once conditions are met. No server, no operator, no permission.

That is the whole developer model — a covenant, not a smart contract in the EVM sense. → Build your first application

What is deliberately absent

No general-purpose VM, no gas market, no unbounded loops: scripts terminate, costs are predictable, the validation surface stays auditable. No Taproot/Schnorr: ECDSA on secp256k1 throughout.

Next: What BATHRON deliberately does not do

What BATHRON deliberately does not do

Bitcoin does not decide who may hold BTC. BATHRON does not decide which markets may exist.

The most important design decisions of this protocol are the things it refuses to do. Each item below is a boundary, not a missing feature — the consensus stays small so that the markets on top of it can be free.

Not in the protocol, on purpose

What the consensus does instead

It settles. It keeps the accounts, verifies Bitcoin facts, evaluates the conditions written into covenants, and finalizes transfers. → Settlement guarantees

Why the negative list is the product

Every item above is a place where a protocol could have taken power — over which pairs exist, who makes markets, what a unit is worth — and chose not to. That refusal is what makes the following sentence true: markets belong to whoever builds them. A protocol that lists cannot be neutral about listing; a protocol that ranks cannot be neutral about providers; a protocol that mints cannot be neutral about value.

The currently deployed surface is intentionally narrow. Any consensus change requires an explicit protocol and governance decision. That is what keeps this list true. Any future value must be built above it — which is exactly what part III describes.

Next: How a market appears See also: Why the consensus is frozen

How a market appears

On an exchange, a market appears when a committee approves it. On BATHRON, a market appears when someone can settle it. This page walks through that moment — who does what, who pays what, and where the protocol stops.

Four steps, no gate

  1. INVENTORY            2. QUOTES                3. SETTLEMENT           4. OTHERS JOIN
  ────────────            ─────────                ─────────────           ─────────────
  someone holds           publishes signed          a counterparty          another provider
  the asset (PIVX,        bid/ask for               accepts; the M1 leg     quotes the same
  DOGE, LTC, BTC…)        PIVX/M1 — off-chain,      settles on BATHRON,     pair, tighter,
  and M1                  on any relay              the external leg on     or deeper
                                                    its own native chain,
                                                    linked by compatible
                                                    conditions
        │                       │                        │                       │
        └───────────────────────┴────────────────────────┴───────────────────────┘
                     no listing committee approves the pair — the protocol only settles step 3

Step 1 — inventory. A market maker holds the asset to be paired and M1. M1 is acquired either from an existing holder or by the one-way route (destroy BTC, receive M0, lock it into M1 — → From destroyed BTC to M1). Creating M0 by burn irreversibly destroys BTC. The resulting protocol position is transferable and may acquire a market value that the protocol neither fixes, supports nor predicts. Whether an activity recovers its economic cost is a commercial outcome, not a protocol guarantee.

Step 2 — quotes. The maker publishes signed quotes: pair, bid, ask, size, expiry. They travel off-chain — a relay, an HTTP endpoint, a message bus. The consensus never sees a quote and never needs to. → Quotes live off-chain

Step 3 — settlement. A taker accepts a quote. If the pair is BTC/M1, the M1 leg settles on BATHRON and the BTC leg on Bitcoin, the two linked by one hashlock so that claiming either reveals what unlocks the other; if the other asset lives on a chain with hashlocks and timelocks, the same pattern applies; if it is an M1-denominated position (a hedge, an escrow), a covenant settles it. The BATHRON leg is the only step consensus performs, and it performs it identically for every market.

Step 4 — others join. Nothing about the pair is registered, so nothing needs to be joined "officially". A second provider publishes a tighter quote and the market has two makers. A third arbitrages against an external venue. The pair deepens because it is profitable to deepen, not because anyone was invited.

Who pays what

Competition compresses spreads; the protocol guarantees none of it and takes none of it.

What "no permission" means precisely

Anyone can build, quote, pair and settle on BATHRON without asking permission. Operator admission is not yet open: the current operator set is project-run while the open-admission threat model is worked. → Status & claims

The first half is a property of the design: the consensus does not know which pairs exist, so it cannot gate them. The second half is where the network is today.

What a market cannot do

It cannot make the protocol publish its price, favour its provider, or guarantee its liquidity. A pair nobody quotes is simply silent — not delisted, silent — and it comes back the moment someone quotes it again. Nobody can revoke what nobody granted.

Next: Quotes live off-chain, settlement on-chain

Quotes live off-chain, settlement on-chain

The consensus never carries a price. That is not a limitation to be fixed — it is what keeps the protocol neutral and the markets free. This page explains where quotes live instead, how a taker finds them, and what the testnet prototypes already do.

The split

   OFF-CHAIN (yours)                              ON-CHAIN (consensus)
   ────────────────                               ────────────────────
   signed quote: pair · bid · ask · size · expiry      one settlement:
   relayed anywhere — HTTP, gossip, a chat, a file     hashlocked legs, or a covenant,
   aggregated by wallets and indexers                  final in ~1 minute
   compared, chosen, ignored                           identical for every market
              │
              └────────── the taker accepts ──────────►

A quote is a signed message. Anyone can publish one, anyone can relay one, anyone can aggregate them. The consensus is involved exactly once: when the accepted quote becomes a settlement.

Why not put the order book in consensus

Because a book in consensus is an exchange. It would fix one matching rule for every market, make the protocol responsible for prices it cannot verify, and hand block producers a view of order flow they could exploit. Keeping quotes off-chain means the protocol can be captured neither on listing nor on price — it does not see either. → What BATHRON does not do

How a taker finds a market

Discovery is a market-layer function and several mechanisms can coexist:

• Announcements. The testnet prototype lets a provider announce its endpoint with a plain OP_RETURN on BATHRON (PNA|LP|01|<endpoint>); any node can list announced providers. Nothing is validated by consensus — an announcement is a pointer, not a listing.
• Relays and indexers. Anyone can run a service that collects signed quotes and serves them; wallets connect to several, the way Bitcoin nodes connect to several peers.
• Direct. A wallet can be pointed at a provider's endpoint.

The taker then chooses — best price, best reputation, largest size, lowest latency. That choice belongs to the wallet and the user, never to the protocol.

What the prototypes already do

The Clearing/Liquidity Provider prototype (pna-lp) exposes quotes and settlement over HTTP: GET /api/quote?from=…&to=…&amount=… returns a priced quote; /api/status, /api/lps, /api/reputation expose provider state, announced providers and observable history; the swap front-end (pna-swap) consumes them. Both are historical testnet prototypes, decommissioned: their application state belonged to a superseded network and the services are not running. They illustrate the split above — they are not a standard, not a product, and not a service you can call today. → Create your first market

The maker's real problem: the free option

A signed quote that a taker can accept "within N seconds" is an option the maker has written for free: the taker will exercise it only when the price has moved in their favour. Every RFQ market in the world has this problem, and none has eliminated it — it is priced: short expiries, firm quotes only after the taker commits (a small collateral, a covenant), or a wider spread. The primitives allow all three; which one a market uses is that market's business.

Next: Roles: Operators, Settlement Providers, users

Roles: Operators, Settlement Providers, users

A market only stays open to everyone if the people who run consensus are not the people who choose which markets exist or who gets to serve them. BATHRON keeps those functions apart: Operators settle, Settlement Providers compete, users build and settle. Knowing which role does what tells you who you depend on — and who you do not.

Three roles, one table

One company may perform several roles; the protocol never requires that they be bundled, and it does not prove that an Operator and a provider are the same entity.

                    ┌──────────────────────────────┐
                    │  Operators (consensus)       │
                    │  produce · finalize          │
                    │  publish Bitcoin facts       │
                    └──────────────┬───────────────┘
                                   │ publish facts
                                   ▼
             ┌────────────────────────────────────────────┐
             │  BATHRON settlement state (M1, covenants)  │
             └───────┬──────────────────────────┬─────────┘
                     │ settle                   │ settle
                     ▼                          ▼
      ┌──────────────────────────┐    ┌──────────────────────────┐
      │  Settlement Providers    │    │  Users                   │
      │  CP: quote, orchestrate  │◄───│  build a market, build   │
      │  LP: inventory, spread   │quote│  an app, or just settle  │
      └──────────────────────────┘    └──────────────────────────┘

There is no arrow from Operators to providers or users. Operators publish facts; they do not select, rank or approve anyone.

Operators: consensus, nothing more

Operators produce blocks, sign finality certificates and carry Bitcoin headers and proofs into consensus. One operator identity has one vote; the protocol publishes facts and never a ranking. Operators do not decide which pairs may exist, do not pick which provider serves a client, and cannot create M0 without a verified Bitcoin destruction (see Security model).

Anyone can build, quote, pair and settle on BATHRON without asking permission. Operator admission is not yet open: the current operator set is project-run while the open-admission threat model is worked.

Settlement Providers: the commercial layer

Settlement Providers are participants, never administrators. They appear when someone brings inventory and quotes, and disappear when they stop; the protocol neither selects nor licenses them.

• The Clearing Provider faces the client: it quotes amount, deadline, fees and refund path in the client's familiar assets, then orchestrates the legs of the settlement.
• The Liquidity Provider faces the market: it holds inventory in M1 and in the paired asset, prices the pair, and takes the inventory risk.

Choosing or pinning a provider establishes a service route. It does not create a private consensus committee and does not replace the global finality set.

Users

Anyone who builds a market, builds an application on the covenant surface, or just settles a trade. End users settle in the assets they already hold; market builders and providers settle in M1.

How providers are paid

The CP charges explicit service fees. LPs set spreads against inventory acquisition, liquidity, capital and operating costs. Competition may compress prices, but the protocol does not guarantee liquidity, a price near par, or that any spread covers any cost.

The Bitcoin-destruction route is one way an LP can acquire M1 inventory. The destruction is irreversible: the bitcoin is gone and nothing in the protocol returns it. What the burn produces is a transferable M0/M1 position that may carry a market value — a value the protocol neither sets, supports nor predicts. Whether service revenue ever covers the cost is a commercial question, and this documentation makes no claim either way. Expected appreciation of M0 or M1 is not a business model.

Quoting and LP software exist as testnet prototypes; see Status & claims.

See also: How a market appears · Create your first market

Native BTC ⇄ M1: paired HTLC components

Every market on BATHRON is a pair against M1, and the pair that matters first is Bitcoin itself: without a way for native BTC to enter and leave M1, no other market can be priced in BTC terms. The burn route creates M1 once and irreversibly (see From destroyed BTC to M1); the paired HTLC construction is how BTC and M1 change hands afterwards — reversibly, repeatedly, and without anyone holding either side.

The mechanism: two locks, one secret

BATHRON can verify Bitcoin facts, but it cannot move native BTC or trigger a Bitcoin transaction. So the BTC leg is an ordinary Bitcoin transaction, and the two legs are tied together by a shared secret rather than by a custodian.

  Bitcoin                                   BATHRON
  ────────                                  ────────
  P2WSH HTLC: pay to hash H, or             M1 HTLC: pay to hash H, or
  refund after CLTV timeout T_btc           refund after timeout T_m1
        │                                          │
        └───────────── same hash H ────────────────┘
                              │
        claiming one leg reveals the preimage of H —
        the other leg becomes claimable with it
                              │
              both settle, or both refund on timeout

1. The two parties agree on a price off-chain (a quote from a Liquidity Provider, or a direct negotiation — the protocol does not care).
2. One side locks BTC in a Bitcoin P2WSH script: spendable with the preimage of H, or refundable to the sender after a CLTV timeout.
3. The other side locks M1 on BATHRON under a hashlock keyed to the same H, with a shorter timeout.
4. The party holding the secret claims the leg it wants; that claim publishes the preimage on chain, and the counterparty uses it to claim the other leg.
5. If either side walks away, both timeouts fire and each party is refunded.

The timeout on the leg locked second is shorter than the timeout on the leg locked first, so that a party who learns the preimage cannot claim one leg while the other has already refunded.

The same construction works with a proof instead of a preimage: a BATHRON covenant can release M1 when TX_CONFIRMED proves that a given Bitcoin payment is buried under the in-consensus header chain (see Bitcoin facts inside consensus).

What this gives a market

• Native BTC enters M1 and leaves M1 without a custodian, a bridge or a wrapped asset.
• Bitcoin sees two unremarkable transactions; the size and counterparties of the trade can stay shielded on the BATHRON side (see Confidential settlement).
• Any chain with hashlocks and timelocks can be paired the same way — a capability, not a shipped product (see Pairing an external asset against M1).

Known limit: the initiator's free option

Between the two locks the initiator can wait and decide whether to complete or let the trade time out, depending on how the price moved; this "free option" is priced by the counterparty (premium, collateral, short timeouts), not eliminated by the protocol.

What was demonstrated

On testnet, paired-HTLC components have been exercised end to end: an M1 HTLC on BATHRON and a Bitcoin P2WSH HTLC keyed to the same preimage, both legs claimed and the same preimage verified on each chain. A general atomic client service — every intermediate state, reorganisation rule and refund branch specified and reviewed — is not claimed; see Status & claims.

Primitives: hashlocks (HTLC) · CLTV / CSV · TX_CONFIRMED · shielded transfers

See also: Delivery-versus-payment and OTC · Create your first market

Pairing an external asset against M1

The question a market builder asks first: can I pair my asset? The honest answer has two parts — what the primitives make possible for any chain, and what has actually been demonstrated. This page keeps them apart.

The mechanism is chain-agnostic

Native BTC ⇄ M1 is paired with two hashlocked, timelocked contracts — one on each chain — keyed to the same secret (→ Native BTC ⇄ M1). Nothing in that pattern is specific to Bitcoin. It needs, on the other chain, exactly two things:

1. a hashlock — a script that pays only when a preimage is revealed;
2. a timelock — a refund path after a deadline (CLTV/CSV or equivalent).

Chains descended from Bitcoin's script (PIVX, DASH, Litecoin, Dogecoin, and many others) have both. So do most chains with a scripting layer. A chain that supports hashlocks and timelocks can be paired against M1 the same way — one HTLC there, one HTLC here, same preimage. No fork of the other chain, no permission from its developers, no bridge, no wrapped asset.

     other chain                             BATHRON
  ┌────────────────┐                    ┌────────────────┐
  │ HTLC(H) + CLTV │◄── same secret ───►│ HTLC(H) + CSV  │
  └────────────────┘                    └────────────────┘
       X inventory                          M1 inventory
                       X / M1  — a market, if someone quotes it

Chains without a scripting layer (or with only signature-based scripts) need adaptor-signature constructions instead; that is a different piece of engineering and is not covered here.

What is demonstrated, and what is not

You will not read on this site that BATHRON "supports" a given coin. It supports hashlocks and timelocks; the market decides which coins get paired.

Why pair against M1 rather than against BTC directly

Because of the hub (→ The settlement unit): with M1 as the common leg, a provider holds one inventory and quotes many pairs, and every pair inherits the depth of BTC/M1 instead of needing its own. And because M1 is what BATHRON's covenants can lock, release, hedge and net — a DOGE/M1 market can be extended into DOGE-against-delivery, DOGE escrow or a DOGE-denominated hedge without leaving the settlement layer.

What it costs a market builder

Inventory in the paired asset, inventory in M1, a node on each chain, and the willingness to quote first. That is the whole entry ticket. The delisting committee does not exist.

Next: Settlement patterns

Settlement patterns

A market needs more than a spot exchange of two assets. Real settlement is conditional: delivery against payment, funds released only when an event is proven, positions that pay out on a Bitcoin fact or on a signed price. Each pattern below is a way to build one of those conditions from the same primitives — hashlocks, timelocks, CTV, CSFS, TX_CONFIRMED — so that a market builder does not have to trust an intermediary to hold the funds in between.

These are compositions of primitives that any market builder can assemble, not shipped products. Each page lists its primitives; the covenant surface is documented in Script & opcodes.

See also: Native BTC ⇄ M1 · Build your first application

Delivery-versus-payment and OTC

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 that holds both legs. A market on BATHRON solves it with a covenant: both legs are locked under the same condition, and they settle together or refund together. OTC settlement is the same pattern with one addition — the size of the trade stays hidden.

Delivery versus payment

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

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/CLTV) guarantee that an abandoned trade refunds both sides.

The legs do not need to live on the same chain: one can be a native Bitcoin transaction, either proven by SPV (TX_CONFIRMED) or paired as an HTLC keyed to the same hash. That is how the native BTC ⇄ M1 pair works — DvP where one deliverable is bitcoin.

Atomic settlement needs programmability (which Bitcoin refuses) plus verification of Bitcoin facts (which nobody else has without an external attester). The combination is the niche.

OTC: DvP with shielded size

Large trades have two enemies: counterparty risk and information leakage. The paired legs address the first; shielded transfers address the second.

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

1. Two parties agree on a price off-chain — the protocol does not care how.
2. Each locks its leg under a hashlock keyed to the same secret; one leg can be native Bitcoin.
3. The paired legs settle both-or-neither, and the M1 side moves shielded: the market never learns the size.

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.

These pages describe component-level behaviour; see Status & claims.

Primitives: hashlocks (HTLC) · CSV / CLTV · TX_CONFIRMED · shielded transfers

See also: Confidential settlement

Conditional escrow

Many trades are not "pay now, receive now": payment depends on a second leg, a deadline or an event that has to be proven. Today that means an escrow agent who holds the money and whom both sides must trust. On BATHRON the escrow is a covenant: it releases when the condition is proven and refunds when the timeout passes, and no agent holds the principal in between. Lightning and plain Bitcoin transactions remain the better choice for ordinary payments; this pattern starts only where a condition is attached.

The flow

A Clearing Provider quotes an execution path and a timeout path in the client's familiar assets — amount, fees, deadline, refund route. Liquidity Provider inventory funds the conditional M1 leg. A proven event releases the settlement; if it does not occur, the client's commitment follows the specified refund path.

client BTC commitment -> quoted condition
                             | condition proven
                             v
                    CP/LP internal covenant -> recipient leg
                             |
                             +-- timeout -> client refund path

The client is not asked to hold or spend M0/M1; the condition is evaluated in BATHRON's settlement state, and the client sees only the quoted BTC path.

Conditions a covenant can check

• a confirmed Bitcoin payment — TX_CONFIRMED proves the payment is buried under the in-consensus header chain;
• a designated signature — CSFS verifies a signature from a named key over agreed data;
• an expiry — CSV/CLTV enforce the timeout;
• a forced destination — CTV constrains where the released funds may go.

What must be defined

Every execution and refund branch has to be spelled out — Bitcoin-side timelock ordering, reorganisation handling, wallet verification — before a flow can promise that no agent can take the principal. That specification is a design target, not a current general guarantee; see Status & claims.

Primitives: TX_CONFIRMED · CTV · CSV / CLTV · CSFS · confidential internal transfers

See also: Build your first application

Hedging on Bitcoin facts

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 someone to report the number. On BATHRON the settlement condition can be Bitcoin's own difficulty, read by consensus from the header chain it already carries. A market for difficulty hedges can therefore exist without a designated reporter, and anyone can build one.

  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. There is no reporter to bribe and no publisher to go offline. Scripts can inspect difficulty, timestamps and accumulated chainwork the same way (see Bitcoin facts inside consensus).

The honest caveat

Difficulty can be verified without an external reporter because Bitcoin publishes it. This still relies on BATHRON's Bitcoin-header validation, its Operator-finality assumptions and the software used by the parties. A full hashprice hedge also involves the BTC price — which is not an on-chain fact and needs a signed input (CSFS), with the additional trust in that signer which it implies.

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

See also: Fixed-term value positions

Fixed-term value positions

Some participants in a market want exposure to a reference value for a fixed period — a merchant who must pay a supplier in ninety days, a provider hedging inventory — without holding the asset itself. Today that means a stablecoin (an issuer's liability) or a broker. On BATHRON it can be a bilateral contract: two parties, collateral in a covenant, and a payout selected at expiry by a signed reference price. BATHRON does not mint a stablecoin, and this pattern is not one.

The contract

A professional counterparty quotes the contract, prices the risk and commits collateral in M1. The other participant sees the quoted payoff and fees. At expiry, a price signature from the designated signer — verified by CSFS — selects which branch of the covenant pays out; CSV/CLTV bound the term and provide the fallback if no valid signature arrives.

  participant ───┐                        ┌─── professional counterparty
                 ▼                        ▼
           both commit collateral in a covenant, term T
                              │
                              ▼  at T
           CSFS checks the signed reference price
                              │
              price above K          price below K
                    │                      │
                    ▼                      ▼
             pays one side          pays the other

Balances on the M1 side can stay confidential; the reference price and the payout rule are explicit in the covenant.

What this is not

It is not a stablecoin: nobody issues a unit that claims par against anything, and the other participant is not invited to acquire network exposure. It is a bilateral position with real signer, counterparty, liquidity and model risk. Collateralisation and a fixed expiry limit some of those risks; they do not remove them. No implementation should be described as stable until its payout rules, signer failure modes and liquidation assumptions have been reviewed — see Status & claims.

Primitives: covenants · CSFS · CSV / CLTV · confidential internal balances

See also: Hedging on Bitcoin facts · Why not an exchange, a bridge, or a stablecoin

Confidential settlement

A market cannot work if every participant publishes its counterparties, sizes and inventory to its competitors. Providers would be front-run on every quote and clients would move the market against themselves with every large trade. Confidentiality is therefore not a product on BATHRON; it is a property the settlement state needs so that markets can be built on it at all.

BATHRON uses Sapling proofs for confidential transfers of M1.

What can be hidden

• amounts and balances in the shielded pool;
• linkage across a shielded transfer — who paid whom, and how much.

What remains verifiable

• consensus verifies conservation without learning the hidden amounts;
• burns, locks and Bitcoin-header proofs remain transparent where auditability requires it;
• the M0 and M1 accounting invariants remain public (see Accounting invariants).

What it does not cover

Shielding hides the M1 side of a settlement, not the whole workflow. Bitcoin edge transactions, timing, network metadata and application behaviour may still reveal information; BATHRON does not claim Monero's anonymity set or a complete privacy guarantee.

In practice, Clearing and Liquidity Providers use the confidential state as back-office infrastructure — inventory moves and OTC sizes stay private — while end users settle in the assets they already hold and are never asked to manage "private cash".

Primitives: shielded transfers (Sapling) · shieldsendmany

See also: Delivery-versus-payment and OTC · Run a wallet

Bitcoin is the final asset

BATHRON exists to let markets settle without asking permission — but it does not exist to replace the asset those markets ultimately care about. Bitcoin stays the reserve of value and the only origin of the settlement unit. Getting this relationship right is what keeps BATHRON from becoming one more custodian, bridge or issuer standing between a user and their BTC.

What BATHRON is, relative to Bitcoin

BATHRON reads Bitcoin; it never commands it.

• It never replaces Bitcoin. Bitcoin is where value is held; BATHRON is where settlements between assets are made final.
• It never holds BTC for redemption. There is no vault of Bitcoin, no custodian, no address that "backs" anything.
• It cannot move native BTC or trigger a Bitcoin transaction. Consensus can verify Bitcoin facts — headers, proofs of inclusion, irreversible destructions — and that is the whole extent of the link (Bitcoin facts inside consensus).

Bitcoin does not decide who may hold BTC; BATHRON does not decide which markets may exist. Both sit underneath what people build, and neither one owns it.

The link is one-way

The only way M1 comes into existence is by destroying BTC. Bitcoin is sent to a provably unspendable output; every BATHRON node verifies the destruction against the Bitcoin header chain it carries in consensus; one M0 unit is permitted per destroyed satoshi; M0 is vaulted 1:1 into M1, the settlement unit.

BTC --one-way, SPV-proven destruction--> M0 --lock 1:1--> M1
                                          (no reserve · no redemption)

Because the arrow only points one way, three things follow in plain words:

• There is no reserve. The destroyed BTC is gone. Nobody holds it, so nobody can lose it, freeze it or lend it out.
• There is no redemption. M1 cannot be handed back to the protocol in exchange for BTC. There is no counter to walk up to.
• M1 has no external peg. The 1:1 rule between M0 and M1 is an internal accounting rule (invariants); it says nothing about what M1 is worth in BTC on any given day. M1 is a settlement unit that market builders and providers use as a pivot — not a claim on Bitcoin.

That is why this site never describes M1 as backed. Backing implies a reserve and a redemption promise; there is neither. M1 originates from Bitcoin — a different thing.

How native BTC comes back: the market

If the protocol cannot give BTC back, what makes native BTC available again is the market. Someone who holds M1 and wants BTC finds a counterparty who holds BTC and wants M1 — a Liquidity Provider, another user, anyone with inventory — and the two sides settle through paired hashlocked contracts: an M1 HTLC on BATHRON and a Bitcoin HTLC on Bitcoin, sharing one preimage. The protocol guarantees the M1 leg; the Bitcoin leg is an ordinary Bitcoin contract; the pairing is what makes the exchange safe for both sides.

This is the native BTC ⇄ M1 pair — the first and most important market on BATHRON, and one the protocol does not run. It exists because providers choose to quote it.

See also: From destroyed BTC to M1 · Status & claims

From destroyed BTC to M1

A settlement protocol needs a unit that its own consensus can lock, release and account for. Bitcoin cannot be that unit — BATHRON cannot command Bitcoin to spend — so an internal one is required. The question this page answers is where that unit comes from, who brings it into existence and why the answer is deliberately narrow: only from Bitcoin that has been provably destroyed.

Why an internal unit is required at all

Covenants, timelocks and hashlocks need an asset the BATHRON consensus can lock and release. M1 carries that programmable settlement state. M0 records where the inventory came from: a one-way origin in verified BTC destruction.

BTC --irreversible, SPV-proven destruction--> M0 --lock 1:1--> M1

Two consensus rules pin this down. In plain words:

• A5 — provenance. One destroyed satoshi permits one M0 unit; nothing else does. There is no block subsidy, no premine, no treasury and no issuer. Even the very first unit at genesis came from a verified destruction, exactly like every later one.
• A6 — accounting equality. The M0 vaulted for M1 equals the M1 in circulation. Lock and unlock are 1:1 protocol operations, so unvaulted M1 cannot exist.

Both rules are checked by every full node on every block; a finality quorum cannot sign its way around them. The formal statement is in Accounting invariants.

What a destruction looks like

Bitcoin is sent to a provably unspendable output — a script that can never be satisfied — with a small OP_RETURN naming the BATHRON destination that will receive the M0. Any node can then verify, against the Bitcoin header chain it maintains in consensus, that the transaction was included under sufficient work; after a maturity delay the M0 becomes claimable. The exact format, the unspendable script and the maturity constants are in the SPV reference.

The BTC is not held for redemption. It is destroyed. That is what makes M0 an inventory unit rather than a deposit receipt.

Who does this

Nobody has to touch M0 to use BATHRON:

End users settle in the assets they already hold; market builders and providers settle in M1.

The destruction route is a professional inventory-acquisition path — for Liquidity Providers who want inventory to quote a pair, for market builders who need a settlement float, and for anyone who wants to register as an Operator (registration requires locking M0 as collateral):

Bitcoin destruction  → M0 creation
M0 acquisition       → inventory, or collateral lock
collateral lock      → operator registration

Two properties matter for whoever takes this route:

• It is an irreversible cost. The BTC is gone; the M0 is inventory. That cost is recovered, if at all, through the service built on it — spreads on a pair, clearing fees, settlement — not through any protocol payment, subsidy or expected appreciation of the unit.
• Destroying Bitcoin yourself is not required. M0 already in existence can be acquired from a third party. The rule is only that every M0 unit, whoever holds it now, traces back to a verified destruction. An Operator's collateral is locked, not destroyed, and is recoverable by leaving the operator set.

What this buys

Because the origin rule is a single, verifiable, one-way path, three questions that plague other designs simply do not arise: there is no reserve to audit or lose, no issuer to trust or pressure, and no rule to vote on — one satoshi, one M0 unit, and there is no mechanism to change that. What M1 is worth in Bitcoin on a given day is then a market question, answered by providers quoting the native pair, never by the protocol.

See also: Bitcoin is the final asset · Bitcoin facts inside consensus · The settlement unit: M1

Bitcoin facts inside consensus

Markets that involve Bitcoin need to know things about Bitcoin: that a payment confirmed, that a burn happened, what the difficulty is. The usual answer is an oracle — a party you trust to report those things. BATHRON removes that party for one class of facts by carrying the Bitcoin header chain inside its own consensus, so that every node checks the fact itself. This page explains what that removes and what it still relies on.

Headers and SPV proofs

Bitcoin block headers enter BATHRON in ordinary transactions. Every node checks each header the way a Bitcoin light client would: proof of work, the difficulty adjustment schedule, timestamps and accumulated chainwork. Reorganisations are followed by chainwork within pinned safety rules — canonical checkpoints on the real chain and a floor below which no reorg is accepted.

Once the headers are there, a Merkle branch can prove that a specific Bitcoin transaction was included under sufficient work. Every validating node evaluates the proof; no designated operator attests to the event.

The Bitcoin chain read by consensus today is Bitcoin testnet4; mainnet will read Bitcoin mainnet. The header database, reorg rules and burial requirements are documented in the SPV reference.

Conditional Bitcoin facts

A script can require proof that a specific Bitcoin payment is confirmed before releasing an internal covenant:

Bitcoin payment -> Merkle proof checked by consensus -> internal covenant may release

TX_CONFIRMED performs this check. It proves one component of a conditional settlement — the "did the Bitcoin leg happen?" question — not a complete client service. What happens on the Bitcoin side, the timeouts and the reorganisation behaviour of a full flow are specified by whoever builds the market (Native BTC ⇄ M1).

Difficulty, time and chainwork

Scripts can also inspect Bitcoin difficulty, timestamps and accumulated work. A difficulty-linked contract therefore does not need a separate signer to report difficulty. A complete hashprice contract still needs an external BTC price input — that fact is not on the Bitcoin chain, so consensus cannot verify it (Hedging on Bitcoin facts).

The opcode-level detail — OP_BTCSTATEVERIFY, which fields are exposed, burial requirements — lives in the SPV reference and Script & opcodes.

What this removes — and what it still depends on

Removed: a designated external oracle for Bitcoin facts. Nobody signs "the payment confirmed"; every node computes it from headers and a Merkle branch.

Still depended on:

• honest-majority Bitcoin hashpower — the header chain BATHRON follows is the heaviest valid one it has seen; if Bitcoin itself were overpowered, so would be the facts read from it;
• operator finality — which BATHRON block a fact lands in is settled by production and finality;
• correct software — the header validation and proof checking are code, and code can have bugs.

The scope is also fixed: BATHRON can verify Bitcoin facts and irreversible destructions; it cannot move native BTC or trigger a Bitcoin transaction. Anything that must happen on Bitcoin is done by a participant, on Bitcoin, with an explicit Bitcoin-side contract.

Primitives: TX_BTC_HEADERS · TX_CONFIRMED / OP_BTCSTATEVERIFY · TX_BURN_CLAIM See also: From destroyed BTC to M1 · Status & claims

The target open network

This page describes what BATHRON is being built toward. It is TARGET NETWORK: with the exception explicitly marked below, none of it is deployed today.

Status & claims prevails over this page for anything about the present.

What the target network looks like

• A public, open network.
• Several independent Consensus Operators, none of whom chooses markets, providers or assets.
• Open Consensus-Operator admission, once the Sybil model and the economic conditions are validated.
• Several independent Settlement Providers, several Clearing Providers, several Liquidity Providers.
• Several competing applications and interfaces.
• No listing committee. No protocol-imposed matching engine. No privileged provider.
• Several providers may serve the same instrument or market.
• A provider may disappear without removing the protocol or the instrument.
• Users choose their application, their provider and their counterparty.

What is true today

Application building is already open: anyone can build an application or propose a settlement flow without a listing committee, and nothing in consensus registers or approves one.

Consensus-Operator admission is not open. The current operator set is run by the project while the open-admission threat model is worked out. That is the single largest gap between today and the target, and it is deliberate.

The invariants that will not change

Whatever admission mechanism is eventually chosen, these hold:

1. One Consensus Operator, one vote. Sybil resistance is counted per operator identity, never per node or per masternode.
2. No operator chooses what settles. Operators order and finalise; they do not curate.
3. No privileged provider. The protocol publishes facts about identities; it never ranks them.
4. Admission opens only when the cost of acquiring a threatening share is understood and acceptable — not when the code merely permits it.

Open design points

The exact admission mechanism is OPEN DESIGN. It is not decided, and this documentation will not pretend otherwise. What is settled is the goal and the invariants above; what is not settled is how identities are admitted, priced and bounded.

Related open points, none of them defects:

• how the expected committee size should be set for an open network;
• how the value at risk within a finality window should be bounded;
• what economic sizing makes a one-third share prohibitively expensive.

See Open-network hardening for the arithmetic that constrains any answer.

Why the consensus is frozen

Most protocols promise features. BATHRON promises the opposite: the consensus — the small set of rules every node enforces — is frozen, and everything of value is meant to grow above it. This matters to anyone building a market here, because it is what makes the ground stable: the rules a market settles under will not shift because a feature became fashionable.

The rule

The freeze is not a mood; it is a written rule with a burden of proof:

Any addition to consensus must demonstrate that it enables something impossible to obtain cleanly in a higher layer. Failing that, it is rejected.

Three things follow from how the rule is phrased:

• The burden is on the addition, never on the absence. Nobody has to justify not adding something. The proposal has to prove that markets, wallets, indexers or applications genuinely cannot do the job.
• The test is about a concrete, current need — never a "future possibility". A hard fork for a proven need is preferable to consensus surface kept around for a hypothetical one.
• The price of a consensus line is understood up front. Every line of consensus is decades of maintenance, a format that can never change again, and an attack surface every node carries forever.

TCP/IP is a fair analogy: the protocol stayed small and dull, and the web grew on top of it. Nobody asks TCP to add a shopping cart.

What lives above consensus

Because of the rule, the things people usually expect a protocol to grow are placed in the layer above, where they can evolve, compete and be replaced without touching the rules:

• Markets and quotes — a pair exists because someone brings inventory and publishes a price; the protocol only settles (How a market appears).
• Applications — escrow, delivery-versus-payment, hedging, fixed-term positions are compositions of covenants, HTLCs, timelocks and Bitcoin facts, not protocol features.
• Reputation and provider choice — the protocol publishes facts about Operators (age, blocks produced, service history) and never says one is better; wallets and indexers rank, the market decides.
• Fast liveness signals — "is this Operator up right now?" is answered by indexers and applications, not by consensus. Consensus keeps only the slow, chain-evident signal (block production), because a fast gossip signal fed into consensus would let a network adversary change who counts toward finality. That decision was studied and settled (Open-network hardening).

The same discipline already rejected proposals that sounded reasonable — for instance a consensus-level link between an Operator and a service identity, which turned out to be an ordinary signed attestation any wallet can verify off-chain.

Not on the roadmap

Discipline is part of the design, so some things are deliberately absent — listing them matters as much as listing the work:

• No token, no treasury, no yield, no governance coin. Security is funded by fees; there is nothing to issue and nothing to vote a subsidy for.
• No protocol rewards or ranking for Operators. The protocol publishes facts about Operators and never says one is better — applications choose, the market decides.
• No changeable origin rule. One verified destroyed satoshi permits one M0 unit. There is no mechanism to change that, and there will not be one.
• No feature sprawl. The substrate is meant to stay small and finished. What should grow is what is built on it, not the kernel.
• No slashing. Deterrence is the up-front cost of acquiring and locking M0 collateral plus proof-of-service bans, never confiscation. A slashing bug can destroy honest Operators' funds — a catastrophic, irreversible failure seen on other chains — and it buys little the up-front cost and bans do not already provide. This is a deliberate choice and will not be reconsidered.

What "frozen" does not mean

Frozen does not mean nothing ever changes. A demonstrable bug or vulnerability is fixed. The open-network hardening work — auditing the finality path, sizing committees, pricing collateral — is a list of proofs to finish and permissions to safely remove, not features to add. It means the shape of consensus is finished, and the site describing it should rarely need to change:

If this page has to change often, something has gone wrong. The currently deployed surface is intentionally narrow, and any consensus change requires an explicit protocol and governance decision; the roadmap is mostly a list of proofs to finish and permissions to safely remove — not features to add.

See also: What BATHRON deliberately does not do · Production and finality · Status & claims

Production and finality

A settlement is only useful once it cannot be undone. BATHRON's consensus therefore answers two questions separately — who makes the next block, and when that block becomes irreversible — and keeps both answers deliberately simple, so that a market builder can reason about when a settlement is final without reading the source.

Two separate layers, deliberately kept apart:

Operator selection

The parties who produce blocks and sign finality are Settlement Operators — network identities collateralised with M0. Because M0 can originate only from verified BTC destruction, Sybil resistance has an up-front acquisition cost paid before a single block is signed. One Operator can run several nodes but counts once: the unit of consensus is the Operator key, not the machine. One Operator, one vote.

Naming note: in the node's RPC surface and source these identities keep their lineage name, masternode (protx, getactivemnstatus). The public model — what an Operator is — is the Settlement Operator. Commercial Clearing and Liquidity Provider roles are separate. → Roles

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. Because the designation is deterministic, a block signed by the wrong Operator is rejected by every 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 eligible Operator count at the block and E a fixed expected committee size (a target the VRF sample varies around, not a hard 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 reorganised — finality overrides the longest chain, whatever the chainwork.

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 accounting 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

Block subsidy and internal-unit origin

There is no block subsidy: block_reward = 0, no treasury and no premine. Coinbase pays exactly the block's fees. Separately, M0 can be created only from verified BTC destructions under A5. That creation path is not a reward or discretionary issuance (From destroyed BTC to M1).

Where the rest is

The design choices behind these mechanisms (signature scheme, why there is no slashing) and what a threshold coalition can and cannot do are on the security model; the work of opening the Operator set is on Open-network hardening; the current status of the network is on Status & claims.

Primitives: deterministic producer draw · ECVRF finality committee · ⌈2/3 · min(E, N)⌉ · block_reward = 0 Reference: Consensus parameters

Security model

A settlement layer is only worth building on if its guarantees are stated precisely — including their limits. This page separates three kinds of statement:

• Fact: enforced by the software and consensus rules today.
• Design goal: intended behaviour that is not yet fully implemented or reviewed.
• Market hypothesis: an economic or institutional claim that still needs evidence.

Security in two minutes

1. Consensus enforces the monetary invariants. Professionals provide quotes, execution, liquidity and client service outside consensus. (fact + design)
2. Operator collateral and public history may create commercial deterrence, but they do not replace the BFT assumption. They prove neither legal identity nor future honesty. (fact + hypothesis)
3. A malicious finality threshold cannot create M0 without a verified Bitcoin destruction. It can, however, censor operations, stall finality or create divergent finalized views. (fact)
4. Open-set Sybil resistance is not demonstrated. (fact + hypothesis)

What consensus enforces

Every node validates every block. Finality is added on top of validation; it does not bypass it.

• A5: M0 can be created only from Bitcoin destruction verified through SPV.
• A6: M0 vaulted for M1 equals the M1 supply; the protocol conversion is 1:1.
• A9: the tracked Bitcoin chain must be the real Bitcoin chain — canonical checkpoints and a reorg floor below pinned anchors and matured burns.
• No block subsidy, premine or treasury issuance: coinbase recycles fees.

A finality threshold cannot sign an invalid issuance into existence. Honest nodes reject a block that creates M0 without a valid proof, breaks M0↔M1 accounting or contains another invalid state transition.

This does not make ordering and liveness unconditional. A threshold coalition can omit an operation from blocks it produces, refuse to finalize blocks that include it, stall finality, or equivocate across a partition.

The BFT assumption

The finality threshold is:

ceil(2/3 × min(E, N))

where N is the number of eligible, distinct Operators and E is the expected committee size (a target, not a hard cap: in the sampling regime the drawn size varies around it). One Operator identity has one vote.

Safety and liveness rely on the applicable committee remaining below the Byzantine threshold. Operator history and collateral are commercial signals; they do not change that mathematical assumption. The assumption also does not remove software bugs, Operator-key compromise, shared-hosting failures or other correlated failures. Who runs the Operator set today, and what that does and does not demonstrate, is stated on Status & claims.

What a threshold coalition can and cannot do

The residual finality failure is therefore a split with divergent views, followed by an out-of-band social recovery. It is not an automatic rollback silently accepted by nodes that already finalized the conflicting height.

Destruction, M0 and Operator collateral

The causal chain is:

Bitcoin destruction  → M0 creation
M0 acquisition       → collateral lock
collateral lock      → operator registration

• The destroyed Bitcoin is not held, reserved or redeemable.
• The M0 collateral is locked, not destroyed. Under the current rules it is recoverable by spending the collateral output and leaving the Operator set.
• An Operator need not have destroyed the Bitcoin itself; it may acquire M0 from a third party.
• The external acquisition cost therefore depends on future M0 liquidity. It is not a fixed protocol price.

The current floor is a launch parameter expressed as 0.01 BTC-equivalent. It is not a demonstrated Sybil price.

The finality threshold counts distinct eligible identities, not an aggregate amount of collateral. An attacker needs enough M0 to register enough separate identities: about a third of the eligible set to stall finality or — combined with a network split — to sign conflicting certificates (with q = ⌈2/3·min(E,N)⌉ and everyone signing while N ≤ E, two certificates always share at least 2q − N signers), and the full quorum to control ordering outright. See Open-network hardening.

Design choices

• ECDSA on secp256k1 only. No BLS, no aggregated signatures — explicit signatures are simpler to audit at these committee sizes, and one round of gossip already reaches finality in about a minute regardless of committee size.
• No slashing. Deterrence is the up-front cost of acquiring and locking M0 collateral, plus a proof-of-service ban that removes an identity from the active set without confiscating its M0. Any loss of future fees or service revenue is only a possible commercial opportunity cost; those revenues are not proven. The reasoning is restated on Open-network hardening.
• Finality above validation, never instead of it. This is what makes the table above hold: the signers decide ordering; the money is checked by every node.

Reputation and provider roles

An Operator's registration age and production history are observable facts, but they do not prove legal identity or future honesty. Provider volume, latency and incident metrics require an independent indexing methodology and can be manipulated through wash activity or selective disclosure.

Settlement Operators, Clearing Providers and Liquidity Providers are distinct roles; see Roles: Operators, Settlement Providers, users. Choosing or pinning a provider establishes a service route or endpoint. It does not create a private consensus committee and does not replace the global finality set. The protocol does not currently prove that an Operator and a Clearing or Liquidity Provider are the same legal or economic entity.

Comparison with Bitcoin

Bitcoin and BATHRON close different attack surfaces with different assumptions. Both require full nodes to reject invalid blocks. Bitcoin orders history through proof of work and probabilistic depth; BATHRON uses a registered Operator set and BFT finality. BATHRON's residual finality failure is split and social recovery, while its open-set economic resistance remains unproven.

For implementation details, continue with Production and finality, Bitcoin facts inside consensus and Accounting invariants.

Reporting a vulnerability

Report suspected security issues privately to security@bathron.org. Please do not open a public issue for an unpatched vulnerability. Include enough detail to reproduce; the inbox is monitored and coordinated disclosure is preferred. The full policy ships as SECURITY.md in the bathron-core repository.

Notes

Node-local destruction policy. The -btcburnsenabled option is a node-local origination and relay policy, not a global administrator switch. A node with the option disabled still accepts a valid block containing a destruction claim produced elsewhere. Pausing new claims across the network would therefore require coordinated producer behaviour.

Open-network hardening

Anyone can build, quote, pair and settle on BATHRON without asking permission. Operator admission is not yet open: the current operator set is project-run while the open-admission threat model is worked.

This page is the work that separates the two halves of that sentence. Opening the Operator set to independent parties is a different threat model from a project-run set: it must hold against a Byzantine fraction of Operators, key compromise and correlated infrastructure failure. The items below are the prerequisites for that transition — the honest core of what remains before mainnet. Where the network stands against them is on Status & claims.

The one thing that never changes

First, the guarantee that holds in every phase and underpins everything below:

The finality committee cannot touch the money. Finality decides ordering, never issuance. Every node fully validates every block, so a quorum — even a fully captured one — cannot mint a unit, break the accounting invariants, or confirm an invalid transaction. M0 origin remains constrained by verified BTC destruction.

The invariants answer whether an invalid monetary state can be accepted by an honest full node. The separate open-network question is whether a threshold can censor, stall or create divergent finalized views. That is what the items below bound.

The attack surface, stated plainly

Four quantities must be kept apart, because the arithmetic below depends on which one is meant. The definitions follow the implementation (HuActiveFinalityThreshold, IsVrfSelected in src/state/quorum.cpp), not a textbook:

Below the Sybil floor (nHuQuorumSize = 4 distinct Operators, mainnet and testnet alike) the threshold is unreachable: a network with fewer eligible Operators keeps producing blocks and never finalizes.

Regime 1 — everyone signs (N ≤ E; every deployment up to 128 Operators)

Here m = N exactly and q = ⌈2N/3⌉, so the arithmetic is exact:

• Liveness. If more than N − q Operators — roughly a third — go silent, finality stalls: it stops advancing until enough honest Operators sign again. The chain keeps producing blocks (production has its own fallback); it is irreversibility that waits. Nothing is lost, nothing is forged — settlement simply isn't final yet.
• Safety. Two conflicting certificates must share at least 2q − N signers — about a third, not two thirds — and those shared signers are, by construction, equivocating. So an adversary holding roughly a third of the identities and a network split can present divergent finalized views to different parts of the network; at the full quorum it controls ordering (and censorship) outright. The money cannot be forged in either case — such an adversary can censor settlement, stall finality and equivocate, never mint. Each honest node's chain-level guard rejects any block that would rewrite a height it has finalized, from any fork, regardless of chainwork; reconciling divergent views across nodes is an operational event, not an automatic one.

Worked examples (q = ⌈2N/3⌉, minimum equivocators = 2q − N):

Put together: liveness and safety both degrade at about one third of the identities; full control of ordering needs two thirds. The economic sizing below is against the one-third figure, never against the quorum.

Regime 2 — sampling (N > E; not reached by any network to date)

The quorum stays fixed at q = ⌈2E/3⌉ (86 at E = 128) while the drawn committee m varies around E from block to block. Consequences that the exact arithmetic above no longer captures:

• the intersection of two certificates is max(0, 2q − m), so the number of equivocators needed shrinks when the draw is large (m = 128 → 44; m = 140 → 32) — an oversized draw with m ≥ 2q (172 at E = 128; astronomically unlikely but not excluded by the rules) would in principle allow two disjoint certificates with no equivocator at all;
• liveness needs q live signers among the m drawn — an undersized draw makes a stall more likely, and a draw with m < q cannot finalize that block at all (no re-draw is defined);
• an adversary's share of the drawn committee is a random variable around its share of N, which is what committee sizing (below) is about.

How this regime should be bounded — whether the quorum should track the realised draw, and what the fallback is when a draw is too small — is an open design point, not a documented property. The examples above are stated only for regime 1. → Status & claims

The committee draw is non-grindable: a per-block ECVRF over each Operator's secret key, so an attacker cannot predict or steer which Operators will be drawn — which is what makes adaptive corruption hard. The levers below turn "bounded" into "priced out."

The work

• Bounding value-at-risk until detection and halt. Because the money cannot be forged, what a captured committee can damage is ordering — and only for as long as the capture lasts and applications keep accepting its finality. The bound to aim for is therefore the cumulative value exposed between the start of a capture and the end of operational recovery — detection of divergent views, wallets and applications halting acceptance, and the out-of-band reconciliation that follows — not merely the throughput of one ~1-minute window: a persistent coalition can attack successive heights, and "more confirmations" does not help if the same compromised identities finalize every block. The levers that do work are a cap on value settled per window (so the exposure per unit of detection time is bounded), a larger committee for high-value settlement (a statistical gain — it lowers the probability that a random draw hands the adversary a third, under the explicit assumptions that the adversary's identities are a minority of the eligible set and that the draw is unbiased; it does nothing against a majority), and fast out-of-band detection of divergent finality. This turns a catastrophic tail into a capped, priced one — provided the halt is real, which is an application-layer obligation as much as a consensus one.

• Committee sizing. The threshold auto-scales as ⌈2/3 · min(E, N)⌉, so no constant needs retuning as Operators join. Setting the expected committee size E for an open network is a security-budget decision — large enough that a random draw statistically yields an honest supermajority against an adversary approaching ⅓ of the eligible set. Under the explicit assumptions above (minority adversary, unbiased draw), the probability that a committee of size E contains ≥ ⌈E/3⌉ adversarial identities falls exponentially in E; a larger cap buys resistance, it does not buy certainty, and in the sampling regime it interacts with the 2q − m intersection described above (open design point).

• Collateral economics. The chain of costs is explicit: BTC destruction is what creates M0; registering an Operator identity requires locking M0 collateral — M0 the Operator may equally have acquired from a third party rather than burned for. Finality is counted over distinct eligible identities, so the Sybil question is the price of that lock — sized against the one-third figure above (enough identities to stall or, with a split, to equivocate), not against the full threshold: acquiring that many identities must cost more than the value exposed until a capture is detected and settlement halts. This is the economic half of the safety argument, decided at opening. Operating a node carries no guaranteed commercial revenue — fees are market-driven.

• External cryptographic audit of the VRF module. Finality has a single path — the ECVRF sortition — so its implementation is the hardest mainnet gate. What is publicly checkable today is the code and its tests in bathron-core — the vendored ECVRF module and src/test/vrf_tests.cpp, which exercises it against known-answer vectors. No external cryptographic audit has been performed, and an independent one is a hard, non-negotiable gate before real value.

• Separating the producer and the provider. An Operator that both produces blocks and also competes as a Clearing or Liquidity Provider could, in principle, order or delay a competitor's settlement (an MEV-like edge). The roles are kept protocol-separable even though they are business-combinable — an open-network design item, not a permissioned-launch one.

• Operator liveness — studied, and deliberately left in consensus as-is. The short version: the consensus signal stays slow and chain-evident, and the fast "is this Operator up right now?" question moves to the market layer. Details below.

No slashing — a deliberate choice, restated

Deterrence is the up-front cost of acquiring and locking M0 collateral plus proof-of-service bans (loss of eligibility to produce — an opportunity cost, since no revenue is guaranteed in the first place), never confiscation. A slashing bug can destroy honest Operators' funds — a catastrophic, irreversible failure mode seen on other chains — and it buys little the up-front cost and bans don't already provide. This will not be reconsidered.

See also: Security model · Production and finality · Why the consensus is frozen

Status & claims

This is the one page on the site that carries the full caveats. Every other page links here instead of repeating them, so that the message elsewhere stays readable — and so that a reader who wants to know exactly what is proven, what is not, and what BATHRON refuses to claim can find it in one place.

Where the network is

Three phases, gated, not scheduled. Each phase must earn the next — a date would be a promise the code hasn't made yet.

Done — private testnet. A multi-node network exercised the consensus surfaces then in scope: VRF finality, the in-consensus Bitcoin header chain, burn → mint, the covenant opcodes, shielded transfers, a real Bitcoin payment releasing a covenant, and paired HTLCs for a BTC-out leg. The consensus surface was frozen during this phase; the work was proof, not features — the primitives then in scope exercised on-chain (accept and reject paths), adversarial red-teaming, fuzzing of the money chokepoints, and dead code removed where it was found. Its gate was passed on the evidence available at the time: the surfaces then in scope were exercised live, with no monetary or safety issue open against them that this work had identified — an absence of findings, not a proof of absence, and no external audit was involved — with a clean launch genesis rehearsed.

Now — public testnet. The current phase. Published genesis and peers, a public block explorer, the Clearing and Liquidity Provider prototypes, the SDK and runnable examples. The public testnet is built to differ from mainnet in as few ways as possible: same block rules, same invariants, same finality math, same M0-origin rule. The differences that remain are the ones that must differ — the Bitcoin network it reads (testnet4 vs mainnet), the genesis message and the address identity bytes. The goal of this phase is one thing: the first builders shipping on the substrate. Disposable-genesis resets remain possible while the network stabilizes. This is also where the Operator set begins to open — from a project-run set toward independent Operators; the open-network hardening track exists to make that safe. Gate to mainnet: the hardening items resolved or explicitly bounded, and the external audits returned.

Then — mainnet. Gated, not scheduled — and not planned for any date. Mainnet carries real value, so it also carries the one rule that never bends: genesis itself is SPV-verified like every block after it — no special case, no bypass, no premine. Any first internal unit on mainnet would have to originate from a verified Bitcoin destruction, exactly like the millionth. The mechanical launch steps (mine and pin the mainnet genesis with a recency proof, flip the covenant gates to active, ship the non-disposable bootstrap tooling) are written down and mostly built — execution, not research. The research-shaped prerequisites are the hardening track.

How to read the five labels

This documentation labels every capability. The labels are load-bearing, and the first one is the one most easily misread: an opcode being active in consensus does not mean a product uses it.

Active primitives. The covenant, introspection and Bitcoin-fact opcodes are active in consensus on this testnet: OP_BTCSTATEVERIFY, OP_TEMPLATEVERIFY, OP_CHECKSIGFROMSTACK, OP_CAT, OP_CHECKOUTPUTVALUE, OP_CHECKOUTPUTSCRIPT, OP_PUSHCURRENTSCRIPT, plus the two timelock opcodes. Declared in src/script/script.h, implemented in src/script/interpreter.cpp.

Demonstrations. Paired-HTLC settlement against Bitcoin, covenant accept and reject paths.

Products that do not exist. No price oracle, no margin engine, no liquidation in consensus, no synthetic asset, no built market. An active opcode is not a product.

Target network, not deployed. Open Consensus-Operator admission, several independent operators and providers — see The target open network. The exact admission mechanism is OPEN DESIGN: not decided.

Known coverage gaps. BTCSTATE_TX_CONFIRMED has no dedicated test suite. OP_CAT, OP_CHECKSIGFROMSTACK and the two output-introspection opcodes have unit tests but no end-to-end demonstration. The confidentiality of covenant-bearing settlement is not demonstrated.

Current public testnet

Live (measurement network):

• Genesis block 0: 691b0a7e8cb0e7ee159ef7a4fa10d9c6ddb2d5282e5bac7447846459ff54c730
• Public seed: 57.131.33.151:27171
• Bitcoin source read by consensus: Bitcoin testnet4 (mainnet at mainnet)

Exercised on this network:

• covenants — accept and reject paths;
• Bitcoin headers and Merkle proofs verified inside consensus;
• burn → M0 → M1;
• shielded transfers;
• paired HTLCs — an M1 HTLC and a Bitcoin P2WSH HTLC sharing one preimage. Components are covered by public test suites; no reproducible artifact of an end-to-end run is published.

Historical demonstrations

Runs from earlier networks, kept for the record. They were real; the network they ran against is not the one live today, and nothing here should be read as describing current behaviour.

• The Clearing and Liquidity Provider prototypes (pna-lp, pna-swap) exposed quotes over HTTP. They are decommissioned: their application state belonged to a superseded network and the services are not running. Their HTTP APIs are not available, and no endpoint should be treated as callable.

What is not proven

• No mainnet.
• No external audit yet — in particular, no external audit of the VRF finality path.
• No proven market: no sustained client demand, provider revenue or competitive liquidity.
• The Operator set is project-run. Sybil resistance under open Operator admission is not demonstrated; the current set does not demonstrate Byzantine resistance under open admission, and does not remove software bugs, key compromise or correlated infrastructure failure.
• No value-at-risk bound per finality window.
• No protocol-enforced or independently verified Operator↔provider identity link.
• No productised, externally reviewed cross-chain conditional-settlement flow: paired HTLC components have been tested, but general atomicity is not claimed before the full state machine is specified and reviewed.

Open design points (not defects, not features)

• Sampling regime of finality (N > E). The quorum is ⌈2/3·min(E,N)⌉ and stays fixed when more than E Operators are eligible, while the VRF-drawn committee size varies around E. Whether the quorum should track the realised draw, and the fallback when a draw is too small, are undecided; no network has reached this regime. → Open-network hardening

Claims we do not make

You will not read on this site that:

• client funds are guaranteed;
• settlement is atomic in general;
• there is "no counterparty risk";
• M1 has an external par or a peg;
• M1 is "backed by Bitcoin";
• BATHRON is a "CLS for crypto";
• M0 or M1 carry a yield or an expected appreciation;
• BATHRON "supports" this or that chain — any chain with hashlocks and timelocks can be paired the same way; that is a capability, not a shipped product.

If a page anywhere on bathron.org contradicts this list, the list wins and the page is wrong.

One line for the other pages

Every other page — and every README in the bathron-network repositories — links here instead of repeating these caveats; where any other public text claims more, this page prevails (documentation policy).

See also: Open-network hardening · Security model · Why the consensus is frozen

Run a node

Running your own node is how you take part in a market without trusting anyone's word for it: your node validates every block, every settlement and every Bitcoin fact carried into consensus, and it needs no permission from anyone to join. A market builder, a provider or a plain user who runs a node verifies every settlement themselves — nobody has to be asked, and nobody can be asked to look away.

The public testnet is live. A published seed node and a fixed genesis are available, and a fresh node can join with only the seed address — no RPC access and no operator address are needed. There is no mainnet. This is experimental software with a disposable-genesis testnet.

Join the public testnet

mkdir -p ~/.bathron
printf 'testnet=1\n[test]\naddnode=57.131.33.151\n' > ~/.bathron/bathron.conf
bathrond -testnet -daemon
bathron-cli -testnet getblockhash 0
# expected:
# 691b0a7e8cb0e7ee159ef7a4fa10d9c6ddb2d5282e5bac7447846459ff54c730
bathron-cli -testnet getblockcount   # syncs to the network tip

RPC is loopback-only by default. Operator addresses are deliberately not published; the seed above is the only endpoint needed to join.

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). Pre-built binaries for tagged releases are published on the bathron-core releases page.

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 (testnet4) header chain

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

During the initial sync, a scary-looking finality status is normal. While the node is still downloading blocks, getfinalitystatus can report last_finalized_height: 0 and status: "critical". Finality certificates are received live: the node catches up on blocks first, then finalizes the current tip as soon as the first live certificate arrives. Nothing is wrong with the network — the node simply hasn't heard a certificate yet.

Consider the node healthy only once all of the following hold: the tip matches the network height, a new block has been received, a finality certificate has been observed, and finality_lag is back to 0.

See the network live

After your node has synchronized, you can compare its public chain height and finality status with the testnet explorer. The explorer is an observational service, not a bootstrap peer or an RPC endpoint.

See also: Run a wallet · Production and finality · Status & claims

Run a wallet

End users settle in the assets they already hold; market builders and providers settle in M1. The wallet described here is for the second group: it is built into the node, exposes M0/M1 and the settlement operations directly, and is what a provider or developer uses to hold inventory, fund covenants and inspect the settlement state. It is not a retail wallet or an invitation to acquire an internal asset — see the accounting invariants.

Everything is reachable over RPC with bathron-cli or any JSON-RPC client. Amounts are satoshis — the unit of account everywhere.

Addresses

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

Transparent addresses are visible on chain; shielded addresses hide amounts and balances and are how providers keep inventory and OTC sizes confidential (see Confidential settlement).

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    # full balance breakdown, including settlement receipts

Settlement operations

The vault/receipt mechanics behind the settlement state 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 provider flows wrap them — but they are ordinary RPCs, not privileged operations.

Getting funds

Every test unit originates from provably destroyed testnet Bitcoin — there is no mint key, premine or issuer. A future faucet may distribute inventory created from prior testnet burns; it cannot create units or bypass the invariants. Developers can also test the burn path directly (see From destroyed BTC to M1).

See also: RPC API · Create your first market

Create your first market

A market on BATHRON is a pair X/M1 that exists the moment someone brings inventory in X and in M1 and starts quoting. There is no listing form, no committee and no fee to pay anyone: the protocol never validates a pair, and Operators cannot approve or refuse one. This page walks through what you need and the four steps from inventory to a live market.

What you need

Provider revenue is explicit fees and spread. Provider risk includes irreversible inventory acquisition, liquidity, pricing, operations and software failure — see Roles.

The prototypes

Two historical prototypes, decommissioned — their state belonged to a superseded network and neither service is running. They are read as illustrations of the two commercial roles, not as software to point at:

• pna-lp — a Liquidity Provider service. It holds inventory, prices a pair and exposes quotes over plain HTTP: GET /api/status for health, and GET /api/quote?from=…&to=…&amount=… for a price on a given amount and direction.
• pna-swap — the swap UI. It reads quotes from one or more LP endpoints and drives a settlement from the client's side.

One participant can run both, but a Clearing Provider may aggregate several LPs; the protocol does not care how they are arranged.

The four steps

1. Bring inventory. Fund your BATHRON wallet with M1 (Run a wallet) and your Bitcoin (or other) wallet with the paired asset.
2. Publish quotes. Run pna-lp (or your own service) and expose /api/quote for your pair. Quotes live off-chain (Quotes live off-chain, settlement on-chain); nothing is written to the chain until someone settles.
3. A counterparty settles. A client accepts a quote; the two legs are locked and settled with the atomic pair or one of the settlement patterns. Consensus enforces the outcome.
4. Others join. Anyone else can quote the same pair, aggregate your quotes, or pair a new asset. Nobody approves the pair; competition sets the spread.

The current software demonstrates quoting and individual settlement components; it must not be represented as a generally atomic or risk-free client service — see Status & claims.

Interested in evaluating the economics? Contact us.

See also: How a market appears · Pairing an external asset against M1 · Patterns for providers

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.

Application map

What can be built, and what each thing actually depends on. The labels are defined in What BATHRON is.

Needs external components and Requires consensus change are not soft warnings — they mean the thing does not work today without that dependency.

A. Native contracts on Bitcoin facts

No oracle. The facts come from Bitcoin headers carried in consensus.

B. Programmable settlement

C. Markets

No guarantee of liquidity, of price, or of general atomicity is offered. No market is proven today; the network is an experimental testnet.

D. Applications needing external components

These are not native. BATHRON has no price oracle, no margin engine and no liquidation in consensus.

A note worth stating plainly: an instrument indexed on Bitcoin difficulty is more native and more verifiable than a synthetic USD. The first settles on a predicate every node checks in consensus; the second on a signature the protocol can verify but never judge.

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 (provider inventory controls, 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 settlement patterns — 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 Clearing Provider?

CP prototypes expose a small HTTP API: fetch quotes, accept a workflow and follow settlement. Pair-specific prices and inventory may come from one or more LPs. The interfaces remain experimental and publish with the public testnet. → Roles: Operators, Settlement Providers, users · Create your first market

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>.

See also: Run a wallet · Transaction types

Examples

Tested components of a conditional settlement

The testnet has exercised the main components needed by the product hypothesis:

Bitcoin fact verification. A payment on the Bitcoin test network and its Merkle branch were checked against the Bitcoin header chain carried in BATHRON consensus (the chain read by consensus today is Bitcoin testnet4). TX_CONFIRMED then released a CTV-constrained internal covenant.

Confidential internal hop. Provider-controlled test inventory moved through Sapling while the M0/M1 conservation invariants remained valid. This demonstrates confidential settlement state; it is not a retail wallet flow.

Paired HTLCs. An M1 HTLC on BATHRON and a P2WSH HTLC on the Bitcoin test network used the same hashlock. The test claimed both legs and verified the same preimage on each chain. This is the mechanism behind the native BTC ⇄ M1 pair.

Bitcoin proof -> internal covenant -> confidential provider state
                                          |
recipient BTC <- paired HTLC test <- CP/LP prototype

These observations do not yet prove a generally atomic client service; see Status & claims.

Where the code lives

The node, tools and application code are published across the BATHRON GitHub organization. Runnable SDK patterns ship with the public testnet. The CP/LP prototypes (pna-lp, pna-swap) are described in Create your first market.

See also: Settlement patterns · Build your first application

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 Settlement patterns 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 deployed surface is intentionally narrow, and widening it requires an explicit protocol and governance decision.

SPV verification

How BATHRON sees Bitcoin without an oracle — the machinery behind Bitcoin facts inside consensus.

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.

Burn format (BCS v1.0)

A Bitcoin burn that BATHRON can mint from is a standard Bitcoin transaction with two required outputs:

OP_RETURN   BATHRON|01|<NET>|<DEST_HASH160>   (29 bytes: "BATHRON" magic + version + network + P2PKH dest hash160)
value out   P2WSH(OP_FALSE)                    (provably unspendable — the BTC is destroyed)

P2WSH(OP_FALSE) commits to SHA256(0x00) = 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d; the script can never be satisfied, so the coins are gone. The OP_RETURN names the BATHRON destination that receives the minted M0. A burn is unique by (btc_txid, vout); duplicates are rejected.

Maturity and genesis constants

Genesis is the same path, not a special case: block 0 is an empty coinbase, block 1 is the first TX_MINT_M0BTC (SPV-verified exactly like every later mint), and operator registrations follow. No burn is ever hardcoded — every minted satoshi traces to a verified Bitcoin destruction.

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.

Accounting invariants

Two consensus rules constrain the internal units. They establish provenance and conservation; they do not establish an external market price or a redemption promise.

Internal units

BTC --irreversible, SPV-proven destruction--> M0
M0 ----------------lock 1:1-----------------> M1
M1 ----------------unlock 1:1---------------> M0

M0 is the base accounting unit. M1 is created when M0 is vaulted and is used as programmable settlement state by CPs and LPs in the target architecture.

A5 — provenance

M0_total == BTC provably destroyed

Every M0 unit originates from a verified destruction. There is no premine, block reward, issuer or genesis exception. Because the BTC is destroyed rather than reserved, M0 is not redeemable for it.

A6 — internal accounting equality

M0_vaulted == M1_supply

Lock and unlock are protocol operations at 1:1. This prevents creation of unvaulted M1. It does not prevent a market discount: external liquidity for M1 can be absent and its realizable value can be zero.

Security consequence

A finality quorum orders transactions but cannot create M0 without a valid burn claim or create M1 without vaulted M0. This limits consensus authority over supply; it does not remove application, liquidity, software or legal risk.

Patterns for providers

Clearing and Liquidity Providers may need standing rules for their M1 inventory: withdrawal delays, rate limits, approved destinations and recovery paths. Covenants can express those controls without turning M0/M1 into a retail savings product.

Inventory controls

A typical withdrawal path: hot key spends inventory to a CTV-constrained staging output → the staging output can only be spent to the approved destination after a CSV delay, or back to the recovery path at any time during that window → change outputs re-create the same covenant.

Scope

This is an operational-security pattern for professional infrastructure. It does not protect the external BTC destroyed to acquire inventory and does not make M1 redeemable.

Primitives: CTV · CSV · output introspection

See also: Script & opcodes · Roles

Glossary

Two lines per term, in the order a new reader meets them.

Settlement — the moment both legs of a trade move, or neither does. The only thing BATHRON's consensus performs. → Settlement guarantees

Market / pair — X/M1: exists when someone brings inventory and publishes quotes; nobody approves it and nobody can revoke it. → How a market appears

M1 — the settlement unit (numéraire) of the network; M0 vaulted 1:1. Held by market builders and providers as working capital; not a coin sold to end users. → The settlement unit

M0 — the base accounting unit, created only when bitcoin has been provably destroyed and the proof verified in consensus (invariant A5). → From destroyed BTC to M1

Burn / destruction — sending bitcoin to a provably unspendable output on Bitcoin. One-way; the BTC is not held for redemption. → Bitcoin is the final asset

Numéraire — a common unit every pair settles through, so N assets need N pairs instead of N².

Operator (Settlement Operator) — a consensus identity collateralised with M0: produces blocks, signs finality, publishes facts about itself. One operator, one vote. Called masternode in the RPC and source. → Roles

Settlement Provider (SP) — umbrella term for the commercial participants: Clearing Providers and Liquidity Providers. Participants, never administrators.

Clearing Provider (CP) — quotes a client, orchestrates the legs, enforces deadlines, offers an SLA; paid by explicit fees.

Liquidity Provider (LP) — holds inventory in a pair and prices it; paid by the spread; bears capital and market risk.

Quote — a signed off-chain message: pair, bid, ask, size, expiry. Never seen by consensus. → Quotes live off-chain

Covenant — a script constraining how value may move (a forced destination, a timeout, a condition). Not a smart contract in the EVM sense. → The infrastructure

HTLC — hashed timelocked contract: pays on a revealed secret, refunds after a deadline. Two of them, one per chain, keyed to the same secret, form an atomic pair. → Native BTC ⇄ M1

Bitcoin facts / SPV — Bitcoin block headers carried and verified inside BATHRON's consensus; a Merkle proof then proves a Bitcoin transaction is confirmed, for every node, without an oracle. → Bitcoin facts inside consensus

TX_CONFIRMED — the script check "this Bitcoin payment is confirmed under enough work"; the engine under DvP and escrow.

CTV, CSFS, CSV/CLTV, OP_CAT, introspection — the covenant opcodes: forced template, oracle signature, timelocks, concatenation, reading the spending transaction. → Script & opcodes

Finality — a block is irreversible after one round of operator signatures (~1 minute), by an ECVRF-drawn committee with threshold ⌈2/3·min(E,N)⌉; finality overrides the longest chain. → Production and finality

Invariants A5 / A6 — A5: M0 total equals BTC provably destroyed. A6: vaulted M0 equals M1 supply. Enforced by every node; a finality quorum cannot break them. → Accounting invariants

Consensus freeze — the rule that any addition to consensus must prove it enables something impossible to build cleanly above; all future value is built above. → Why the consensus is frozen

Open admission — the state in which anyone may register as an operator. Not yet reached: the current operator set is project-run. → Status & claims

Documentation policy

One canonical source, one status page, and a rule for what wins when texts disagree.

Where things live

What repository READMEs may contain

A README in any bathron-network repository contains only what is specific to that repository: what the software is, how to build, install, configure and run it, its commands, and warnings proper to that software (experimental status, network it targets, known limitations of that component).

READMEs do not restate the protocol's positioning, the security model, the economics of M1, the atomicity status, the roadmap or the network status. Where a reader needs those, the README links to the canonical page. Two independent texts explaining the same protocol property is a defect, not redundancy.

Precedence

• On what the software does: the code and its tests prevail over any prose.
• On what the protocol claims — capabilities, guarantees, status: the Status & claims page prevails over every other page, README, release note or announcement. If another public text claims more, that text is wrong and is corrected; the status page is not softened to match it.
• Reference pages under Reference describe the current implementation; where they lag the code, the code prevails and the page is fixed.

Historical documents

Documents written for an earlier framing or an earlier network are archived, not deleted: they carry an explicit "archived" banner with the date, state what has since changed, and are removed from the main navigation. They are not a current reference. Examples on this site: the essay and its French version; in bathron-core, the signet-era provider prototypes and burn tool under contrib/.

Public claims must be traceable

Every public statement about BATHRON must be attributable either to the code of a bathron-network repository or to a page in docs/src/. Public documentation never depends on private notes, internal rules, local files or unpublished documents; if a claim rests only on such a source, it is not made.

Reporting a discrepancy

Open an issue on the site repository for documentation, or on the repository concerned for implementation. Security-relevant discrepancies go to security@bathron.org first (see Security model).

FAQ

Do I need permission to create a market?

No. A market on BATHRON exists when someone brings inventory, publishes quotes and finds a counterparty. There is no listing process, no committee, no fee to the protocol. Nobody can approve a pair, so nobody can delist it. → How a market appears

Who decides which assets can trade?

Nobody. The consensus does not know which pairs exist — it only settles. A chain that supports hashlocks and timelocks can be paired against M1 with the same pattern used for native BTC — but each chain needs its own application work: script shapes, timelock ordering, reorganisation handling and a provider willing to hold both sides. Only the Bitcoin pair has been demonstrated. That is a capability of the primitives; no pair other than BTC/M1 has been tested or shipped. → Pairing an external asset

Is M1 a coin I should buy?

No. M1 is the settlement unit — the working capital of whoever runs a market. End users settle in the assets they already hold; market builders and providers settle in M1. Because anyone can create M1 by destroying bitcoin, destruction is a permanent reference supply route that tends to limit any premium when it is accessible — there is nothing to speculate up — and nothing guarantees a floor or any external price. There is no token sale, premine, treasury, block reward or promised yield. → The settlement unit

Is M1 pegged to Bitcoin? Is it "backed by Bitcoin"?

No, and no. Consensus enforces the internal 1:1 between M0 and M1. It does not enforce, and the protocol never promises, an external price. The destroyed bitcoin is gone — there is no reserve and no redemption desk. What makes native BTC available again is the market: providers holding inventory on both sides, paired with linked hashlocked legs. → Bitcoin is the final asset

Why destroy bitcoin at all?

Because it is the only way to create the unit without a keeper. A reserve needs a custodian or a federation; a destroyed satoshi needs nobody. The BTC is gone, verifiably, and one M0 unit exists in its place. Irreversible by design — a cost recovered through service revenue, never through appreciation. → From destroyed BTC to M1

Why not just use an exchange, or a bridge?

An exchange's listing committee is the permission problem itself; a bridge always has a keeper. BATHRON is custody-free, verifies Bitcoin itself, and is open — and gives up a recoverable vault in exchange. → Why not an exchange, a bridge, or a stablecoin

Does BATHRON hold my BTC?

Never. BATHRON verifies Bitcoin facts and irreversible burns; it cannot move native BTC or trigger a Bitcoin transaction. Native BTC moves only through Bitcoin-side contracts (hashlocked legs) between you and a counterparty.

Who provides the service?

Settlement Providers — participants, not administrators. A Clearing Provider quotes and orchestrates; a Liquidity Provider holds inventory and prices a pair. Operators run consensus and finality; they publish facts about themselves and never rank anyone, choose a provider or set a price. → Roles

Is the network permissionless today?

Anyone can build, quote, pair and settle on BATHRON without asking permission. Operator admission is not yet open: the current operator set is project-run while the open-admission threat model is worked. → Open-network hardening

Is settlement atomic and risk-free today?

Not as a general guarantee. Paired-HTLC and covenant components have run on the testnet; the complete cross-chain state machine, reorganisation handling and timelock ordering still need formal specification and external review. → Status & claims

Why is the consensus so small?

On purpose. Anything that can be built above consensus must be built above it — quotes, matching, reputation, provider choice, fast liveness signals. Every consensus line is decades of maintenance and attack surface, and a protocol that lists cannot be neutral about listing. The surface is frozen. → Why the consensus is frozen

Why confidentiality?

Commercial settlement exposes counterparties, sizes and treasury flows. Shielded transfers hide amounts and linkage on the internal leg while consensus still checks conservation. It is a property of settlement, not a "private cash" product, and not Monero's anonymity set. → Confidential settlement

Is this CLS for crypto?

No. Payment-versus-payment — one leg if and only if the other — is a useful functional analogy. BATHRON has no central-bank accounts, no regulated membership, no equivalent legal finality and no systemic track record.

What exists today?

A public testnet with covenant execution, Bitcoin headers and proofs checked in consensus (source: Bitcoin testnet4), confidential internal transfers, paired-HTLC demonstrations, fast finality, and provider prototypes exposing quotes over HTTP. No mainnet, no external audit, no proven market. → Status & claims

Understanding BATHRON — a calm essay

Archived (July 2026). This essay was written for an earlier framing of the site, in which M1 was described as a back-office unit and the client-facing product as conditional BTC settlement served by providers. The mechanisms it describes are unchanged and still accurate; the positioning has since moved to what Start here describes: an open settlement protocol where anyone can create a market without permission. Read it as a long, careful walk through the same machine from an older angle. Where it says a client "never sees M1", read: end users settle in the assets they already hold; market builders and providers settle in M1.

Version française : Comprendre BATHRON — essai.

This text is meant to be read slowly — aloud, if you like. It explains the economic and technical mechanism of BATHRON as it is understood today, while keeping three things separate from beginning to end: what already exists in code, what is a design goal, and what remains an open market question. It makes no promises, and it never uses the word "trustless" without spelling out what still has to be trusted.

1. What Bitcoin does very well — and where it stops

Let us start by giving Bitcoin its due.

Bitcoin is remarkable at one precise thing: holding and transferring bitcoin. A person owns bitcoin because they control a key. They sign a transaction, the network records it, and once it is sufficiently confirmed it becomes extraordinarily hard to change. No bank keeping a private ledger, no central operator deciding balances: public rules, verifiable by anyone, upheld for more than fifteen years.

But that strength does not cover every settlement need.

An ordinary payment is simple: Alice sends bitcoin to Bob. A conditional settlement is something else: Bob should only receive the money if a precise condition is met — and if it is not met by a given date, Alice must be refunded, automatically, without depending on anyone's goodwill.

Bitcoin can express some simple conditions: a signature, the revelation of a secret, a delay. But as soon as you want a complete commercial logic — composed conditions, verification of an event, coordination of several transactions, the case where one party disappears — Bitcoin's small language runs out. It was deliberately restricted, long ago, out of caution, and that restriction is defended by serious people with good arguments: every capability added to a system protecting hundreds of billions is added risk.

Proposals to enrich this language have circulated for years. One of them even has, at the time of writing, a proposed activation schedule — proposed, not adopted; nobody knows whether it will succeed.

So BATHRON does not start from the idea that Bitcoin is deficient. It starts from the opposite: Bitcoin is an excellent ownership-and-transfer layer, and certain conditional operations are hard to organize directly on it — especially if you refuse to let an intermediary hold clients' money.

2. Bridges: trusted by whom, for what, and for how long

Faced with this limit, the classic answer is to leave Bitcoin: lock bitcoin on one side, create a representation of it on another system, do there what Bitcoin does not allow, then — in theory — come back. That is called a bridge, and every bridge raises a single question: while you are on the other side, who holds your bitcoin?

A custodian is a keeper: a company that holds the funds on behalf of users. The system works as long as that keeper stays solvent, honest, available, and permitted to honor withdrawals.

A federation is a group of keepers: several institutions must sign together to move the funds. That is better — one compromised key is no longer enough. But the underlying problem remains: the bitcoin still exists, in a reserve controlled by identifiable actors. A majority of signers can move it; an authority can compel the members; keys can be lost.

The most recent constructions, the so-called optimistic bridges, do better still: it is enough for one honest watcher to exist to prevent fraud. That is real progress — and it still rests on an honest setup ceremony, operators designated in advance, and watchers who remain alive and funded for the life of the bridge.

None of these systems is absurd. Some are well run and useful. But one should never call them "trustless." One should say precisely whom the user trusts, for what, and for how long. And in every case, the answer contains a keeper — because the original bitcoin still exists, and somebody holds it.

3. Why settlement needs internal state

BATHRON's founding idea is conditional settlement without a common custodian. Its chain can verify Bitcoin facts but cannot command Bitcoin to spend. Contracts therefore need internal state they can lock and release. The chosen acquisition mechanism for that state is severe: a professional does not hand bitcoin to a reserve — they destroy it.

Destroying has a precise technical meaning. It is possible to send bitcoin to a spending condition designed to make it definitively unrecoverable. Not a lost key: a demonstrable absence of any key. This act is called a burn, and it is recorded forever in Bitcoin's public ledger.

On the other side, on the BATHRON chain, every satoshi proven burned brings into existence exactly one M0 accounting unit. One for one. And this creation is not decided by any counter clerk: the BATHRON chain verifies for itself, inside its own consensus rules, that the burn happened on Bitcoin. This exists in code today and runs on the test network: there was no initial allocation to founders, there is no block reward, and the only path of M0 creation is the proven destruction of bitcoin.

What the burn removes is exactly the weakness of bridges: the recoverable reserve. No vault to raid, no federation to compel, no custodian to subpoena, no exit to authorize. There is nothing to seize, because there is nothing left.

What the burn freezes is the other side of the coin: the path is one-way. No mechanism, anywhere in the protocol, turns the internal units back into bitcoin. Whoever burns acquires professional inventory with no protocol exit. Its realizable external value depends on future liquidity and can be zero. If the network fails, that capital is lost.

And let us say what remains to be trusted, since this text committed to doing so: reading the burns rests on the assumption that the majority of Bitcoin's hashpower is honest; the BATHRON chain has its own operators, a qualified majority of whom must be honest; and, as always, you must trust the software you run. Real assumptions — different, and arguably healthier, than "a company holds my money."

One last point, which governs everything that follows: it is not the ordinary user who burns. Asking the general public to perform an irreversible act in order to use a service would be bad experience and bad risk allocation. The one who burns is a professional, knowingly, the way one ties up capital to open a business. We will meet them in chapter six.

4. M0 and M1: the vault and the ticket

Two technical names run through the documentation: M0 and M1. One image is enough.

Think of a cloakroom. You hand in a coat; you receive a numbered ticket. The coat sleeps in the wardrobe, the ticket circulates, and a strict rule binds them: as many tickets as coats.

M0 is the coat: the base accounting state, created from verified burns. When you want to use it for settlement, you place it in a vault — kept not by a company, but by the chain's common rule, the one every node enforces together.

M1 is the ticket: the receipt attesting that an amount sleeps in the vault, and it is the ticket that circulates and enters contracts. The cloakroom rule is checked at every block: the total of tickets equals exactly the total in the vault, one for one, freely convertible in both directions. This equality is an invariant — a property the code verifies permanently. This exists in code today.

Why two floors? To separate reserve from circulation: a rigid, boring base, and an active, contractual layer. And let us be clear about what M1 is not: neither an investment token nor a yield-bearing instrument. It is a settlement instrument, whose value ultimately depends on the success of the whole system.

5. The client stays in bitcoin

Here is the ergonomic principle that governs the model — and it is a design goal, a deliberate and coherent architecture, not yet a service in production.

In this model, the ordinary client lives entirely in bitcoin. They never hold M1, never see a burn, never learn the vocabulary of this text. Their experience fits in one sentence, displayed before anything starts: "you send this much BTC; the recipient will receive this much, if this condition is met, within this delay; otherwise you are refunded in full before this date; here are the fees." They pay in bitcoin; someone, at the other end, receives bitcoin.

All the machinery works backstage, the way interbank systems work behind a payment card without anyone knowing their names. One can picture the whole, by analogy, as a clearing house: a discreet institution that records commitments, nets crossed debts, and enforces the rules of settlement — except that here the rules are not enforced by an institution that could fail, but by a chain's consensus.

But if the client burns nothing and holds nothing — who runs the backstage?

6. Clearing and liquidity providers: who carries the risk

The client-facing character is the Clearing Provider (CP). They must immediately be distinguished from a custodial intermediary: a custodial payment processor receives the client's money and updates its database; the CP, in the intended model, routes a contract-bounded flow, without ever receiving the client's money as a free deposit. They supply liquidity; they must have no arbitrary power over the outcome.

The CP may finance its own inventory or aggregate one or more Liquidity Providers (LPs). LPs keep bitcoin on one side and M1 on the other. To build M1 inventory, an LP may burn bitcoin. That irreversible acquisition cost belongs to the professional, not the client.

Their revenue, in the model: a gap between entry and exit prices — a spread — and fees on the conditional services that a simple payment cannot render. The spread also serves as a rudder: when their M1 stock runs low, they quote better prices for flows that replenish it and worse for flows that consume it; when it is their bitcoin stock, the reverse. Their inventory breathes through their prices — the ordinary craft of market makers.

Their risks, stated plainly: the burned capital, to be amortized over years; price risk on the stock; imbalance risk, if flows run durably one way; delay risk, when capital sits locked in pending operations; and the opportunity cost of all that money. If they ever want to reduce their position, they can only sell it to other professionals — if any exist.

Their equation is brutally simple: revenues must exceed costs, durably. And it must be said without evasion: nobody knows today whether that equation can be positive. It is the project's central market hypothesis — to be measured with real professionals and their real numbers, not assumed.

7. Alice and Bob, step by step

Here is the story that justifies everything. Alice buys a valuable item from Bob. They do not know each other. Alice refuses to pay before receiving; Bob refuses to ship before being paid. The oldest deadlock in commerce.

Let us walk through the BATHRON version — keeping in mind that this complete journey is a design goal: the bricks exist, the assembly is not yet a product.

The quote. Alice goes to a CP's service. She is shown, in plain terms: amount to send, amount Bob will receive, release condition, deadline, fees — and the guarantee being sought: automatic refund if nothing has happened by expiry.

The lock. Alice sends her bitcoin — not into someone's pocket, but into a contract. From that second, this money has only two possible futures, written into the contract itself: end up with Bob if the condition is met, or return to Alice after the deadline. No third path; no "at the provider's discretion" clause.

The backstage. The provider sets up, on BATHRON, the mirror of the operation with its own M1: the escrow, the condition, the delays. Alice sees none of it.

The outcome. Bob delivers, the condition occurs, the contract observes it — we will see how — and releases the funds to Bob, in bitcoin, along the pre-committed path. Or Bob does not deliver, disputes, disappears: then nobody decides anything; time passes, the deadline falls, and Alice's refund executes.

At no point did an intermediary hold Alice's money with the power to do anything other than the two planned outcomes. That is the service being sought.

8. The four gears: the padlock, the seal, the eye, and the clock

Four mechanisms carry this story.

The secret padlock — the HTLC. A sum is locked so that it opens either with a secret — a cryptographic password — or, failing that, through a refund after a delay. The beauty of the device: you can put the same secret on two locks, in two different worlds. Whoever reveals the secret to collect on one side makes it, by that very act, usable on the other. The two legs of the payment — Alice's going in, Bob's going out — become interlocked. An old, battle-tested technique in the Bitcoin ecosystem.

The seal on the futures — the covenant, including CTV. At the moment money enters the contract, the exhaustive list of its authorized exits is sealed cryptographically. "To Bob if the condition holds, back to Alice otherwise" — nothing else, ever. This is one of the capabilities Bitcoin has not activated to date; on BATHRON it exists and runs, along with a whole family of sibling mechanisms. Verifiable fact on the test network. The remaining assumption: that the covenant was built correctly and that the user — in practice, their software — verifies what they sign. A very restrictive contract can still be a bad one if its restrictions were badly chosen.

The eye on Bitcoin — SPV. The BATHRON chain follows Bitcoin's block headers and verifies, inside its consensus rules, that a precise transaction is included and confirmed — every node redoes the verification; nobody takes it on faith. A contract can thus stipulate: "release when such-and-such Bitcoin transaction has so many confirmations." No oracle, no attesting third party. This capability exists in code today — and, to our knowledge, this precise combination exists nowhere else; we prefer third parties to verify that claim rather than proclaim it. The remaining assumption: that the Bitcoin chain being followed is the majority chain, and that the chosen confirmation depth covers reorganization risk. The more confirmations you wait for, the safer — and the slower.

The clock — timelocks. Every refund path opens at a date fixed in advance, and the ordering of deadlines is no detail: Bob's window closes before Alice's opens, with margins for the chains' slowness — otherwise an ambiguous moment would exist where both paths overlap. Add the operational assumption everyone forgets: a refund right is only useful if Alice's software watches the chain and publishes the transaction at the right time.

A padlock that interlocks the legs, a seal that freezes the exits, an eye that observes the facts, a clock that guarantees the endgame. And the sentence of caution that must follow immediately: the global guarantee — "Alice is settled per the quote or refunded, in all cases, including failures at the worst moment" — is a security objective. The flows have not been formally specified; no external review has taken place. Saying today "the provider cannot steal the principal" would be a promise, not a fact — and we forbid ourselves from saying it until that work is done.

9. The economics of the first entrant

One question decides a great deal: the first Clearing Provider — who will it be?

Put yourself in the shoes of a neutral, rational market maker. They will ask three questions. How much does it earn? — spreads and fees on a volume that does not yet exist. How much does it cost? — burned capital, unrecoverable through the protocol, to be amortized over years. And above all: how do I exit? — by selling their M1 to other professionals… who do not exist yet; or by consuming it slowly through the business; or by losing it if the network dies. For the very first entrant, the exit market is empty by definition.

A neutral market maker, facing that picture, says no — and by their criteria they are right. The honest conclusion is therefore: the first provider will probably be a strategic sponsor, not an arbitrageur. Someone whose interest exceeds the quarter's return: a payment company seeking to differentiate through conditional settlement, a trading desk wanting its own escrow rail, an actor buying the thesis and the infrastructure at once. They might accept weak or zero profitability at first, to bootstrap.

And the consequence for what proves what must be drawn: the arrival of the first will prove that a sponsor believes. It is the second — independent, arriving uninvited — who will prove that a market exists. The nuance matters: it prevents applauding at the wrong moment.

10. The honest inventory of what is not proven

Let us list the gaps, as a chapter in its own right.

No external audit. The code has been reviewed and attacked repeatedly — by its own team. In financial software, self-examination does not count as proof. Outside eyes, paid to break things, are a prerequisite to any real value. That has not happened.

A known, accepted vulnerability. The test network opens to outside operators with a near-free entry ticket; it follows that a malicious actor could, at little cost, create a few fake identities and freeze finalization of blocks. Let us be precise about what this does not allow: neither theft nor money creation — the accounting invariants hold no matter what; that is in the code. Visible sabotage, reversible by restarting the test network; accepted for the experimentation phase, to be hardened before any definitive network.

No real Clearing Provider. Nobody has opened a real conditional-settlement service. No real client transaction has ever been routed. The economy described above is an architecture awaiting its first inhabitant.

Unproven economics. The provider must earn enough; the client must accept the price; both at once. Too small a spread does not pay for the capital; too large a spread drives the client away. It will have to be measured, not reasoned.

Client protection still to specify and review — technically, and beyond. For cryptographic protection does not replace commercial protection: what happens if the delivered item is not as described? who defines that the condition is met? who answers for an interface bug? is there any recourse? The protocol can guarantee that a secret was revealed; it cannot guarantee that commercial reality matches the secret. Those questions belong to the service built on top — and they remain open.

11. Against the alternatives: who wins what

A word of competitive fairness, for nothing discredits faster than claiming to beat everything.

Lightning is better for simple, fast payments, no contest. It aims at transferring bitcoin through pre-funded channels, with its own assumptions — channel liquidity, route availability, chain monitoring. BATHRON does not compete on that ground; its subject begins where rich conditions are needed.

Liquid brings fast, confidential transfers between institutions, with real liquidity — at the price of its model: an identified federation holds custody, and the exit passes through its members. A different trade-off, not an absurdity; one must simply know one has signed it. BATHRON gives up the recoverable vault; in exchange, its exit liquidity must come from providers and their inventory.

A custodial payment processor wins on simplicity: deposit, database, customer service — against custody of your funds and the power to decide. BATHRON seeks to reduce that power through pre-committed transactions; in exchange, the system is genuinely more complex.

Multisig with an arbiter and a legal contract, finally, is the most honest alternative for escrow — and its own strength must be acknowledged: a human arbiter can look at photos, read messages, judge whether a product was as described. No cryptographic contract can do that. The fair boundary is therefore this: BATHRON targets objectively verifiable conditions — an elapsed delay, a signature, a confirmed transaction; human arbitration remains better when the condition requires interpretation. This is not a decorative concession: it is the product's boundary.

The real question is never "who is superior" — it is: what kind of trust, and what kind of cost, does this particular client prefer?

12. The real market question — and the honest summary

Everything this text has described hangs on a question of disarming banality:

How much would a real client pay to avoid custody and arbitration?

Put yourself in Alice's place. For her escrow she has choices: the arbiter and their fees, the processor and its terms, or this new rail. What price difference would make her choose the rail? For a small ordinary payment, probably none. For a large transaction, an international one, one exposed to freezing or to a custodian's bankruptcy — perhaps a lot. Nobody knows that number. It cannot be computed in code; it is measured with real clients, real offers, real refusals. And it governs everything: if it is comfortable, the provider's equation can close and the system can live; if it is near zero, no technical elegance will change anything.

Let us summarize, one last time, in the three registers.

What exists. A chain runs, on a public test network. It creates M0 exclusively through proven destruction of bitcoin — no premine, no block reward, one unit per destroyed satoshi. It verifies Bitcoin's state for itself, inside its rules. It maintains a vault and receipts at strict parity, checked at every block. And it runs a family of sealed-path contracts that Bitcoin, to date, declines to activate. All of it verifiable by anyone who cares to look.

What is aimed for. A conditional-settlement engine behind an ordinary bitcoin experience: clients who pay and receive BTC without seeing any machinery; professional providers who carry inventory, prices, and risk; and one central guarantee — settled per the quote, or refunded by the clock — governing every contract. This design is coherent, written down, and unbuilt: neither formally specified, nor audited, nor inhabited by a single real provider.

What is hoped, and not yet known. That clients exist whose pain is worth a price; that this price pays for a professional's burned capital; that a first sponsor walks through the door, and then that a second arrives uninvited.

BATHRON's proposition can thus be stated without exaggeration. It is not about removing trust: it is about moving part of it — replacing a keeper's discretion with an irreversible burn, Bitcoin proofs, pre-committed transactions, secrets, and delays. The price of that move is real technical complexity and a vital need for liquidity providers. What remains to be trusted is named; what remains to be proven is listed; and what would prove the project wrong is written down in advance.

The code exists. The design is clear. The market is a question that has been asked — and the only answer that counts will come from external audits, real trials, and real clients.

Comprendre BATHRON — un essai calme

Archivé (juillet 2026). Cet essai a été écrit pour un cadrage antérieur du site, où M1 était décrit comme une unité de back-office et le produit comme un règlement BTC conditionnel servi par des prestataires. Les mécanismes décrits sont inchangés et restent exacts ; le positionnement a évolué vers ce que décrit Start here : un protocole de règlement ouvert où n'importe qui peut créer un marché sans permission. À lire comme une longue promenade dans la même machine, sous un angle plus ancien. Là où il dit que le client « ne voit jamais M1 », lire : les utilisateurs finaux règlent dans les actifs qu'ils détiennent déjà ; les bâtisseurs de marchés et les prestataires règlent en M1.

Version française de l'essai — English version: Understanding BATHRON — a calm essay.

Ce texte est prévu pour être lu lentement, à voix haute si l'on veut. Il explique le mécanisme économique et technique de BATHRON tel qu'il est envisagé aujourd'hui — en distinguant, du début à la fin, trois choses qu'il ne faut jamais confondre : ce qui existe déjà dans le code, ce qui est un objectif de design, et ce qui reste une hypothèse de marché. Il ne contient aucune promesse, et il n'emploie jamais le mot « trustless » sans expliquer ce qui reste à croire.

1. Ce que Bitcoin fait très bien, et où il s'arrête

Commençons par rendre à Bitcoin ce qui lui appartient.

Bitcoin est remarquable pour une chose précise : détenir et transférer du bitcoin. Une personne possède des bitcoins parce qu'elle contrôle une clé. Elle signe une transaction, le réseau l'enregistre, et une fois la transaction suffisamment confirmée, il devient extraordinairement difficile de la modifier. Pas de banque qui tient un registre privé, pas d'opérateur central qui décide des soldes : des règles publiques, vérifiables par n'importe qui, respectées depuis plus de quinze ans.

Mais cette force ne couvre pas tous les besoins de règlement.

Un paiement ordinaire est simple : Alice envoie du bitcoin à Bob. Un règlement conditionnel est autre chose : Bob ne doit recevoir l'argent que si une condition précise est remplie, et si elle ne l'est pas avant une date donnée, Alice doit être remboursée — automatiquement, sans dépendre de la bonne volonté de qui que ce soit.

Bitcoin sait exprimer certaines conditions simples : une signature, la révélation d'un secret, un délai. Mais dès qu'on veut une logique commerciale complète — des conditions composées, la vérification d'un événement, la coordination de plusieurs transactions, le cas où une partie disparaît — le petit langage de Bitcoin ne suffit plus. Il a été volontairement bridé, il y a longtemps, par prudence, et ce bridage est défendu par des gens sérieux avec de bons arguments : chaque capacité ajoutée à un système qui protège des centaines de milliards est un risque ajouté.

Des propositions pour enrichir ce langage circulent depuis des années. L'une d'elles dispose même, au moment où ce texte est écrit, d'un calendrier d'activation proposé — proposé, pas adopté ; personne ne sait si cela aboutira.

BATHRON ne part donc pas de l'idée que Bitcoin serait mauvais. Il part de l'idée inverse : Bitcoin est une excellente couche de propriété et de transfert, et certaines opérations conditionnelles sont difficiles à organiser directement dessus — surtout si l'on refuse qu'un intermédiaire conserve durablement l'argent des clients.

2. Les ponts : à qui fait-on confiance, pour quoi, et combien de temps

Face à cette limite, la réponse classique consiste à sortir de Bitcoin : on immobilise du bitcoin d'un côté, on crée une représentation de ce bitcoin sur un autre système, on y fait ce que Bitcoin ne permet pas, puis — en théorie — on revient. Cela s'appelle un pont, et tout pont pose une question unique : pendant que vous êtes de l'autre côté, qui tient vos bitcoins ?

Un custodian est un gardien : une entreprise qui conserve les fonds pour le compte des utilisateurs. Le système fonctionne tant que ce gardien reste solvable, honnête, disponible, et autorisé à honorer les retraits.

Une fédération est un groupe de gardiens : plusieurs institutions doivent signer ensemble pour déplacer les fonds. C'est mieux — une seule clé compromise ne suffit plus. Mais le problème de fond demeure : les bitcoins existent toujours, dans une réserve contrôlée par des acteurs identifiables. Une majorité de signataires peut les déplacer ; une autorité peut contraindre les membres ; des clés peuvent être perdues.

Les constructions les plus récentes, dites optimistes, font encore mieux : il suffit qu'un seul surveillant honnête existe pour empêcher la fraude. C'est un vrai progrès — et il repose encore sur une cérémonie de départ honnête, des opérateurs désignés d'avance, et des surveillants vivants et financés pendant toute la vie du pont.

Aucun de ces systèmes n'est absurde. Certains sont bien administrés et utiles. Mais il ne faut jamais dire qu'ils sont « sans confiance ». Il faut dire précisément à qui l'utilisateur fait confiance, pour quoi, et pendant combien de temps. Et dans tous les cas, la réponse contient un gardien — parce que le bitcoin d'origine existe encore, et que quelqu'un le tient.

3. Pourquoi le règlement exige un état interne

L'idée fondatrice de BATHRON est le règlement conditionnel sans dépositaire commun. La chaîne peut vérifier des faits Bitcoin, mais elle ne peut pas commander une dépense Bitcoin. Les contrats ont donc besoin d'un état interne qu'ils peuvent verrouiller et libérer. Le mécanisme choisi pour acquérir cet état est sévère : un professionnel ne confie pas ses bitcoins à une réserve — il les détruit.

Détruire a un sens technique précis. Il est possible d'envoyer des bitcoins vers une condition de dépense conçue pour qu'ils soient définitivement irrécupérables. Pas une clé perdue : une absence de clé, démontrable. Ce geste s'appelle un burn, et il est inscrit pour toujours dans le registre public de Bitcoin.

En face, sur la chaîne BATHRON, chaque satoshi prouvé brûlé fait naître exactement un satoshi d'unité comptable M0. Un pour un. Et cette création n'est pas décidée par un guichet : la chaîne BATHRON vérifie elle-même, dans ses propres règles de consensus, que le burn a eu lieu sur Bitcoin. Ceci existe dans le code aujourd'hui et fonctionne sur le réseau de test : il n'y a eu aucune distribution initiale aux fondateurs, il n'existe aucune récompense de bloc, et l'unique voie de création de M0 est la destruction prouvée de bitcoin.

Ce que le burn supprime, c'est exactement la faiblesse des ponts : la réserve récupérable. Plus de coffre à piller, plus de fédération à contraindre, plus de dépositaire à assigner, plus de sortie à autoriser. Il n'y a rien à saisir, parce qu'il n'y a plus rien.

Ce que le burn fige, c'est l'autre face : le chemin est à sens unique. Aucun mécanisme, nulle part dans le protocole, ne retransforme les unités internes en bitcoins. Celui qui brûle acquiert un inventaire professionnel sans sortie protocolaire. Sa valeur externe réalisable dépend de la liquidité future et peut être nulle. Si le réseau échoue, ce capital est perdu.

Et disons ce qui reste à croire, puisque ce texte s'y est engagé : la lecture des burns repose sur l'hypothèse que la majorité de la puissance de calcul de Bitcoin est honnête ; la chaîne BATHRON a ses propres opérateurs, dont une majorité qualifiée doit être honnête ; et il faut, comme toujours, faire confiance au logiciel qu'on utilise. Des hypothèses réelles — différentes, et sans doute plus saines, que « une entreprise tient mon argent ».

Une dernière évidence, qui commande tout le reste : ce n'est pas l'utilisateur ordinaire qui brûle. Demander au grand public une action irréversible pour utiliser un service serait une mauvaise expérience et une mauvaise répartition du risque. Celui qui brûle est un professionnel, en connaissance de cause, comme on immobilise du capital pour ouvrir un commerce. Nous ferons sa connaissance au chapitre six.

4. M0 et M1 : le coffre et le ticket

Deux noms techniques traversent la documentation : M0 et M1. Une image suffit.

Pensez à un vestiaire. Vous déposez un manteau ; on vous remet un ticket. Le manteau dort dans la penderie, le ticket circule, et une règle stricte les relie : autant de tickets que de manteaux.

M0, c'est le manteau : l'état comptable de base, créé à partir de burns vérifiés. Quand on veut s'en servir pour du règlement, on la dépose dans un coffre — tenu non par une entreprise, mais par la règle commune de la chaîne, celle que tous les nœuds font respecter ensemble.

M1, c'est le ticket : le reçu qui atteste qu'un montant dort au coffre, et c'est lui qui circule et s'engage dans les contrats. La règle du vestiaire est vérifiée à chaque bloc : le total des tickets égale exactement le total en coffre, un pour un, convertible librement dans les deux sens. Cette égalité est un invariant — une propriété que le code vérifie en permanence. Ceci existe aujourd'hui dans le code.

Pourquoi deux étages ? Pour séparer la réserve de la circulation : un socle rigide et ennuyeux, une couche active et contractuelle. Et précisons ce que M1 n'est pas : ni un jeton d'investissement, ni un titre qui rapporte. C'est un instrument de règlement, dont la valeur, en dernier ressort, dépend du succès du système entier.

5. Le client reste en bitcoin

Voici le principe d'ergonomie qui gouverne le modèle — et c'est un objectif de design, une architecture voulue et cohérente, pas encore un service en production.

Dans ce modèle, le client ordinaire vit entièrement en bitcoin. Il ne détient jamais de M1, ne voit jamais un burn, n'apprend jamais le vocabulaire de ce texte. Son expérience tient en une phrase, affichée avant de commencer : « vous envoyez tant de BTC ; le bénéficiaire recevra tant, si telle condition est remplie, dans tel délai ; sinon vous serez remboursé intégralement avant telle date ; voici les frais. » Il paie en bitcoin ; quelqu'un, à l'autre bout, reçoit des bitcoins.

Toute la mécanique travaille en coulisse, comme les systèmes interbancaires travaillent derrière une carte de paiement sans que personne connaisse leur nom. On peut se représenter l'ensemble, par analogie, comme une chambre de compensation : une institution discrète qui enregistre les engagements, compense les dettes croisées et fait respecter les règles du règlement — à ceci près qu'ici, les règles ne sont pas appliquées par une institution qui pourrait fauter, mais par le consensus d'une chaîne.

Mais si le client ne brûle rien et ne détient rien — qui fait tourner la coulisse ?

6. Clearing Provider et Liquidity Provider : qui porte le risque

Le personnage tourné vers le client est le Clearing Provider (CP). Il faut d'emblée le distinguer d'un intermédiaire de garde : un prestataire custodial reçoit l'argent du client et met à jour sa base de données ; le CP, dans le modèle visé, route un flux encadré par contrat, sans jamais recevoir l'argent du client comme un dépôt libre. Il apporte la liquidité ; il ne doit pas avoir de pouvoir arbitraire sur le résultat.

Le CP peut financer son propre inventaire ou agréger un ou plusieurs Liquidity Providers (LP). Les LP détiennent du bitcoin d'un côté et du M1 de l'autre. Pour constituer le stock M1, un LP peut brûler des bitcoins. Ce coût d'acquisition irréversible appartient au professionnel, pas au client.

Ses revenus, dans le modèle : un écart entre prix d'entrée et de sortie — un spread —, et des frais sur les services conditionnels que le paiement simple ne sait pas rendre. Le spread lui sert aussi de gouvernail : quand son stock de M1 baisse, il cote mieux les flux qui le regarnissent et renchérit ceux qui le consomment ; quand c'est son stock de bitcoins, il fait l'inverse. Son inventaire respire à travers ses prix — le métier ordinaire des teneurs de marché.

Ses risques, dits sans fard : le capital brûlé, à amortir sur des années ; le risque de prix sur son stock ; le risque de déséquilibre, si les flux vont durablement dans un seul sens ; le risque de délai, quand le capital reste immobilisé dans des opérations en cours ; et le coût d'opportunité de tout cet argent. S'il veut un jour réduire sa position, il ne peut la revendre qu'à d'autres professionnels — s'il en existe.

Son équation est d'une simplicité brutale : il faut que les recettes dépassent les coûts, durablement. Et il faut le dire sans détour : personne ne sait aujourd'hui si cette équation peut être positive. C'est l'hypothèse de marché centrale du projet — à mesurer avec de vrais professionnels et leurs vrais chiffres, pas à supposer.

7. Alice et Bob, pas à pas

Voici l'histoire qui justifie l'ensemble. Alice achète à Bob un objet de valeur. Ils ne se connaissent pas. Alice refuse de payer avant de recevoir ; Bob refuse d'expédier avant d'être payé. Le plus vieux blocage du commerce.

Déroulons la version BATHRON — en gardant à l'esprit que ce parcours complet est un objectif de design : les briques existent, l'assemblage n'est pas encore un produit.

Le devis. Alice s'adresse au service d'un CP. On lui affiche en clair : montant à envoyer, montant que Bob recevra, condition de libération, date limite, frais — et la garantie recherchée : remboursement automatique si rien ne s'est passé à l'échéance.

Le verrouillage. Alice envoie ses bitcoins — non dans la poche de quelqu'un, mais dans un contrat. Dès cette seconde, cet argent n'a plus que deux avenirs possibles, inscrits dans le contrat même : finir chez Bob si la condition est remplie, ou revenir à Alice après l'échéance. Pas de troisième chemin ; pas de clause « à la discrétion du prestataire ».

La coulisse. Le fournisseur met en place, sur BATHRON, le miroir de l'opération avec son propre M1 : le séquestre, la condition, les délais. Alice n'en voit rien.

Le dénouement. Bob livre, la condition se réalise, le contrat le constate — nous allons voir comment — et libère les fonds vers Bob, en bitcoins, par le chemin prévu. Ou bien Bob ne livre pas, conteste, disparaît : alors personne ne décide rien ; le temps passe, l'échéance tombe, et le remboursement d'Alice s'exécute.

À aucun moment un intermédiaire n'a détenu l'argent d'Alice avec le pouvoir d'en faire autre chose que les deux issues prévues. Voilà le service recherché.

8. Les quatre rouages : le cadenas, le sceau, l'œil et l'horloge

Quatre mécanismes portent cette histoire.

Le cadenas à secret — le HTLC. Une somme est verrouillée de sorte qu'elle s'ouvre soit avec un secret — un mot de passe cryptographique — soit, à défaut, par un remboursement après délai. La beauté du procédé : on peut poser le même secret sur deux verrous, dans deux mondes différents. Celui qui révèle le secret pour encaisser d'un côté le rend, par là même, utilisable de l'autre. Les deux jambes du paiement — celle d'Alice qui entre, celle de Bob qui sort — deviennent solidaires. Technique ancienne et éprouvée dans l'écosystème Bitcoin.

Le sceau sur les avenirs — le covenant, dont CTV. Au moment où l'argent entre dans le contrat, la liste exhaustive de ses sorties autorisées est scellée cryptographiquement. « Vers Bob si condition, vers Alice sinon » — rien d'autre, jamais. C'est l'une des capacités que Bitcoin n'a pas activées à ce jour ; sur BATHRON, elle existe et tourne, avec une famille entière de mécanismes cousins. Fait vérifiable sur le réseau de test. L'hypothèse restante : que le covenant ait été bien construit et que l'utilisateur — en pratique, son logiciel — vérifie ce qu'il signe. Un contrat très restrictif peut être mauvais si ses restrictions ont été mal choisies.

L'œil sur Bitcoin — le SPV. La chaîne BATHRON suit les en-têtes des blocs de Bitcoin et vérifie, dans ses règles de consensus, qu'une transaction précise est incluse et confirmée — chaque nœud refait la vérification, personne n'y croit sur parole. Un contrat peut ainsi stipuler : « libère-toi quand telle transaction Bitcoin aura tant de confirmations ». Pas d'oracle, pas de tiers qui atteste. Cette capacité existe dans le code aujourd'hui — et, à notre connaissance, cette combinaison précise n'existe nulle part ailleurs ; nous préférons que des tiers le vérifient plutôt que de le proclamer. L'hypothèse restante : que la chaîne Bitcoin suivie soit bien la chaîne majoritaire, et que la profondeur de confirmation choisie couvre le risque de réorganisation. Plus on attend de confirmations, plus c'est sûr — et plus c'est lent.

L'horloge — les timelocks. Chaque chemin de remboursement s'ouvre à une date fixée d'avance, et l'ordre des échéances n'est pas un détail : la fenêtre de Bob se ferme avant que celle d'Alice ne s'ouvre, avec des marges pour les lenteurs des chaînes — sans quoi un moment ambigu existerait où les deux chemins se chevauchent. Ajoutons l'hypothèse opérationnelle qu'on oublie toujours : un droit de remboursement n'est utile que si le logiciel d'Alice surveille la chaîne et publie la transaction au bon moment.

Un cadenas qui lie les jambes, un sceau qui fige les issues, un œil qui constate les faits, une horloge qui garantit la fin de partie. Et la phrase de prudence qui doit suivre immédiatement : la garantie globale — « Alice est réglée selon le devis ou remboursée, dans tous les cas, y compris les pannes au pire moment » — est un objectif de sécurité. Les flux n'ont pas été spécifiés formellement ; aucune revue externe n'a eu lieu. Dire aujourd'hui « le fournisseur ne peut pas voler le principal » serait une promesse, pas un fait — et nous nous l'interdisons tant que ce travail n'est pas fait.

9. L'économie du premier entrant

Une question décide de beaucoup : le premier Clearing Provider, qui sera-t-il ?

Mettons-nous à la place d'un teneur de marché neutre et rationnel. Il posera trois questions. Combien ça rapporte ? — des spreads et des frais sur un volume qui n'existe pas encore. Combien ça coûte ? — un capital brûlé, irrécupérable par le protocole, à amortir sur des années. Et surtout : comment je sors ? — en revendant son M1 à d'autres professionnels… qui n'existent pas encore ; ou en le consommant lentement dans l'activité ; ou en le perdant si le réseau meurt. Pour le tout premier entrant, le marché de sortie est vide par définition.

Un teneur de marché neutre, devant ce tableau, dit non — et il a raison selon ses critères. La conclusion honnête est donc : le premier fournisseur sera probablement un sponsor stratégique, pas un arbitragiste. Quelqu'un dont l'intérêt dépasse le rendement du trimestre : un prestataire qui veut se différencier par le règlement conditionnel, une maison de négoce qui veut son propre rail de séquestre, un acteur qui achète la thèse et l'infrastructure en même temps. Il pourrait accepter une rentabilité faible ou nulle au début, pour amorcer.

Et il faut en tirer la conséquence sur ce que prouve quoi : l'arrivée du premier prouvera qu'un sponsor y croit. C'est le deuxième, indépendant, venu sans invitation, qui prouvera qu'un marché existe. La nuance est importante — elle évite de s'applaudir au mauvais moment.

10. L'inventaire honnête de ce qui n'est pas prouvé

Faisons la liste des manques, en chapitre à part entière.

Aucun audit externe. Le code a été relu et attaqué de façon répétée — par son équipe. Dans le logiciel financier, l'auto-examen ne compte pas comme preuve. Un regard extérieur, payé pour casser, est un prérequis à toute valeur réelle. Il n'a pas eu lieu.

Une vulnérabilité connue et assumée. Le réseau de test s'ouvre à des opérateurs extérieurs avec un ticket d'entrée quasi gratuit ; il en découle qu'un acteur malveillant pourrait, à peu de frais, créer quelques identités fictives et geler la finalisation des blocs. Précisons ce que cela ne permet pas : ni voler, ni créer de la monnaie — les invariants comptables tiennent quoi qu'il arrive, c'est dans le code. Un sabotage visible, réversible par un redémarrage du réseau de test ; assumé pour la phase d'expérimentation, à durcir avant tout réseau définitif.

Aucun Clearing Provider réel. Personne n'a ouvert de service réel de règlement conditionnel. Aucune transaction de client réel n'a été routée. L'économie décrite plus haut est une architecture qui attend son premier habitant.

Une économie non prouvée. Le fournisseur doit gagner assez ; le client doit accepter le prix ; les deux en même temps. Un spread trop faible ne rémunère pas le capital ; un spread trop élevé fait fuir le client. Il faudra mesurer, pas raisonner.

Une protection client à spécifier et à revoir — techniquement, et au-delà. Car la protection cryptographique ne remplace pas la protection commerciale : que se passe-t-il si l'objet livré n'est pas conforme ? qui définit que la condition est remplie ? qui répond d'un bug d'interface ? existe-t-il un recours ? Le protocole peut garantir qu'un secret a été révélé ; il ne garantit pas que la réalité commerciale correspond au secret. Ces questions relèvent du service construit au-dessus — et elles restent ouvertes.

11. Face aux alternatives : qui gagne quoi

Un mot de loyauté concurrentielle, car rien ne décrédibilise plus vite que de prétendre tout battre.

Lightning est meilleur pour le paiement simple et rapide, sans discussion. Il vise le transfert de bitcoins par canaux préfinancés, avec ses propres hypothèses — liquidité des canaux, disponibilité des routes, surveillance de la chaîne. BATHRON ne le concurrence pas sur ce terrain ; son sujet commence là où il faut des conditions riches.

Liquid apporte des transferts rapides et confidentiels entre institutions, avec de la liquidité réelle — au prix de son modèle : une fédération identifiée tient la garde, et la sortie passe par ses membres. Compromis différent, pas absurdité ; il faut simplement savoir qu'on l'a signé. BATHRON renonce au coffre récupérable ; en échange, sa liquidité de sortie doit venir des fournisseurs et de leur inventaire.

Un prestataire custodial gagne en simplicité : dépôt, base de données, service client — contre la garde de vos fonds et le pouvoir de trancher. BATHRON cherche à réduire ce pouvoir par des transactions préengagées ; en échange, le système est techniquement plus complexe.

Le multisig avec arbitre et contrat juridique, enfin, est l'alternative la plus honnête pour le séquestre — et il faut lui reconnaître sa force propre : un arbitre humain peut regarder des photos, lire des messages, juger si un produit était conforme. Aucun contrat cryptographique ne fait cela. La délimitation loyale est donc celle-ci : BATHRON vise les conditions objectivement vérifiables — un délai écoulé, une signature, une transaction confirmée ; l'arbitrage humain reste meilleur quand la condition demande une interprétation. Ce n'est pas une concession décorative : c'est la frontière du produit.

La vraie question n'est jamais « qui est supérieur » — c'est : quel type de confiance, et quel type de coût, ce client-ci préfère-t-il ?

12. La vraie question de marché — et le résumé honnête

Tout ce que ce texte a décrit se suspend à une question d'une banalité désarmante :

Combien un client réel accepterait-il de payer pour éviter la garde et l'arbitrage ?

Mettez-vous à la place d'Alice. Pour son séquestre, elle a le choix : l'arbitre et ses honoraires, le prestataire et ses conditions, ou ce rail nouveau. Quel écart de prix la ferait choisir le rail ? Pour un petit paiement ordinaire, probablement aucun. Pour une transaction importante, internationale, exposée au gel ou à la faillite d'un dépositaire — peut-être beaucoup. Personne ne connaît ce chiffre. Il ne se calcule pas dans le code ; il se mesure avec des clients réels, des offres réelles, des refus réels. Et il commande tout : s'il est confortable, l'équation du fournisseur peut fermer et le système vivre ; s'il est proche de zéro, aucune élégance technique n'y changera rien.

Résumons, une dernière fois, dans les trois registres.

Ce qui existe. Une chaîne fonctionne, sur un réseau de test public. Elle crée M0 exclusivement par destruction prouvée de bitcoins — sans prémine, sans récompense de bloc, une unité par satoshi détruit. Elle vérifie elle-même, dans ses règles, l'état de Bitcoin. Elle maintient un coffre et des reçus à parité stricte, vérifiée à chaque bloc. Et elle fait tourner une famille de contrats aux chemins scellés que Bitcoin, à ce jour, refuse d'activer. Tout cela est vérifiable par quiconque veut regarder.

Ce qui est visé. Un moteur de règlement conditionnel derrière une expérience bitcoin banale : des clients qui paient et reçoivent du BTC sans rien voir de la machinerie ; des fournisseurs professionnels qui portent l'inventaire, les prix et les risques ; et une garantie centrale — réglé selon le devis, ou remboursé par l'horloge — qui gouverne chaque contrat. Ce dessin est cohérent, écrit, et non construit : ni spécifié formellement, ni audité, ni habité par un seul fournisseur réel.

Ce qui est espéré, et pas encore su. Qu'il existe des clients dont la douleur vaut un prix ; que ce prix rémunère le capital brûlé d'un professionnel ; qu'un premier sponsor franchisse la porte, puis qu'un deuxième vienne sans qu'on l'invite.

La proposition de BATHRON peut donc se formuler sans exagération. Il ne s'agit pas de supprimer la confiance : il s'agit d'en déplacer une partie — remplacer la discrétion d'un gardien par un burn irréversible, des preuves Bitcoin, des transactions préengagées, des secrets et des délais. Le prix de ce déplacement est une complexité technique réelle et un besoin vital de fournisseurs de liquidité. Ce qui reste à croire est nommé ; ce qui reste à prouver est listé ; et ce qui donnerait tort au projet est écrit d'avance.

Le code existe. Le dessin est net. Le marché est une question posée — et la seule réponse qui compte viendra d'audits externes, d'essais réels, et de clients réels.