BSV USA Association: Technical program for a US listing

What this is

This is what John Calhoun (@johncalhooon), the named Director, is building on his own and offering to the association free. No line in this document is a request for money. The cost figures show what John carries, so the board can see the size of the gift and the conflict-of-interest policy has something real to disclose.

It is a menu, not a plan anyone has to approve. Each item says what question it answers, how long it might take John, what it costs him each month, and what evidence it could put in the data room. Take what helps; skip the rest.

Nothing here has been built for the association yet, and no exchange has asked for any of it in writing. Nancy (@NasdaqNancy) is the pseudonymous founder; this document does not speak for any exchange, custodian or the existing BSV Association.

The starting point is the critical blocker from the 9 October analysis: BSV took reorg attacks in August 2021. Robinhood's 2022 Form 10-K describes attackers able to "spend coins they did not have and prevent transactions from completing," and Robinhood ended BSV support on 25 January 2023. The filing does not say the attacks were the only reason. What a reviewer can accept is measurement, published policy, and tooling an exchange can run itself. That is engineering, and it is what John likes to do.

Two limits apply to everything below:

• No tool here prevents a majority-hash attack. A listening node, a monitor, more confirmations and SPV all help an exchange see and limit risk. None of them removes it. Every document we send must say so.
• Costs below are either computed by a named file or marked as estimates. Where a number is an estimate, it says so.

Where the cost figures come from

• COSTS.md means docs/COSTS.md in John's bsv-node-cloudflare project. Every figure in it is produced by tools/costs.py from daily chain data (bitinfocharts, 2018-11-15 to 2026-10-11) and Cloudflare and Modal unit prices read on 2026-10-12. We reran tools/costs.py on 2026-10-12 and it printed the same figures.
• Estimate means our own arithmetic or judgment, not read from a price page or computed by that tool. Each one should be checked before anyone relies on it.

What John already has

These exist today and the menu builds on them:

• Headers service (chaintracks). Block headers on Cloudflare Workers, D1, R2 and a Durable Object tip stream. Open source in Rust.
• Wallet infrastructure on Cloudflare and BRC-100 wallet tooling. An open Rust and Workers stack: SDK, wallet toolbox, wallet CLI, overlay, message box, storage, wallet infrastructure, header service. Public on GitHub under Calhooon and on crates.io.
• The executable specification. BSV script consensus written in Lean 4, with a conformance harness that runs transactions against SV-node, Teranode and the SDKs and reports every disagreement as a witness transaction with the rule it exercises. The public node-specification page (October 2026) reports 21 of 21 check legs green at the newest full check on 2026-10-11, and Teranode v0.16.0 with 0 disagreements on the 26,918 entries it decided in the block path. The public edition opens on a date to be agreed with the maintainers of the implementations it measures.
• The bsv-node-cloudflare design. A listening BSV node built from Cloudflare's metered services. It peers with Teranode, validates transactions, keeps the mempool and UTXO set, follows subtrees and blocks, serves proofs and BEEF, and never builds a block. Design and costs only as of 2026-10-12; no code exists yet. Three milestones: M1 a listening node on mainnet, M2 the full UTXO set, M3 owned hardware and pools.
• The membership registry design (drafts/membership-and-voting-system.md). A Cloudflare Worker with D1 and R2, X verification and BRC-100 keys. The demand counting item reuses it.

1The questions a US listing team asks

Each question maps to the menu items that answer it. Item numbers refer to section 2.

2The menu

The order is the likely priority. The first three answer the critical blocker (Q1, Q2, Q7) and feed everything after them. The next items complete the technical integration guide. The last items help, but a listing team can proceed without them.

2.1 A listening-only, non-mining node on Cloudflare

Why first. Every other security item needs our own view of the chain. Without it, the monitor and the incident history depend on someone else's explorer, which is the trust a reviewer will question first.

What it answers. Q1, Q3, Q9. It is the data source for Q2 and Q7.

What it is. 1. A node that peers with Teranode miners and listens. It never mines and never builds a block. 2. It follows headers, blocks and subtrees, validates transactions, and keeps the mempool and UTXO set. 3. It records every block it sees, including blocks that lose, so competing tips and reorgs are on our own record. 4. It serves headers, merkle proofs and BEEF, plus a status feed of seen, in subtree, mined and rejected. 5. It runs on Cloudflare: one always-on container for the peer, Workers, Durable Objects, Queues, Workflows and R2.

What exists. The design and cost model (bsv-node-cloudflare README, DESIGN.md, COSTS.md). The headers layer (chaintracks) runs today. The Rust script engine exists and is one of the implementations the harness measures. No node code exists yet.

