Start here

This guide assumes you know how to run a shop and take card payments. It explains Bitcoin from the beginning, so you can decide whether this way of being paid would suit your business.

OpenBMT is a project for taking bitcoin payments at a shop’s counter. A customer pays from a Bitcoin wallet, an app that lets them send and receive bitcoin. The payment goes to a wallet controlled by the shop. OpenBMT does not hold the proceeds in an account or send you a later bank payout.

That gives you control of the money, along with responsibility for keeping access to it. You also receive bitcoin rather than dollars. If you want dollars in your bank account, you arrange the conversion through an exchange you choose.

OpenBMT is pre-release. It has had internal review only and no independent security audit. Do not use it with real funds.

You can use this handbook to evaluate the design. OpenBMT is not ready to put into service with paying customers. Its Android apps have started on an emulator, a computer that simulates a phone, but have not been tried on a physical phone. Setup instructions are still being written. The status page distinguishes working code, tests and unfinished parts.

What would change at the shop

A cashier would enter the sale amount, show a payment code and wait for the counter to report the payment. The customer needs a wallet containing bitcoin. The cashier then closes the order in the shop’s existing point-of-sale system, or POS, using a Bitcoin payment type.

You would also have owner work outside checkout: looking after the wallet, approving refunds and transfers, checking the records, and deciding how much bitcoin to keep or sell. There is no company that can reset the wallet if you lose access to it.

The next chapters explain those tasks before the detailed software rules. They use shop examples and explain terms when they first matter. The fee examples and all starting limits are examples or dated figures, not promises about future costs or losses.

What to read first

The decision today

If you need a finished payment system now, OpenBMT is not ready for that job. If you are curious about a shop-controlled Bitcoin checkout, the handbook explains what the project offers and what it asks of the owner.

The merchant guide also covers privacy, risks and the backup routine. The project-choice chapters explain the reasons for the design.

For readers who already know Bitcoin

The separate technical design section assumes familiarity with transactions, descriptors, multisig and full nodes. It sets out the trust boundaries, format choices, exact checks, alternatives and current test gaps, with links to the rules and source code. You can start there without reading the introductory lessons.

The status and source chapters record implementation progress and dated fee and tax material. References such as SR-34 and CR-15 identify rules in the repository’s docs/ folder and corresponding tests in the code. You do not need to follow them to read the merchant guide. “Not verified” marks something that has not been checked; the surrounding text says what is known.

What a bitcoin payment is

Suppose a customer buys something for $20 and asks to pay with bitcoin. You can still price the goods in dollars. The counter works out how much bitcoin the customer needs to send at the quoted exchange rate. You then receive that amount of bitcoin.

For example, if one bitcoin were worth $100,000, a $20 sale would require 0.0002 bitcoin. That is 20,000 satoshis. A satoshi is one hundred-millionth of a bitcoin, a small unit used to avoid long decimal amounts. The $100,000 rate here is an illustration, not a current price.

The wallet and the payment address

A wallet is software for receiving and spending bitcoin. It manages the secret information needed to authorize spending, called private keys. The bitcoin itself is recorded on the shared Bitcoin transaction record, usually called the blockchain. It is not stored inside a phone like a photograph.¹

To receive a sale, the shop gives the customer a payment address. Think of it as the destination for that payment, rather than the shop’s name or a bank account login. OpenBMT displays it as a QR code together with the amount. The customer scans the code, checks the amount in their wallet and approves sending it.

OpenBMT gives each sale a fresh address. This helps keep the sales separate and reduces how easily someone can link them. A fresh address does not make the public transaction record private.

Seeing a payment and confirming it

When the customer presses send, their wallet announces a transaction to the Bitcoin network. The counter may see that announcement quickly. The payment is still unconfirmed at this point. The sender may be able to replace it, so seeing it is not enough to know it will remain paid.

Bitcoin miners collect transactions into blocks. A block is a group of transactions added to the shared record. Miners compete using computer work to produce an accepted block, and receive newly issued bitcoin and transaction fees for doing so. This process is called proof of work.

When a payment is included in a block, it has its first confirmation. For a reversal that removes that block, a competing valid transaction history must overtake it in total computer work. Later blocks add more confirmations and make that harder. Competing blocks can arise naturally as well as during an attack.²

A block arrives about every ten minutes on average. That is not a timer: a particular payment may confirm sooner, later, or much later if its fee is too low for the transactions being included. No fixed number of confirmations makes a reversal impossible.²

For a shop, this creates a practical choice. It can wait for its chosen number of confirmations before handing over goods, or accept the risk of an unconfirmed payment for a small sale. OpenBMT calls the second choice instant acceptance. The owner sets limits on both one sale and the total still waiting for a first block. The cashier does not have to make that policy during each sale.

Receiving bitcoin and receiving dollars

The dollar price on the counter tells the customer how much bitcoin to send. It does not convert the receipt into dollars. After the sale, the shop holds bitcoin until it spends it or sells it.

Using the same illustrative rate, your 20,000 satoshis are worth $20 at receipt. If the dollar price of bitcoin later falls by 20%, they are then worth $16. If it rises by 20%, they are worth $24. The amount of bitcoin has stayed the same. Costs and cashing out explains the extra steps if you want a bank deposit.

Lightning is another way to pay bitcoin

Lightning is a payment system built on Bitcoin. It lets payments move through arrangements called channels without putting every purchase in a separate blockchain transaction. The channels hold bitcoin and can be settled back to the Bitcoin blockchain.³

OpenBMT can use Lightning only through a node the shop already runs. A node here is software you operate to connect to that payment network. Running a Lightning node involves keeping it online, maintaining backups and making sure it has capacity to receive payments. It is additional owner work. OpenBMT’s connection to such a node is built at the counter but has not been tried against a real node.

Ordinary blockchain payments are called on-chain payments. The next chapter starts with one of those. Lightning is an optional route for a shop prepared to operate its own node.

1. Bitcoin developer guide: wallets and the Bitcoin FAQ explain wallets, keys and the shared transaction record. Read 2026-11-11. ↩

2. The Bitcoin FAQ and payment-processing guide distinguish an announced payment from a confirmed one. The interval is an average, not a promised waiting time. Read 2026-11-11. ↩ ↩2

3. The payment-channel lifecycle explains channel balances and settlement. The liquidity guide explains receiving capacity. Read 2026-11-11. ↩

A sale at the counter

Imagine a customer buying an $8 item. They already have bitcoin in a wallet that can make an on-chain payment. The cashier still rings up the goods in the shop’s usual POS. OpenBMT handles the Bitcoin payment alongside it. The counter is a shop phone or tablet running the Counter app.

The following describes the current design and built payment handling. The Android app has not been tested on a physical phone, so this is not a live-sales walkthrough.

Enter the sale and show the code

The cashier enters $8 on the counter’s keypad. The counter calculates the bitcoin amount using its quoted exchange rate and shows a QR code. That code contains the amount and a fresh payment address for this sale. The screen also displays the address’s first and last characters so it can be checked.

The customer scans the code, reviews the payment in their wallet and presses send. Their wallet pays the network fee for sending. OpenBMT then watches for the payment.

Today the cashier enters the amount manually. A Square or Clover order does not automatically start the counter, and OpenBMT does not automatically close the POS order. The cashier closes it using the shop’s Bitcoin payment type after the counter reports acceptance. Order matching can later flag a mismatch between the POS and counter records; it cannot prove that goods were handed over.

Decide when to hand over the goods

Seeing the transaction on the network is different from seeing it confirmed in a block. The owner decides how much the shop will accept before a first confirmation. The cashier follows the counter’s result.

With the initial light-check limits, an $8 sale is small enough to be considered for instant acceptance. It can turn green before a block if the owner has enabled instant acceptance, the payment checks pass and there is room in the shop’s risk budget. It is still possible for the payment to fail. The shop is choosing to expose up to $8 in that sale.

An $80 sale is above the initial $10 per-sale limit, so it waits for a block. The confirmation depth starts at one block. The wait is not a fixed ten minutes, and the counter cannot promise when a miner will include the payment.

Read the result

The refund threshold starts at six confirmations. It is a later point for refunds and accounting, so the cashier does not normally wait for it before releasing goods at the ordinary confirmation depth. Both depths can be changed, but neither can be below one block. More confirmations reduce reversal risk without eliminating it.

Staff can override some red-screen decisions within their assigned limits. That accepts risk on behalf of the shop and is recorded with the person’s name, time and amount. Overrides also use the exposure budget. A replaced payment raises an alarm that only the owner can clear.

Understand the line below the result

The counter also says where its information came from. “Light check” means its own check through other computers on the Bitcoin network. “Your Box reports it” means only the shop’s Box has reported it so far. The Box is an optional server explained in Equipment and daily work.

The counter can combine those reports or add a check from the shop’s own full node. A full node is software that checks Bitcoin’s rules itself. “Your node and light check” means both saw the payment. A report from the Box is not the same evidence as checking against a full node.

The complete screen wording and combinations are in the payment reference.

Keep the total at risk under control

A per-sale cap does not limit a sequence of small unpaid purchases by itself. OpenBMT also tracks the total accepted instantly but still waiting for first confirmations. It calls this exposure.

The initial light-check limits are $10 for one sale and $50 outstanding across the shop. In a one-counter example with that full budget allocated, five $8 payments would use $40. Two more would exceed it, so they cannot both be accepted instantly while those five remain unconfirmed. A payment leaves the total after its first confirmation or the owner’s action, never just because time has passed.

These defaults are guesses, not measured probabilities of loss. You can lower the limits or set them to zero to wait for confirmation on every on-chain sale. Raising them needs the Key app on a separate signing phone, explained in Who controls the money. Other check modes and the exact conditions are listed in the payment reference.

In today’s apps, instant acceptance also needs the Owner app, running on the owner’s phone, and the Counter app open and linked. The initial setup leaves it off until the owner answers the customer-network question. It is not an unattended default.

When a sale does not go as expected

If the customer sends too little, the cashier can ask for the remainder with an updated payment code or cancel. Small shortfalls can be covered by a shop-set tolerance, initially 0.5% and never above 5%.

If too much arrives, OpenBMT records the surplus as owed to the customer. It does not silently treat that extra money as revenue. A late payment to an expired or cancelled sale is still recorded and flagged to the owner; it cannot make a different sale appear paid.

A customer can request a refund at the counter. That creates a request for the owner. It does not let the cashier send money from the wallet. The owner later reviews and approves the refund with the second signer. The step-by-step refund guide is still being written.

If the counter has no connection, it stops offering Bitcoin and asks for another payment method. Customers scan a code today; NFC tap to pay is not built.

Small sales and Lightning

For a low-priced item, the customer’s on-chain sending fee can be large relative to the purchase. The shop can set a minimum Bitcoin sale or add its own Lightning node. With that node, the payment code can offer both an on-chain address and a Lightning invoice, a request payable over Lightning.

The Lightning node reports receipt immediately, without the on-chain instant cap. The shop runs and maintains it. This option is built at the counter but has not been tested with a real node. It is additional setup and operating work, described in Equipment and daily work.

Costs and cashing out

A card processor usually deducts a fee from each sale and pays the remainder to your bank. With OpenBMT, the customer sends bitcoin directly to the shop’s wallet. There is no OpenBMT percentage fee or scheduled OpenBMT payout. The costs occur in different places.

Who pays which fee

The on-chain fee depends on how much transaction data must be processed, not a percentage of the sale amount. When the wallet sends several incoming payments together, the new transaction has to describe each one being spent. Many small payments can therefore cost more to move than one larger payment of the same total value. That cost appears later, when you move the money.

During a busy fee market, a very small receipt can cost more to spend than it is worth. The shop can set a minimum on-chain sale. A shop running its own Lightning node can offer that route for small purchases, with its own routing fees and operating work.

Compare a familiar sale

On Square’s United States Free plan, the in-person rate read on 2026-11-11 was 2.6% plus 15 cents. For a $20 purchase, that is:

• 2.6% of $20 = $0.52.
• $0.52 + $0.15 = $0.67.

At 1,000 such sales a month, that would be $670 a month, or $8,040 a year, before dispute or payout fees. These are dated figures, not a quote for your account or a prediction of future pricing.

A direct Bitcoin receipt has no processor deduction. You still need to allow for the customer’s sending fee, your later spending fee, conversion terms if you want dollars, and the work of operating the system. The comparison does not establish that Bitcoin is always cheaper. The fee reference has the full card-rate table and a dated Bitcoin fee calculation.

There is no processor payout to release

When a card processor holds a payout or reserve, you wait for it to release the money under its terms. A Bitcoin payment to the shop’s wallet is under the shop’s control once the required payment conditions are met. OpenBMT has no account balance to release or freeze.

This also means there is no company to restore access after you lose the necessary wallet keys. Control of the receipts and responsibility for access come together. Who controls the money explains the three-key arrangement.

Turning the bitcoin into a bank deposit

The dollar amount displayed at checkout is a price quote. It does not sell the bitcoin for you. In the design, cashing out involves separate steps. The owner phone prepares the transfer, and the Key app, a separate approval app on another phone, reviews it:

1. Choose an exchange and obtain its deposit address.
2. Enroll that destination on the Key app by scanning it. A new destination has a 24-hour wait on that app before use.
3. Prepare the transfer on the owner phone and review it on the separate signer. The two signatures authorize spending from the shop’s wallet.
4. Send the bitcoin to the exchange. Selling it and withdrawing to a bank are your dealings with that exchange, outside OpenBMT.

