What we cannot do is the feature

Keys

BitBacker has no key generation, no seed phrases, no backup flow and no recovery flow. Not as a policy: there is no code for it. The wallet interface the app is built against exposes four operations: check availability, connect, read the identity public key, and request a payment. There is nothing in that surface that could return a private key, so no future change to a component can start leaking one.

Identity comes from a BRC-100 wallet through getPublicKey({ identityKey: true }). Payments go through createAction. Your keys stay in the wallet and this app never asks for them.

Identity is not permission

Connecting a wallet establishes who you are. It does not establish what you may do. Role is a server-side claim looked up from the store: it is never read out of a cookie, never sent by the browser, and never inferred from an identity key.

In practice that means hiding a navigation item is not access control and is never relied on as such. Every route re-checks the role on the server: the back office returns 403 to a lender who guesses the URL, lender-only updates are stripped from the API response rather than filtered in the browser, and the arbitration case room is gated on an actual position in the loan.

The server owns state

There is no client-side database, no localStorage persistence layer and no merge-on-read. Every read and every write goes through a Route Handler. A browser cannot assert that a payment happened: the wallet produces a receipt, and the server decides whether a position exists.

Demo mode

This build runs a demo wallet so the product can be walked without a BSV wallet installed. It is labelled wherever it matters, it generates no keys, and it stores nothing in your browser. Switching to the real BRC-100 adapter changes one environment variable and no component.

What is not hardened yet

The honest list, because a security page that only describes strengths is marketing. This build holds state in memory rather than in a database, so it has no durability, no transactions and no rate limiting. The demo role switch lets one session move between roles, which a production build removes. And the platform’s receiving script is unconfigured: the payment path is wired but not pointed at a real output.

Reporting something

If you find a problem, tell us before you tell anyone else and we will not argue about disclosure timelines with somebody who did us a favour. Get in touch.