Build time for John. Estimate: 1 to 2 weeks for a watcher tier (peer container plus chaintracks, recording block announcements and competing tips, no transaction validation). 6 to 10 weeks for M1, the full listening node. M2, the full UTXO set, depends on where a snapshot comes from (SV Node, Teranode, or a request to the BSV Association, Teranode Group or GorillaPool); add 3 to 4 weeks once that is settled.

Monthly cost. John's working figure is "a $250 a month listening-only node on Cloudflare." COSTS.md puts it a little higher:

So the real number is about $290 a month at today's volume, about $300 once the UTXO set is loaded, and about $490 with the whole chain archived. The $250 figure is reachable: COSTS.md says folding the subtree-id update into the first write cuts the hot path to $4.64 per million, which works out to about $240 a month plus $10 for the UTXO set (our arithmetic on COSTS.md's numbers). That optimization is named, not built.

The bill follows chain volume. If volume returns to 2024 levels, the same node costs about $1,080 a month. It needs a budget alarm and a fallback: drop to the watcher tier, or move the store to owned hardware through the seam in DESIGN.md.

The watcher tier alone costs the $25 fixed figure plus the headers service. The headers service's own running cost is not broken out in COSTS.md. Estimate: under $10 a month at this volume.

COSTS.md compares this with renting a box for Teranode: $150 to $400 a month bare metal, $900 to $2,000 on a cloud. It marks those as rough rental prices, not read from a price page.

What it buys. An independent chain view. Headers. Merkle proofs and BEEF. Block and reorg data on our own record, with timestamps. A validator we can measure against the specification. It does not add hashrate and does not stop an attack.

Evidence for the data room. Document 1: the node's block and tip log as the primary source for the monitor and incident history. Document 2: the deployed design, its source version and its cost record.

Risk if not done. Every security claim cites someone else's data. A reviewer asks "how do you know?" and the answer is an explorer.

2.2 A public reorg monitor

Why second. It is the single most direct answer to "what happened since 2021, and would you see it again?" The data room index already lists it as a release requirement for Document 1.

What it answers. Q1, Q6, Q7.

What it is. 1. Watches competing tips and chain work from the node, the headers service and at least one other observation point. 2. Records every reorg: time, heights, hashes, depth, and any transactions that changed or vanished. 3. Measures miner share from coinbase tags over 24 hours, 7 days and 30 days, with the unknown share shown. 4. Sends alerts by webhook, email and a public feed; every alert test is logged. 5. Keeps a public archive and an API, including the monitor's own outages.

What exists. The headers service and its tip stream. The node design records losing blocks. Nothing of the monitor is built.

Build time for John. Estimate: 2 to 3 weeks on top of the watcher tier of 2.1.

Monthly cost. Estimate: $0 to $5 beyond 2.1. It runs as Workers and a Durable Object inside the same Workers Paid plan, and its archive is small in R2. Not computed by COSTS.md.

Evidence for the data room. Document 1: the monitor's address, source version, observation points, event log, alert history and alert test records. Named operator and backup.

Risk if not done. "Chain security" stays the item a reviewer cannot wave through. Robinhood's filing cites 2021, and we have nothing dated to set beside it.

Care needed. Coinbase tags are labels a pool chooses. They are not proof of who controls the hashpower. The monitor must say this on its page.

2.3 Confirmation-depth guidance, as a living document and a small service

Why third. Every exchange sets a deposit confirmation count for BSV. If we do not publish a reasoned method, each one picks a number alone, often a very high one, and that number becomes the story.

What it answers. Q2, Q7.

What it is. 1. A published method: given measured hashrate concentration, deposit size and an assumed attacker share, how many confirmations make a reversal unlikely enough. 2. Deposit tiers, for example small, medium, large and very large, with a recommended count for each. 3. Halt and resume rules: stop crediting on competing tips, a reorg past a set depth, stale data, or a sudden shift in miner share. 4. A small API that returns the current recommendation per tier, computed from the monitor's latest concentration series. 5. A versioned changelog. Each exchange approves its own thresholds; ours are inputs, not orders.

What exists. The data room index outline for this section. The concentration data comes from 2.2. Nothing is built.

Build time for John. Estimate: 1 week for the document, 1 week for the service, after 2.2 has a few weeks of data.

Monthly cost. Estimate: $0 beyond the Workers plan. Not computed by COSTS.md.