OpenBMT does not choose the exchange or control its deposit, conversion or withdrawal terms. The exchange may have its own sign-up and identity checks. OpenBMT’s lack of an account does not remove those requirements from other services, or the shop’s tax, licensing and trade obligations. The cash-out walkthrough is still being written.

Decide what to keep

The price of bitcoin can change between the sale and cash-out. Receiving $20 worth today does not promise a $20 bank deposit later. The opening example shows how the same bitcoin amount could later be worth $16 or $24.

You choose how much to retain and when to sell. OpenBMT makes no price prediction and does not recommend buying or holding bitcoin as an investment. The reasons for choosing Bitcoin as the project’s money are explained in Why Bitcoin only; that choice does not remove price risk.

Refunds and disputes work differently

A cardholder can dispute a payment through their bank, and the processor can hold the merchant’s money while the dispute proceeds. A payer or bank cannot pull a confirmed Bitcoin payment back from your wallet. A chain reversal remains possible; more confirmations reduce its likelihood.

A customer refund is a new Bitcoin payment approved by the shop. The cashier requests it; the owner and second signer approve spending. The customer does not get a card-style chargeback mechanism through OpenBMT. This makes a clear shop refund policy important. Consumer obligations still apply.

The source reference preserves the dated Visa dispute periods and processor dispute fees. The reference also documents payout and reserve terms for comparison.

Keep records in the shop’s currency

For United States reporting, bitcoin received for goods or services is income at its dollar fair market value on the day received. That value is also the basis used to work out a later gain or loss when the bitcoin is sold or spent. The sale record and the later disposal record therefore matter even when you eventually want only dollars.

OpenBMT’s accounting export follows United States rules only and reports what is in its records. It is not tax advice. Ask a tax professional about your circumstances. The tax reference contains the dated IRS sources, reporting-form distinctions and unresolved regulation check from 2026-11-11.

Customers still need bitcoin to pay this way. OpenBMT makes no claim about how many of your customers will want it. Its fit chapter considers that demand alongside the equipment and owner work. The full fee, reserve, supply and tax source material is in the reference chapter.

Who controls the money

A wallet needs secret information to authorize spending. That information is called a private key. Someone with the required keys can authorize a payment; someone without them cannot ask a company to reset the wallet.

OpenBMT gives the shop three wallet keys and requires any two to spend. This arrangement is called two-of-three multisig, meaning multiple signatures. The three keys are not three pots of money. They are three ways to authorize spending from the same wallet, with two needed together.

What the second key does

Suppose the owner phone is stolen. It has one wallet key. That key alone cannot spend the money. The owner can use the remaining two to move funds to a new wallet.

Now suppose two keys are lost and no usable backups remain. Only one key is left, so nothing can be spent. OpenBMT or Avila Labs cannot regenerate the missing keys. Keeping the keys apart protects against one loss; keeping usable recovery information protects against losing access permanently.

The separation also matters when approving a transaction. A compromised owner phone could display one thing while preparing another. The second device checks the transaction independently and shows it on its own screen before signing.

Where the three keys are kept

No device may hold two keys or make another key sign without that key’s own device reviewing the transaction. Keeping both signing devices in the same place would also make a single theft more damaging.

Key 3 must be made outside OpenBMT software and away from key 2’s device. Only its public information is imported into OpenBMT. Recovery words are secret words that can recreate a key; they are not the public payment address. Keys 2 and 3 need their words recorded separately on steel. Key 1 has no recovery words by default, a choice still marked for review in the design. A locked phone without a known PIN or recovery words counts as a lost key.

A hardware wallet, a dedicated signing device, or an offline computer is an alternative for key 2 in the design. Hardware signing has not been tried on real devices. The wallet reference contains the generation methods and exact validation checks; a tested setup walkthrough has not been written yet.

What is not protected yet

The apps are currently signed for release by one publisher. The independent second person who must hold the Key app’s release key has not been named. Reproducible builds and an independent rebuilder, which would help check released software against its source, are also not in place.

A malicious release could undermine the separation between the phones. The design recommends a hardware or another publisher’s signer for key 2 until release independence exists, but those alternatives remain unverified. The claim that no single compromised component can spend the wallet does not hold today. This is a launch condition, not a setting the merchant can solve by choosing a stronger PIN.

OpenBMT has had no independent security audit. The apps have not been tested on a physical phone. Do not use it with real funds.

What staff can do

An exception override accepts the sale on the shop’s behalf and is logged. It does not make the underlying payment more reliable. Only the owner can clear a payment-cancel alarm. The counter has one manager PIN and a local list of cashiers today; several independent manager accounts are not built. The reference gives exact permissions, PIN lengths and limits.

Increasing a risk limit needs another approval

Lowering the amount accepted before confirmation reduces risk. The owner can do that immediately. Raising it increases risk and needs approval on the Key app as well. OpenBMT calls these directions tightening and loosening.

The same distinction applies to changes such as reducing the number of confirmations, adding a counter or adding a Lightning node. The separate approval shows each old and new setting. Some hard bounds cannot be overridden by either signer. A proposed delay for hardware signers that cannot sign settings is not built; without the spare Key app as approver, the design discloses dependence on the owner phone alone.

Approving refunds and transfers

The owner phone collects work in a queue: refunds, cash-outs, more payment addresses, sensitive settings and device pairings. Putting a request in the queue does not move money.

When the second signer is available, the owner opens an approval session:

1. Transfer the queued requests from the owner phone to the Key app by animated QR code or file.
2. Read each request on the Key app. Approve or decline it there. An item left undecided is declined.
3. Transfer the signed reply back. The owner phone adds its signature and sends the approved result.

The Key app checks where the money goes, change returned to the wallet, fees and its own spending limits. It cannot check the shop’s sales record or independently prove that a refund is owed. Dollar figures come from the owner phone. Review the actual destination and amounts rather than assuming a second signature makes a false refund claim true.

New cash-out destinations are enrolled by scanning on the Key app and have a 24-hour wait before use. The app has per-transaction, daily and weekly spending ceilings. The approval reference explains those ceilings and the clock and software limits behind them.

Why the owner approves payment addresses

The counter is not allowed to choose an arbitrary destination for sales. It receives a batch of addresses approved by both signing devices, then uses each once. If it runs out, it stops offering Bitcoin. This is why preparing more addresses belongs in the owner’s routine.

A stolen counter can reveal addresses in that batch, including future ones, but it has no wallet signing key. The full wallet description, which lets other software find all its addresses, stays off the counter.

The instant-sale limits protect a different thing: the value of goods released before payment confirms. They cap that checkout exposure rather than replace the two-key protection for spending the wallet. A sale at the counter explains the difference.

Plan recovery before depending on the wallet

The owner and Key apps lock their keys behind a PIN or passphrase. The tenth wrong attempt wipes the key from that phone. That is a reason to have usable recovery arrangements, not a reason to keep two keys together. A hostile or already compromised phone can defeat protections enforced by its software.

After losing an owner phone, the designed response is to move money to a new wallet and set up the counters again. The automatic “Move to a new wallet” feature is not built. Restoring the Key app from key 2’s words starts a fresh app with its initial ceilings and no enrolled destinations.

The planned recovery kit is a printed page of public wallet information, key locations and recovery steps, not a page of secret words. Other wallet software can use its wallet description to locate the funds. Two keys are still needed to spend. The Key app can check a scanned description, but kit printing is not built and a Sparrow restore has not been tested.

Backups and routine checks describes storage, access for someone acting for the owner, and independent recovery checks. The wallet reference preserves the exact kit fields, scan behavior and test results.

Equipment, daily work and fit

Receiving bitcoin directly changes the owner’s job as well as checkout. The decision depends on whether customers want to use it, the amounts you sell, and whether you want to manage the money yourself.

Today OpenBMT is pre-release and unsuitable for real-funds use. The considerations below help evaluate the design; they do not make it ready for a live shop.

The equipment

The separate Key app on a spare phone is the default second signer. Hardware wallets and an offline computer are alternatives in the design, but hardware signing has not been tried on real devices. The current release-signing weakness makes a hardware or different publisher’s signer preferable in the design; those alternatives are still unverified. Who controls the money explains that limitation.

A full Bitcoin node is optional. It checks the Bitcoin rules on a computer you run and can give the counter another source of payment evidence. The counter keeps its light check as well. Its own-node connection currently requires a Tor v3 address, a kind of network address reached through Tor. The technical setup is in the network reference.

A Lightning node is a separate, optional responsibility. OpenBMT connects only to a shop-run LND or Core Lightning node, two implementations of Lightning software. You maintain the receiving capacity, updates and backups; OpenBMT does not do that for you. If you do not want to operate one, evaluate the on-chain route and its fees first.

At the start of a day

The counter needs to stay open, connected and powered. The Owner app also needs to be open and linked for instant on-chain acceptance in the current apps. Its regular signed message tells the counter that the owner’s payment watcher is still running. If that check stops, instant acceptance stops too.

Tor sends network connections through a separate routing system to hide the device’s network address from its Bitcoin peers. On Android the apps need a separate app called Orbot to use it. The Owner app always requires Tor. The counter has a switch, but it must use Tor for instant acceptance on a network customers can join. Plan for that dependency rather than expecting a phone on guest Wi-Fi to work unattended.

The counter also needs a supply of addresses approved by both wallet signers. If it uses them all, it stops offering Bitcoin instead of reusing an address. Approving more addresses belongs in the owner’s routine.

During the day

Cashiers create sales, read the payment result and close the POS order. A manager can handle some exceptions within the shop’s limits. Refunds become requests for the owner rather than immediate cashier payments. An owner must be available to deal with a payment-replacement alarm.

Square and Clover support read-only order matching. The cashier still enters the Bitcoin sale and closes the POS order manually. The readers have not been tried with a real seller account, so a shop cannot assume an existing POS will provide a finished automatic connector.

The counter currently quotes prices in United States dollars only. The accounting export also follows United States rules only. A shop needing another pricing currency cannot assume that route is supported.

Outside checkout

The owner reviews queued refunds, cash-outs, address batches and changes that increase risk. These are taken to the separate Key app for review and approval. You can group the work into approval sessions, but the software does not yet remind you to do so.

You also choose whether to keep bitcoin or send it to an exchange. There is no automatic bank payout. The accounting library can produce records and exports, but there is no books screen in the apps yet. Detailed end-of-day instructions are still being written.

Once a month, the design calls for an independent comparison: open a copy of the wallet’s public description in other wallet software and compare its receipts with the POS Bitcoin total. This helps detect a counter or app falsely claiming payment. It does not require giving that other software your spending keys. Backups and routine checks explains the task.

What would make it a plausible fit after release

A shop with customers who already hold bitcoin has a practical reason to consider the extra payment method. The case is stronger when the owner wants direct control of the receipts and can keep separate signing devices, maintain backups and review records.

Sale size matters. A shop selling occasional higher-value items may be able to wait for confirmations. A busy shop selling low-priced goods may find on-chain fees or waiting impractical; its own Lightning node is an option only if it is willing to operate one. These are workflow choices, not a prediction that either route will be cheaper on a particular day.

What would make it a poor fit

OpenBMT is a poor fit if you need a finished system now, automatic conversion and bank payouts, a single device with no separate approvals, or a provider that can restore wallet access for you. It also adds little checkout value if your customers do not want to pay with bitcoin.

If the owner cannot keep up with keys, approvals and reconciliation, the absence of a payment company does not remove that work. It leaves the work with the shop. The status page lists what must still be finished and tested before a live-use decision is possible.

What others can see

Paying with bitcoin does not require the customer to send a name or bank account number with the payment. It still creates a public transaction. Anyone who knows the payment address or transaction ID, its identifying number, can look up the movement of bitcoin and follow links to other transactions.

A customer knows the address used for their purchase. An exchange knows the deposit you send it. A person who connects an address with your shop may be able to learn more than the amount of one sale. OpenBMT limits what it shares, but does not make the shop’s activity invisible.

The main contacts

The network reference lists every contact and the exact data exposed. OpenBMT sends no analytics or crash uploads to its publisher. Push wake-ups and a hosted Box service are not built yet.

A fresh address helps, but is not a private account

OpenBMT uses a new address for each sale. That prevents every customer from seeing all receipts at one reused shop address. The transaction record remains public, and later spending can link the receipts.

Suppose you receive several purchases, then send their bitcoin together to an exchange. That one transaction links the incoming payments. A customer following their own payment, or the exchange receiving the transfer, can see the association. Consolidating small incoming payments has the same effect. The app warns when it offers a merge.

Wallet software can also leave recognizable patterns in the transactions it builds. OpenBMT does not claim to hide which software created its transactions. The fingerprint reference links a detector for readers who want to inspect that issue.

What Tor changes

Tor routes connections through other computers so the destination does not see the phone’s ordinary network address. It does not hide the public Bitcoin transaction. It also does not turn an unconfirmed payment into a reliable one.

The Counter app’s Tor switch covers its Bitcoin and price connections. It is off by default for speed. If customers can join the counter’s network, instant acceptance requires Tor, because a customer on that network could feed the counter false information. The Owner app sends its Bitcoin peer traffic and broadcasts of spends and refunds through Tor, with no switch to turn that off. An explicitly configured local link between shop devices can run directly over the local network.

