BSV Browser v1.8.0 Adds Live Payments Over WebRTC

Wallets & Identity

In Brief

BSV Browser has published version 1.8.0 with a downloadable Android build and a new payment flow that attempts to reach the recipient’s wallet through an encrypted WebRTC connection.

The release brings WebRTPay into the mobile application’s sending and receiving screens. App-store distribution and device testing remain separate steps, while further broadcasting and privacy changes are under development.

News Report

BSV Browser v1.8.0 was published on GitHub on October 21, 2026, at 19:58 UTC. The release includes an Android APK produced through the project’s successful publication workflow.

BSV Browser combines mobile web browsing with a locally controlled wallet, identity functions and permission-based access for websites using the BRC-100 interface.

BSV TIMES covered the experimental WebRTPay package on October 20. This release adds a distinct application milestone: the payment transport is now connected to the browser’s wallet interface and included in a published Android build.

Trying the Recipient’s Wallet First

The new flow applies to BSV token payments addressed to a handle or identity key. When direct payment is available, the wallet first attempts a live connection to the recipient.

A relay helps the wallets establish the encrypted WebRTC connection. The payment data then travels through that connection to the receiving wallet.

If the recipient is unavailable, the application asks whether the payer wants to use MessageBox instead. That fallback is offered when the live attempt is known not to have spent funds, avoiding a fresh payment after an uncertain outcome.

The Receive screen adds an “Open to live payments” status card. In the released implementation, live receiving operates while the application is in the foreground. Payments through MessageBox remain supported.

The interface also distinguishes a payment delivered live from one handed to the MessageBox route.

Android Release and iOS Preparation

The confirmed downloadable release is the Android APK attached to GitHub.

The developer reports successfully producing a signed iOS build for TestFlight, alongside successful simulator and Android builds. However, the release discussion leaves TestFlight upload and Google Play internal-test submission as outstanding steps.

Apple’s current public lookup record, checked on October 22, 2026 (UTC), still identifies version 1.7.0 as the App Store version.

The contribution reports 1,334 passing automated tests and two skipped tests. Its checklist leaves phone-to-phone and phone-to-desktop live payments, offline-recipient fallback and receipt notifications for physical-device testing.

Broadcasting and Privacy Follow-Ups

Direct delivery and blockchain submission remain distinct parts of the payment process.

An open browser contribution reports that version 1.8.0’s wallet dependency records incoming transactions for later submission by background monitors. The proposed update moves recipient-side broadcasting into receipt processing and improves how temporary broadcaster failures are handled.

A separate, unmerged mobile-toolbox contribution addresses live-receiving privacy. Its author reports that foreground-wide availability lets a party who knows a wallet’s identity key learn that the application is open and obtain network-address information, including the phone’s IP address.

The proposed change would make live receiving available only while the Receive screen is open. It also introduces a payment-size limit and changes connection-discovery settings.

Those follow-up changes are not included in the published v1.8.0 build. The privacy concern relates to connection metadata; an encrypted payment channel still requires careful control over when the wallet answers connection requests.

BSV TIMES Read

The new milestone is the movement of direct payment transport into a mobile application’s ordinary payment screens. Users are given a route that attempts live delivery and asks before falling back to a stored message.

That makes the transport work more concrete, while exposing the practical questions that arise during application integration: availability, payment status, interrupted delivery and network privacy.

The Android release gives users a concrete build to evaluate. The outstanding device checks and documented follow-ups remain relevant when assessing the feature’s readiness for wider use.

Developer Context

Darren Kellenschwiler, known publicly as Deggen and using the GitHub account sirdeggen, authored the browser integration and the shared mobile-toolbox contribution connecting live payments to the sending and receiving screens.

His public GitHub profile lists the BSV Association. He also submitted the broadcasting and live-receiving privacy follow-ups discussed above.

Source Links

Posted on October 22, 2026 (UTC)