Evidence for the data room. Document 1: the method, its assumptions, the tier table, the halt and resume rules, and the residual risk. Document 2: the API and how an exchange wires it into deposit crediting.

Risk if not done. Exchanges either refuse BSV or pick punitive confirmation counts. A count with no stated method looks like marketing.

Care needed. No "safe" number. More confirmations raise the cost of an attack. They do not stop an attacker with most of the hashpower. The 9 October analysis cites Crypto51's estimate that an hour of majority hashpower rents for low thousands of dollars; that figure is dated and must be rechecked before it is used.

2.4 A headers-and-proofs (SPV) service for exchanges and custodians

Why fourth. It lets an exchange check a deposit with headers and a merkle proof instead of trusting an explorer or a broadcaster's status word. It is cheap to run because the headers service exists.

What it answers. Q4, Q9.

What it is. 1. A headers API: chain tip, header by height or hash, chain work, and a push stream of new tips. 2. A proof API: merkle path for a txid, and BEEF for a transaction with its ancestry. 3. Verification libraries: check a proof against headers locally, in Rust, Go and TypeScript, using the open SDKs. 4. Documentation of what SPV proves and what it does not. Inclusion in a block is not proof that every consensus rule was checked. 5. A mirror policy: an exchange can run its own copy so it never depends on ours.

What exists. The headers service (chaintracks) on Cloudflare. BEEF and proof handling in the open Rust stack. Proofs from our own node arrive with 2.1 M1; until then proofs come from existing public services.

Build time for John. Estimate: 2 to 3 weeks to package, document and publish.

Monthly cost. Estimate: $0 to $10 at expected request volume, inside the Workers plan. The headers service's running cost is not broken out in COSTS.md. Proof caching uses R2 at COSTS.md's unit prices.

Evidence for the data room. Document 2: the API, the libraries, test results for invalid and missing proofs and stale headers, and the trust limits written out.

Risk if not done. Exchanges verify deposits through third-party explorers. That is the trust model a reviewer flags, and it contradicts the whitepaper's own read model.

2.5 A listing-grade node package

Why fifth. An exchange's infrastructure team needs something it can deploy in a day. This is larger work than 2.1 to 2.4, and a reference instance costs John real hosting money.

What it answers. Q3, Q6, Q8.

What it is. 1. A reproducible deployment of SV-node or Teranode at pinned versions, with build hashes and checksums. 2. Monitoring dashboards and alerts for sync, peers, tip, reorgs and mempool, wired to 2.2 and 2.3. 3. The confirmation policy from 2.3 built in as configuration. 4. Runbooks: install, upgrade, rollback, reorg handling, halt and resume, restore from backup, escalation contacts. 5. One reference instance we run ourselves, so every claim in the package has been exercised.

What exists. The Teranode facts the bsv-node-cloudflare design relies on. The conformance harness already runs both nodes at pinned versions, so the version pins and a working regtest setup exist in that program. No package exists.

Build time for John. Estimate: 4 to 6 weeks for one node (Teranode or SV-node), plus 2 weeks for the second.

Monthly cost, by where it runs.

The Cloudflare listener is our own implementation, not SV-node or Teranode. It is a good light option and an independent second view, but an exchange that wants a reference implementation will run one of the two node programs. COSTS.md's comparison is that the metered design is about even with a bare-metal Teranode box at today's volume and three to seven times cheaper than cloud Teranode, with no host to operate.

Evidence for the data room. Document 2: the versioned package, release hashes, resource measurements, test results, runbooks and a named support contact.

Risk if not done. The exchange's engineers build their own BSV integration from scratch. That is the two to four months of node work the 9 October analysis expects after approval, and it is where listings stall.

2.6 A conformance badge per implementation and release

Why sixth. It answers a question no other chain can answer this way: does this node release follow the consensus rules, checked by machine? It also turns the SV-node to Teranode migration into a measured fact.

What it answers. Q3, Q10.

What it is. 1. For each implementation and release (SV-node, Teranode, bsv-rs, go-sdk, ts-sdk), a run of the harness against the executable specification. 2. A badge: in tune when a full run at the pins finds no unexplained divergence. 3. The corpus counts and check-leg results behind each badge. 4. Witness transactions published for every divergence, each with the rule it exercises and a one-command replay. 5. A page per release, run the week the release lands.

What exists. The specification and the harness, 21 check legs green at the 2026-10-11 record, Teranode v0.16.0 at 0 disagreements on 26,918 entries in the block path (public node-specification page). The public edition opens on a date agreed with the maintainers, so the badge page waits for that date.