Both apps need Orbot, a separate Android app, to use Tor. If Orbot stops answering, the Owner app will not start and a counter with Tor enabled will not send around it. This is a real operating dependency: turning Tor on requires keeping Orbot running.

Checking through your own node

A full node checks the Bitcoin rules on a computer you run. OpenBMT can add its report to the counter’s own light check. It does not replace that check or remove the need to wait for confirmations under the shop’s policy.

The current own-node connection requires a Tor v3 address. This address also helps establish that the counter has reached the intended node. The network reference explains the connection restriction and why the counter retains its own chain checks.

Who runs the Box matters

The Box relays messages and reads POS orders. Device messages are encrypted so only their intended recipient can read the contents. The Box has no wallet key, wallet description, address or transaction ID. It can still see order values and timing. Someone else running it can estimate how much the shop sells.

Running it yourself keeps that information inside the shop. The Box can be reached on the local network or through a Tor address. A hosted Box service is not built yet.

Give the accountant the accounting export

The ordinary accounting export uses sale IDs that do not reveal a blockchain transaction by themselves. It excludes wallet addresses, transaction IDs and bitcoin amounts in satoshis. The full ledger does contain those details and is placed behind a warning. Choose the file that fits the recipient’s job rather than sending every wallet detail with the accounts.

The network reference also explains block-request patterns, encrypted peer connections and transaction fingerprints. These are limits on what observers can learn, rather than a promise of anonymity.

Risks and current limits

There are several different ways a shop can lose money. A wallet that requires two keys addresses one of them. It does not protect the value of goods released for a bad payment, eliminate price changes or guarantee that every app behaves correctly.

OpenBMT has had internal review only, with no independent security audit. The Android apps have not been tested on a physical phone. Do not use it with real funds.

The release separation is unfinished

The design aims to prevent one compromised component, device or person from spending the wallet. It depends on key 3 being generated outside OpenBMT and away from the key 2 device, and on an independent second person holding the Key app’s release key.

The second release-key holder has not been named. Reproducible builds and an independent rebuilder are also missing. A bad release could undermine the independence of the signing devices. The single-component protection claim does not hold today. A stronger PIN does not fix that gap. The wallet rule counts keys rather than people: a person with two usable keys can spend.

A small unconfirmed sale can fail

If an $8 payment is accepted before a block and is replaced, the shop may already have handed over $8 of goods. Instant acceptance limits the amount at risk rather than making that payment irreversible.

The exposure budget limits the total currently accepted but waiting for first confirmations. It is not a cap on every kind of loss or a guarantee about a whole trading day. Confirmed payments can still be affected by a chain reversal. Staff overrides also accept risk and are counted.

When a cancellation is detected, the alarm and pause reduce further exposure. They cannot recover goods already handed over. The payment reference gives the exact pause rules, limits and conditions.

A payment report can have incomplete evidence

The counter’s light check asks other computers on the network for payment information. It cannot check every detail that a full node checks, and it cannot inspect all the input amounts or fee of an unconfirmed payment. If all the computers it can reach belong to one attacker, that attacker can shape what it sees.

Using different peers, Tor and the shop’s own node makes interference harder without making it impossible. This is why the counter names the source of a report and why a block confirmation matters. The technical explanation sets out the exact checks it omits.

A bad counter can send sales to the wrong place

A counter can be compromised without stealing a key from the shop’s wallet. It could show an attacker’s payment address and falsely report that the shop was paid. That would steal new sales proceeds rather than spend the existing wallet balance.

Matching POS orders to wallet receipts helps find discrepancies. The design also requires the monthly outside check below, so the shop does not rely entirely on OpenBMT to judge its own records.

A locked phone and a hostile phone are different problems

The app lock slows guessing and can wipe a key after wrong attempts. It does not protect a phone someone can already use unlocked. A rooted phone, hostile keyboard or accessibility service may read typed or displayed information. The Key app refuses some of these conditions, but a malicious build could omit those refusals.

Someone with a locked file and the phone’s Keystore material may also attempt offline guessing or restore an older stored file. The detailed limits are in the wallet reference. Keep recovery arrangements separate; a wipe removes a phone’s key rather than restoring the money automatically.

Devices and supporting software must keep working

Today’s Owner and Counter apps run only while open. Instant acceptance needs them linked, and Tor needs Orbot running. A closed app or broken connection can stop the intended payment flow. The counter must stay open and powered. Some phones provide only software protection for stored keys; the apps report that condition.

The shop also maintains any Box or Lightning node it chooses. These are owner responsibilities rather than a service operated by OpenBMT.

Check the receipts independently

Once a month, the design calls for comparing the wallet’s incoming payments with the POS Bitcoin total using different wallet software. It uses the wallet’s public description in watch-only mode: it can locate and display payments but has no spending keys.

This is the only check independent of OpenBMT’s software, and the only one that catches a counter or main-app build substituting its own address while claiming payment. The estimate is five minutes, which has not been measured. In-app reminders and instructions are planned.

Backups and routine checks explains what must be kept for this check and for recovery. A missing alert or clean-looking screen is not a substitute for reconciliation.

What the tests do not establish

Test-network payment and restore checks show specific parts working with test bitcoin. They do not establish readiness for real funds. Real-phone use, hardware signers, real POS seller accounts, a real Lightning node and Sparrow recovery remain unverified in the ways recorded on the status page and in the detailed inventory.

The project has four internal design reviews. Device testing, outside code review and an independent audit are still required. The detailed threat model also records losses, mitigations and the limits of each.

Backups and routine checks

Direct control of the wallet means the shop has to preserve the information needed to use it. Replacing a phone is only part of recovery. You also need enough keys and the wallet description to find and spend the money again.

These are responsibilities to plan before live use. OpenBMT is still pre-release, has had no independent audit and must not be used with real funds. The setup and recovery walkthroughs remain unfinished.

Keep the secret words and public description separately

Recovery words can recreate a key. Anyone who obtains two of the three wallet keys can spend, so recording two sets together would make one loss or theft affect both. Keys 2 and 3 should have separate steel records, kept apart from each other and from the owner phone.

Record each set alone, without someone watching. Use steel rather than paper for the retained backup. Paper can burn or tear and writing can fade. If paper is needed while stamping steel, compare the steel with the phone and destroy the paper afterward. Do not keep it as a backup.

Key 3 is generated outside OpenBMT, offline and away from key 2. A phone or tablet used for that job is factory-reset afterward. The detailed procedures and current hardware-signer limitations are in the wallet reference.

The wallet description is different. It tells compatible software how to find the wallet’s addresses, but does not authorize spending. The planned recovery kit puts this description, the key locations and recovery steps on one printed page. It contains no secret words. Keep it current, dated and available to the people who may need to act.

The Key app can compare a scanned description with its own. It does not verify every kit field, and producing and printing the kit is not built. Do not assume a successful scan proves that every recovery instruction or key location is correct.

Test that the plan can recover the wallet

A backup that cannot be read or used will not help after a loss. The design calls for a restore test with a small amount before relying on the wallet for more. In today’s pre-release project, money tests belong on a test network, not in real-funds use.

The Bitcoin Core test-network restore passed. A Sparrow restore has not been run. Both are used watch-only for finding the funds: they receive the public wallet description, not the secret keys. A separate signer provides the signatures needed to spend. The eventual kit instructions are held back until the Sparrow test is complete.

Inspect key 3 once a year without exposing its words. Confirm that the steel is still present and readable and that its storage remains appropriate. That inspection is a planned responsibility, not a reminder the app currently enforces.

Compare the records each month

The monthly outside check uses different wallet software to compare incoming payments with the POS Bitcoin total. Watch-only means the software can display activity but cannot spend. This helps catch a bad counter or app claiming the shop received payments that actually went elsewhere.

Bitcoin Core on a computer you run can provide this view; Sparrow is another option in the design. The future guide also needs to explain privacy configuration, so the check does not hand the wallet description or addresses to a public service. Never provide recovery words to a website for a balance check.

The estimated five minutes has not been measured. In-app reminders and instructions are planned. This task still needs a place in the owner’s routine.

Arrange access for someone acting for the owner

Decide who should be able to act and how they could reach two keys and the wallet description. A sealed letter can give locations and contacts without containing the secret words themselves. The recovery kit should be somewhere those people can find it.

OpenBMT cannot reset a key or override the wallet if the owner dies or cannot act. A will or trust is a matter for a lawyer. General inheritance resources and the original self-custody guidance are linked in the precautions reference.

Protect the phones without depending on them as backups

Use at least six digits for a signing app’s PIN or, preferably, a passphrase of at least eight characters. The tenth wrong attempt wipes that phone’s key. Never keep the PIN beside the words. A cashier PIN should differ from the manager PIN, and any PIN known by a former employee should be changed.

Keep the operating system updated, use a screen lock and avoid unrelated apps on the signing phones. Do not sideload apps onto the owner or Key phone. A hostile keyboard or accessibility service can read input; the Key app refuses to run with an accessibility service enabled. A phone already controlled by someone else cannot be made trustworthy by an OpenBMT PIN.

The signing apps exclude their key files from cloud backup and device transfer. Those files depend on Android’s protected key storage on that phone, so copying them to another phone would not provide a usable restore. The spare Key phone should stay in airplane mode with no accounts on it.

Review checkout risk when the shop changes

Set the instant limit to what the shop can afford to lose, not merely the amount that avoids a wait. Zero turns instant acceptance off. Overrides also count toward exposure. If customers can join the counter’s network, instant acceptance requires Tor through Orbot; cellular is another way to keep the counter off their shared Wi-Fi.

For larger sales, choose how many confirmations to wait for. The reference links a confirmation-risk calculator. It does not turn the default limits into measured guarantees. Running a full node adds an independent check; the counter accepts its own-node connection only through a Tor v3 address.

Include approvals and money transfers in the routine

Review refunds, cash-outs, more payment addresses and sensitive settings with the second signer. A new cash-out address must be enrolled on the Key app and wait 24 hours. Cashiers should know that requesting a refund does not pay it immediately.

If the shop keeps bitcoin, the design calls for moving savings to separate long-term storage it controls while leaving working amounts in the shop wallet. Approve those transfers in a session. Combining small incoming payments links them publicly; choose when to do it deliberately rather than treating it as a privacy-neutral housekeeping task.

Give each cashier a name and PIN so records identify who acted. The list is local to the counter phone. There is one manager PIN today; restrict it to the person running the counter.

Know the response to a lost device

Do not split a set of recovery words into extra pieces. The two-of-three wallet already distributes control among three keys. Splitting one key adds pieces that can be lost. The detailed reference discusses Seed XOR and similar tools and links the source guidance.

Check the software you install

Verify the app’s signature and published hash before installation. These checks help establish that you have the file released by the publisher. They do not prove that the released file matches the source code. Reproducible builds and independent rebuilding, which would help check that, are not available yet. The technical design explains this remaining dependency.

Design choices

OpenBMT gives the shop control of its receipts by keeping spending keys and payment checking on shop-run devices. That choice reduces dependence on a payment company and creates work for the owner. The design has to be judged with both effects in view.

Why use separate devices

The Key app checks the transaction it receives; it cannot know whether a customer really deserves a refund. Independent review also depends on the releases and devices being independent. The second release-key holder and reproducible builds are not in place, so the intended protection is not established today. Who controls the money explains the consequences, and the technical overview separates wallet keys, device identities and app release keys.

Why there is no OpenBMT payment account

A hosted balance would put another company’s release of funds between the sale and the shop’s control. OpenBMT instead sends payments to the shop’s wallet. It excludes services able to hold, move, freeze or redirect those funds, or obtain the keys, wallet description or addresses. These remain excluded as optional integrations and future features.

This ruled out co-signed instant payments, whose signer group could freeze funds and see spends. It also ruled out third-party Lightning swaps, whose provider would see the amount, timing and both sides of each swap. The supported Lightning route uses the shop’s own node.

The POS vendor and a chosen cash-out exchange still see their part of the business. Any future optional service that saw metadata alone would have to be off by default, explain the exposure where it was selected, and be listed in Privacy. No such service is offered today.

Why the owner sets the checkout limits

The owner decides the amount the shop can afford to release before a payment confirms. The counter applies that policy; a cashier does not have to judge the Bitcoin network while a customer waits.

Lowering risk can take effect immediately. Increasing it needs the second approval device. Owners can choose keys, a node and waiting periods only within supported combinations. The interface recommends an option and excludes unsafe combinations. These choices and current restrictions are explained in Equipment, daily work and fit.

Bitcoin only

OpenBMT chooses Bitcoin’s monetary rules and the network enforcing them. The bitcoin-only chapter explains that choice, including why independently mined alternatives are excluded. It is a different argument from objecting to a token issuer’s control.

Why the counter names its evidence

An unconfirmed transaction report, a payment in a block and a report from the shop’s own node are different observations. Combining them into one unqualified “paid” claim would hide a decision the merchant needs to understand.

The counter names the check that was done. It uses the shop’s refund depth for “settled” or “final”, without claiming that reversal is impossible. The payment chapter explains the result in cashier terms; the technical reference gives exact screen wording and acceptance conditions, including CR-105 and docs/screens/counter.md.

Why Bitcoin only

