DarkHorse Wallet Update #03 | Accurate Balances, Reliable Transfers

Accurate balances, assets that do not interfere with one another, and reliable fund recovery after channel closure are essential to a dependable wallet.

Following the previous round of performance improvements, the DarkHorse Wallet team continued testing and refining real-world workflows. This update fixes inflated balances caused by duplicate credits and issues where assets sharing the same output could become unavailable together. It also improves Lightning channel management, platform deposits and withdrawals, and transaction status feedback.

The wallet extension has been updated to v0.18.7 and v0.18.8. Platform changes have been deployed to the test site. DarkHorse Wallet remains in internal testing, and Lightning functionality is available only on Signet. These versions will be submitted for Chrome Web Store review after testing is complete.

1. More Accurate Balances and Separate Handling of Assets Sharing an Output

Fixing Inflated Balances Caused by Duplicate Credits

During testing, the team found that a duplicate credit for the same incoming transfer caused the wallet to display a balance of 5,450 when the actual balance was 250.

This issue has been fixed so that each incoming transfer is credited only once.

Sending One Asset Without Making Other Assets Unavailable

A single Bitcoin transaction output, or UTXO, can carry multiple RGB assets. Previously, sending one asset could also make other assets on the same output temporarily unavailable.

With this update, the other assets are moved to separate available empty outputs, reducing interference between assets. This workflow has been verified on-chain.

Fixing Allocation Slot Issues and Protecting Asset-Bearing Outputs

RGB asset issuance and some receiving operations require available allocation slots. This update fixes an issue where slots could remain permanently occupied, preventing asset issuance or invoice creation. When an invoice cannot be created, the wallet now explains why.

Outputs that carry assets but do not yet have corresponding wallet records are locked to prevent them from being mistaken for empty allocation slots or spent on transaction fees.

Adding Assets by Contract ID

The wallet now includes an Add Asset option for adding assets you do not yet hold using their contract IDs.

Input is validated as it is entered. Any mismatch with indexed information is clearly flagged to help users check the asset details.

2. Checking Asset Recovery Before Closing a Lightning Channel

Blocking Channel Closures That Could Cause RGB Asset Loss

If insufficient BTC on either side of a channel could cause that side’s RGB assets to be lost during closure, the wallet and platform node reject the closure and explain the reason.

Clearer Closure Confirmation and Channel Status

Channels that are still opening cannot be closed. Before closure, the wallet displays a confirmation prompt showing the estimated amount of satoshis to be returned and the expected arrival time.

This update also fixes an issue where a channel could reappear while still showing a “Returning funds” status, keeping the interface aligned with the actual processing state.

Automatic Recovery Retries and Manual Reconnection

Failed fund recovery attempts are retried automatically. After eight consecutive failures, the wallet notifies the user that action is needed.

When the Lightning connection drops, automatic reconnection attempts become progressively less frequent. Users can also select Reconnect Now to attempt an immediate reconnection.

Lightning Interface Updates and Fee Limits

• The channel page displays the five most recent records for easier review.
• The receive page lists only assets that can currently be received and shows the maximum amount per payment.
• Lightning cannot be disabled while channels remain open.

The platform node’s testnet fee rate cap has been set to 10 sat/vB. Earlier tests recorded a single channel closure fee of 37,000 sats. The updated cap helps control network fees during testing.

3. Fewer Steps and Faster Queries for Platform Lightning Deposits and Withdrawals

The following changes have been deployed to the test site. Lightning workflows are available only on Signet and are not publicly accessible.

Automatic Channel Opening on the First Withdrawal

When a user withdraws through Lightning for the first time, the platform automatically opens a channel, incorporating channel setup into the withdrawal workflow. The user only needs to initiate one withdrawal.

Under the current testing rules, the fixed setup fee is 4,000 sats, covering channel opening and cooperative closure. Each account can use the shared free allowance once to waive this fee.

Channel Queries Reduced from 25.9 Seconds to Under 0.01 Seconds

The team fixed issues involving Lightning disconnections and blank panels. In this round of testing, channel query time fell from a previous worst case of approximately 25.9 seconds to under 0.01 seconds.

This measurement applies specifically to the channel query, not the loading time of the entire page or the time required to complete a payment.

Reusing Change Addresses During Fund Recovery

The platform node now reuses change addresses during fund recovery. This prevents repeated attempts from generating additional addresses and increasing the amount of data the wallet needs to synchronize.

4. Prompt Broadcast Feedback Without Misreporting Synchronization Failures as Send Failures

Separating Transaction Broadcast Results from Subsequent Synchronization

Once a transaction has been successfully broadcast, the wallet immediately reports the successful broadcast.

This prevents a later synchronization failure from causing an already-broadcast transaction to be reported as a failed send, reducing unnecessary retries and duplicate fees.

A successful broadcast means the transaction has been sent. Its final confirmation status still needs to be tracked.

Less Reliance on the Indexer for Cancellation

Operations for canceling invoices or eligible unconfirmed sends no longer depend on the indexer. In this round of testing, processing took approximately 0.6 seconds.

Processing Pending Transfers Across Categories in Turn

Each synchronization round processes pending transfers across categories in turn. This prevents one category from continuously occupying processing time and gives other transfers an opportunity to progress.

Limiting Internal Invoice Accumulation

Invoices used for swaps and Lightning fund recovery are now reused according to their purpose, with a maximum of 20 retained at a time. This avoids the previous accumulation of thousands of invoices.

This update also includes other workflow and interface refinements.

5. Four Key Tests Passed, with Feedback Review Continuing

The following four tests were completed and passed in this round.

• Separate asset handling: When one asset is sent, other assets sharing the same output are handled separately.
• Allocation slot handling: Relevant slot occupation and release workflows were verified.
• Cancellation: Operation results and response behavior were verified.
• Broadcast feedback: Successful transaction broadcasts were correctly reported.

The team continues testing, reviewing feedback, and addressing issues. Versions v0.18.7 and v0.18.8 will proceed to Chrome Web Store review after this round of testing is complete.

6. Plans for Upcoming Versions

Further Refinements to the Wallet’s Internal Architecture

The next phase will centralize wallet state management, coordinate background tasks, and improve execution time limits and cancellation mechanisms. These changes are intended to help stalled tasks recover and reduce interference between modules.

Expanding RGB Asset Management

Building on these architectural changes, the team plans to continue developing the following features.

• UniSat import: Improve onboarding for existing wallet users.
• Horseshoes and Genesis rewards: Display related information within the wallet.
• Automatic cloud backup of consignments: Add consignment backup capabilities.
• Portfolio view: Provide a consolidated view of assets.
• Validation status and UTXO location: Make asset status and the outputs holding assets easier to inspect.
• Watch-only mode: Provide an additional way to view assets.

These features are planned for upcoming versions. Further progress will be covered in future development updates.