DarkHorse Wallet Update #04 | Clearer Assets, Smoother Transfers

When you open your wallet, it should be clear which assets you can send, which are awaiting confirmation, and how far each transfer has progressed through validation.

In this update, the DarkHorse Wallet team focused on asset overviews, proof validation, and sending and receiving workflows. We also integrated the Genesis campaign into the wallet, allowing users to check asset status, track transfers, and claim Horseshoes in one place.

This update covers wallet extension versions v0.19.0, v0.20.0, and v0.21.0. Platform changes have been deployed to the test site. DarkHorse Wallet remains in internal testing, and Lightning functionality is available only on Signet.

1. A Clearer Asset Overview

Total Value and Separate Balance Categories

The home screen now displays total value denominated in BTC and separates asset balances into Available to Send and Confirming. Assets awaiting confirmation are excluded from the total value.

The valuation data service has been developed but has not yet been deployed. At this stage, the wallet’s total value includes only Bitcoin. RGB assets temporarily display “No Quote.”

Balance calculations during transfers have also been refined. The original outputs are marked as sending, while change belonging to the user is accounted for separately, preventing assets from being counted twice during a transfer.

See Which Outputs Hold Your Assets

The new Holdings Details view lets users inspect each Bitcoin transaction output, or UTXO, holding an asset.

Users can check the amount held in each output, its confirmation status, whether it is being spent, and the incoming transfer it originated from. They can also revalidate the associated asset proofs.

Beyond showing a balance, the wallet now helps users understand where their assets are held and whether they are currently available to use.

Dedicated Detail Pages for BTC and RGB Assets

BTC and each RGB asset now have dedicated detail pages showing balances and related records. RGB asset pages also provide access to transfer history, the outputs holding the asset, and contract information.

Users can open an asset’s details directly from the asset list and follow its records without repeatedly switching between pages.

2. Visible Validation Status, Exportable Proofs, and Offline Verification

Clear Validation Progress for Every RGB Transfer

Transaction history now directly displays whether each RGB transfer’s consignment has arrived, whether it has been validated locally, and its current confirmation count.

The cancellation option appears only for records that support cancellation, reducing unnecessary attempts.

The home screen also displays the number of locally validated assets and the validation time. Users can trigger revalidation, and each asset carries its own validation indicator.

Export and Verify Asset Proofs Offline

The wallet supports exporting consignments individually or exporting all of them as .rgb files.

Users can also import a consignment file for offline verification and inspect its history step by step, from issuance through the latest transfer.

These tools make client-side validation results easier to inspect and give users a way to retain and verify their own asset proofs.

3. A Unified Send Interface and Easier Receiving and Importing

One Input Field for Different Payment Requests

The send page now uses a single input field. Users can paste a Bitcoin address, an RGB invoice, or a Lightning invoice, and the wallet directs them to the appropriate workflow.

Transaction fees are displayed in satoshis, while fee rate settings are grouped under Advanced, keeping common actions easier to access.

For RGB invoices that do not specify an asset, users now choose the asset themselves instead of having the first asset in the list selected automatically.

Clearer Payment Results and Reasons for Waiting

Once an invoice has been paid, it displays Sent, helping users recognize completed requests and avoid duplicate payments.

After sending, if change is still awaiting confirmation, the wallet explicitly shows that it is waiting for change to confirm. This explains why the available balance may be temporarily restricted.

Reducing Interference Between Assets When Receiving

Previously, incoming assets could be assigned to outputs that already held other assets, causing those assets to become unavailable together.

With this update, the affected receiving workflow uses only empty allocation slots. If none are available, the wallet uses an alternative receiving method.

Asset issuance amounts are now entered in whole-token units rather than the smallest denomination, reducing errors caused by decimal precision conversions. Assets previously issued with an incorrect supply because of this unit mismatch need to be reissued.

UniSat Import Support

The wallet now supports importing from UniSat, with the imported wallet’s login address matching its UniSat address.

DarkHorse Wallet uses a separate new address for its own BTC transfers, leaving assets on the original UniSat address untouched, including inscriptions and Runes.

When exporting a recovery phrase, the words are blurred by default and become visible only when clicked.

4. The Genesis Campaign Comes to the Wallet

The home screen now includes a permanent DarkHorse Genesis entry.

On first access, users must authorize the wallet before it reads campaign data. This authorization can be revoked at any time.

The campaign page displays claimable and previously claimed Horseshoes, updates the mining total every second, and includes a burn countdown and status cards for DarkHorse Knights and Genesis Partners.

Users can claim Horseshoes directly within the wallet. In this round, claims were successfully completed and credited in the Signet testing setup.

This progress applies to the test environment. Public availability will be announced later.

5. More Reliable Background Processing and Clearer Status Messages

Website Approvals and Rejections Are Delivered Promptly

The team fixed an issue where a user’s approval or rejection could be lost while a website was waiting for the wallet’s response. These results are now returned promptly to the requesting website.

When an indexer encounters an error, the wallet automatically switches and retries, reducing the need for manual intervention.

Distinguishing a Busy Lightning Node from a Connection Failure

The Signet Lightning page now distinguishes between a busy platform node and a connection failure. If the node does not respond within 20 seconds, the interface displays a busy status. After 35 seconds, it displays an error.

This helps users understand the current connection state.

After the wallet popup is closed, background processing continues to track assets returning from closed channels.

Fewer Data Writes and Coordinated Task Processing

The wallet’s planned internal restructuring for this round is complete. State management is now centralized, with tasks coordinated through a shared queue and execution time limits.

Saving now writes only the data that has changed. The amount written per synchronization round has been reduced to tens of kilobytes, cutting redundant writes.

This update also fixes stalled synchronization indicators, long lists that could not scroll to the bottom, language changes that did not take effect immediately, and flickering scrollbars when switching pages on Windows.

6. Test Results

The team tested version upgrades and Signet workflows.

• All 54 test cases covering upgrades from v0.19.0 passed.
• All 25 Signet regression tests passed.

These results apply to the scope tested in this round. The team will continue reviewing internal testing feedback and validating subsequent changes.

7. Work in Progress

A Transaction Review Page Before Signing

The team is developing a review page for RGB sends. Before signing, it will display the recipient, the outputs being spent, change, transaction fees, and any other assets affected by those outputs being temporarily unavailable.

Signing begins only after the user confirms. The review remains valid for 10 minutes. If the relevant state changes, the wallet returns to the previous step and explains why.

Resuming Submitted Sends After Locking or Closing the Browser

The team is testing recovery workflows for submitted sends.

After submitting a send, users can lock the wallet or close the browser, then resume processing after unlocking without initiating the transfer again. In the scenarios tested this round, transactions were broadcast within approximately 3–24 seconds after processing resumed.

This functionality remains under validation. On-chain confirmation must still be tracked after broadcast.

Further Valuation and Campaign Features

The team will also continue working on the following:

• Deploying the asset valuation data service to add RGB asset quotes and include them in total value calculations.
• Completing the additional bonus for claiming Horseshoes through the Genesis campaign, with eligibility rules and availability to be announced separately.
• Supporting switching between multiple wallets.

These features remain in progress and are not yet publicly available. Future development updates will cover further test results and hands-on demonstrations.