OpenBMT is intended for a shop that wants to receive bitcoin directly and keep control of it. That is a choice of money and of the network used to settle payments. It is not a promise that Bitcoin will have the lowest fee or that its price will be stable.

Bitcoin’s rules and the network enforcing them

Bitcoin’s issuance schedule approaches a limit of 21 million. A full node checks that rule itself and rejects a block creating too much, even if miners produced it. Developers can release different software, but cannot make a holder’s existing node accept different rules.¹

A limit written into software is useful only while people enforce it. Payments also depend on miners doing the work that protects settlement and people continuing to hold and accept the currency. OpenBMT regards Bitcoin’s record of enforcing its issuance rules, independent validation and established use as the strongest basis for the money it supports. That is the project’s judgment about a monetary network.²

Other monetary networks

Other currencies can use proof of work, cap their supply and let anyone verify issuance without a central issuer. Those properties do not make the currencies interchangeable. Each network settles its own asset under its own rules.³

Copying Bitcoin’s code or choosing another supply cap does not by itself reproduce the people using Bitcoin, the mining work protecting its current payments or the continued agreement on its rules. A chain split can share the earlier transaction record, then settle a different currency under separate rules. It does not create more BTC on the Bitcoin record.⁴

Verification also has an operating cost. If more transaction data has to be downloaded and checked, running a full node can become more demanding. OpenBMT favors keeping that check practical for the shop.⁵

The project gives more weight to Bitcoin’s monetary rules and independent verification than to another network’s advertised fee or block interval. For small purchases, its supported alternative is bitcoin through the shop’s own Lightning node. For on-chain purchases, the shop can set a minimum sale and decide how many confirmations to wait for.

Tokens, sidechains and mints

An issuer-controlled token adds a dependence on the issuer, which may retain powers over creation, redemption or transfers. That is an additional objection, separate from the choice between independently mined currencies.

The exclusion covers stablecoins, other coins and tokens on every layer, including tokens on Lightning, Taproot Assets and RGB. Using Bitcoin-related infrastructure does not make a different asset into bitcoin.

A federated sidechain such as Liquid asks a group of operators to hold the coins behind its system. An ecash mint such as Cashu or Fedimint holds money while giving users claims against it. OpenBMT excludes those claims as well. These are permanent restrictions, including optional features and later versions.

The technical policy reference explains the transaction-format restrictions and their limits. Those checks implement a Bitcoin wallet; they should not be mistaken for a universal detector of every token protocol.

The shop keeps custody

OpenBMT and Avila Labs hold no shop wallet key or account balance. The phones holding the wallet keys belong to the shop, and a payment does not pass through an OpenBMT company account. That prevents a processor’s payout freeze from locking the wallet’s funds.

It leaves recovery with the shop. Losing two usable keys can make the money unspendable. A bad software release also remains a risk while the Key app’s independent release arrangements are unfinished. The wallet chapter explains both limits.

There is no OpenBMT sign-up

OpenBMT requires no account or identity verification. Devices identify themselves using keys, and staff names are labels entered by the shop. The shop still has its own POS and exchange relationships. Their account and legal requirements remain outside OpenBMT.

Payment addresses come from the shop’s devices

A remote address-selection service could substitute someone else’s address for the shop’s. OpenBMT instead uses addresses approved by the shop’s own devices. The Box cannot select or change them.

It also avoids public address-indexing services, which could learn the shop’s history from its address queries. The counter requests Bitcoin network data without handing peers its shop addresses. Peers can still learn which blocks it asks for or withhold information. The privacy chapter explains that exposure.

No automatic reporting to the publisher

OpenBMT does not upload analytics or crash data. The Key app has no network permission. The other apps make the contacts described in Privacy. To share a crash log, the shop must export it and send it manually.

The operating system or a compromised device can still leak information. The app rules and permission checks have not had independent review.

The owner chooses updates

The apps do not check for and install their own updates, and there is no OpenBMT service that can switch the shop off remotely. Counter commands must come from the shop’s owner and are protected against replaying old commands.

A Box host such as Umbrel or StartOS controls its own updates, which the shop must manage there. The proposed signed release process, installation delay, F-Droid or signed-file distribution and reproducible builds are still planned. Google Play distribution is excluded.

Lightning belongs on the shop’s node

OpenBMT connects only to the shop’s LND or Core Lightning node. It does not choose, run or rent one. A provider holding the channels would control those funds and see payments. Third-party swaps are excluded for the same reason.

Naming or changing the node needs approval through the Key app. OpenBMT cannot establish who actually operates the named node: pointing it at a node run by a hosting company would leave those channels with that operator. The shop must manage liquidity, updates and backups, and the counter integration has not yet been tried against a real node.

The report cannot promise more than the check

An unconfirmed on-chain payment can be replaced. A payment in a block can still be affected by a chain reversal. The counter identifies its evidence and uses the shop’s refund depth for “settled” or “final”. The own-node label requires both the shop’s node and the light check to see the payment. No screen says “fully verified”.

The source remains available

The code, rules and design are published under the MIT licence. The project also restricts dependency licences. A shop can inspect and build the source, although reproducible releases that can be independently checked against it are not built yet. Dependencies, the phone’s operating system and Orbot remain separate software with their own licences and maintainers.

1. Bitcoin Core validation explains full-node enforcement of the supply limit. The Bitcoin FAQ describes voluntary adoption of protocol rules. Read 2026-11-11. ↩

2. The Bitcoin developer guide describes independent validation and proof of work. The Bitcoin FAQ on value explains the role of acceptance and adoption. The judgment about which network OpenBMT should use is the project’s. Read 2026-11-11. ↩

3. Examples of independently mined currencies are described in the Bitcoin Cash protocol documentation and Litecoin proof-of-work reference. Read 2026-11-11. ↩

4. The Bitcoin developer guide on consensus changes explains how incompatible rules can split a chain. The distinction between copying software and reproducing a monetary network follows from those separate rules and participants. Read 2026-11-11. ↩

5. Bitcoin Core’s capacity discussion explains the validation costs involved in increasing capacity and the use of payment channels to reduce on-chain data. Published 2015-12-23; read 2026-11-11. This is a design tradeoff, not a measurement of current node costs. ↩

Technical design and trust boundaries

This section assumes familiarity with Bitcoin transactions, descriptors, multisig and full-node validation. It examines the implementation choices behind the merchant workflow. The merchant guide starts without those prerequisites.

The reference chapters contain exact limits and conditions. The linked rule documents describe individual acceptance and refusal rules, with IDs used in the tests. Where a broader design description is less exact than a rule, the implementation follows the rule document. None of these internal checks constitutes an independent security audit.

Start with the authority of each component

The on-chain threshold is two of three keys, not two people. A person controlling two usable wallet keys can spend, and the script cannot enforce physical device separation. The intended claim about one compromised component also depends on key 3 being generated independently and the Key app’s release key being held by a second independent person. That second condition is unmet. Reproducible builds and an independent rebuilder are also absent. The protocol threshold should not be confused with an established single-component security result.

Wallet keys, device identities and release keys

These are three different kinds of authority:

Device identities use BIP340 tagged signatures and are not derived from wallet keys. The owner phone holds both its wallet account secret and its separate identity secret. The default Key app likewise has an identity and wallet key 2. An approver-only Key app has its identity but no wallet key. Counters and Boxes have identities without wallet keys.

An address batch carries owner-identity and Key-app-identity signatures. A settings change is signed by the owner identity; a loosening change also needs the Key app identity. The session request and response have identity-signed envelopes. A spend inside that exchange separately needs Bitcoin wallet signatures. Calling every signature “key 1” or “key 2” would obscure these different checks.

See session rules, batch implementation and settings implementation.

Descriptor choice and independent recovery

