# BitcoinOS trustless-bridge claims: code, protocol, and finite-model audit

**Research cutoff:** 21 August 2026  
**Scope:** historical public claims, public code, Bitcoin consensus behavior, and formal safety/liveness properties. Production deployment testing lies outside this historical audit.

## Summary

BitcoinOS published real cryptographic work. The reviewed public code implemented a two-party optimistic verifier; the bridge described in sales material additionally required custody, multiparty, two-way, recovery, and liquidity components. The simplest analogy is an alarm-and-dispute system rather than a vault that automatically rejects every false withdrawal: a capable watcher must have the right data, notice a bad claim, fund the response, and get the required Bitcoin challenge confirmed before the deadline. If that effective challenge never completes, the published design contains a claimant path after the timeout.

The design also uses transactions signed in advance to restrict how bitcoin can later move. Before any bitcoin is deposited, participants sign the permitted future withdrawals. Those signatures are tied to those exact transactions and cannot simply be copied to a different recipient. But if both required BitSNARK signing capabilities survive—or the parties secretly sign another transaction during setup—the holders can authorize a different withdrawal. The safeguard therefore assumes at least one capability, including every copy or backup, becomes permanently unusable. Bitcoin can verify the signatures, but not that deletion.

A credible setup would use fresh one-use keys held by independent participants, publish every allowed transaction and refund path for verification, construct the Taproot internal path so no private key was ever known, and complete an independently audited setup before funding. Those measures document and distribute the assumption. Bitcoin still cannot certify deletion or rule out a secretly pre-signed alternative.

A proof checker is only one part of a bridge. The reviewed repository contained no complete networked, multiparty, two-way custody system binding deposits, burns, amounts, recipients, replay protection, redemptions, recovery, and liquidity. BitcoinOS's own sale-period material described the public app as one-way and testnet-only while some of that work remained unfinished.