Build time for John. Estimate: 1 to 2 weeks for the badge page and publishing pipeline. The harness runs already exist.

Monthly cost. Estimate: $0 cash. Runs use compute John already has. Not computed by COSTS.md.

Evidence for the data room. Document 2: the badge for the node release the exchange will run, the pins, the run record and any witnesses with their rulings.

Risk if not done. A reviewer has no independent way to know the node software is consistent across releases. The migration to Teranode reads as a risk instead of a measured change.

Timing. Gated by the public edition date.

2.7 An incident history since 2021

Why seventh. Document 1 requires it, and a reviewer will ask for it directly. It ranks here only because it takes research time rather than building, and the node's own data only starts when the node starts.

What it answers. Q1.

What it is. 1. An incident register from the August 2021 attacks to the report date: UTC dates, heights, hashes, depth, double-spend evidence, response, recovery. 2. Each entry tagged as observed, reported or alleged, with its sources. 3. A coverage map: which periods are covered by which data, and which are unknown. 4. From the day the node starts, entries come from our own records. 5. Updated monthly and hashed to chain with the association's other records.

What exists. The 2021 baseline is documented (Robinhood's 2022 Form 10-K, press coverage cited in the 9 October analysis). No register exists.

Build time for John. Estimate: 3 to 4 weeks, mostly research with agent lanes, then a monthly update.

Monthly cost. Estimate: $0 cash. Any paid research runs only inside a budget John names.

Evidence for the data room. Document 1: the register, coverage map and sources.

Risk if not done. The packet cannot say what happened after 2021. We must never claim "no attacks since 2021" without this register, and the absence of the register reads as hiding.

2.8 A custody integration guide with test vectors

Why eighth. Custodians are the gate every exchange checks first. A guide with machine-checkable vectors cuts the integration cost a custodian would otherwise charge us to sponsor.

What it answers. Q4.

What it is. 1. How BSV differs from BTC and BCH: signature hashing with FORKID, no SegWit, Genesis-era script rules, address and network identifiers, BSV and BCH separation. 2. Script forms a custodian will meet, and the ones it should refuse to accept as deposits. 3. BEEF and SPV for deposits; UTXO management, fees and broadcast for withdrawals. 4. Test vectors: signature-hash and signing cases drawn from the specification's corpus, including real mainnet inputs, each checked against the specification and the SDKs. 5. A provider matrix: Fireblocks, BitGo, Anchorage and screening providers, recorded as enquiries with dates, not as partners.

What exists. The specification's signature-hash corpus (500 cases plus vectors with eight mainnet inputs, per the public page) and the open SDKs. Fireblocks' public catalog lists Bitcoin SV, checked 12 October 2026; that is a catalog entry, not a custody confirmation.

Build time for John. Estimate: 2 to 3 weeks.

Monthly cost. Estimate: $0.

Evidence for the data room. Document 2: the guide, the vectors with their check record, and the provider matrix.

Risk if not done. Custodians price BSV as an unknown chain. The 9 October analysis puts a sponsored integration at $50k to $250k; a good guide is the cheapest way to lower that.

2.9 Broadcast reliability statistics

Why ninth. Exchanges send withdrawals. They need to know transactions get mined and how fast. This is cheap but less urgent than security.

What it answers. Q5.

What it is. 1. Small test transactions sent on a schedule through ARC endpoints and miner propagation endpoints. 2. Measured per endpoint: accepted, rejected, time to seen, time to in subtree, time to mined. 3. Our own node's status feed as the independent check, not the broadcaster's reply. 4. Published daily and weekly figures, with outages shown. 5. Raw records downloadable.

What exists. The wallet tooling can build and send transactions. The node design has the status feed. Production apps John runs have fired large transaction packs, but those records are not a published series.

Build time for John. Estimate: 2 weeks, after 2.1 M1.

Monthly cost. Estimate: transaction fees of cents a month at current fee rates, plus $0 to $5 in Workers. Some endpoints may need an API key or a paid tier; not checked. Spending real satoshis needs John's approval.

Evidence for the data room. Document 2: the endpoint table and the reliability series.

Risk if not done. "Will our withdrawals go through?" is answered with anecdotes.

2.10 A sandbox for exchange engineers

Why tenth. Useful once an exchange is actually integrating. Before that, nobody uses it.

What it answers. Q4.

What it is. 1. A regtest network (or testnet access) with a public endpoint. 2. A faucet. 3. Example deposit and withdrawal flows that use SPV, in Rust, Go and TypeScript. 4. Scripted scenarios: a reorg at chosen depth, a double spend, a stale header, a missing proof. 5. Reset on demand.

What exists. The harness already drives private regtest nodes. The specification work shows how to put a wallet into any chain state, including a reorg at any depth.

Build time for John. Estimate: 3 to 4 weeks.

Monthly cost. Estimate: $20 to $60. The $20 is COSTS.md's figure for a basic container awake all month; a regtest node probably needs a larger container, which COSTS.md does not price.

Evidence for the data room. Document 2: the sandbox address and the scenario test results.

Risk if not done. Each exchange builds its own test rig, which slows integration after approval.

2.11 A status page with uptime and propagation times

Why eleventh. It makes the association look and act like an operator, and it is where "who answers the phone" gets a written answer.

What it answers. Q5, Q6, Q8.

What it is. 1. Uptime of every association service: node, monitor, SPV service, guidance API, sandbox. 2. Block and transaction propagation times measured by our node. 3. Current incidents and their history. 4. Named contacts: John as Director, a named backup, and an escalation path. 5. A subscribe option for exchanges' operations teams.

What exists. Nothing for the association. The public site already runs on Cloudflare Pages.

Build time for John. Estimate: 1 week.

Monthly cost. Estimate: $0 to $5 inside the Workers plan.

Evidence for the data room. Documents 1 and 2: the uptime record and the contact sheet.

Risk if not done. No visible operator and no published contact. The 9 October analysis notes that an anonymous counterparty fails the first email to a listing team; this is the operational version of that.

2.12 Demand evidence counting

Why last on this menu. Demand is Kraken's first filter, but it is not a technical blocker, and it depends on the membership registry.

What it answers. Q11.

What it is. 1. A consented count of US holders and businesses, built on the membership registry's X verification and BRC-100 keys. 2. Optional proof of holding by signature, never by moving coins. 3. A list of businesses building on BSV with a link each. 4. Counts published as totals, with the method and the hash of the underlying roll. 5. Agents count only. They never message exchanges. Requests to exchanges go only through each exchange's official channel, by people.

What exists. The membership registry specification. Nothing is built.

Build time for John. Estimate: 2 to 3 weeks, shared with the registry build.

Monthly cost. Estimate: $0 inside the Workers plan. The registry spec says version 0 needs no X API spend.

Evidence for the data room. Document 6: reproducible counts and the method.

Risk if not done. Demand is argued from social media posts, which a listing team discounts.

3One-page plan

First: the three that matter most. The listening node (start at the watcher tier, grow to M1), the reorg monitor, and confirmation-depth guidance. Together they answer the critical blocker (Q1, Q2, Q7) with our own data. The watcher tier and the monitor can be running in about 3 to 5 weeks; M1 and the guidance follow.

• Monthly: about $25 to $35 at the watcher tier (COSTS.md fixed cost plus estimate), rising to about $290 to $300 once the full listener runs at today's volume (COSTS.md).

Next three. The SPV service, the incident history, and the custody integration guide. These complete the first drafts of Documents 1 and 2 with almost no new spend.

• Monthly: about $0 to $10 more (estimate). Running total about $300 to $310.

Gated by a date. The conformance badge waits for the public edition date agreed with the maintainers. Broadcast statistics, the status page and demand counting cost cents to a few dollars and can fill gaps between the larger items. Running total stays about $300 to $320 (estimate).

Later, if John chooses.

• The node package's reference instance: Teranode on bare metal, $150 to $400 a month (COSTS.md, rough).
• The sandbox: $20 to $60 a month (estimate).
• The whole-chain archive in R2: $128 to $192 a month (COSTS.md).
• An independent technical reviewer for Document 1: not priced.
• Monthly for this tier: about $300 to $650 more. Running total about $600 to $970.

Standing risk. The Cloudflare node's bill follows chain volume. At 2024's volume it is about $1,080 a month (COSTS.md). Set a budget alarm before launch and decide the fallback in advance.

4What it costs John

Unit prices behind COSTS.md (Workers Paid, read 2026-10-12): Workers requests $0.30 per million; Workers CPU $0.02 per million CPU-ms; Durable Object rows written $1.00 per million; Durable Object storage $0.20 per GB-month; R2 storage $0.015 per GB-month standard, $0.01 infrequent; no R2 egress charge; Queues $0.40 per million operations; basic container awake all month about $20; plan $5. COSTS.md's main assumption to check first is 5.5 row writes per transaction, the single biggest lever on the bill.

These are John's own costs, given in kind. None is a line the association pays. Build times are estimates for John working with agent lanes, not commitments.