{ "recordTitle": "BitcoinOS trustless-bridge claims, BOS sale, and public delivery record", "researchCutoff": "2026-08-22", "scope": "Dated public statements, fundraising records, pinned and executed public code, formal trust-model artifacts, technical assumptions, and records needed to test whether BOS purchasers received a materially misleading impression.", "assessment": "The public record warrants investigation of categorical trustless-bridge and production-readiness representations made beside BOS sale calls to action. The pinned public code substantiates a genuine two-party optimistic prototype; the reviewed sale-period artifacts contain no public working two-way Grail bridge or unconditional ZK-only custody guarantee. Authorities should compel any private code, production-key and custody records, marketing approvals, purchaser exposure and reliance records, causation, and loss evidence.", "claimStatusRecords": [ { "date": "2024-08-07", "saleStage": "before the public presale", "claim": "Edan Yago said BitcoinOS allowed Bitcoin to have truly trustless layer twos.", "qualification": "The official recording establishes the claim, not technical delivery.", "sourceIds": ["bos-nashville-trustless-video"] }, { "date": "2025-01-29", "saleStage": "five weeks before the presale opened", "claim": "Yago described Grail as moving BTC across chains trustlessly without a multisig or federation.", "qualification": "The official recording contains no adjacent implementation-status qualification in the published excerpt.", "sourceIds": ["bos-swiss-web3-grail-video"] }, { "date": "2025-02-16", "saleStage": "before the presale", "claim": "BitcoinOS launched a Grail application under trustless-bridge marketing.", "qualification": "The issuer said the app used valueless Bitcoin and EVM testnets, moved only from Bitcoin to EVM, and still needed a return prover and two-way path.", "sourceIds": ["grail-testnet"] }, { "date": "2025-02-19", "saleStage": "paid promotion before the presale", "claim": "A paid promotion quoted Yago saying users could experience truly trustless Bitcoin bridging with one honest validator.", "qualification": "The same promotion disclosed the one-way testnet status and that two-way transfers were still in development.", "sourceIds": ["bos-paid-grail-presale-promo"] }, { "date": "2025-02-27 to 2025-03-03", "saleStage": "direct BOS solicitation", "claim": "Official sale pages said BitcoinOS enabled trustless cross-chain Bitcoin connectivity and that BOS stakers could sit near more than $7 billion in annual revenue flows.", "qualification": "The revenue wording was conditional, not a guaranteed yield. The pages used direct purchase calls to action, stage-based price increases, bonuses, referrals, and a $50 minimum.", "sourceIds": ["bos-presale-pitch", "bos-presale-open"] }, { "date": "2025-03-20", "saleStage": "presale open", "claim": "CoinDesk attributed the description fully production-ready to Yago.", "qualification": "BitcoinOS's same-day post called the public release a basic two-party regtest version, put multiparty verification in active development, and said Grail code would be released later. The pinned public commit compiles and its default Jest selection passes, supporting a genuine two-party optimistic prototype; excluded, undiscovered, and separately invoked test paths are stated in the code-audit limits below. Its README and complete tracked tree contain no public working two-way Grail bridge. Any different private scope or version requires dated source, build, audit, and deployment records.", "sourceIds": ["coindesk", "bos-bitsnark-v02", "bitsnark-v02-executed-commit", "bitsnark-readme"] }, { "date": "2025-04-14", "saleStage": "during the continuing presale", "claim": "Gadi Guy said BitSNARK enabled trustless bridges with no counterparty or group able to steal user funds.", "qualification": "Later in the same interview, Guy said the first product BitcoinOS wanted to productionize was Grail and expected it shortly.", "sourceIds": ["gadi-trustless-bridge-interview"] }, { "date": "2025-04-24", "saleStage": "phase-one result and phase-two promotion", "claim": "BitcoinOS reported 294,411,364 BOS sold and $2,225,000 raised in phase one.", "qualification": "This is an issuer-reported result, not an independently audited proceeds total or proof that each purchaser saw a particular claim.", "sourceIds": ["bos-presale-phase-one"] }, { "date": "2025-06-12", "saleStage": "presale continuing", "claim": "In a presale interview, Yago acknowledged additional trust assumptions and described honest-participant and BOS-incentive conditions.", "qualification": "This is an important direct qualification and must be considered with the categorical claims.", "sourceIds": ["yago-bos-presale-interview"] }, { "date": "2025-09 onward", "saleStage": "late presale, token launch, and current product record", "claim": "Current BitcoinOS marketing continues to describe bridging without trusting anyone.", "qualification": "The MiCA paper calls Grail trust-minimised. Current Grail Pro materials describe institution or custodian operators, protected hardware, and a supermajority or 12-of-16 example for Bitcoin releases. Grail Pro is a later institutional architecture and should not be silently substituted for original Grail.", "sourceIds": ["bos-mica", "bos-tech", "grail-pro-architecture", "grail-pro-overview", "grail-pro-institutional", "grail-pro-article"] }, { "date": "2025-10-22", "saleStage": "completed launchpad sale", "claim": "Origins' two completed BOS backend periods recorded 609,509,366.81050959 BOS in tokensSold and $4,888,380.29942801134947357397 in the USD-valued usdCollected counter across accepted crypto assets during the full launchpad sale.", "qualification": "The first backend period includes the issuer-reported $2,225,000 Phase 1 result. The figures reproduce first-party platform fields; audited net proceeds, allocation composition, and purchaser-level exposure require issuer, banking, subscription, and account records.", "sourceIds": ["bos-origins-home", "bos-origins-ledger-one", "bos-origins-ledger-two", "bos-presale-phase-one", "bos-presale-maintenance", "bos-presale-close"] } ], "fundraisingRecord": { "record": "bos-launchpad-sale.json", "combinedTokensSold": "609509366.81050959", "combinedUsdCollected": "4888380.29942801134947357397", "displayTokensSold": "609,509,366.81 BOS", "displayUsdCollected": "$4,888,380.30", "periodCount": 2, "periodRelationship": "completed, contiguous, and non-overlapping", "phaseOneTreatment": "The first Origins backend period includes the issuer-reported Phase 1 amount; the combined total sums the two completed backend periods.", "qualification": "The dollar figure reproduces Origins' first-party USD-valued usdCollected counter across accepted crypto assets. It is not an independently audited net-proceeds or bank-receipt total.", "walletFlowRecord": { "record": "bos-presale-wallet-flows.json", "verifier": "verify-bos-presale-wallet-flows.mjs", "finding": "Three rotating primary Ethereum collectors are attributable to the BOS Origins sale through exact participant-to-deposit-to-collector sweeps, shared gas-funding infrastructure, official vesting-beneficiary matches, published stage-price corroboration, and direct collector succession. A smaller 60c branch is separately supported by five exact deposit sweeps, the shared later gas cluster, and one official beneficiary match. Both the middle and post-maintenance collectors transferred canonical assets directly to 0x509201…AbD6; the later collector alone sent 204,103.50752 USDT, 30,056.588245 USDC, and 3.605528140408725578 ETH there. On Rootstock, that same collector sent 0.02221978958 RBTC of swept participant proceeds, net of onward gas, into Sovryn's Exchequer.", "distributionFinding": "The official Ethereum Community Sale vault created 1,162 cancellable schedules totaling 351,227,296.056466997646462718 BOS. Its administrator and emergency-control record connects it to the official BOS owner Safe already sharing DD's five-address owner set.", "measurementStatus": "The reconstructed deposit counts and payer-to-beneficiary matches are lower bounds. Complete multichain proceeds, exchange-account ownership, beneficial control, and source-and-use accounting require Origins, Fireblocks, Binance, issuer, and intercompany records." }, "followThroughRecord": { "record": "bos-proceeds-509-trace.json", "verifier": "verify-bos-proceeds-509-trace.mjs", "finding": "On Ethereum, the middle and post-maintenance collector wallets sent 206,901.784486 USDT and 32,080.705141 USDC directly to 0x509201…AbD6. Balance conservation establishes that at least 226,480.572473 of that designated lot left the address by 30 November 2025. At least 183,441.682473 entered first-hop routes terminating at publicly labeled Gemini, Kraken, and Coinbase addresses; after route losses and relay prebalances, at least 183,433.939419 necessarily reached those labeled endpoints. On BNB Chain, 7,857.87166544 stablecoin units sent directly by the same known collectors remained conserved at 0x509201 through the research cutoff.", "reconciliationStatus": "The legacy EVM-and-Polygon stablecoin view reaches 6.287198% of the Origins counter under the conservative participant-deposit match and 7.044136% under the expanded canonical-token reconstruction. The current non-overlapping multichain public benchmark adds BNB stablecoin roots and high-confidence Origins-style Bitcoin and Cardano collection paths: its transaction-date daily-VWAP estimate is $4,169,986.839549, or 85.304060% of the Origins counter. This is a scale benchmark across different measurement bases; Origins, Fireblocks, exchange, and entity ledgers are required for an order-level source-and-use reconciliation." } }, "leadershipAndControlRisk": { "classification": "Dossier editorial judgment based on separately identified primary, on-chain, code, and mathematical records. Authorities and courts determine criminal charges and civil liability.", "officialLeadership": { "finding": "BitcoinOS identifies Edan Yago as co-founder and CEO and Elan Nahari as co-founder and COO. BTC OS Limited's 2025 MiCA filing lists Yaron Edan Yago as the only named management-body member and describes the company as issuing and supporting BOS and coordinating contributors.", "boundary": "The cross-project record identifies the BOS token-owner and allocation Safes, their five owner addresses, and their shared DD/BOS deployment and owner network. Natural-person control of those addresses and control of production bridge keys, signer seats, operators, custodians, roster administration, TEE allowlists, and service credentials remains unidentified.", "sourceIds": ["bos-about", "bos-mica"] }, "crossProjectControlRecord": { "recordArtifacts": ["dd-bitcoinos-control.json", "bos-presale-wallet-flows.json", "bos-proceeds-509-trace.json", "btc-origins-flow.json", "cardano-origins-flow.json", "exchequer-shared-terminal-flow.json"], "finding": "Assets traced from Sovryn's Exchequer reached DD. Matching DD Safes and the official BOS token-owner and allocation Safe family were deployed by 8C with the same five owner addresses. The same 0x509201…AbD6 and 0xcD9003…fBAA pair approved all 14 observed Ethereum DD executions; 0x509201…AbD6 also links B7, Sovryn's official Ethereum bridge, recurring organizational payments, direct DD payments, and BOS token operations. The BOS sale-wallet record adds direct proceeds paths from two primary Ethereum collector wallets to 0x509201…AbD6 and from the later collector's Rootstock instance into Sovryn's Exchequer. The follow-through record establishes that most of the designated Ethereum stablecoin lot then left 0x509201, with a strict mathematically bounded minimum reaching publicly labeled Gemini, Kraken, and Coinbase addresses, while the directly traced BNB Chain lot remained at that address through the cutoff. The record establishes cross-project operational-control overlap and unreconciled cross-project financial flows requiring a complete source-and-use reconciliation.", "identityStatus": "The natural-person and beneficial controllers behind the five owner addresses remain unidentified. 8C is Tyrone-linked through the separately documented May 2024 project-account session; 8C deployed DD and the BOS Safe family but is not a listed DD owner.", "sourceIds": ["dd-safe-ethereum", "dd-safe-bnb", "dd-safe-ethereum-creation", "dd-safe-bnb-creation", "dd-safe-ethereum-executions", "dd-safe-bnb-executions", "bos-token-page", "bos-token-contract-read", "bos-token-owner-safe", "bos-token-owner-safe-creation", "bos-ecosystem-safe-creation", "bos-founding-safe-50db-creation", "bos-founding-safe-56a-creation", "bos-founding-safe-06d-creation", "bos-ecosystem-safe-transfers", "bos-founding-safe-50db-transfers", "bos-founding-safe-56a-transfers", "bos-founding-safe-06d-transfers", "bos-token-allocation-transaction", "sovryn-bridge-config", "sovryn-b7-to-509", "bos-509-to-5c07", "bos-509-to-e31c", "bos-509-to-59c4", "sovryn-509-bridge-usdt", "sovryn-payment-safe-d518-creation", "sovryn-payment-safe-d518-executions", "dd-to-509-eth", "dd-to-509-usdt", "bos-presale-1160-to-509-usdt", "bos-presale-1160-to-509-usdc", "bos-presale-1160-to-509-eth", "bos-presale-rbtc-to-exchequer", "bos-509-gemini-route", "bos-509-kraken-routes", "bos-509-coinbase-routes", "bos-presale-bnb-to-509"] }, "sovrynDossierBasis": { "finding": "The 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 also documents B7-first-funded address coordination, lender exposure, liquidations, and a failure to locate a Yago commitment to require repayment, pause affected lending, pursue any available protective action, or independently investigate the disclosed loans.", "loanRiskFinding": "Borrowing RBTC against thinly traded SOV obtained bitcoin liquidity without an immediate market sale and transferred collateral-liquidity risk to the lending pool. The all-eleven-loan model estimates a 4.044086930453946278-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.", "legalClassification": "This is the dossier's evidence-based theft finding tied to the cited record. Authorities and courts determine criminal charges and civil liability.", "recordArtifacts": ["asset-map.json", "actor-attribution.json", "curated-transactions.json", "fee-authority-records.json", "b7-activity-coordination.json", "loan-records.json", "pool-model-inputs.json", "snapshots.json", "case-chronology.json", "call-excerpts.json"], "sourceIds": ["disclosure-2", "disclosure-3", "disclosure-4", "call-72", "call-73", "sip-0015", "exchequer-minutes-2021-04-27", "financial-report", "ratification-post", "feesharing-commit", "deployment-commit"] }, "protectiveThreatModel": "A bridge is meaningfully independent of leadership only if user BTC remains safe and redeemable when any founder, company officer, software publisher, operator, custodian, or infrastructure administrator becomes dishonest, compromised, or unavailable. Independent beneficial control requires verified ownership, key-custody, infrastructure, and instruction records rather than address, key, or operator counts alone.", "technicalControlSurfaces": [ { "system": "Sale-period public BitSNARK prototype", "finding": "Safety depended on an effective funded challenge before timeout, correct setup and pre-signed transaction graphs, both required script-path signing capabilities not remaining jointly available, and the discrete log for the configured Taproot internal key remaining unavailable. Under the stated premises, 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.", "conditionalHarm": "Wrongful release or unrecoverable delay can follow if the challenge, setup, key-nonretention, inclusion, or recovery premises fail.", "boundary": "BitcoinOS should produce key-generation, erasure, custody, backup, and instruction records identifying every holder, any alternate transaction, and every disallowed signing path.", "sourceIds": ["bitsnark-readme", "bitsnark-verifier-timeout-code", "bitsnark-two-key-setup-code", "bitsnark-whitepaper", "bitcoin-taproot"] }, { "system": "Later Grail Pro threshold design", "finding": "The official architecture describes TEE-held operator keys, mutable rosters and thresholds, and a 12-of-16 example. Twelve effective signing authorities can authorize under that example; five unavailable or refusing authorities leave eleven and stop the normal threshold path. The architecture's statement that twelve compromises are required for loss of service or funds is therefore false for service availability because 16 - 5 = 11 < 12. A mandatory custodian policy can separately create a custodian veto; its composition with the 12-of-16 threshold remains unresolved.", "conditionalHarm": "A threshold, policy, attestation, or approved-software compromise can enable wrongful release; insufficient quorum, a custodian veto, or failed availability can freeze or delay redemption.", "boundary": "Effective signing authority counts cryptographic capability rather than people. The live roster, beneficial controllers, and common administration topology remain undisclosed in the reviewed public record.", "sourceIds": ["grail-pro-architecture", "grail-pro-overview", "grail-pro-institutional", "grail-pro-article"] }, { "system": "Frontend, operator software, and company service layer", "finding": "BitcoinOS states that users trust the frontend, which queries operator public keys to construct Taproot deposit addresses. Its operator runbook uses the mutable grailpro/cosigner:latest image tag. A pinned public frontend source file 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 discretion to suspend or restrict service access.", "conditionalHarm": "A substituted roster or deposit address can bypass the intended quorum at deposit time. The mutable tag can change what a later pull resolves to; if operators deploy it and the admission policy accepts it, a common faulty or malicious operator image can affect nominally separate authorities. Company-controlled access can be withheld even where protocol recovery remains possible.", "boundary": "BitcoinOS should produce release, allowlist, attestation, deployment, presentation, acceptance, custody, and service-access records identifying how these controls operated and who administered them.", "sourceIds": ["grail-pro-frontend", "grail-pro-operator-runbook", "grail-pro-workflow", "grail-frontend-terms"] } ], "recordsNeeded": [ "production operator and custodian roster, legal identities, beneficial controllers, and related-party relationships", "vault addresses and scripts, signer thresholds, key-generation and erasure evidence, and Taproot internal-key custody", "challenger funding, data-availability, monitoring, inclusion, refund, recovery, and incident-response plans", "roster, threshold, software-measurement, attestation-allowlist, emergency, suspension, and upgrade authority", "reproducible operator and frontend source, immutable builds and container digests, expected enclave measurements, independent audits, and signed update logs", "BOS treasury, allocation, vesting, custody, related-party, and source-and-use-of-funds accounting", "Sovryn and BTC OS Limited general ledgers, intercompany accounts, reimbursements, cost allocations, DD payee records, and every BOS-on-behalf-of-Sovryn payment mapping" ], "editorialJudgment": "Until those controls 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. Valueless testing and independent verification are appropriate; founder reputation and operator count are not substitutes for verifiable control separation.", "controlDisclosureStatus": "The reviewed public record identifies a shared Sovryn/BitcoinOS control network around DD and the official BOS token-administration and allocation Safes: the same 8C deployer, the same five owner addresses, and recurrent 0x509201…AbD6 and 0xcD9003…fBAA operation. Natural-person control of those keys, production bridge signers, operator seats, custodian roles, roster administration, TEE allowlists, and service credentials remains unidentified." }, "publicCodeAudit": { "asOf": "2025-02-28", "commit": "752b35b4777b222c45e9f9acf8d37920f5700e14", "characterization": "A genuine two-party optimistic BitSNARK prototype, not a publicly substantiated working two-way Grail bridge.", "execution": { "runtime": "Node.js 20.17.0, the version specified by the repository", "results": "TypeScript compilation and configured lint passed. The default Jest selection ran 19 suites: 154 tests passed and two refutation test cases marked it.skip were skipped.", "limits": "The .skip-suffixed Jest end-to-end file was outside normal discovery; the Jest configuration excludes integration and testnet-integration directories; and separate Python and Docker/local-regtest end-to-end paths remain unreproduced. The passing default selection establishes the configured unit-test result; a production-bridge result requires the separate networked, multiparty, two-way integration evidence." }, "salePeriodSnapshot": { "commit": "dd403e017f43e9b1ee46d6ec46ea4c60fbb42bd0", "authoredAt": "2025-02-26T11:49:32+02:00", "committedAt": "2025-02-26T14:43:54+02:00", "readmeSha256": "fb818d68f0a81c9e4ddb921a5266c31cccf6125470a14467f440e8774d0b7a5b", "finding": "The snapshot's README describes a local two-party regtest demo and leaves networked multi-verifier operation and a Bitcoin-to-ERC20 two-way peg as future work.", "boundary": "Git metadata dates the repository object; its public-availability date requires hosting or release evidence.", "sourceIds": ["bitsnark-presale-snapshot"] }, "findings": [ { "finding": "The README calls the repository a local prover-verifier demo and leaves multi-verifier operation and a Bitcoin-to-ERC20 two-way peg as unchecked future work. The complete tracked public tree contains no executable Grail bridge, bridge smart contract, operator registry, peg-in, mint-and-burn, UTXO-accounting, or recovery implementation.", "boundary": "This finding covers the pinned public artifact. Any private or unpublished implementation requires dated source, build, audit, and deployment records.", "sourceIds": ["bitsnark-presale-snapshot", "bitsnark-v02-executed-commit", "bitsnark-readme", "bos-bitsnark-v02"] }, { "finding": "The only Circom source is a toy Multiplier(1000) circuit with example inputs a=11 and b=2. The runtime uses a hard-coded proof, verification key, and precomputed vk_x rather than dynamic public inputs binding a Bitcoin inclusion, bridge state, burn, amount, destination, or replay domain.", "boundary": "This describes the runnable public demonstration at the pinned commit. A bridge-specific circuit requires separate source, setup, test vectors, audit, and deployment records.", "sourceIds": ["bitsnark-toy-multiplier-circuit", "bitsnark-runtime-proof-binding"] }, { "finding": "Invalid-release safety is conditional on correct circuit and setup, the intended pre-signed graph, uncompromised or effectively erased signing capabilities, at least one honest verifier that remains online with the required data and challenge funds, operator and recovery availability, and Bitcoin inclusion before each applicable deadline.", "boundary": "One honest verifier is not sufficient if that verifier is unavailable, uninformed, unable to fund a response, or censored past a timeout.", "sourceIds": ["bitsnark-readme", "bitsnark-verifier-timeout-code", "bitsnark-two-key-setup-code", "bitsnark-whitepaper"] }, { "finding": "The published TLA+ action ProofUncontested does not consult proof validity. An audit patch specializes the model's fixed CHOOSE expression to the invalid case and adds an audit-defined label-preservation invariant; TLC then reaches Init -> Proof -> ProofUncontested and removes the Locked Funds label.", "boundary": "The audit-specialized TLA+ model has no CSV-time semantics, signatures, Bitcoin consensus, transaction value, ownership, or recipient. The trace proves symbolic reachability in that transition system, not confirmation of an exact Bitcoin transaction or a complete bridge-safety violation. The code-level counterexample separately requires a matured timelock, unspent inputs, an available valid pre-signature, no effective challenge sequence, and confirmation through the claimant path.", "sourceIds": ["bitsnark-tla-model", "bitsnark-locked-funds-code"] }, { "finding": "The intended locked-funds Tapscript leaf checks prover and verifier Schnorr signatures, embeds SHA-256(setupId), and contains no proof predicate or opcode-level output covenant. The exact pre-signature path uses output-binding SIGHASH_DEFAULT for non-fundable templates, so copied signatures do not authorize changed outputs; if both leaf signing capabilities survive, the holders can instead create fresh signatures for another recipient. This two-key predicate is leaf-scoped: the surrounding P2TR output also has a key path derived from configurable INTERNAL_PUBKEY.", "boundary": "The separate isolated Bitcoin Core lab transaction establishes the output-binding and retained-key proposition in a generic P2WSH/ECDSA SIGHASH_ALL analogue. Exact BitSNARK P2TR/Tapscript/Schnorr replay, production-key custody, alternate production transactions, and bridge-fund movement require separate deterministic and production records.", "sourceIds": ["bitsnark-locked-funds-code", "bitsnark-two-key-setup-code", "bitcoin-taproot", "bitcoin-tapscript", "bitcoin-core-v31", "bitcoin-bip143", "bitcoin-covenants-paper"] } ], "trustModelArtifacts": [ "evidence/public/bitcoinos-trust-model.json", "evidence/public/bitcoinos-trust-model.md", "evidence/public/verify-bitcoinos-trust-model.mjs", "evidence/public/bitcoinos-invalid-proof.patch", "evidence/public/bitcoinos-invalid-proof.cfg" ], "legalEvidenceRequired": "Pinned code, executable tests, consensus behavior, and formal counterexamples test defined technical representations. Speaker intent or recklessness, purchaser exposure and reliance, causation, damages, attribution, jurisdiction, and a final legal finding require internal, purchaser-level, accounting, and legal evidence." }, "technicalBoundary": [ "A zero-knowledge proof establishes a computation relative to a circuit, verification key, and inputs; Bitcoin key custody and future spending enforcement require separate mechanisms.", "The pinned public BitSNARK code is a genuine two-party optimistic dispute prototype: a verifier checks the complete proof outside Bitcoin and Bitcoin adjudicates a disputed computation step. A completed two-way Grail bridge additionally requires the custody, networking, accounting, redemption, recovery, and liquidity components absent from the reviewed public tree.", "The runnable public statement is the fixed toy Multiplier circuit, not a dynamic bridge statement binding chain inclusion, state, burn, amount, destination, and replay protection.", "A one-honest-verifier property is conditional on correct setup, binding pre-signatures, effective key erasure or non-retention, accurate data and circuit evaluation, verifier funding and availability, operators and recovery, and timely Bitcoin inclusion. Liveness, censorship resistance, destination-chain consensus, data availability, peg-out liquidity, and sustainable verifier incentives require additional mechanisms.", "The invalid-proof/no-challenge trace and conditional retained-two-key spend through the intended Tapscript leaf are counterexamples to absolute formulations. The whole P2TR output also has a configurable internal-key path. Neither observation is evidence that a production bridge was exploited, that any production leaf or internal key was retained, or that the generic Bitcoin Core analogue executed the exact BitSNARK script.", "Pre-signed transaction graphs can emulate limited finite covenant behavior without OP_CAT, but add setup, signer, hidden-path, and key-erasure assumptions. That precision narrows Weikeng Chen's literal wording while confirming his technical concern: the later categorical trustless-bridge sale claims omitted the trust and setup conditions shown by the code.", "Current Grail Pro documentation describes a distinct threshold-signing and protected-hardware system, not a ZK-only bridge with no trusted parties or operational dependencies." ], "investigativeElements": [ { "issue": "Representation and materiality", "publicRecord": "Categorical trustless, no-multisig, no-counterparty, production-ready, token-value, and revenue-flow statements were placed near direct BOS sale calls to action.", "recordsNeeded": "Archived buyer-facing page and email versions, checkout terms, risk disclosures, campaign briefs, approval chains, and analytics." }, { "issue": "Falsity or misleading omission at the time", "publicRecord": "Contemporaneous first-party records described a one-way testnet, a local or regtest two-party implementation, unfinished multiparty and two-way work, and unreleased Grail code. A code snapshot carrying 26 February Git timestamps contains the same local-demo and future-work boundaries; public availability on that date requires hosting or release evidence. The pinned 28 February public commit executes as a genuine optimistic prototype but contains only a fixed toy proof statement and no public two-way Grail implementation.", "recordsNeeded": "Exact represented and deployed commits, testnet and mainnet configurations, complete audits, bridge transactions, operator sets, and version-specific trust models." }, { "issue": "Knowledge or recklessness", "publicRecord": "The dated public record includes expert challenges and separate, narrower trust-assumption statements before or during the sale. Internal technical reviews, marketing approvals, and speaker communications should be compelled to establish knowledge, subjective belief, intent, and recklessness.", "recordsNeeded": "Internal technical reviews, audit drafts, marketing review, Telegram and Space records, architecture decisions, and communications reconciling the different formulations." }, { "issue": "Reliance, causation, and loss", "publicRecord": "The issuer reported substantial sale proceeds. Purchaser-level exposure and reliance require account, communication, subscription, and allocation records.", "recordsNeeded": "Subscription ledger, purchaser declarations, exposure and click records, deposits, allocations, vesting and claim records, token dispositions, prices, and alternative market causes." } ], "recordsAuthoritiesShouldCompel": [ "production key-generation, erasure, custody, backup, signer, internal-key, and incident records", "any private or later source, build, audit, deployment, operator, and bridge-transaction records", "hosting and release evidence for the 26 February repository snapshot", "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", "Origins and Fireblocks deposit-address, vault, sweep, workspace, API-user, signer, policy, and audit logs across every accepted chain", "Binance, Gemini, Kraken, and Coinbase account records for the identified collector and 0x509201 routes, including credited accounts, KYC, trades, internal transfers, withdrawals, and bank movements", "Sovryn and BTC OS Limited intercompany, reimbursement, source-and-use, payroll, vendor, and allocation ledgers for the identified collectors, relays, and 0x509201", "corporate attribution, agency, jurisdiction, accounting, and evidence required for a final legal finding" ] }