> ## Content Index > Fetch the complete content index at: https://blog.dhorse.fun/llms.txt > Use this file to discover other available public pages before exploring further. # DarkHorse Wallet Development Update #02 | Faster Access, Smoother Transfers - URL: https://blog.dhorse.fun/wallet-2/ - Published: 2026-10-16T00:46:03.000Z - Updated: 2026-10-16T00:57:55.000Z - Author: Julian Weber - Tags: Wallet > In internal testing, DarkHorse Wallet now unlocks in around 0.5 seconds and displays existing asset data on the home screen in around 0.1 seconds. The wallet team has completed another round of architectural changes focused on everyday Bitcoin and RGB asset use, alongside updates to transaction history, platform withdrawals, Lightning connectivity, and recovery phrase backups. We also disconnected the platform services the wallet depends on, simulating connection failures and servers that connect but never respond. These tests helped us identify and fix issues affecting the wallet under unstable network conditions. Here is the full development update. The current internal testing version of the wallet extension is v0.18.6\. The performance architecture changes are complete and awaiting testing before release. Platform changes have been deployed to the test site. DarkHorse Wallet remains in internal testing, and Lightning functionality is available only on Signet. ## 1\. Faster Access to Your Wallet, Even During Synchronization ### Pages No Longer Wait Behind Sync Tasks Checking balances and transaction history is one of the most common reasons to open a wallet. Previously, these requests shared the wallet engine’s queue with synchronization tasks, so slow network responses could delay the interface. This update separates page reads from background synchronization. Pages read directly from data snapshots maintained by the wallet engine, without waiting in line for network responses. Internal development measurements showed: - **Existing asset data appears on the home screen in around 0.1 seconds**, without waiting for background synchronization. - **Pages read directly from local data snapshots**, reducing delays caused by network requests. - **Unlock time has dropped from around 0.8–2 seconds to around 0.5 seconds**, providing faster access to the wallet. 0:00 /0:05 1× Pages display existing wallet data first. The latest onchain state still requires background synchronization. These figures come from internal testing; actual performance depends on the device, wallet data size, and network conditions. Unlocking no longer waits for the indexer either. If the current indexer is unavailable, the wallet automatically tries a backup for the selected network. If neither is reachable, the home screen displays a notice while the interface remains usable. ### Coordinated Background Synchronization An internal scheduler now coordinates synchronization, reducing duplicate requests and tasks waiting on one another. - When transfers are pending, a sync round is scheduled every 30 seconds. - While the wallet interface is open, a sync round is scheduled every five minutes. - When the interface is closed, periodic synchronization stops. - Failed sync attempts automatically back off to avoid repeated requests. - Each round has an execution time limit, with unfinished work carried over to the next round. Expired invoices are invalidated locally, without querying the consignment relay individually. If a relay stops responding, synchronization ends within its time limit while pages remain usable. Updates resume when the service recovers. The wallet and Lightning node also share cached indexer queries, including the latest block and transaction status. This reduces duplicate requests and the likelihood of hitting public indexer rate limits. ## 2\. Clearer Transaction History and Better Handling of Pending Receipts ### Separate BTC, RGB, and Lightning Records Transaction history is organized into **BTC, RGB assets, and Lightning**. Outgoing records show the amount actually sent, making transactions easier to check. 0:00 /0:08 1× The page reads wallet-maintained snapshots and updates entries in place. Longer histories are paginated at **50 entries per page**, reducing the work required to load the list. A loading indicator appears while records are being retrieved. If another operation is keeping the wallet busy, the interface explains what it is processing instead of showing an empty list. ### Handling Receipts Stuck in Confirmation This update fixes an issue where incoming transfers could remain in “Confirming” for an extended period and leave other assets on the same Bitcoin output unavailable for use. The wallet attempts to retrieve the consignment again from the relay and complete the receipt. If the consignment cannot be retrieved, users can cancel the pending receipt workflow from transaction history to make the affected assets available again. This does not reverse an onchain transaction. ### Separate History for Closed Channels Closed Lightning channels now appear in a separate tab, making it easier to distinguish active channels from historical ones. Assets held in a channel return to the wallet after closure. This update also covers asset returns from small channels. ## 3\. Clearer Status When Network Services Fail ### Testing Two Types of Connection Failure We tested three platform domains individually under two conditions: connection refusal and a connection that remains open without returning a response. During these tests, BTC and RGB transfers continued to work when the main platform or Lightning service was disconnected. An unresponsive consignment relay could stall some wallet operations, which we addressed. All servers accessed by the wallet now have response time limits. When the relay is unresponsive, balance and history reads use local cached data, preventing pages from remaining blocked for several minutes. ### Timed-Out Send Requests Stop Queuing If a send request remains queued for more than **40 seconds**, the wallet explicitly reports “Not sent” and cancels the request. Once that timeout is reported, the queued request will not execute later, giving users a clearer outcome. ### Lightning Connection Status Updates Promptly When the Lightning connection drops, the wallet promptly displays “Connecting.” It reconnects automatically when connectivity returns and updates payment status. In this round of testing, payments initiated before disconnection completed after the connection recovered. This fixes an issue where a stalled connection could still appear “Online” while payments remained pending indefinitely. Requests from the Lightning node now use the wallet’s shared queue, resolving an issue where Lightning operations and synchronization could block each other. Requests to enable Lightning from the platform no longer remain stuck on “Loading” because of this issue. ## 4\. Smoother Interaction Between the Platform and Wallet ### One-Click RGB Withdrawals to DarkHorse Wallet The DarkHorse test site now supports one-click RGB asset withdrawals to **DarkHorse Wallet**, prioritizing invoices that do not require an empty allocation slot in the receiving wallet. When a website initiates a request while the wallet is locked, the wallet first opens the unlock screen. After unlocking, it displays the confirmation window for that request so users can continue the operation. ### Address Network Checks and Fee Estimates Both platform BTC withdrawals and BTC sends from the wallet now check whether the entered address belongs to the selected network. Network mismatches are flagged as the address is entered. The payment confirmation window also displays the estimated network fee in **satoshis (sats)** for review before approval. 0:00 /0:04 1× ### Backup Routes for Consignment Delivery Platform deposit invoices and wallet receive invoices now include backup consignment relay information. If the platform’s primary relay fails, consignments can be delivered through a backup route, reducing transfer interruptions. ### Less Manual Setup for Lightning Opening a Lightning channel from the platform automatically starts the wallet’s Lightning node. Users no longer need to enable it manually in the wallet first. When the platform’s Lightning node has insufficient assets, it automatically replenishes them from the platform wallet. Peer-to-peer swaps are also restricted to the platform’s own websites. All Lightning-related changes described here apply to the Signet test environment. ## 5\. Improved Backups, Network Switching, and Diagnostics ### Recovery Phrase Verification During Setup Recovery phrases are blurred by default when creating a wallet and become visible only when clicked. The backup process now asks users to verify three randomly selected words before entering the wallet, helping them check that their backup is accurate. When exporting a recovery phrase, “Copy” copies only the words themselves for easier backup and recovery. ### The Home Screen Follows Network Changes Switching networks in Settings now updates the home screen’s address and balance accordingly, fixing an issue where information from the previous network could remain visible. This round also includes other interface and interaction refinements. 0:00 /0:08 1× ### New Diagnostics Section Settings now includes a **Diagnostics** section with recent sync rounds, time spent at each stage, and command logs. These details can be copied with one click. During internal testing, this information helps the team investigate reports with less back-and-forth and faster issue reproduction. ## 6\. Testing Progress The team is continuing functional testing, reviewing feedback, and addressing issues. The performance architecture changes will be released once testing is complete. The connection-failure scenarios described above have been tested. Dedicated security and stress testing remain in planning. We will continue sharing test results, feature changes, and hands-on demonstrations in future development updates.