The wallet is native P2WSH sortedmulti, two of three. Account origins use BIP48 script type 2h, and the descriptor represents receive and change with BIP389 <0;1>/* multipath notation. BIP380 provides the checksum.

The schematic below uses placeholders; it is not an importable wallet:

wsh(sortedmulti(2,[fp1/48h/0h/0h/2h]xpub1/<0;1>/*,[fp2/48h/0h/0h/2h]xpub2/<0;1>/*,[fp3/48h/0h/0h/2h]xpub3/<0;1>/*))#checksum

The stored text has a pinned canonical form: full origins, h hardened markers, slot order and checksum. sortedmulti sorts the derived public keys for the script as described by BIP67, so script ordering and stored slot ordering have different jobs. The parser requires distinct master fingerprints and account xpubs and checks network, path and depth.

This choice makes the wallet describable outside OpenBMT. It does not prove compatibility with every signer. The Core test-network restore passed; Sparrow recovery and the actual hardware-signer matrix remain unverified. The wallet reference gives key 3 import checks, recovery-kit fields and the tested import requirements.

Specifications: BIP48, BIP67, BIP380 and BIP389. The implementation’s supported subset is in openbmt-core/src/wallet.rs; support in external software must be tested rather than inferred from a descriptor alone.

The signer independently reconstructs what it can check

The signer accepts a bounded BIP174 PSBT version 0, not an arbitrary transaction proposal or a wallet learned from that proposal. It requires the full previous transaction for every input, derives input scripts from the registered wallet, checks existing signatures and proves change by derivation rather than output position.

Outputs are classified as derived change, active allowlisted destinations or other destinations. A second change-like output counts as another destination. Fees face both absolute and rate ceilings. Satoshi ceilings apply per transaction, rolling day and rolling week, with separate tiers for allowlisted and other destinations.

The signer counts authorized signatures, not chain confirmations. Its rules handle repeated signing and mutually exclusive replacement spends without treating a signed-but-unbroadcast transaction as harmless. New cash-out destinations have a 24-hour activation wait. The clock is local; an unlocked signer with a deliberately advanced clock can shorten that wait.

The library has no network, storage or clock of its own. The caller must persist changes before releasing a signature and must supply the time. The Key app’s PIN, screenshot and accessibility controls are separate app protections. The wallet reference contains starter ceilings and limitations; the signer rules and BIP174 provide the granular format checks.

Address ownership and settings are separate protocols

Counters receive contiguous address ranges and pin the owner and Key app identity roots. Both identities must sign a batch. The Key app checks the wallet ID, counter membership and range, independently derives addresses, and persists its receive mark before releasing the co-signature. A crash may waste an address but must not allow reuse.

The counter persists its address use and exposure before showing their results. An exhausted batch disables Bitcoin rather than reusing an address. The minimum batch is 1,000 addresses, which exposes a useful future range if a counter is stolen. These are availability and privacy costs of operating without a descriptor on the counter.

Tightening takes effect with owner-identity authorization; loosening requires the Key app identity as well. Counters check signed settings, version floors and hard bounds. The first settings count as loosening. The hardware-signer delay fallback is still planned.

Inspect counter rules, session rules and the wallet reference.

Header work and payment evidence have explicit limits

The counter maintains its own header chain, including in Box mode. Mainnet starts at a compiled checkpoint at height 967,680. It checks parentage, required difficulty, proof of work and median time, and selects the best chain by accumulated work. This is a trust anchor and a bounded header implementation, not validation from genesis.

Block inclusion and chain work do not establish that the counter executed scripts or validated the UTXO set. Unconfirmed monitoring cannot prove input values, input confirmation or fee rate. Peer diversity and conflict monitoring reduce some risks; instant acceptance remains bounded risk rather than transaction finality.

The payment reference details checkpoint, proof and storage bounds. The watcher rules, network rules and policy implementation separate evidence collection from the decision to accept a sale.

A relay is not a payment authority

The link encrypts content separately for each recipient with a fresh message key and authenticates the sender’s identity. Message numbering and stored counters prevent replay under the stated persistence rules. Padding reduces message-size detail. None of that makes relayed content true: each recipient still checks the signed object and its policy.

The Box has order amounts and timing even when it lacks addresses and transaction IDs. Tor hides the phone’s address from peers, while BIP324 encrypts peer traffic without authenticating a peer. These solve different problems. The own-node endpoint must currently be a Tor v3 address, and its report must agree with the light check for the own-node label.

See the network reference, link protocol and Box rules.

The dependency and release boundary remains part of the review

The dependency policy lists what enters each shipped component. Some transports and bindings are implemented in the repository to avoid adding external packages. That reduces the package set while leaving more local code to examine; package count alone establishes no security result.

The exact dependency lists, cryptographic libraries, JNI bindings and transport tests are documented in Dependencies. Release independence, device behavior, hardware interoperability and an outside audit remain open on the status page.

Payment rules and screen reference

For a sale explained from the cashier’s point of view, start with A sale at the counter. This reference gives the exact states, limits and acceptance conditions.

Header-chain and proof assumptions

The counter maintains a best-work header chain independently of a Box. WR-04 starts mainnet at compiled checkpoint height 967,680; signet and regtest start at genesis. The watcher refuses Testnet and Testnet4. This network restriction is distinct from the descriptor parser’s support for test-network key encodings.

WR-05 checks parentage, required difficulty, proof of work and median time past from up to 11 earlier headers. WR-06 defers a header more than two hours ahead of the supplied clock. WR-07 selects cumulative work, not block count; equal work does not displace the current best chain. Side branches have depth and count bounds: within 2,016 of the tip and at most 4,032 stored headers beside the best chain. These are actual acceptance limits, not a claim that a deeper reorganization is impossible.

The stored form retains the best-chain headers, not side branches, with a maximum of 2,000,000 headers beyond the start block (WR-08). It does not prune that chain or advance its checkpoint automatically. A valid older copy can be rolled back; freshness checks must detect an old tip.

The watcher supports a Box-provided confirmation proof. This describes the verifier, not a claim that the current relay Box runs a full node or chain watcher; full-node integration on the Box is not built. A supplied confirmation proof must anchor into the current best chain. Its BIP37-format partial merkle tree proves the full coinbase transaction at position zero and the full payment transaction at a later position. The checks reject 64-byte non-witness transactions and malformed or unused tree data (WR-10 to WR-16). The coinbase and position checks address ambiguity between transaction leaves and 64-byte internal merkle nodes; a merkle root by itself does not establish those structural facts.

The current proof limit is 64 KiB, marked “to tune” in WR-10, with each supplied transaction at most 400,000 bytes. The tree’s declared transaction count is between 2 and 16,666. Inclusion, header work and those proof checks do not execute the payment’s scripts or validate the UTXO set. Signet headers are checked for work only; this is not signet challenge validation.

Sources: watcher rules and header implementation.

The counter’s sale handling is built and has been tested against Bitcoin Core on a test network. The Android app is a first build and has not been run on a phone.

An on-chain sale, as built

1. Ring up the order in the POS.
2. Enter the amount on the counter’s keypad in the shop’s currency. The POS does not start the counter automatically.
3. Show the customer the payment code. The screen also displays the amount and the address’s first and last characters in large type.
4. The customer scans the code and approves the payment in their wallet.
5. When the counter turns green, close the POS order with the shop’s “Bitcoin” tender.

The code is a standard bitcoin: payment request, so any wallet that reads that format can pay it. Each sale gets a new address, saved before it is displayed (CR-01 to CR-09). If the connection is down, the counter stops offering Bitcoin and asks the cashier to take another payment type (CR-01).

Customers must scan today. NFC tap to pay is not built; the design proposes an NFC tag for Android customers. The manifest checks currently fail the build if an NFC permission appears.

Square and Clover support read-only order matching. The POS closes the order, and the owner phone matches each Bitcoin tender to a counter sale under docs/POS-RULES.md. The amount still comes from the cashier’s entry. Matching can flag a discrepancy but cannot prove that goods were handed over for a payment (section 10 of those rules). Both readers were written from vendor documentation and have not been tried with real seller accounts. A Clover custom tender button and Lightspeed gateway are planned.

The states a cashier sees

A non-final state explains both the reason and the next step. Waiting is blue; it does not use the red warning screen. The complete wording is in docs/screens/counter.md, generated from the code.

The confirmation depth starts at 1 block and the refund depth at 6. You can change either, but cannot set either below 1. The counter recalculates the displayed state from the watcher’s facts each time (CR-10 to CR-12).

Which check saw the payment

The source line tells you who saw the payment, separately from its state:

An own-node report alone is insufficient for the own-node label: the counter’s light check must also see the payment (CR-104, CR-105).

What “instant” means, and the limit that bounds it

An unconfirmed payment can be replaced by its sender. Accepting one means handing over goods before the first block, with a limit on the loss the shop is willing to take.

The initial limits are:

The light check is the default. These figures are guesses marked “to tune”, not measured risk estimates. Limits are enforced in satoshis and displayed in dollars. You can change any of them, including to zero to disable instant acceptance. Raising one needs approval as a loosening change.

Before accepting instantly, the counter checks all of the following (policy, CR-12, CR-50):

• The amount at risk is below the per-sale limit. It uses the greater of the sale amount and the amount received: paying $5,000 for a $10 sale exposes $5,000.
• Its allocated share of the shop’s outstanding budget has room. A payment leaves this total at its first confirmation or through the owner’s action, never by timeout.
• No conflicting spend has been seen for 8 seconds.
• The light check has enough peers in different network groups, some serving compact filters, a current header chain and a sensible clock.
• The owner phone’s signed heartbeat is recent; the initial interval is 10 minutes.
• The order is being paid at the counter, rather than remotely.
• Instant acceptance is not paused. One cancel pauses it for 1 hour. A second within 24 hours disables it until the owner resets it.
• Tor is on if customers can join the shop’s Wi-Fi.

A replaced payment turns the screen red and triggers a loud alarm. Only the owner can clear it. The counter saves a signed record of both the original payment and its replacement.

The light check cannot inspect the inputs or fee of an unconfirmed payment. Different peer groups and conflict monitoring help, but the cap is what limits the shop’s loss from a fake or cancelled payment. A cancel sent privately to a miner becomes visible only when its block arrives. The screen names which check accepted the payment.

The heartbeat detects a dead or disconnected owner watcher. It comes from the same software family and does not protect against a bad build (CR-56). In the current apps it travels through a relay, normally the Box. A newly created wallet has no relay configured, and neither app has a background service. Instant acceptance therefore needs both the Owner and Counter apps open and linked.

The initial settings assume customers can join the Wi-Fi and leave Tor off. Instant stays off until the owner answers that question. There is no public measurement of double-spend rates since full replace-by-fee on which to base the defaults; choose limits the shop can afford to lose.

Confirmations, the refund depth, and the red screen

At the confirmation depth, the screen says “Paid” and “The payment is in a block.” At the refund depth it says “Paid” and “The payment is settled, so a refund can be paid out if the customer asks.” The books count the sale as money only at the refund depth (CR-31).

If the payment is replaced, dropped, or loses its block in a reorganization, the counter shows “Do not hand over goods”. It reports what it observed: “A different payment replaced this one” or “A block that confirmed this payment was replaced”. It does not guess the cause.

A cashier may override a red screen within the per-sale instant limit and daily cap. A manager may override within a dollar ceiling. Each override records the person’s name, time and amount, counts toward the exposure total, and is refused when that total is full (CR-20 to CR-22).

Late and wrong payments

The price is locked for 5 minutes at a time. It refreshes automatically without changing the address. It comes from at least two public sources that must agree; only United States dollars are supported (docs/RATE-RULES.md).

Customers request refunds at the counter. Refunds are paid in an approval session; the walkthrough belongs to the next part of the handbook.

Small sales and the shop’s own Lightning node

An on-chain fee does not scale with the sale amount, so it can be large relative to a small purchase. A Lightning-only wallet also cannot pay an on-chain address. The counter tells customers “This shop takes on-chain bitcoin”.

You can set a minimum on-chain sale. Below it, the cashier must take another payment type (CR-75). There is no minimum by default. Each receipt also costs the shop a fee when spent later, which is another reason to set one.

Alternatively, a shop already running LND or Core Lightning can let the counter display a code with both an on-chain address and a Lightning invoice. A Lightning payment is final immediately at any amount, without the instant limit. This counter integration is built but has never been run against a real node.

The shop must operate the node and manage liquidity, updates and backups. OpenBMT does not do that work. Eclair is unsupported (LN-02), and third-party swap providers are excluded from the payment path.

Wallet rules and recovery details

For an introduction to keys and the shop’s responsibilities, start with Who controls the money. This reference preserves the detailed checks, limits and recovery conditions.

OpenBMT uses a wallet with three keys. Spending requires any two of them, so losing one phone need not lose the money. The protection depends on keeping the keys apart and having the second device check what it signs.

OpenBMT has had internal review only and no independent security audit. The apps have not been run on a phone. Do not use it with real funds.

Key classes and transaction format

Wallet keys and device identities are separate. Device identities sign address batches, settings and approval-session envelopes. Bitcoin spends use the wallet’s signatures. The owner phone stores its owner-identity secret as well as wallet key 1; OA-08’s restriction is that it holds no other wallet signing key. See OA-01 for the two stored secrets.

The Key app has its own identity and, in the default setup, wallet key 2. An approver-only Key app has an identity without a wallet key. Counters and Boxes have device identities but no wallet spending key. App release keys are a third category, controlling which software runs rather than directly satisfying the wallet script.

The signer restricts PSBT fields to the wallet it implements. SR-06 rejects Taproot-related PSBT fields, redeem scripts and preimages. SR-22 still allows a plain P2TR destination script among its output classes: paying a Taproot address does not turn this into a Taproot multisig wallet. Rejecting data outputs and unsupported fields is not a universal detector of every token protocol. Bitcoin-only support is the product policy; the parser implements the stated transaction constraints.

The lock also has two layers. openbmt-lock derives a key from the PIN or passphrase using Argon2id and locks bytes with ChaCha20-Poly1305. The Android app then seals that frame with an AES-256-GCM key in the Android Keystore. The library does not itself count wrong attempts or wipe; those are app responsibilities. Compromise while the app has opened the key file is outside what encryption of a stored file can prevent.

Sources: identity code, owner app rules, signer rules and lock rules.

The wallet: two of three

One key cannot spend. If one key is lost, the other two can move the money to a new wallet. If two are lost, the money cannot be spent. Two keys held by the same person or device are also enough to spend, regardless of the roles assigned in OpenBMT.

The wallet uses native segwit sortedmulti with three different keys (SR-60). Its standard output descriptor can be read by other wallet software. A restore drill rebuilt the wallet and found its payments in Bitcoin Core on a test network; the recovery kit is described below.

The three keys

Write down the words for keys 2 and 3 and store them separately. A phone whose PIN is unknown, with no written words available, counts as a lost key. After losing any key, use the remaining two to move to a new wallet.

Three rules about the keys

A device may neither hold two keys nor cause a second key to sign without that key’s own device displaying and checking the transaction. This is what the design means by “drive” a key. Otherwise, malware on one device could spend the wallet with one routine approval tap. The apps do not offer a setup that breaks this rule.

Key 2 must run different software from key 1. Running the same build on both would let one bad update affect both signatures. The default is the separate Key app, with its own code base. A hardware wallet or another publisher’s signer is also acceptable under the design.

Key 3 must be generated outside OpenBMT. The design allows another publisher’s wallet on the counter tablet before it becomes a counter: put the tablet in airplane mode, generate the key, then factory-reset it. A hardware wallet provides stronger separation. The Key app receives only key 3’s public key and origin by QR code. It never generates or displays key 3’s words; its screen says “do this step alone”.

The Key app rejects a secret key, a single-signature form, or a key 3 that matches key 2 (SR-64 to SR-67). Exactly one key in the registered wallet must match the imported key 3. The app also compares its own slots byte for byte before registration.

These checks do not yet establish independence between the apps’ releases. One publisher signs both apps, and the second, independent holder of the Key app’s release key has not been named. Until that changes, use a hardware wallet or another publisher’s signer for key 2 as the design recommends. The claim that no single component can spend the wallet does not hold today. Risks and current limits explains the launch conditions.

Hardware wallets and an offline computer as key 2 are still planned. Spending with a hardware key 2 has not been tried on real hardware. The Key app can run on a separate phone as an approver. Its refusal to run with debugging or an accessibility service enabled, and its screenshot blocking, are checks in its own software. A malicious build could omit them, and the phone displaying the words could retain them. A hardware wallet reduces that dependence on the phone.

How a key is made

For key 1 in the Owner app and key 2 in the Key app, you can let the device generate a key, use dice or coin throws, or enter words you already hold. The two methods based on throws mix nothing else in, so the same throws produce the same words in other tools. These methods are built but have not been run on a phone. Key 1 has no seed words by default; the design leaves that choice open for review.

Roles: owner, manager, cashier

The counter shows settings read-only and never displays the wallet balance. It enforces the override and refund limits (CR-21, CR-69). Cashier actions need no PIN; manager actions require the manager’s PIN (CR-86). Only the owner can clear a cancel alarm, with a signed command (CR-14).

There is one manager PIN, 6 to 12 digits long. After a wrong attempt, the wait rises from 1 second to 2, 4, 8 and so on, up to 5 minutes. It does not lock the manager out for longer. The counter holds no wallet key and has no wipe.

The counter also keeps up to 30 cashier names, each with a 4 to 8 digit PIN. This list is local, is outside the signed settings, and is lost with the phone (CR-156). It deters casual access. Separate accounts for multiple managers are not built yet.

Loosening needs the Key app; tightening does not

Raising the instant limit, reducing the confirmation depth or increasing a refund cap allows more risk. Adding a counter or Lightning node, or removing a check or alert, does too. OpenBMT calls these changes loosening. Lowering a limit, requiring more confirmations or removing a counter is tightening.

A tightening change takes effect immediately on the owner phone with its owner-identity signature. A loosening change waits in the approval queue. The Key app displays each old and new value and marks its direction; both devices must sign before the change counts. Counters require both signatures. The initial settings count as loosening in every field (AS-27).

Counters also check that the settings version is above the floor recorded at pairing (CR-94). Some bounds cannot be exceeded regardless of who signs: underpayment tolerance cannot exceed 5%; confirmation depth cannot be below one block; the heartbeat interval must be between one minute and one hour; and counter shares cannot total more than 100%.

A hardware key 2 may be unable to sign settings. The design proposes a delay measured on each counter’s own header chain as a fallback, but that is not built. A spare Key app acting as an approver preserves the second signature. Without that approver, settings changes depend on the owner phone alone, which the screens disclose.

The approval session

The Owner app queues refunds, cash-outs, address batches, loosening changes, counter pairings and health checks. Queuing does not move money. When you have key 2 available, open an approval session:

1. Transfer the queue from the owner phone as an animated BC-UR QR code or a file on USB-C or an SD card. BC-UR is also used by Sparrow and hardware wallets. The Key app needs no network connection.
2. Review each item on the Key app and approve or decline it. Undecided items are declined (AS-30).
3. Transfer the signed reply back by QR code or file. The owner phone checks the response, adds wallet key 1’s signature to approved Bitcoin spends and completes the approved operations. The session envelopes and non-spend approvals use device identities.

The Key app has neither sales records nor its own price source. It labels every dollar figure as information from the owner phone. Its spending limits are therefore in satoshis, and it checks the transaction itself. For every spend it requires:

• A plain version-0 PSBT containing the full previous transaction for every input. This lets it check the input amounts (SR-01, SR-10).
• Inputs belonging to the registered wallet, checked by deriving their scripts (SR-12).
• Outputs consisting only of change it derived, allowlisted destinations, or other destinations within its ceilings (SR-20 to SR-22).
• A change index within 20 of the highest index it has signed (SR-34).
• Fees below both its rate and absolute ceilings. Each ceiling has a fixed bound another device cannot change (SR-40 to SR-42).
• Amounts within its per-transaction, daily and weekly ceilings (SR-35, SR-36).

The initial ceilings are guesses marked “to tune” (SR-38):

They can be changed only on the Key app’s own screen. To enroll a cash-out destination, scan the exchange’s deposit code with the Key app’s camera, then wait 24 hours on that device’s clock (SR-30).

The Key app counts signatures rather than confirmed spends. It may count more than was actually spent, but cannot undercount (SR-33). It cannot check the owner phone’s claim that a refund is for sale 123 or is no more than the customer paid. The ceilings limit the cost of a false claim.

Someone with the unlocked Key app device can move its clock forward and end the destination wait early. A malicious Key app build could ignore all its checks. The separate release key, independent holder, reproducible builds and independent rebuilder intended to address that risk are not in place yet.

Weekly or monthly approval reminders are not built. The Owner app runs only while open and does not send notifications.

Address batches

The counter receives a contiguous range of addresses without receiving the wallet description. The owner phone signs the batch with its identity key. The Key app derives the addresses from its own wallet copy and co-signs with its identity key. The counter accepts only a batch with both signatures and uses each address once. If none remain, it must stop offering Bitcoin rather than reuse one.

The Key app saves the highest signed index before releasing its signature. A crash may waste an index, but cannot cause reuse (SR-70, design section 5.1). A batch contains at least 1,000 addresses (CR-96). Every address shown remains watched for late payments.

The counter reads the two roots from the Key app’s own screen and pins them at pairing. It then generates a fresh random number. The counter displays four words derived from those roots, the wallet, the counter’s key and the random number. The owner compares them with the words on the Key app. The words carry 44 bits and undergo about a million hashing rounds; they help a person check the pairing. The software also compares full hashes (CR-91 to CR-98).

A stolen counter exposes the addresses in its batch, including future ones. This can reveal incoming payments and their timing, but does not reveal the wallet’s history, keys or access to its funds.

The instant limit and the exposure total

An unconfirmed payment can be replaced. The per-sale instant limit and shop-wide exposure budget cap how much the shop accepts before the first block. A sale at the counter gives the defaults and acceptance checks. These limits bound losses from failed instant sales; they cannot prevent every failure.

The design also proposes a screen saying “If every instant sale failed you would lose at most $X”, where X is the exposure budget plus the override ceilings. That combined total screen is not built yet.

When a phone is lost or stolen

The owner phone holds only key 1. A thief needs a second key to spend. Its key file is protected by a PIN of at least 6 digits or a passphrase of at least 8 characters. Argon2id uses 64 MiB and 3 passes, together with an Android Keystore key. The key files are excluded from cloud backup and device transfer.

Wrong attempts are recorded in a separate file. After the fifth wrong attempt, the next try must wait 30 seconds. Further wrong attempts increase the wait to 1 minute, 5 minutes, 15 minutes and 1 hour. The tenth wrong attempt wipes key 1 from the phone. The screen explains that the other two keys can still spend and gives the next steps (LC-01 to LC-06, OA-60 to OA-65).

After losing the owner phone, move all funds to a new wallet with a new key in that slot. The designed “Move to a new wallet” button, sweep and counter re-pairing are planned. Today, the Key app treats a different wallet as a fresh setup with empty state (SR-63).

The spare phone has the same lock and wipe (SR-71 to SR-77). Restore key 2 from its written words to a new Key app. This starts with no destinations, the initial ceilings and indexes at zero. All signing rules still apply (SR-39); recovery has no mode that loosens them.

A lost counter holds neither a signing key nor the wallet description. Remove it from the owner phone, which is a tightening change, and pair a replacement. Its pairing record and manager PIN file are sealed with the Android Keystore.

A six-digit PIN has a million possible values. A computer with the locked file could try them at the cost of Argon2 for each attempt. The additional Keystore key requires the phone, and the app wipes after ten wrong tries (LC-07, “What these rules do not do”). The app reports a software-only Keystore when the phone has one. These controls depend on the software running as intended: a rooted phone or hostile keyboard or accessibility service can read what is displayed or typed.

The recovery kit

The proposed kit is one printed page with the wallet description and its checksum, four checksum words, the first block height, an explicit address range to import, “any two of three”, key locations and holders, and restore instructions. It contains no secret keys or seed words.

The Key app can scan the printed description and compare it byte for byte with its own. A different description with matching four words gets the most serious warning. This check is built but has not been run on a phone; it does not check the kit’s other fields. Generating and printing the kit is not built.

The Bitcoin Core restore drill passed on a test network. It established four requirements for the eventual instructions: import the specified address range rather than a default; mark the receive descriptor inactive; request version-0 PSBTs; and give the signer wallet the same range. Core finds the coins and builds the transaction without reading seed words. A separate signer that reads the words signs it.

The Sparrow restore has not been run. The kit’s restore instructions are withheld until that test is done. An annual physical check that key 3’s words remain present and readable is also in the design, not the software.

Operating precautions

OpenBMT is pre-release and has had internal review only. No independent security audit has been done. Do not use it with real funds.

For general self-custody guidance, see https://btcmaxis.com/. The pages linked here were read on 2026-11-11. Some procedures below remain part of OpenBMT’s design rather than controls the software enforces.

Keys

Keep key 1 on the owner phone, key 2 on a separate phone or hardware signer stored away from it, and key 3 away from the shop. Any two can spend. Storing two together removes the protection against losing or compromising one location.

Record each set of words alone, in separate sittings with nobody watching. Never keep key 2’s words with key 3’s. Use steel. Paper burns and tears, and writing can fade. As the linked guidance puts it, “Paper is not an acceptable form of backup because it is so fragile” (https://btcmaxis.com/bitcoin-information/recommended-wallets.html, read 2026-11-11). If paper is needed while stamping the steel, compare the steel with the phone, then destroy the paper. Do not retain paper as a backup.

Generate key 3 outside OpenBMT, offline, on a device holding no other key, or use a hardware wallet. Factory-reset a phone or tablet used for this step afterward.

Until an independent second person holds the Key app’s release key, prefer a hardware signer or another publisher’s signer for key 2. Hardware signers are planned and have not been tried. Before choosing one, read its public disclosure history. The “Historic Wallet Failures” list on the recommended-wallets page collects reported hardware-wallet flaws (read 2026-11-11).

Keep a current, dated recovery kit with the wallet description away from the shop, and check the description by scanning it with the Key app. Kit printing is not built yet. Once a year, inspect key 3 without exposing the words: check that the steel is still present, readable and safely kept.

PINs

Use at least six digits for the locks on keys 1 and 2, preferably a passphrase of eight characters or more. The tenth wrong attempt wipes the key from that phone. Never keep a PIN beside the words.

Cashier PINs should differ from the manager PIN. Change any PIN a former employee knew.

The phone

Keep the operating system updated and the screen lock enabled. Install apps only from known sources; do not sideload apps onto the owner or Key phone. A hostile keyboard or accessibility service can read input. The Key app refuses to run with an accessibility service enabled.

Keep the spare phone in airplane mode with no accounts on it. Leave cloud backup off for the apps. They deliberately exclude key files: each is wrapped with a key in that phone’s Keystore, so its copy could not be opened on another phone.

Tor and the shop’s own node

If customers can join the counter’s Wi-Fi, enable Tor or use cellular instead. Instant acceptance on a shared network requires Tor. The apps need Orbot running to use it.

Run your own node if you can. The counter accepts it as an own-node check only through a Tor v3 address.

The instant limit

Set the instant limit to an amount the shop can afford to lose. The default light-check limits are first guesses. Zero disables instant acceptance and makes the sale wait for a block. Overrides also count toward the exposure total.

For a large sale, the Bitcoin Confirmation Risk Calculator linked on https://btcmaxis.com/bitcoin-information/security.html (read 2026-11-11) can help choose how many confirmations to wait for. It does not change what the shop can afford to lose before confirmation.

Seed splitting

Do not split a key’s words with Seed XOR, Penlock or similar tools. The two-of-three wallet already distributes control across three keys. Splitting one adds pieces that can be lost. The linked security guidance advises “keep it as simple as possible” (https://btcmaxis.com/bitcoin-information/security.html, read 2026-11-11).

If the owner dies or cannot act

Choose who should be able to act and make sure they can reach two of the three keys. Keys 1 and 2 are on devices; key 3 is on steel. Leave the recovery kit where those people can find it: the wallet description lets other software locate the funds.

A sealed letter can state where each key is kept without containing the words themselves. OpenBMT has no company that can reset a key or open the wallet. Without access to two keys, nobody can restore it. Ask a lawyer whether a will or trust should name the people who can act.

The security page links inheritance resources: https://btcmaxis.com/bitcoin-information/security.html (read 2026-11-11).

Cash-out and what the shop keeps

If keeping bitcoin, move it regularly from the shop wallet to long-term storage the shop controls. Leave only working amounts in the wallet the counters pay into, and approve the transfers in an approval session.

Enroll a cash-out destination by scanning it on the Key app, then wait 24 hours. Consolidating small receipts links them on the public ledger; do it deliberately, when fees are low.

Staff

Give each cashier a name and PIN so the records identify who acted. The cashier list is local to that counter phone. There is currently one manager PIN; give it only to the person running the counter.

If a phone is lost

Test recovery first

Test restoration with a small amount before depending on the wallet for more. A Bitcoin Core restore has been run on a test network; a Sparrow restore has not. Both are used watch-only: the keys never go into them. The linked guidance advises newcomers against putting keys in a node’s built-in wallet.

Each month, open the wallet description watch-only in Sparrow or Bitcoin Core and compare the receipts with the POS Bitcoin-tender total. This checks the records using software outside OpenBMT.

Verify what you download

Check the app’s signature and published hash before installation. Reproducible builds are not available yet. The hash establishes that you have the file the publisher released; it cannot establish that the build matches the source.

Network checks, risks and policy details

For the information a merchant needs before choosing a setup, start with Privacy and Risks. This reference describes network behavior and the detailed threat model.

Sealed messages and identity authentication

Application messages carry their own signatures and policy checks. The link adds confidentiality, sender authentication and replay handling; it does not turn the contents into trusted payment evidence.

For each message, the sender generates a fresh one-time secp256k1 key and uses ECDH with the recipient identity. HKDF-SHA256 derives a new ChaCha20-Poly1305 key, binding the one-time public key and both identities. The nonce is zero because the key is one-use. That construction requires fresh, unpredictable ephemeral secrets; nonce reuse under a repeated key would violate the design’s premise (LK-02, LK-03).

A BIP340 tagged signature authenticates the header and ciphertext hash. The header binds recipient, sender, message number, kind and one-time key. A recipient checks the frame, identity authorization, signature, message number, decryption and padding before returning contents. It persists the new last-seen message number before delivery. Gaps are allowed, but old numbers and jumps more than 2^32 above the last are refused.

Padding buckets are 256, 1,024, 4,096, 16,384 and 65,536 bytes. A relay can see sender and recipient identities, message kind and padded size, even without plaintext. Those device identities are separate from wallet keys and payment addresses. The Box’s order-reader role additionally reveals order amounts and timing.

The full wire forms and message authorization matrix are in Link rules, with sealing code.

Network privacy

A Bitcoin payment need not carry a customer’s name, but its transaction is public. An address or transaction ID can let someone connect that payment to other activity. OpenBMT keeps these details out of the POS and ordinary accounting exports, and does not upload analytics or crash data.

This network behavior is built. It has been checked against Bitcoin Core and observed on test and live networks. The apps have not been run on a phone.

Who sees what

The counter never sends a shop address or script to a Bitcoin peer (NR-60). It requests compact block filters, then whole blocks when a filter matches. This reveals interest in those blocks. While waiting for a payment’s first block, it also downloads every new block in full: a cancelling spend is absent from the filters it could match (NR-44). These requests do not completely conceal which blocks interest the shop (NR-61).

Tor

With the counter’s Tor switch on, all connections, including Bitcoin peers and price sources, go through Orbot. Orbot is a separate Android app and must be running. If it is unavailable, the counter reports the problem and sends nothing around it (CR-87).

The Owner app sends its Bitcoin peer traffic and spend or refund broadcasts through Tor, and will not start if Orbot is not answering (OA-05). Its behavior does not depend on the counter’s switch. An explicit direct local link route is not sent through Tor.

The counter switch is off by default for speed. If customers can join its network, instant acceptance requires Tor, because a customer on the same network could feed the counter false data.

Peers use encrypted BIP324 transport when they support it. This conceals requests from a passive listener but does not establish the peer’s identity (NR-62). Tor hides the device’s address from peers; it does not hide that the traffic belongs to a Bitcoin wallet (OA section 9). Onion peers are grouped coarsely, so two onion peers do not establish two independent operators (docs/NETWORK-RULES.md, section 8).

The shop’s own node

You can run Bitcoin Core on a Box, Umbrel, StartOS or a computer at home, and have the counter check payments against it. The node adds a check; it does not replace the counter’s light client.

The current counter accepts an own-node connection only at a Tor v3 address. The address authenticates the node through its public key. A local-network address or plain internet address is not enough to establish who answers, so it is not accepted as the own node (NR-98, NR-99, CR-100 to CR-102). The counter retains its own header chain from random peers, preventing a Box from inventing a confirmation.

The Box

The Box relays sealed messages between the shop’s devices, reads the POS and matches orders to sales. It can be reached on the local network or through an onion address. Only the recipient can read a relayed message.

It sees order amounts in the shop’s currency and their timing, as the POS vendor does. It holds no wallet key and sees no address, transaction ID or wallet description (BX-04, BX-40). A host can nevertheless estimate payments by combining the orders with a public Bitcoin price. Run the Box yourself to keep that information inside the shop (docs/BOX-RULES.md, section 6).

The books and the export

The accountant’s export contains opaque sale IDs. It excludes transaction IDs, addresses and satoshi amounts, as do all POS fields, because those would let the recipient trace payments on the public ledger. The full ledger contains those details and is shown behind a warning.

Spending several receipts in one transaction links them on the blockchain. Someone who paid the shop, or an exchange receiving the spend, can then see that the receipts belong to one wallet. Consolidating receipts has the same effect. The app warns when offering a merge (design section 9).

Wallet fingerprints

Transactions can also reveal which wallet software built them. OpenBMT does not claim to hide that fingerprint. A wallet fingerprint detector is listed at https://btcmaxis.com/bitcoin-information/privacy.html (read 2026-11-11).

Limits and risks

OpenBMT has had internal review only and no independent security audit. None of the Android apps has been run on a phone. Do not use it with real funds.

What the protection claims, and when it does not hold

The wallet design aims to withstand one compromised OpenBMT component without allowing a spend. The script itself enforces two keys, not two distinct people: a person controlling two usable keys can spend. Device and holder separation are operational conditions. The design also requires both of these launch conditions:

1. Key 3 is generated outside OpenBMT software and away from the key 2 device.
2. An independent second person holds the Key app’s release key.

The first is part of the setup design. The second is unmet: no second holder has been named. Reproducible builds and an independent rebuilder are also launch requirements and are not in place. The single-component protection claim does not hold today; the documents and screens say so.

Even with those conditions met, protecting the wallet does not prevent every loss at the counter. Limits bound the exposure of sales proceeds and goods, and the owner must reconcile records to catch a bad counter, app build or Box.

The threat model in plain words

What the light check cannot see

The light check asks Bitcoin peers directly. For an unconfirmed payment, it cannot inspect input amounts, establish whether the inputs are confirmed, or calculate the fee rate. It monitors conflicting spends and requires different peer network groups. It does not execute scripts or check each transaction’s coins within a block (docs/WATCHER-RULES.md, section 8). Confirmation depth is therefore a choice about how much work must accumulate above the payment.

An attacker controlling every reachable peer controls what the counter sees. Distinct network groups, stored long-lived peers and Tor make this harder without ruling it out (docs/NETWORK-RULES.md, section 8).

On signet, the header check verifies work only. Test-network results do not establish protection for real funds.

What the PIN does not stop

The phone’s key file is locked behind the PIN, and guessing is slowed. That does not protect against someone using an unlocked phone, restoring an older stored file, or obtaining both the file and the Keystore material needed for offline guessing.

A rooted phone, hostile keyboard or accessibility service can read input or displayed data. The Key app refuses to run with debugging or an accessibility service enabled, but that refusal is enforced by the app itself. A cashier PIN on the counter deters casual access only.

Phone and hardware risks

The apps run only while open. The Owner app does not follow the chain when closed, and the counter must stay open and plugged in. The Owner and Counter apps need Orbot, a separate Android app, to use Tor. Some phones offer a software-only Keystore; the app reports this on screen. The design assumes the phone is not already controlled by an attacker.

Android versions may handle wallet opening from an NFC tag differently. Tap to pay is not built and this behavior is untested.

Unverified items

The monthly outside check

Once a month, open the recovery kit’s wallet description as watch-only in Sparrow or Bitcoin Core. Compare the receipts with the POS Bitcoin-tender total. This is the only check independent of OpenBMT’s software, and the only one that catches a counter or main-app build substituting its own address while claiming payment.

The estimate is five minutes; it has not been measured. In-app reminders and instructions are planned.

The audit status

The four internal design reviews examined remote theft, insiders, hostile customers, wallet engineering, privacy, adversarial behavior and recovery. They also checked single-component compromise and compared the first implementation with the design. They were not an independent audit.

Device testing, outside code review and an independent security audit remain necessary before OpenBMT can be considered for real funds.

What OpenBMT will never do

These restrictions apply to future versions as well as the current design. Some depend on release safeguards that are still unfinished; those limits are stated here. The design choices explain how they shape the checkout system.

Never anything but bitcoin

OpenBMT accepts BTC on the Bitcoin network, and bitcoin over the shop’s own Lightning node. Other currencies, stablecoins and tokens on any layer are excluded.

Why Bitcoin

OpenBMT’s starting point is money whose supply the holder can verify and whose rules do not depend on an issuer’s discretion. Bitcoin’s issuance schedule approaches a limit of 21 million. A full node checks that schedule itself and rejects a block that creates too much, even if miners produced it. Developers can publish different software, but cannot make a holder’s node accept different rules.¹

A supply limit is useful only while people enforce it. The currency also needs miners doing the work that protects settlement and people willing to hold and accept it. OpenBMT regards Bitcoin’s record of enforcing its issuance rules, independent validation and established use as the strongest basis for money. That judgment is why the project builds on this network; a supply cap or proof-of-work algorithm alone is not enough.²

Other monetary networks

Other currencies can also use proof of work, cap their supply and let anyone verify issuance without a central issuer. Those properties do not make the currencies interchangeable. Each network settles its own asset under its own rules.³

Copying Bitcoin’s code or specifying another supply cap does not by itself reproduce the people choosing to use Bitcoin, the mining work protecting its current payments, or their continued agreement on its rules. A chain split can share the earlier ledger, but the networks follow separate rules and settle different currencies after the split. Creating those currencies does not create more BTC on the Bitcoin ledger.⁴

Independent verification also depends on what it costs to run a node. More transaction data has to be downloaded and checked; increasing base-layer capacity can make that work more demanding. OpenBMT favors keeping verification practical for the shop.⁵

OpenBMT gives greater weight to preserving Bitcoin’s monetary rules and independent verification than to a different chain’s block interval or advertised transaction fee. Lower fees alone are not a reason to ask the shop to receive another currency. For small purchases, the supported alternative is bitcoin through the shop’s own Lightning node. For on-chain payments, the shop can set a minimum sale and choose how many confirmations to wait for.

Tokens, sidechains and mints

An issuer-controlled token introduces another objection: its issuer may retain powers over issuance, redemption or transfers. Those powers create a dependence on that issuer, in addition to the reasons for choosing BTC over another currency.

The exclusion includes tokens on Lightning, Taproot Assets and RGB. A token carried over Bitcoin-related infrastructure is still a different asset. Federated sidechains such as Liquid require a federation to hold the coins, and ecash mints such as Cashu or Fedimint hold money while issuing claims against it. OpenBMT does not accept those claims as payment.

The wallet is native segwit, two of three (SR-60). The Key app rejects data outputs, non-standard scripts and inputs containing Taproot fields (SR-22, SR-06). These format checks implement the supported wallet; they are not a general detector of all token protocols. Lightning accepts bitcoin invoices from the shop’s own node only (LN-01). The checks follow the currency choice described above.

Bitcoin still has price risk and fees. Choosing it does not establish a stable purchasing power or remove the payment risks described in A sale at the counter. The exclusions are not trials or features waiting for a later release.

Never custody

Neither OpenBMT nor Avila Labs holds a shop’s wallet key or balance, and there is no hosted wallet. A processor’s failure, sanction or account freeze therefore cannot lock up money held in the shop’s own wallet.

The Owner app holds wallet key 1 and its separate owner identity secret; it holds no other wallet key (OA-01, OA-08). The default Key app holds wallet key 2 as well as its own identity. The counter cannot sign a spend. Its refund request is a record, not a payment (CR-60). The Box holds no wallet description, address, transaction ID or key that signs for the shop (BX-04).

The shop takes responsibility for lost and stolen devices; see Who controls the money. Avila Labs will hold app release keys, which are separate from wallet keys. A malicious app release remains a risk: the Key app is separate, but its independent release-key holder has not been named.

Never an account or an identity check

OpenBMT requires no sign-up or KYC. An account could be closed, frozen, subpoenaed or breached, and software that holds no funds for a shop should not need its identity.

A device identifies itself with a key it generates. Staff names on the counter are labels entered by the shop, without identity verification (CR-156). There is no OpenBMT account or payment server.

The shop still deals with accounts at its POS vendor and chosen exchange. Those companies have their own sign-up and checks. OpenBMT neither asks for those accounts nor sees them.

Never a third party deciding where money goes

Only the shop’s devices can choose its payment addresses. A counter accepts address batches signed by two separate devices, checked against the roots pinned at pairing (CR-02, design section 5.1). It cannot make an address of its own, and the Box cannot choose or alter one (BX-04). An address-selection server would have the power to substitute a thief’s address.

OpenBMT also excludes public Electrum and Esplora indexers. Giving one the shop’s addresses would reveal its sales and let the server link them. The counter instead requests compact block filters and blocks without sending an address or script (NR-60).

Peers can still observe which blocks it requests or withhold information. Several peers from different network groups make interference harder, but cannot eliminate it. The counter reports when it lacks enough information (NR-61; docs/NETWORK-RULES.md, section 8).

Never telemetry, analytics or crash upload

OpenBMT does not send the publisher the shop’s sales activity. The Key app has camera permission only, with no network permission; a build check fails if its manifest changes. The Counter and Owner apps have network permission only for the contacts listed in the design: Bitcoin peers, price sources, POS reads, and the shop’s own Box and node. The Owner app itself opens no connection beyond the proxy greeting and till read (OA-15). Privacy lists all contacts.

These rules and manifest checks have not had outside review. They cannot control a compromised device or an operating system that leaks data. To share crash information, the shop must export a local log and send it manually.

Never automatic updates, and never a remote switch

The owner must choose to install an update. Automatic installation would let the publisher, or someone taking over its releases, change the shop’s devices without that choice. The apps have no update check and no background service, receiver or provider to run one; each app’s manifest check verifies this.

There is no OpenBMT service for a remote switch. Counter commands require the owner phone’s signature and sequence numbers that prevent replay (CR-14).

The Box ships as a container without an updater. Its host, such as a mini PC, Umbrel or StartOS, controls its own update behavior. The shop must manage that there.

The Key app’s proposed signed release manifest, install-date delay, F-Droid and signed-file distribution, and reproducible builds are planned. Google Play distribution is excluded.

Never a Lightning service provider holding the shop’s channels

Lightning connects to the shop’s existing LND or Core Lightning node. OpenBMT does not run, rent or select one (design section 8). A provider holding the channels would hold the money and see every payment. The same reason excluded third-party swaps.

The node’s public key is in the signed settings. Naming or changing it needs the Key app’s co-signature, and each invoice must be signed by that key (LN-03, LN-17). Setup checks that the counter’s credential permits invoices only (LN-04 to LN-20).

OpenBMT cannot establish who actually operates the named node. If the shop chooses a hosting company’s node, that company holds its channels. OpenBMT offers no such provider. Setup explains that the shop must manage liquidity, updates and backups. The counter integration is built but has never been run against a real node.

Never calling an unconfirmed payment final

An unconfirmed payment can be replaced by its sender. The fixed counter states (CR-10) therefore show “Paid” with “it could still be undone” when accepting before a block. A payment is confirmed at the shop’s confirmation depth; “final” refers only to its refund depth. The books count it as money at that refund depth (CR-31). More blocks reduce the chance of reversal without making it impossible.

Each screen identifies its check (CR-105). The own-node label requires both the shop’s node and the counter’s light client to see the payment (CR-104). OpenBMT will not say “fully verified” without a report from the shop’s own node.

Never closed source

The code, rules and design are published under the MIT licence in LICENSE. A shop should be able to read the source, build it and check what it is being asked to install. The dependency policy accepts only licences on its published list (docs/DEPENDENCIES.md, rule 6).

Dependencies retain their own licences. OpenBMT does not publish the phone’s operating system or Orbot, the separate app needed for Tor. Reproducible builds, which would let someone check a released app against the source, are not built yet.

1. Bitcoin Core validation explains full-node enforcement of the supply limit. The Bitcoin FAQ describes voluntary adoption of protocol rules. Read 2026-11-11. ↩

2. The Bitcoin developer guide describes independent validation and proof of work. The Bitcoin FAQ on value explains the role of acceptance and adoption. The judgment about which network OpenBMT should use is the project’s. Read 2026-11-11. ↩

3. Examples of independently mined currencies are described in the Bitcoin Cash protocol documentation and Litecoin proof-of-work reference. Read 2026-11-11. ↩

4. The Bitcoin developer guide on consensus changes explains how incompatible rules can split a chain. The distinction between copying software and reproducing a monetary network follows from those separate rules and participants. Read 2026-11-11. ↩

5. Bitcoin Core’s capacity discussion explains the validation costs involved in increasing capacity and the use of payment channels to reduce on-chain data. Published 2015-12-23; read 2026-11-11. This is a design tradeoff, not a measurement of current node costs. ↩

What is built and tested

OpenBMT is pre-release. Internal review only. No independent security audit has been completed. Do not use it with real funds.

The handbook describes a design and the code built so far. A successful software test does not establish that a shop can rely on the whole system. The Android apps have started on an emulator but have not been tried on a physical phone.

How the status terms are used

A test network uses test bitcoin rather than money for live purchases. Bitcoin Core is a full-node implementation used in the project’s engineering tests. The current results are not an independent audit.

Current components

Four internal design reviews are complete. Device testing, outside code review and an independent security audit remain necessary.

Guides still to be written

The step-by-step guides for choosing keys and the key ceremony, counter setup, the Box, POS integration, daily use, refunds, end-of-day books, cash-out, hardware signers, troubleshooting and development are unfinished. The merchant chapters explain what the work involves so you can assess it; they are not a substitute for those tested setup instructions.

Fee figures, tax details and sources

For the costs explained in shop terms, start with Costs and cashing out. The figures and United States tax information below are dated source material, read on 2026-11-11.

A shop accepting bitcoin directly receives the payment in its own wallet, without a processor taking a percentage or controlling the payout. It also takes responsibility for its keys, network fees and the value of the bitcoin it keeps. Whether this is useful depends on the shop’s customers and costs. OpenBMT does not recommend buying or holding bitcoin as an investment and makes no price prediction.

Processing and network fees

A $20 card sale on Square’s United States Free plan costs $0.67: 2.6% of $20 is $0.52, plus $0.15. At 1,000 such sales a month, that is $670 a month or $8,040 a year, before dispute or payout fees.

Square’s pricing, read on 2026-11-11, lists:

Stripe’s page, read the same day, lists 2.9% + 30 cents for a domestic online card payment, another 1.5% for an international card and another 1% for currency conversion.

An on-chain payment to an OpenBMT wallet has no processor fee. The customer pays to send it; the shop pays a network fee when it later spends the receipt, cashes out or consolidates receipts. That fee depends on transaction size and the current fee rate rather than the sale amount.

On 2026-11-11, mempool.space listed a fastest rate of 4 satoshis per virtual byte. A spend from one receipt in the shop’s two-of-three wallet to two outputs, payment and change, is 201 virtual bytes: 804 satoshis at that rate. The size is calculated from the weight rules in BIP 141. Each additional receipt spent adds 104.5 virtual bytes (design section 9).

During a fee spike, spending a small receipt can cost more than it is worth. A shop can set a minimum on-chain sale or use its own Lightning node for small purchases, avoiding a separate on-chain receipt for each sale. Lightning has routing fees: the mempool.space snapshot of 2026-08-30 showed a median channel charge of 500 millisatoshi plus 100 parts per million. Check https://mempool.space/ for current rates. A sale at the counter describes both options.

Disputes and refunds

Card disputes can reach well beyond the day of sale. The Visa Core Rules, 24 October 2026 edition, allow a card-fraud dispute up to 120 calendar days after processing. For goods or services not received, the period runs from expected delivery and ends no later than 540 days after the transaction.

Stripe charges $15 when a dispute arrives and retains it even if the merchant wins. Countering costs another $15, returned only on a win. The disputed amount is held for the process, which Stripe says can take 2 to 3 months. Square lists no dispute fee, but holds the funds immediately and keeps its processing fee when the payer wins.

A payer or bank cannot pull back a bitcoin payment confirmed in a block. A refund requires the shop to send a new payment. A chain reversal remains possible, becoming less likely as blocks accumulate; no depth makes it impossible.

Before confirmation, the sender can replace a payment. Above the instant limit, OpenBMT waits for a block. Below it, the shop accepts the risk that a customer could cancel during the roughly ten-minute wait, with the loss bounded by the limit. See A sale at the counter for the checks and exposure budget.

Payouts and reserves

Card processors can hold funds under their published terms:

• Square can delay payouts during chargebacks, withhold funds or require a reserve. Its rolling-reserve page names advance payment before delivery, high dispute rates and a lack of processing history as factors.
• PayPal can place a reserve on a business account at any time. A risk-based hold generally lasts up to 21 days, and a balance can be held for up to 180 days. Its rolling-reserve example holds 10% of payments for 90 days.
• Stripe says reserve funds cannot be paid out or transferred.

Square’s default payout is the next business day; instant transfer costs 1.95%. Stripe’s standard United States payout is 2 business days after payment; instant payout costs 1.5%.

OpenBMT receives the money in the shop’s wallet. There is no payout to request, and no company holds a wallet key or has a switch to stop receipt. A company cannot freeze that wallet. The shop must keep its own access: losing two keys makes the money unspendable, and approving a bad spend cannot be reversed. The wallet chapter and Backups and routine checks explain the precautions.

Merchant accounts

A card merchant applies to a processor, supplies identity and bank details, and accepts its terms. The processor decides whether to serve the shop and can later close the account.

OpenBMT needs the shop’s phones and, optionally, a Box. There is no sign-up, identity check or company approval. The shop’s tax, licensing and trade obligations still apply. What OpenBMT will never do explains the account policy.

Supply and price

The Federal Reserve states a goal of “inflation of 2 percent over the longer run”, measured by the personal consumption expenditures price index (read 2026-11-11). At that rate, a dollar held for ten years buys about 18% less: 1 / 1.02^10 = 0.82. Higher inflation would erode it further.

Bitcoin’s block reward began at 50 bitcoin and halves every 210,000 blocks, about four years. Total issuance therefore cannot reach 21 million. Bitcoin Core computes this in GetBlockSubsidy in src/validation.cpp, using the interval in src/kernel/chainparams.cpp. Full nodes reject blocks that pay too much. An operator who keeps the existing rules continues to reject excess issuance; publishing different rules cannot force adoption.

This supply schedule does not stabilize the dollar price. Bitcoin has risen and fallen sharply. A shop holding receipts bears both directions of that movement, and chooses how much to retain or cash out. OpenBMT does not convert the money. Cash-out is an owner-approved transaction to the chosen exchange; its walkthrough will be in the next part.

Running the system

The shop operates its own phones and optional Box, keeping them charged, updated and protected. Small on-chain purchases can be uneconomic; its own Lightning node is an option, but the counter integration has not been tested against a real node. OpenBMT is pre-release and has had no independent audit. Do not use it with real funds.

Fewer customers pay with bitcoin than with cards. OpenBMT makes no claim about adoption numbers. Treat it as an additional payment method when planning for the shop’s customers.

United States tax records

The following is information, not tax advice. Ask a tax professional about your situation. OpenBMT’s accounting export follows United States rules only.

Under IRS Notice 2014-21, Q&A-3 and Q&A-4, bitcoin received for goods or services is income at its dollar fair market value on the day received. That value is also the shop’s basis. The IRS digital-assets page, reviewed 2 September 2026, treats digital assets as property rather than currency. Selling or spending them can create a gain or loss.

Brokers file Form 1099-DA about their customers; a shop does not file it for its own sales. Form 8300 reports cash above $10,000 received in a trade or business. IRS Announcement 2024-4 says digital assets do not count toward that threshold until regulations are published. No final regulation was found on 2026-11-11; check irs.gov for the current rule.

Customers and privacy

A customer holding bitcoin can pay a shop that accepts it. A foreign-issued card carries a foreign-exchange fee; bitcoin has no such fee, while the customer still pays the network fee.

A payment contains no customer name or shop bank details. The wallet description stays on the shop’s devices, and OpenBMT does not give its addresses to a company. Anyone with an address or transaction ID can, however, inspect linked payments on Bitcoin’s public ledger. Privacy describes what the POS vendor and network still see.

Sources

Each page below was read on 2026-11-11.

• Square pricing: https://squareup.com/us/en/pricing
• Square deposits: https://squareup.com/help/us/en/article/3807-deposit-options-with-square
• Square disputes: https://squareup.com/help/us/en/article/3882-payment-disputes-walkthrough
• Square payment terms: https://squareup.com/us/en/legal/general/payment
• Square reserves: https://squareup.com/help/us/en/article/6832-reserves-faq
• Stripe pricing: https://stripe.com/pricing
• Stripe disputes: https://docs.stripe.com/disputes/how-disputes-work
• Stripe balances and reserves: https://docs.stripe.com/payments/balances
• Visa Core Rules, 24 October 2026 edition, section 11.8.2.4 and condition 13.1: https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf
• PayPal User Agreement: https://www.paypal.com/us/legalhub/paypal/useragreement-full
• Federal Reserve, inflation goal: https://www.federalreserve.gov/faqs/economy_14400.htm
• Bitcoin Core block reward: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp and https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp
• IRS Notice 2014-21: https://www.irs.gov/pub/irs-drop/n-14-21.pdf
• IRS digital assets: https://www.irs.gov/filing/digital-assets
• IRS Announcement 2024-4: https://www.irs.gov/pub/irs-drop/a-24-04.pdf
• IRS Form 8300: https://www.irs.gov/businesses/small-businesses-self-employed/form-8300-and-reporting-cash-payments-of-over-10000
• Transaction weight (BIP 141): https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
• Fee rates: https://mempool.space/api/v1/fees/recommended
• Lightning fee snapshot (dated 2026-08-30): https://mempool.space/api/v1/lightning/statistics/latest

Glossary

Address batch. A contiguous range of receive addresses assigned to one counter, signed by the owner and Key app device identities. These are separate from their Bitcoin spending keys.

Approval session. The owner reviews queued items with key 2 available. The owner phone presents them; the Key app checks and signs the approved items. Money movements and loosening changes require a session.

Approver. A Key app holding an identity key but no wallet key, used when key 2 is a hardware wallet.

BC-UR. A format used by Sparrow and hardware wallets to transfer data through animated QR codes.

BIP321. The standard for a bitcoin: payment request.

Bitcoin (BTC). The currency accepted by OpenBMT. One bitcoin is 100,000,000 satoshis.

Blockchain. The shared transaction record, extended in groups called blocks. A payment included in a block has its first confirmation.

Box. The shop’s optional server for relaying device messages and reading POS orders. It holds no wallet key.

Cash-out. Sending bitcoin to an exchange the owner chooses, followed by conversion and withdrawal under that exchange’s terms. OpenBMT does not perform the sale or bank withdrawal.

Change. Money returned to the shop’s wallet by its own spending transaction.

Compact block filter. A small summary used by a light client to find blocks that might contain a relevant transaction.

Confirmation. Inclusion of a payment in a block. The shop’s confirmation depth starts at 1 block and its refund depth at 6. A refund can be paid at the latter. Both show “Paid”, with text distinguishing the depth.

Counter. The phone or tablet displaying the sale and payment code. It holds no wallet signing key.

Descriptor (wallet description). Text describing how to derive the wallet’s addresses from its three public keys.

Exchange rate. The quoted relationship between bitcoin and dollars. A checkout quote calculates what to send; it does not convert the receipt.

Exposure. Instant sales still waiting for their first block.

Full node. A computer that checks every block itself. Running one is optional for the shop.

Heartbeat. A signed message from the owner phone telling the counter that the owner’s watcher is running.

Identity key. A device key signing OpenBMT messages and approvals. It is separate from the wallet keys that authorize Bitcoin spends.

Instant. Acceptance before the first block, within the shop’s limit.

Key app. The separate app holding key 2 and providing the second approval.

Light check. A check through Bitcoin peers and compact block filters without running a full node.

Lightning invoice. A request payable over Lightning, supplied by the shop’s own Lightning node in OpenBMT.

Loosening / tightening. A settings change that permits more risk, or one that reduces it.

Multisig, two of three. A wallet requiring any two of its three keys to spend.

On-chain. A payment recorded through the Bitcoin blockchain, as distinct from an individual payment made through Lightning channels.

Orbot. A separate Android app providing Tor connections to other apps.

Private key. Secret information used to authorize spending. OpenBMT’s wallet needs two of its three wallet keys to spend.

PSBT. A standard transaction file passed between signers.

Recovery kit. A printed page of wallet recovery information, without secret keys or seed words.

Recovery words (seed words). A secret word sequence that can recreate a key. It is not a payment address or the public wallet description.

Release key. A key signing an app for distribution, separate from the wallet’s keys.

Reorganization (reorg). Replacement of blocks by a different set of blocks.

Root. An owner-phone or Key-app identity key pinned by a counter at pairing.

Satoshi (sat). One hundred-millionth of a bitcoin.

Tor. A network that hides where a connection originates.

Unconfirmed. Seen as a transaction but not yet included in a block. It can still be replaced and is subject to the shop’s instant-acceptance limits.

Watch-only. A wallet view using public information to display payments without holding keys that can spend them.

xpub. A public key used to derive addresses without being able to spend.