[Origins' first completed backend counter](https://origins.sovryn.app/api/phase/3bee1d18-fdc2-4328-ae80-5920d0a4b568/info) and [post-maintenance continuation counter](https://origins.sovryn.app/api/phase/982bd8f6-026f-4d24-89b1-968ab5b71d0c/info) together record the full launchpad sale: approximately 609.51 million BOS in `tokensSold` and $4.89 million in the USD-valued `usdCollected` counter across accepted crypto assets. The issuer-reported $2.225 million Phase 1 result falls within the first period. Treat these as first-party platform counters; audited net proceeds and the composition of purchased, bonus, referral, and staker allocations require issuer, banking, and subscription records. The linked [`bos-launchpad-sale.json`](./bos-launchpad-sale.json) record preserves the exact values, response snapshots, and calculation.

The technical record supports investigation of whether categorical no-counterparty claims gave purchasers a misleading or incomplete account of the actual conditions. Production-key custody, bridge-fund movement, marketing approvals, speaker knowledge, purchaser exposure and reliance, causation, and loss are records authorities should compel.

## Leadership and control-risk judgment

[BitcoinOS identifies Edan Yago as co-founder and CEO and Elan Nahari as co-founder and COO](https://www.bitcoinos.build/about). [BTC OS Limited's 2025 MiCA filing](https://a.storyblok.com/f/343174/x/33d8e92e07/mica-whitepaper.pdf) lists Yaron Edan Yago as the only named management-body member and describes the company as issuing and supporting BOS and coordinating contributors. Those records establish executive leadership. The [`dd-bitcoinos-control.json`](./dd-bitcoinos-control.json) record identifies the BOS token-owner and allocation Safes, their five owner addresses, and the shared DD/BOS deployment and owner network. The natural-person controllers—and any production bridge keys, operators, custodians, roster administration, software allowlists, and service credentials—remain unidentified.

The separate Sovryn dossier characterizes the treasury transfers and the taking of stakers' fee rights as theft. It documents Yago as the public leadership, policy, explanation, and ratification actor in that course, and as the speaker who dismissed the lender warning; it places Nahari in the Exchequer finance, accounting, and reporting lane. It documents B7-first-funded address coordination, measurable staker and lender harm, and no located Yago commitment to require repayment, pause affected lending, pursue any available protective action, or independently investigate the disclosed loans. Borrowing RBTC against thinly traded SOV obtained bitcoin liquidity without an immediate market sale transferred collateral-liquidity risk to the lending pool; the all-eleven-loan model estimates a 4.0441-RBTC shortfall under its stated assumptions. The pattern warrants examination as an exit-risk scenario. The B7-linked borrower cluster remains pseudonymous; authorities should compel key-custody and communications records to identify its controllers and motive. This is the dossier's evidence-based theft finding; authorities and courts determine criminal charges and liability.

The protective technical question is not whether users consider a founder honest. It is whether their BTC remains safe and redeemable when any founder, company officer, software publisher, operator, custodian, or infrastructure administrator becomes dishonest, compromised, or unavailable. On the reviewed public record:

- Sale-period BitSNARK needed an effective funded challenge before timeout, correct setup and transaction graphs, both required script-path signing capabilities not remaining jointly available, and the discrete log for the configured Taproot internal key remaining unavailable. An invalid claim can reach the claimant path if no effective challenge confirms; if both required script-path signing capabilities survive, their holders can co-sign a fresh alternative spend through the locked-funds leaf. BitcoinOS should produce key-generation, erasure, custody, backup, and instruction records identifying every holder and disallowed signing path.
- Later Grail Pro uses TEE-held operator keys, mutable rosters and thresholds, and a 12-of-16 example. Twelve effective signing authorities can authorize; five refusals or outages leave eleven and block the normal path. The architecture page's statement that twelve compromises are required for “loss of service or funds” is therefore wrong for service availability: `16 - 5 = 11 < 12`. The reviewed documentation leaves the composition of its custodian-specific veto and 12-of-16 threshold unresolved. Independence requires verified beneficial controllers rather than an authority count alone.
- [The official frontend trust model says users trust the frontend](https://docs.bitcoinos.build/technical-documentation/grail-pro-charms-zkbtc/technical-overview/grail-pro/grail-pro-system-architecture/front-end.md), which queries operator keys to construct Taproot deposit addresses. [The operator runbook uses `grailpro/cosigner:latest`](https://docs.bitcoinos.build/technical-documentation/grail-pro-charms-zkbtc/technical-overview/grail-pro/grail-pro-operational-workflows/running-an-operator.md), a mutable tag rather than an immutable digest. A substituted roster or address can bypass the intended quorum at deposit time. The tag can change what a later pull resolves to; if operators deploy it and the admission policy accepts it, one shared faulty or malicious image can affect nominally separate operators. The reviewed record leaves the referenced frontend audit, expected enclave measurement, image digest, and update approver unidentified.
- [A pinned public Grail frontend source file](https://github.com/bitsnark/florin-fe/blob/9e8c66b57bd512ff94fac8075a62afeaf43352f6/src/pages/terms-page.tsx) contains terms that call BTC OS Limited the Bridge Operator, limit reverse redemption to where technically feasible, warn of partial or total loss, and reserve company discretion to suspend or restrict access. BitcoinOS should produce the versioned deployment, presentation, acceptance, custody, and service-access records that establish when those terms operated and who exercised the reserved authority.

**Protective judgment:** until the production roster and beneficial-control map, vault scripts, setup and key-erasure evidence, internal-key custody, challenger plan, software and threshold-change authority, immutable builds, TEE measurements, audits, and incident records are published and independently verified, users should not entrust BTC to a BitcoinOS bridge or treat “trustless” as an operational fact or a reason to buy BOS. Test only with valueless assets; founder reputation and operator count are not substitutes for verifiable control separation.

The reviewed public record names Yago and Nahari as BitcoinOS leaders and identifies the BOS token-owner and allocation Safes plus their shared DD/BOS owner-address network. Natural-person control of those owner addresses—and control of every production bridge key, signer threshold, operator seat, custodian role, roster-administration power, TEE allowlist, and service credential—remains unattributed. Those undisclosed controls raise the diligence standard and should be compelled before users entrust BTC or rely on “trustless” claims.

## Determination

The reviewed protocol does not support unconditional invalid-claim safety. Under explicit timeout and transaction premises, an invalid claim can reach a claimant-controlled path if no effective challenge completes. Separately, the intended locked-funds Tapscript leaf permits an alternative spend if both signing capabilities remain available.

Two distinct adverse constructions establish those boundaries:

1. **Invalid proof with no timely challenge.** BitSNARK is optimistic. Its own published transition graph permits `ProofUncontested` to consume the locked funds after the timeout without checking `IsProofValid`. Set the proof to invalid and let every verifier fail to land a challenge before the deadline. The invalid claim reaches the prover path.
2. **Both script-path signing capabilities retained.** The locked-funds Tapscript leaf checks one prover signature and one verifier signature but contains no proof predicate or opcode-level covenant. Its Schnorr `SIGHASH_DEFAULT` signatures bind the transaction and its outputs, so an existing signature cannot simply be copied to a changed recipient. If both capabilities survive—or the parties pre-sign an exact alternative before erasure—the coalition can instead create valid signatures for that alternative through the leaf. A fresh isolated Bitcoin Core regtest accepted a generic two-key analogue; it did not execute the exact BitSNARK Tapscript.

The supplied decoder test successfully verifies its supplied Groth16 witness, and a correctly executed deleted-key setup can constrain spending to the pre-signed graph. The published design is **trust-minimized under explicit setup and active-verifier premises**, rather than unconditionally free of trusted parties or groups.

The sale-period record compounds that technical overbreadth. Before and during the BOS solicitation, first-party materials described the public product as a one-way, valueless testnet and the public code as a local or regtest two-party demonstration; networked multiparty operation, a return path, a two-way peg, and Grail code remained future work. This identifies a substantiation gap and supports further investigation into whether sale-linked statements were materially misleading or incomplete. Authorities should obtain marketing approvals, internal technical reviews, purchaser exposure and reliance records, allocations, transaction history, and loss evidence.

The 24 July 2024 Telegram exchange records [Weikeng Chen challenging Yago’s covenant claim](https://t.me/bitVM_chat/19108), asking to inspect the challenge code, and [warning him to consider whether his technical team had misled him](https://t.me/bitVM_chat/19117). The independent audit confirms the technical concern he raised: the identified transaction was a real proof-verification milestone, while the reviewed public code was a two-party optimistic verifier whose safety depended on a timely challenger, correct setup, a complete pre-signed graph, no complete signing coalition remaining available, no secretly pre-signed alternative, and an unavailable Taproot internal-key discrete logarithm. Chen’s literal statement that covenant behavior was impossible without `OP_CAT` was broader than the consensus result because deleted-key presigning can emulate a limited finite covenant. His technical concern survives that correction: the emulation is not a native covenant, and the later categorical trustless-bridge sale claims omitted its off-chain setup, deletion, and active-challenger assumptions. Telegram establishes the dated warning and response; code, consensus rules, executable tests, and the bounded formal analysis establish the technical result independently.

## Reviewed representations, paraphrased except where quoted

The reviewed representations include:

- [Edan Yago, 29 January 2025, 09:05–09:17](https://www.youtube.com/watch?v=EqAQmVrfDdI&t=545s): BTC could move across chains “trustless” without a multisig or federation.
- [Paid promotion quoting Yago, 19 February 2025](https://news.bitcoin.com/bitcoinos-launches-holy-grail-bitcoin-bridge-app-ahead-of-bos-presale/): users could experience “truly trustless Bitcoin bridging” with one honest validator.
- [Official BOS presale page, 27 February 2025](https://blog.bitcoinos.build/blog/bos-presale-be-early-to-bitcoin-again): BitcoinOS already enabled any blockchain to connect to Bitcoin trustlessly through zero-knowledge cryptography.
- [Gadi Guy, 14 April 2025, 07:22–07:44](https://www.youtube.com/watch?v=wT7TYY4QRnw&t=442s): BitSNARK enabled trustless bridges with no counterparty and no person or group together able to steal the user's money.

Each recording or page establishes the representation made. The verification below separately tests the represented property as a falsifiable proposition.

## Definitions

Let `F` denote the Bitcoin UTXO containing bridge funds. Let `P` be a proof claim, and let `valid(P)` mean that the exact bridge statement encoded by the intended circuit, verification key, public inputs, chain state, recipient, amount, and anti-replay rules is true.

For verifier `i` in execution `e`, define the event:

`E_i(e) := verifier i's complete required conflict/dispute sequence becomes canonical before every competing timeout`

Honesty, availability, correct canonical data, correct computation, funding, and timely Bitcoin inclusion are premises that can make `E_i(e)` possible. They are not logically equivalent to the event itself: an otherwise dishonest verifier could still challenge, while an honest verifier whose transaction is not confirmed in time does not protect that execution.

The absolute safety claim is:

`for every execution e: NOT valid(P_e) => F is never released to the claimant as acceptance of P_e`

This permits a safe refund or recovery to an authorized party; it does not classify every movement of `F` as a safety failure.

The actual one-of-N conditional claim is:

`NOT valid(P_e) AND (E_1(e) OR ... OR E_n(e)) => the invalid claimant-release path is blocked`

Those are not equivalent. The second contains an explicit operational premise that the first omits.

## Proof 1: the no-challenge execution

The immutable [BitSNARK README](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/README.md#high-level-overview) says the complete proof is checked by a verifier off-chain and that, absent a challenge during the window, the prover claims the locked funds and the proof is treated as valid. The official [September 2024 explanation](https://blog.bitcoinos.build/blog/bitcoinos-open-sourcing-the-bitsnark-verification-protocol) says the same thing and names the security premise as one-of-N.

The code implements that branch:

- [`LOCKED_FUNDS`](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/common/templates.ts#L17-L33) contains the external value.
- [`PROOF_UNCONTESTED`](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/common/templates.ts#L131-L160) consumes `LOCKED_FUNDS` plus the proof outputs and creates a prover-only output.
- The [prover agent](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/protocol-logic/protocol-prover.ts#L43-L57) sends that transaction when the no-challenge timeout expires and marks the peg-out successful.
- The [verifier agent](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/protocol-logic/protocol-verifier.ts#L118-L153) checks the complete proof off-chain and must actively send the challenge.

The counterexample is constructive:

1. Choose an invalid `P`.
2. Publish `Proof`.
3. Choose the permitted execution in which no `E_i(e)` occurs. This could result from collusion, outage, missing data, inability to fund the dispute, or late inclusion; no probability assumption is needed.
4. Require that the relevant CSV/timelock condition matures, the necessary inputs remain unspent, and the valid pre-signed `ProofUncontested` transaction remains available.
5. Confirm `ProofUncontested` through the claimant path.
6. `F` is consumed into that path although `valid(P)` is false.

Therefore the reviewed release rule does not provide unconditional invalid-claimant-release safety under those premises. The executable verifier accepts that release rule as an input and enumerates its aggregate Boolean truth table. With `n` verifiers it finds one counterexample state among the `2^n` effective-challenge states: no `E_i(e)` occurs. The public v0.2 implementation has one verifier; values above one are hypothetical one-of-N generalizations, not an exploration of an implemented multiparty BitSNARK state machine. These are logical case counts, not probability estimates.

### The official TLA+ property leaves the required invariant untested

The published [TLA+ model](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/specs/BitSnark.tla) has the same transition:

- `ProofUncontested` consumes `Locked Funds` without referencing `IsProofValid`.
- `VerifierWins` is defined only as `Locked Funds` being present.
- For an invalid proof, `HonestVerification` asks that `VerifierWins` eventually hold.

But `Locked Funds` is present in the initial state. The invalid-proof branch of `HonestVerification` is therefore satisfied before any proof is published, leaving post-attempt preservation of the funds outside the invariant.

The repository defines `IsProofValid` with a fixed `CHOOSE` expression; it is not a state variable that explores both valid and invalid values. The public packet includes [`bitcoinos-invalid-proof.patch`](./bitcoinos-invalid-proof.patch), which creates an audit specialization with `IsProofValid` fixed to `FALSE` and adds a deliberately strong label-preservation surrogate:

`InvalidProofSafety == IsProofValid OR "Locked Funds" \in outputs`

Using the official TLA+ model checker 2.19, TLC produces this counterexample:

```text
State 1: Init
outputs = {"Stakable Funds", "Locked Funds", "Payable Funds"}

State 2: Proof
outputs = {"Proof Value", "Proof Signal", "Locked Funds", "Payable Funds"}

State 3: ProofUncontested
outputs = {"Proof Uncontested", "Payable Funds"}

Invariant InvalidProofSafety is violated.
3 states generated, 3 distinct states, depth 3.
```

The audit patch specializes the project's own symbolic transition model, fixes proof validity to the adverse case, and adds an audit-defined invariant. The model has no time or CSV semantics, signatures, Bitcoin consensus, transaction value, ownership, or recipient. TLC establishes symbolic reachability `Init -> Proof -> ProofUncontested`, where the `Locked Funds` label disappears. Exact Bitcoin confirmation timing and a complete bridge-safety specification require the separate code and consensus premises documented above.

## Proof 2: the published locked-funds Tapscript leaf is two-of-two

The v0.2 public code constructs one locked-funds Tapscript leaf from the prover and verifier public keys in [`createLockedFundsExternalAddresses`](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/setup/create-external-addresses.ts#L32-L42). [`generateSpendLockedFundsScript`](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/agent/setup/generate-scripts.ts#L61-L77) iterates over both keys and emits a signature verification for each. [`verifySignature`](https://github.com/bitsnark/bitsnark-lib/blob/752b35b4777b222c45e9f9acf8d37920f5700e14/src/generator/btc_vm/bitcoin.ts#L1353-L1356) emits the public key and `OP_CHECKSIGVERIFY`.

The remaining setup identifier is dropped when the program is finalized, followed by a true stack result. No opcode in this leaf evaluates a proof or independently enforces an output covenant. The actual Taproot Schnorr signatures use `SIGHASH_DEFAULT`, whose ALL-equivalent semantics commit to the outputs of the transaction being signed. Its script acceptance predicate is therefore:

`Accept(T) = Verify(pkP, sigP, T) AND Verify(pkV, sigV, T)`

This leaf is logically a two-of-two authorization condition even though it is expressed as two `OP_CHECKSIGVERIFY` operations instead of legacy `OP_CHECKMULTISIG`.

Let coalition `K` hold both private signing capabilities. Let `Tbad` spend the locked output through this leaf to a recipient chosen by `K`. The coalition computes fresh signatures `sigP` and `sigV` for `Tbad`, or prepared those exact signatures before erasure. Both clauses of `Accept(Tbad)` are true, so Bitcoin accepts that script path. Existing signatures for another transaction cannot simply be copied because their sighash binds the outputs. This is nevertheless one explicit group that can redirect funds if both capabilities survive. It disproves the universal “no person or group together” definition for this leaf under that premise.

The intended response is a presigned or deleted-key setup: sign only the permitted transaction graph and ensure enough signing capability is destroyed so no alternate threshold can ever be formed. That can work, but it is a premise outside Bitcoin consensus. The public implementation loads private keys and signs templates; it publishes no consensus-verifiable erasure ceremony. A backup, snapshot, hidden alternate signature, incorrect graph, missing signed path, or bypass leaf changes the result.

The address also commits to a setup-ID hash, and the surrounding P2TR output contains a key path derived from a configurable `INTERNAL_PUBKEY` whose public-code default is x-coordinate `1`. The two-of-two predicate above describes the intended script leaf rather than the whole Taproot output or address construction. Treating the output as script-path-only additionally requires that the internal-key discrete logarithm be unavailable; BitcoinOS should publish the ceremony and custody record supporting that premise.

## Independent Bitcoin Core construction

To test the signature-and-key-retention proposition raised by the exchange independently, an isolated Bitcoin Core v31.1 regtest created a valueless two-of-two P2WSH output using ECDSA `SIGHASH_ALL`:

`2 <P1> <P2> 2 OP_CHECKMULTISIG`

Four cases were submitted to the live node:

| Case | Result |
|---|---|
| Agreed recipient, both original signatures | Accepted, broadcast, and mined (`39dd4537…cbea3`) |
| Recipient changed, original signatures copied | Rejected (`840c102e…1191`) |
| Same changed recipient, freshly signed with both retained keys | Accepted (`b666ed42…366b`) |
| Agreed recipient, only one of two signatures | Rejected (`5816997b…c3b`) |

This lab record demonstrates both halves needed for a fair account:

- binding pre-signatures plus effective deletion can restrict a finite transaction graph without `OP_CAT`; and
- pre-signing alone is not a covenant. If every required signing key remains available, their holders can sign another transaction.

This generic Core construction uses P2WSH/ECDSA, legacy `OP_CHECKMULTISIG`, and BIP143. It tests the analogous proposition: output-binding signatures reject mutation, while retaining every required key permits fresh authorization of another transaction. Exact BitSNARK P2TR/Tapscript/Schnorr replay remains unreproduced. The public packet records txids and hashes; a complete deterministic replay additionally requires the raw transaction, witness, and node fixture. The primary [deleted-key covenant paper](https://arxiv.org/abs/2006.16714) reaches the same conditional result and explains the unverifiable-erasure problem between participants.

## What the public repositories actually demonstrated

### v0.1 during the pre-sale claim period

BitcoinOS [announced the public v0.1 release on 25 September 2024](https://blog.bitcoinos.build/blog/bitcoinos-open-sourcing-the-bitsnark-verification-protocol). The public mainline commit pinned for this review is `c7326cdb3f019d0b8d7373c56408a5c650abbae7`.

Its README says:

- the demo generated JSON descriptions rather than binary transactions transmitted to Bitcoin;
- transaction generation still required a private repository;
- the agents still required a private repository;
- a runnable local regtest demo, networked multi-verifier operation, and a two-way ERC-20 peg were future plans.

All 56 public tests pass. They test cryptographic arithmetic, encoding, Merkle logic, and Taproot primitives. They do not constitute a public two-way bridge test.

This pinned v0.1 tree is the public baseline verified here for Yago's 29 January statement and the 19 February paid promotion. It cannot substantiate a delivered networked, bidirectional bridge.

### Snapshot dated before the 27 February sale page

Commit `dd403e017f43e9b1ee46d6ec46ea4c60fbb42bd0` carries authored and committed timestamps of 26 February 2025. Its README describes a local two-party regtest demo and leaves multi-verifier networking and a two-way peg as future work. Git metadata dates the repository object; its public-availability date remains unverified and requires hosting or release evidence.

### v0.2

The reviewed v0.2 commit is `752b35b4777b222c45e9f9acf8d37920f5700e14`, dated 28 February 2025. All 154 tests selected by the default Jest configuration pass; two are skipped; TypeScript compilation passes. The default Jest run excludes the regtest and testnet integration directories, and a Jest end-to-end test file has a `.skip` suffix. The repository also documents `npm run e2e` and `scripts/e2e.sh` as a Docker-dependent local two-party regtest demo; this audit did not reproduce that full path because Docker was unavailable. Neither the default suite nor that documented local demo establishes a networked multiparty two-way bridge.

The immutable README still calls the repository a local prover/verifier demo and leaves multi-verifier operation and a two-way peg unchecked under future plans. The [20 March issuer release](https://blog.bitcoinos.build/blog/bos-open-sources-bitsnark-v0-2-go-verify-any-computation-on-bitcoin) calls it a basic two-party regtest version, says multiparty verification is in development, and says Grail code will be released later.

The separate immutable decoder test passes and verifies its supplied Groth16 witness. That supports the narrow mainnet proof-verification milestone. A proof verifier is not yet a bridge: a two-way bridge also needs custody, authenticated source and destination state, mint and burn accounting, replay protection, operator membership, challenge availability, fee handling, redemptions, and liquidity.

### Sale-period product status

The official [16 February Grail launch record](https://blog.bitcoinos.build/blog/bos-grail-testnet-bridge-is-live-the-holy-grail-of-trustless-bitcoin-scaling) says:

- the assets had no monetary value;
- the app moved from Bitcoin Testnet 3 to EVM testnets;
- only one-sided transfers worked;
- the return prover, two-way path, and mainnet use remained future objectives.

Eleven days later, the [BOS presale page](https://blog.bitcoinos.build/blog/bos-presale-be-early-to-bitcoin-again) used the present-tense claim that BitcoinOS enabled any blockchain to connect with Bitcoin trustlessly. The sale page linked the claimed capability to token purchases and potential network revenue. Origins' two completed, contiguous backend periods record 609,509,366.81050959 BOS in `tokensSold` and $4,888,380.29942801134947357397 in its USD-valued `usdCollected` field across accepted crypto assets. The first period includes BitcoinOS's separately reported $2.225 million Phase 1 result. Audited net proceeds and token-allocation composition require issuer, banking, and subscription records.

That sequence establishes a dated substantiation gap between the categorical capability representation and the issuer's own public product/code status. Purchaser-level exposure and reliance require account, communication, and allocation records.

## Later Grail Pro is also conditional

Current Grail Pro documentation describes a later architecture, separate from the sale-period design. It supplies first-party disclosure of another trust model.

The official architecture describes institution or custodian operators running AWS Nitro enclaves. The enclaves check proofs and authorize Bitcoin releases through a threshold; a dated article gives a 12-of-16 example. Bitcoin sees the threshold signatures, not the off-chain TEE policy.

For the documented example `n=16, t=12`:

- the minimum coalition with enough effective signing authority is 12;
- the minimum unavailable/refusing set that leaves fewer than 12 is 5;
- there are `C(16,12)=1,820` minimal 12-authority coalitions and 2,517 authorizing coalitions including larger sets;
- two 12-member quorums intersect in at least eight authorities.

The later documentation also describes a custodian-specific approval condition while leaving that custodian's membership among the 16 ambiguous. The public model therefore enumerates both readings:

- if the custodian is a distinct seventeenth mandatory authority, authorization needs that custodian plus 12 of 16 operators—a minimum of 13 effective authorities—and the custodian alone can veto;
- if the custodian is one of the 16 and must be included in the 12, authorization still needs 12 effective authorities including that custodian, and that custodian alone can veto.

For the plain 12-of-16 rule, “simultaneous safety-and-liveness tolerance 4” is a single Byzantine fault-set bound assuming every authority outside that one set remains available and cooperative. Eleven compromised authorities plus four different unavailable authorities fall outside that calculation.

“Effective signing authority” counts cryptographic capability rather than people. Twelve independently secured enclaves may require twelve separate compromises; a common build signer, attestation allowlist, roster administrator, cloud account, recovery path, or implementation defect could affect many. The minimum human coalition remains indeterminate until BitcoinOS publishes deployment topology and beneficial-control records.

The architecture is therefore conditional on correct enclave code, circuit and verification key, canonical chain inputs, AWS Nitro and its attestation root, approved measurements, roster and threshold governance, independent key control, availability, frontend integrity, and the absence of a common-mode compromise. No current public repository or immutable container digest exposes the Grail Pro cosigner implementation needed to verify those predicates.

This is a design-level counterexample to an unconditional “no group” claim using the later Grail Pro architecture. Production-incident analysis and sale-period architecture attribution require separate contemporaneous records.

## Established findings and unresolved evidence

### Established

- Under the stated timelock, unspent-input, valid-presignature, and confirmation premises, the no-effective-challenge path releases locked funds to the claimant without Bitcoin evaluating the full proof.
- The audit-patched symbolic model admits a three-state invalid-proof label-removal trace under its abstractions; exact Bitcoin execution and complete safety require the separate code and consensus premises documented above.
- The published locked-funds Tapscript leaf is a two-key authorization condition with no opcode-level output covenant or proof predicate; its signatures bind the authorized transaction, and the surrounding P2TR key path adds a separate internal-key premise.
- A retained full signing threshold can authorize a changed recipient through the intended leaf; a separate Bitcoin Core lab accepted the generic P2WSH/ECDSA analogue.
- Deleted-key presigning can emulate a finite covenant without `OP_CAT`, but only under correct-graph, binding-signature, no-hidden-signature, and effective-erasure premises.
- Public sale-period artifacts did not substantiate a delivered networked, multiparty, two-way mainnet bridge.
- The published protocol does not support an unconditional no-counterparty/no-group-can-steal formulation; it supports narrower conditional claims under explicit premises.

### Records authorities should compel

- production key-generation, erasure, custody, backup, signer, internal-key, and incident records;
- any private or later source, build, audit, deployment, operator, and bridge-transaction record;
- internal technical reviews, marketing approvals, architecture decisions, and speaker communications;
- purchaser-facing page and terms versions, exposure logs, deposits, allocations, reliance evidence, token disposition, causation, and loss records; and
- corporate attribution, agency, jurisdiction, accounting, and evidence required for a final legal finding.

## Reproduce the finite models

From the public evidence directory:

```sh
node verify-bitcoinos-trust-model.mjs
```

The verifier exhaustively enumerates the assumed effective-challenge truth table, the published leaf's two-key coalitions, and the later 12-of-16 threshold subsets. Its executable scope is finite Boolean and threshold arithmetic against the expected results in [`bitcoinos-trust-model.json`](./bitcoinos-trust-model.json). Source authentication, repository execution, TLC and Bitcoin Core reproduction, editorial findings, and legal findings are documented separately above.

To reproduce the TLA+ counterexample:

```sh
git clone https://github.com/bitsnark/bitsnark-lib.git
cd bitsnark-lib
git checkout 752b35b4777b222c45e9f9acf8d37920f5700e14
git apply /path/to/bitcoinos-invalid-proof.patch
java -cp /path/to/tla2tools.jar tlc2.TLC \
  -config /path/to/bitcoinos-invalid-proof.cfg specs/BitSnark.tla
```

TLC should terminate with an invariant violation and the three-state trace above. The model checker JAR used for this review was TLA+ 2.19 with SHA-256 `936a262061c914694dfd669a543be24573c45d5aa0ff20a8b96b23d01e050e88`.