DigiByte Core v9.26.7 release notes

v9.26.7 is a small follow-up to v9.26.6. It fixes slow chain-information
requests, fixes a false fatal error during shutdown, and improves three
wallet details. It includes five user-facing changes and
five test and CI corrections, for ten fixes and improvements.

The block-validation rules, oracle requirements and Thaw Day heights are
unchanged. Mainnet Thaw Day remains at block 24,490,000. Testnet26
activated at block 432,100. These are block heights, not calendar dates.

All full-node and mining operators must run Thaw Day-compatible software
before mainnet reaches block 24,490,000. v9.26.6 already contains those rules;
v9.26.7 does not introduce another activation or require another reindex.

What to do when the release is available

1. Back up your wallets and configuration. Keep the backups private.
2. Download the package for your system and compare its SHA-256 checksum with
   the published checksum file. A checksum detects changed bytes; it is not
   a digital signature.
3. Stop the old wallet or daemon normally. Replace the program and restart it.
4. Check that it reports v9.26.7 and finishes synchronizing.

A normal upgrade from a working v9.26.6 node does not need a reindex. Keep
the required DigiDollar block history and your existing wallet files.

User-facing changes

1. Fixed: getblockchaininfo and getchainstates read the difficulty
   directly from the tip block for the chain they describe.
   Why: The old default could walk far back through retired Groestl
   history while holding the main chain lock, delaying other requests.

   The scalar difficulty field now means the difficulty of that tip block,
   matching getblockheader. The separate difficulties object still reports
   the active algorithms. Historical Groestl blocks remain supported.

2. Fixed: Unused DigiDollar receive addresses created in Qt appear in
   listdigidollaraddresses when include_empty is true, with their labels.
   Why: Qt saved these addresses in the address book, but the RPC did not
   include that source. Empty addresses remain hidden by default. Ordinary
   DGB receive addresses and foreign contacts are not added to the list.

3. Improved: The Send DigiDollar amount tooltip explains that change must
   be zero or at least 1.00 DD.
   Why: Users should see this rule before trying a send. The existing
   $1 minimum output rule has not changed.

4. Fixed: Pending DigiDollar statistics updates finish their supply checks
   when the node shuts down.
   Why: A stop request could interrupt an update and make a normal shutdown
   report a fatal error. Startup scans can still be cancelled. Supply checks
   and the rules for accepting blocks are unchanged.

5. Improved: The wallet overview draws its version number from the build
   settings.
   Why: The artwork previously contained a fixed version number that could
   become outdated. The displayed version now follows the software build.

Test and CI corrections

These changes improve how the project checks its code. They do not change
the rules used to accept transactions or blocks.

1. Fixed: The block-map memory test checks that entries use pooled storage.
   Why: Its old percentage threshold depended on the operating system's
   allocator and failed on Mac despite working pooled allocation.
2. Fixed: CodeQL excludes the retired qa/rpc-tests framework from imports.
   Why: It confused that old framework with the current functional tests.
   The current tests and security checks remain enabled.
3. Fixed: Isolated mainnet and testnet schedule checks use a small prune budget.
   Why: These nodes only read settings at genesis. A warning about room
   for a full chain was incorrectly failing the test on smaller CI disks.
4. Fixed: The Thaw Day node comparison waits for connected followers to
   download mined blocks before advancing its simulated clock.
   Why: A clock jump during an unfinished download can disconnect a test
   peer. Production timeouts and all accounting and reorg checks remain intact.
5. Fixed: Failed Linux and Mac CI jobs retain their unit and functional
   test logs, including the failed functional test's node logs.
   Why: The workflow previously requested a log file that these commands
   did not create. Missing logs made intermittent failures harder to diagnose.
   A failing test still fails the job.

Verification so far

The latest Linux checks used source commit
b41399e61166ce265706cd7881f891dae946f01f. Later documentation commits do not
change the tested code.

The optional script-data unit case also passed with real external test vectors.
The functional skips require older binaries, tracing support, special network
interfaces, or unsupported Signet features. A skip is not a pass.

The first functional run had one setup failure: the separate crash test and
the fee-estimation test selected the same local RPC port. The fee test passed
when rerun alone on the same source and port. No product code was changed for
that failure. Independently launched test suites need separate port ranges.

The shutdown fix has two new regression tests. Both failed before the fix and
pass with it. They check shutdown during a pending chain reorganization and
during the first Thaw Day update, then check supply after reopening the index.

The final fuzz run checked 85,933 saved inputs. Each of the two targets without
saved inputs generated new inputs for ten seconds. The run reported no
sanitizer errors. This is a bounded test, not proof that every possible input
is safe.

Desktop checks covered the changed tooltip and version display in light and
dark themes. An unused receive address created in Qt kept its RPC entry and
label after a wallet restart. These checks used an isolated test wallet.

Release packages have been built. The Linux package passed the checks described
above. Windows, ARM Linux and Mac still need launch checks on their target
systems. Package integrity checks do not replace those launch checks.

The Apple Silicon launch report also needs a test of the final Mac package.
The Mac packaging guide now requires checking the whole app's signature and
opening the exact package intended for release. This is a release check, not
a claim that the reported launch problem has been fixed.

The reported 45-minute startup has not been reproduced or explained. The RPC
speed fix above must not be described as a fix for that separate startup report.

Existing limits

• Use validateddaddress for DD, TD and RD addresses. validateaddress
  continues to handle ordinary DigiByte addresses.
• importdigidollaraddress remains an unsupported no-op. This release does
  not add a new watch-only import feature.
• Address creation dates remain empty where no reliable date was recorded.
• A transfer waiting on a parent mint can still wait for the wallet's normal
  rebroadcast schedule. This release does not promise immediate rebroadcast.

Report sensitive security findings privately through GitHub's security
reporting page or security@digibyte.io.

DigiByte Core v9.26.6 release notes

Final v9.26.6 release

v9.26.6 includes RC1, RC2 and the final wallet improvements listed below.
The final changes improve minting from wallets with many small coins, explain
send errors, and make the wallet easier to read. They do not change RC2's
consensus rules, oracle requirements or Thaw Day heights. Consensus means
the rules nodes use to agree on valid blocks.

All full-node and mining operators must upgrade before mainnet block
24,490,000, including operators who do not use DigiDollar. Older software
can disagree about valid blocks after that height. Testnet26 activated Thaw
Day at block 432,100. Mainnet activation is controlled by its block
height, not a calendar date.

What to do

1. Back up your wallets and configuration. Keep the backups private.
2. Download the final release for your system and verify the published checksums.
3. Stop the old wallet or daemon normally, replace the program, and restart it.
4. Check that the version is v9.26.6 and that the node finishes synchronizing.

A normal upgrade from a working RC2 node does not require a reindex. Keep the
required DigiDollar block history. If the old node stopped on a rejected block,
use the reviewed recovery instructions for that failure.

Installing this release enables its wallet and display improvements immediately.
The scheduled mainnet rule changes begin at block 24,490,000. Minting still
requires an eligible price, sufficient collateral and the other existing checks.

Changes added after RC2

Each entry is one change group. Supporting tests count with their fix.
The version number, wallet version image and release-note edits are not extra fixes.

Minting and sending

1. Change: Large mints wait for coin-merge transactions to confirm before building the mint, and show the merge transaction IDs. Repeated requests reuse that pending status, including after restart.
   Why: Spending several large, unconfirmed merges at once can exceed the existing transaction-chain limit. The wallet must explain the wait without recording a failed mint or starting unnecessary extra merges.

2. Change: The Qt mint form respects manually locked DGB coins and uses the wallet's normal spendable-coin checks.
   Why: Coins the user has locked must stay out of automatic collateral selection.

3. Change: DigiDollar sends report the actual coin-selection error and check the selected inputs before asking for confirmation.
   Why: Change below $1 needs a different amount or input selection. Waiting for confirmations will not fix that error. The $1 output minimum is unchanged.

4. Change: Oversized DGB sends explain that too many coins are needed and suggest a smaller send or combining small coins first.
   Why: The existing transaction-size limit remains necessary, but users need a useful next step.

5. Change: A DigiDollar send that lacks fee funds shows the estimated fee in DGB.
   Why: Users should not have to convert an internal unit or assume every send costs the same amount.

Wallet screens and CSV exports

6. Change: The Send DigiDollar address field says "Enter a DigiDollar address."
   Why: Example text should not look like an address already entered by the user.

7. Change: DigiDollar paste and address-book icons have readable contrast, and Send and Clear buttons visibly respond to hovering and clicking.
   Why: The controls should be recognizable and show when they are being used in both themes.

8. Change: DigiDollar transaction rows, filters and dropdowns use the DigiDollar green theme consistently.
   Why: Mixed background and text colours made the page harder to read.

9. Change: Main Transactions CSV dates include hours, minutes and seconds without an unnecessary ".000" ending.
   Why: Exports should contain clear, consistent dates. Dates shown inside the wallet still follow the computer's regional settings.

10. Change: The main Transactions page exports DigiDollar amounts as plain decimal numbers without a currency suffix.
    Why: Spreadsheets need numeric cells for calculations. This completes the CSV amount repair started in RC2.

11. Change: Transaction exports suggest a dated filename and make the disabled Save button readable.
    Why: Users should have a useful starting filename and understand when saving is unavailable.

12. Change: New folder names remain readable while editing them in the dark-theme export dialog.
    Why: The old styling could put white text on a white background.

13. Change: The About window gives its text enough room, keeps links readable, and points to the current DigiByte website and source repository.
    Why: Users need to find their version and the project's current information without a cramped text column.

RPC, logging and test tools

14. Change: listdigidollaraddresses returns saved labels, transaction counts and last-used times from the wallet.
    Why: These fields previously returned empty or zero values. An unknown address creation date remains empty rather than being guessed.

15. Change: validateaddress help and wallet integration instructions direct DigiDollar users to validateddaddress.
    Why: DigiByte and DigiDollar use different address formats. The existing DigiDollar command checks DD, TD and RD addresses without changing ordinary DigiByte address validation.

16. Change: Expected nonmatching DigiDollar key checks appear only when DigiDollar debug logging is enabled.
    Why: Routine wallet scanning should not fill the normal log with misleading messages.

17. Change: The isolated Thaw Day test builds the current release candidate by default and also accepts an exact commit or tag.
    Why: Each rehearsal must exercise the intended candidate rather than an older, fixed commit.

18. Change: The Thaw Day test leaves its last permitted block available while oracle signatures finish.
    Why: A block mined without a price bundle cannot gain one later. The test must wait before mining that block and still check the actual signed bundle afterward.

Integration notes and limits

When a mint needs coin merging, mintdigidollar can return
status: "consolidation_pending" and consolidation_txids. This means that
no DigiDollar has been minted yet. Wait for those transactions to confirm,
then retry. Check any accompanying error if a later merge failed. The normal
successful mint response is unchanged. Coin merges are ordinary DGB
transactions and pay the normal network fees.

listdigidollaraddresses counts distinct DigiDollar transactions known to the
wallet. last_used is the latest wallet transaction time, in UTC. These fields
describe this wallet's records, not a complete public address history.

This release does not add a general "combine coins" button or DigiDollar
watch-only import support. An oracle pause remains a restriction, not permission
to bypass missing signatures or price checks. A reported Windows-only blank
progress popup was not reproduced in the Linux checks; no speculative change
was made for it.

Final verification

The Linux test runs checked the production source at a96e6b10b6. The later
rehearsal correction changes only the test script and its regression tests;
the production source is identical.

The functional skips require older binaries, tracing support, special network
interfaces, or unsupported Signet features. Fuzz checks replayed the saved
test inputs; the two targets without saved inputs each generated new inputs
for ten seconds. This was a bounded test run, not an exhaustive search.

Linux visual checks covered all seven DigiDollar tabs, the changed controls
and export dialogs, and the About window in light and dark themes. Native
Windows and macOS checks are still needed on their release packages.

The private rehearsal used commit 86c8176902 with the isolated lab patch.
All nine nodes finished on the same block at height 5,686. The lab changes
its own network settings and activation height; it does not replace a full
mainnet history reindex or native release-package checks.

The RC1 and RC2 results below describe those earlier candidates. Release
packages must be built from the reviewed final tag and checked before
publication. These source tests do not verify packages that have not yet
been built.

Release package checks

These five packages were built with the same native Guix process used for RC2,
from tag v9.26.6, commit 92330d9.

• Builds completed for Linux x64, Linux ARM64, Windows x64, Apple Silicon Mac and Intel Mac.
• All 15 build-output checksums passed. The five packages contain the expected processor architectures. ZIP integrity checks passed.
• The packaged Linux programs report v9.26.6. All 3,759 unit cases passed, with two existing partial-fixture warnings. The optional script-data...

DigiByte Core v9.26.6 RC2 — testing release

This is the second release candidate. Please test it before the final v9.26.6 release.

RC2 adds 24 fixes and improvements to RC1. The full v9.26.6 release has 107 change groups, including tests and documentation. The changes improve DigiDollar wallet displays, transaction handling, synchronization, memory use and shutdown.

Thaw Day has activated on testnet26 at block 432,100. Mainnet activation remains at block 24,490,000, expected around November 1, 2026. The block height starts the change; the date is an estimate.

All full-node and mining operators need the upgrade before mainnet activation, including those who only use DGB. Older software can disagree with the new block rules. Wallet and performance improvements apply when the updated program runs. The scheduled Thaw Day rules start at the activation height.

Before you test

1. Back up every wallet and keep your existing backups.
2. Check the downloaded package against the release checksums.
3. Close the old wallet or node normally before replacing it.
4. Start RC2 and check the version, network, synchronization and wallet balances.
5. Report problems with the version, network, block height and relevant logs. Remove private information first. Send sensitive reports to security@digibyte.io.

Start with testnet where possible. RC2 is a test candidate, not the final production release. Windows and Mac packages are unsigned. Mac application packages are ZIP files.

Release build checks

Source-reference correction (October 2, 2026): The public
v9.26.6rc2 tag points to 998140ec6ba951ceaea40b22ddcdc89e8fa7154e.
It does not identify the source recorded for these RC2 packages. The saved
RC2 build record and source archive identify commit
d96d58545a4683057cfc24dc903353a64fe71698. SHA-256 checks of all five saved
packages match the published asset digests. The public tag and binaries
are unchanged. This verification did not independently rebuild the packages.

• Native Guix builds completed for Linux x64, Linux ARM64, Windows x64, Apple Silicon Mac and Intel Mac.
• All package checksums and ZIP integrity checks passed. The packages contain the expected processor architectures.
• The Linux build passed all 3,755 unit tests. Nine additional tests passed using the packaged Linux programs. These cover Thaw Day activation, fresh synchronization, restarts, reorganizations, accounting and oracle-bundle validation.
• Windows, Mac and Linux ARM64 packages still need testing on their own operating systems and hardware.

Download checksums

The attached SHA256SUMS file and the hashes below identify the five downloads.
They are not digitally signed.

eb615258b66fe25276e4b96b9ce4d680e116ea6ea6b5daa306ffd524a93295a7  digibyte-9.26.6rc2-x86_64-linux-gnu.tar.gz
5e496af872cd1c244ddd886134ed84ca7fa648d135b7c2bb6c45dd64c09455fa  digibyte-9.26.6rc2-aarch64-linux-gnu.tar.gz
48f2aacd0102ff811357312a4d0204bd62e392c88fab28673a65e451fda458a5  digibyte-9.26.6rc2-win64-setup.exe
1402fa8b77fd4ed19729f6f828b53abd25f0494518fbb6fdca4f844cf804be02  digibyte-9.26.6rc2-arm64-apple-darwin.zip
b803ebf9c9a2c07ba57e28e14255b8be80efb95b4a12db0fb81f9dce9dcb39c2  digibyte-9.26.6rc2-x86_64-apple-darwin.zip

Complete release notes

The RC2 changes come first. The original RC1 notes follow and are clearly marked as historical.

DigiByte Core v9.26.6 release notes

RC2 — second release candidate

RC2 adds the changes below to RC1. The code change list covers source through
943243613ce7f75492eae8b4a074859eeb5ba6d1. RC2 is a test release before the
final v9.26.6 release. For the published packages, use the source-reference correction above.

Full-node and mining operators must upgrade before mainnet block
24,490,000. Thaw Day changes the rules used to agree on valid blocks, even
for operators who do not use DigiDollar. Older software can disagree after
activation. Installing the update prepares the node; the block height starts
the scheduled rule changes.

Testnet26 has passed block 432,100 and Thaw Day activated there. RC2 is being
tested on the already-active testnet. Mainnet block 24,490,000 remains the
future production activation height. Calendar estimates in the preserved RC1
notes are historical. The RC2 repair that removes wallet state from DigiDollar
validation also applies when checking blocks below Thaw Day.

What the totals count

Each numbered entry counts one distinct change group. Related repairs are
grouped, and a repair's supporting tests are included with that repair. A
separate test tool or coverage expansion has its own entry. Version labels,
wallet version artwork and edits to these notes are not extra improvements.
These totals are not counts of security vulnerabilities or outside reports.
The categories describe the main purpose of each group, not its severity.

Corrective fixes since RC1

1. Change: DigiDollar block and mempool validation read amounts and vault identity from chain records independently of the wallet's local script table.
   Why: Nodes checking the same transaction must reach the same result regardless of their wallet history.

2. Change: Header synchronization calculates mining work using the header's actual chain history, including competing branches.
   Why: Valid headers must receive the work score required by the existing mining rules.

3. Change: Incoming block checks verify proof of work before consulting more expensive chain history.
   Why: Invalid block submissions should be rejected without unnecessary history lookups.

4. Change: The DigiByte send form identifies a missing or invalid address, an invalid amount, or an amount too small to send.
   Why: Clicking Send should explain the field that needs attention.

5. Change: DigiDollar transaction dates and amounts, position dates and receive-request dates sort by their underlying values.
   Why: Formatted text can put dates and money in the wrong order.

6. Change: DigiDollar transaction CSV exports write amounts as plain decimal numbers.
   Why: Spreadsheets and accounting tools need numeric amounts without a currency suffix.

7. Change: DigiDollar pages distinguish expired, abandoned and conflicted mint attempts from confirmed vaults and completed redemptions.
   Why: An unsuccessful mint must not appear as collateral that was redeemed or can still be redeemed.

8. Change: The pending DigiDollar balance excludes local mint attempts whose confirmation window has expired.
   Why: A mint that cannot confirm on the current chain should not inflate the pending balance.

9. Change: Redemption commands and estimates use the correct block boundary for the transaction's time lock.
   Why: A vault must not be reported as redeemable one block before its redemption can enter the mempool.

10. Change: Redemption status finds the actual collateral output when an older mint places its outputs in a different order.
    Why: An unconfirmed redemption must remain pending until it confirms, including when ordinary change precedes the collateral.

11. Change: Bounds the recent Dandelion transaction hashes remembered for each peer while keeping exact checks for retained entries.
    Why: Long-running peer connections need predictable memory use without weakening transaction relay checks.

12. Change: Clears Dandelion peer routes before shutdown deletes peer connections.
    Why: Shutdown must not leave transaction relay referring to a peer that has already been removed.

Usability and logging improvements since RC1

13. Change: DigiDollar dates use the computer's regional format, with columns sized to fit.
    Why: Dates should follow the user's settings across the wallet.

14. Change: The DigiDollar overview and mint pages explain missing prices, unavailable checks and restrictions that pause minting.
    Why: Users need to know why minting is unavailable and when they can check collateral and fees.

15. Change: DigiDollar controls, labels, dropdowns and status text follow the wallet's light and dark themes consistently.
    Why: Both themes need readable text and recognizable controls.

16. Change: Repeated redemption requests distinguish a pending redemption, a redeemed vault and another inactive position.
    Why: Users need the position's actual state before deciding whether to retry.

17. Change: estimatecollateral includes mint restrictions and their reason alongside its collateral figures.
    Why: A collateral estimate alone does not mean a mint can currently proceed.

18. Change: DigiDollar commands distinguish an unavailable next-block oracle quote from unavailable health state.
    Why: The error should identify which information is missing.

19. Change: senddigidollar help explains that the sending wallet needs spendable DGB for the transaction fee.
    Why: A DigiDollar balance cannot pay a DGB network fee.

20. Change: Repeated wallet reconciliation messages during synchronization require -debug=digidollar.
    Why: Routine progress should not fill the normal log once per block.

21. Change: Routine compact-block header messages follow the network debug setting.
    Why: Normal logs should stay quiet when network debugging is disabled.

Tests, tools and docume...

DigiByte Core v9.26.6rc1 release notes

Current version: v9.26.6rc1. This is the first release candidate: a test
build before the final release. THIS IS A TEST RELEASE, PLEASE TEST CAREFULLY.

Summary

v9.26.6 includes 83 fixes and improvements. It improves wallet recovery,
DigiDollar (DD) sending and redemption, wallet displays, node stability, price
services, memory use and startup. The count also includes tests and documentation.

Node and mining operators must upgrade before mainnet block 24,490,000,
expected around November 1, 2026. This applies even if you only use DGB.

Thaw Day changes consensus: the rules nodes use to agree on valid DigiDollar blocks.
Older software may follow a different chain after the change.

We are testing Thaw Day on testnet first. The final mainnet release follows
the remaining tests and release review.

What you need to do

1. Read the upgrade notes below. Check scripts that send DD amounts and
   make sure the node has enough disk space.
2. Back up your wallets and keep existing backups. Keep your configuration
   and oracle keys too.
3. Verify the build, then replace the old program. Check the release's
   signed checksums. Stop the old node normally and wait for it to exit first.
   RC1 is for the test exercise; use the approved final build for the mainnet rollout.
4. Let startup finish. The node may need to check or rebuild accounting.
   Do not mistake a long scan for a stopped program.
5. Check the running node. Confirm its version, network, sync progress and
   Thaw Day height. Check any wallet or oracle service you operate.

Full nodes, miners, pools, exchanges, oracle services and wallet backends need
the update. If a provider runs your wallet or exchange service, check its
upgrade notice.

Thaw Day: testnet first, then mainnet

The block number starts the change. The date is an estimate. Faster or
slower block production can move that date. The old rules remain below the
height, including when old blocks are checked again.

Release files and instructions must be available at least 3 days before
testnet activation and 14 days before mainnet activation. Track block
progress during that time.

There is no miner vote or local public-network setting to change Thaw Day.
Postponing it requires a replacement build and coordinated upgrades before
the original height. Editing an announcement cannot postpone installed software.

The testnet exercise will check the switch itself, minting, transfers,
redemptions, oracle prices and agreement between independent nodes. Tests also
cover restarts and chain changes, where recent blocks are replaced by another
branch. Public testnet activation and observation have not yet finished.

To check your node's schedule:

digibyte-cli getdigidollardeploymentinfo
digibyte-cli -testnet getdigidollardeploymentinfo

The result shows the height and whether the rules apply to the current tip
or next block. The tip is the latest block on that node's chain.

Upgrade details that matter

Amounts sent by scripts

Four commands accept amount_unit: senddigidollar,
sendmanydigidollar, redeemdigidollar and getredemptioninfo.
The amount filters in listdigidollarpositions and
listdigidollaraddresses use it too.

Existing scripts using whole cents keep working. Scripts using decimals
must specify dollars. The new unit argument goes last in a positional call.
For example, this requests a $250.00 send:

digibyte-cli -named senddigidollar address="<DigiDollar address>" amount="250.00" amount_unit="dollars"

mintdigidollar still takes whole cents.

The $1 minimum DD output is unchanged. The $100,000 request limit
applies to a single send, each sendmany recipient and a requested redemption.
It does not limit the extra DD the rules may require burning in an emergency
redemption. A redemption still closes the whole vault.

Minting and redemption after Thaw Day

A vault is DGB locked to back newly minted DigiDollars. Oracles provide
the signed DGB prices used by DigiDollar.

At Thaw Day, a new price check replaces the old mint freeze. It uses prices
already recorded in the chain. Transfers and redemptions stop using the old
volatility freeze, but their other requirements still apply.

New mints still need an accepted oracle price, enough collateral and a price
that passes the new check. Large price swings can still pause minting.

Health will count the original DD amounts attached to vaults that remain open.
DD still in circulation is a separate total. Extra DD burned during redemption
can make circulation smaller than the amount attached to open vaults.

This can lower health, keep emergency restrictions in place longer or require
more DD to redeem than the old calculation. Check the current estimate before
confirming. Thaw Day itself creates no tokens and changes no wallet balances.

Wallets and service integrations

• Minting needs the modern descriptor wallet format, private keys and supported
  receiving and change addresses. The wallet explains missing support early.
• Existing wallets can still send and redeem if they hold the needed keys.
  Recovery of a missing key record cannot replace a missing private key.
• CSV exports add Amount ($DD). Position status can include expired_mint,
  abandoned_mint and conflicted_mint.
• Statistics separate open_vault_principal from circulating supply.
  selected_health_denominator identifies the total used for health.
  An unavailable total is not zero.
• Oracle signing keys and required agreement stay the same.
• Use -debug=digidollar if your log tools need routine DD details.
  Errors and startup progress remain visible without it.

Disk space, startup and recovery

Pruning deletes older block files to save space. A pruned node must still keep
DigiDollar's required history. On mainnet, the retention floor remains
23,627,520. Required blocks and the data used to reverse them must stay.

That history can exceed a small prune target. The target is not a hard disk
limit, and this release does not add a warning for every overrun. Leave room
for growth and check actual disk use.

An ordinary upgrade with the required data does not need a full reindex.
A reindex rebuilds the node's chain databases from block history. A late
upgrade may need extra checks; missing files need restoration or download.
Repeated restarts cannot supply missing data.

If recovery fails, keep the error, logs, wallets and block files. Pause any
automatic restart loop while the cause is checked. After Thaw Day, downgrading
to old software is not a repair. If nodes disagree, compare block hashes at
the same height and coordinate recovery before resuming settlement.

Feather's RAM improvements work on installation. On Unix, the new database
file allowance may expose a low system open-file limit. Check that limit if
startup reports it or reduces connections.

All 83 fixes and improvements

Each entry states the change and the reason. Related repairs are grouped.
These are implemented changes, not a claim that every outside bug report is fixed.

Thaw Day and DigiDollar accounting

New block rules wait for Thaw Day. Status reporting and preparation are available before it.

1. Change: All new DigiDollar block rules start at one Thaw Day height on each network.
   Why: Nodes need to change rules at the same point.

2. Change: Status shows the scheduled height and whether the current or next block uses the new rules.
   Why: Operators can see when their node reaches Thaw Day.

3. Change: At Thaw Day, new mints use earlier block prices to check for large price swings.
   Why: Nodes checking the same chain need the same minting reference.

4. Change: At Thaw Day, transfers and redemptions stop using the old volatility freeze.
   Why: The minting price safeguard should not apply that freeze to these operations.

5. Change: At Thaw Day, checks use the prices, coins and history belonging to the block being checked.
   Why: A restart or a different branch must not change the inputs to that block's checks.

6. Change: At Thaw Day, health counts the original DD amounts attached to vaults still open.
   Why: The system needs a consistent measure of what those vaults back.

7. Change: Vault totals are saved with chain data and updated as blocks are added or reversed.
   Why: Accounting must stay with the right chain through restarts and interrupted saves.

8. Change: At Thaw Day, validation and recovery give each vault the same transaction-based identity.
   Why: Both paths must find the same vault.

9. Change: Recovery checks saved vault totals and unchecked Thaw Day history, and rebuilds totals from available records when needed.
   Why: Late upgrades and interrupted recovery must finish their checks before using the results.

10. Change: Status separates DD still in circulation from the amounts attached to open vaults.
    ...

DigiByte Core v9.26.5 DigiDollar Release Notes

DigiByte Core v9.26.5 is a patch release on top of v9.26.4 in the formal
DigiByte v9 / DigiDollar mainnet release line, and it is the first release
after DigiDollar activated on mainnet. DigiDollar locked in through BIP9
miner signaling and became active at block 23,869,440 on 17 July 2026,
alongside the AlgoLock retired-algorithm rule. Taproot has been active since
block 21,168,000.

v9.26.5 contains two changes:

1. A startup fix — the DigiDollar oracle startup scan no longer hangs the
   node for ~15 minutes or longer on mainnet; it now completes in a few seconds.
2. Deployment burial (BIP90) — the Taproot, DigiDollar, and AlgoLock soft
   forks, all now active on mainnet, are converted from live BIP9 version-bits
   deployments into buried deployments with hardcoded activation heights — the
   same housekeeping Bitcoin Core performed for CSV and SegWit after their
   activations.

Neither change alters which blocks or transactions are valid on the current
mainnet or testnet chains. The burial does change several RPC output shapes
and regtest options — see "Breaking Interface Changes" below before upgrading
anything that parses deployment status.

Changes In v9.26.5 Since v9.26.4

• Fixed the ~15-minute DigiDollar oracle startup hang on mainnet (RPC error
  -28 / "Verifying blocks…" / stalled P2P while the node started). Startup is
  now a few seconds.
• Buried the Taproot, DigiDollar, and AlgoLock deployments (BIP90): activation
  is now a fixed per-network height; the BIP9 state machine no longer runs for
  them and blocks no longer signal bits 2, 23, or 0.
• getdigidollardeploymentinfo has a new, simpler "buried" output shape (the
  BIP9 signaling fields are gone), and getdeploymentinfo now reports the
  three deployments as type: "buried".
• getblocktemplate version fields are permanently clean of deployment
  signaling bits; the rules array now always lists taproot, digidollar,
  and algolock once active.
• Regtest testing knobs changed: -digidollaractivationheight=N now activates
  DigiDollar at exactly height N; new
  -testactivationheight=taproot|digidollar|algolock@HEIGHT overrides exist;
  -vbparams for the three buried names is now a startup error.
• Versionbits warning heights raised so historical signaling does not trigger
  spurious "unknown new rules" warnings.
• Documentation updated across the DigiDollar doc set; full release notes in
  doc/release-notes/release-notes-9.26.5.md; new unit and functional tests
  pin the burial heights and boundary behavior.

Read This First

DigiDollar is live on mainnet. There is nothing left to signal and nothing
to configure: any v9.26.5 node on mainnet enforces DigiDollar, AlgoLock, and
Taproot from their recorded activation heights.

Upgrading is drop-in: shut down, replace binaries, restart. No reindex is
required and no configuration changes are needed for normal full or pruned
nodes. Wallets, mining, pruning, and oracle operation continue to work as in
v9.26.4.

Mainnet is normal mainnet:

Fix: DigiDollar Oracle Startup Hang (~15 Minutes → Seconds)

What Happened

On startup, a DigiDollar node rebuilds its in-memory oracle price and
volatility state by scanning the last 172,800 blocks (~30 days). In v9.26.4,
every scanned block re-evaluated the DigiDollar activation gate through a code
path that allocated a throwaway versionbits cache and re-ran the BIP9
threshold state machine from scratch — roughly 172,800 times, with nothing
memoized. On mainnet, right after activation, this took ~15 minutes, held the
main lock before RPC warmup finished (so RPC returned error -28, the GUI sat
on "Verifying blocks…", and P2P stalled), and wrote 150,000+ per-block log
lines.

The Fix

The startup per-block gate now goes through the node's shared, memoized
versionbits cache — the exact same lookup block validation already uses — and
the per-block log flood was replaced with a single aggregate line. Verified
live on mainnet: the oracle startup scan dropped from ~15 minutes to ~3
seconds, and the node came up healthy and caught up.

This is a pure performance change with no consensus impact: unit and
functional tests prove the startup gate computes the identical activation
result at every height, and that a restart equals a -reindex equals the
pre-restart oracle state.

With the deployment burial below, every DigiDollar activation check in the
node becomes a single height comparison, which removes this entire class of
cost permanently — including the per-block cost that block validation itself
was still paying during sync.

Housekeeping: Taproot, DigiDollar, And AlgoLock Are Now Buried (BIP90)

What "Buried" Means

A soft fork activates once. After it is active and buried deep in the chain,
there is no reason to keep re-running the BIP9 signaling state machine for it
on every node forever. "Burying" a deployment (BIP90) replaces the state
machine with the recorded activation height, hardcoded in chainparams —
exactly what DigiByte and Bitcoin already did for CSV, SegWit, ReserveAlgo,
and Odo.

Activation Heights

The heights are the real, on-chain BIP9 activation heights — read from live
mainnet getdeploymentinfo and verified block-by-block on testnet26
(signaling in blocks 200–599, active at exactly 600):

Why Bury Them

• The BIP9 machinery serves no further purpose for these deployments: they can
  never re-signal, time out, or fail.
• It removes all remaining BIP9 threshold-state recomputation from block
  validation and startup. Every DigiDollar activation check is now one height
  comparison.
• Blocks stop signaling bits 2, 23, and 0, so getblocktemplate version
  fields are permanently clean for pool software (this also structurally
  resolves the bit-23 version-rolling interference some SHA256D pool stacks
  reported during signaling).
• It matches upstream practice and shrinks the consensus surface.

What Deliberately Did NOT Change

• The static DigiDollar gates keep their historical floors:
  nDDActivationHeight = nOracleActivationHeight = nDigiDollarMuSig2Height = 23,627,520 on mainnet (600 on testnet26). The 23,627,520 floor is
  intentionally below the 23,869,440 activation height; it continues to
  drive the pruning floor, the prune lock, and the pre-floor collateral gate
  exactly as in v9.26.4, so existing pruned nodes are unaffected.
• The AlgoLock static backstop (nGroestlDeactivationHeight = 23,808,000)
  remains and is still enforced alongside the deployment check —
  retired-algorithm blocks are rejected over exactly the same height ranges as
  before.
• Taproot script validation was already applied unconditionally, so the
  Taproot burial has zero script-consensus effect.

Consensus Compatibility

A v9.26.5 node accepts and rejects exactly the same blocks as a v9.26.4 node
for every block on the current mainnet and testnet chains. The standard BIP90
caveat applies, as it did for Bitcoin's burials: only in the hypothetical of
an astronomically expensive deep reorganization back below the activation
heights could pre-burial and post-burial nodes judge a re-mined chain
differently. This affects no real chain and does not change the security model
in practice.

Versionbits Warnings

MinBIP9WarningHeight rises to 23,909,760 on mainnet (activation height plus
one 40,320-block confirmation window) and 800 on testnet26, so the historical
bit-2/23/0 signaling periods do not trigger spurious "unknown new rules
activated" warnings now that upgraded nodes no longer set those bits.

Breaking Interface Changes

RPC

• getdigidollardeploymentinfo has a new shape. It now returns:

  • enabled — whether DigiDollar is active at the current tip
  • type — always "buried"
  • status — "active" or "defined"
  • activation_height — the burial height (omitted only if the deployment
    is disabled on the network)
  • plus the unchanged oracle/MuSig2 fields (oracle_activation_height,
    musig2_format_activation_height, oracle_pubkey_count,
    oracle_consensus_required, oracle_total_slots, oracle_seed_peers,
    musig2_session{...})

  The BIP9 fields are removed: bit, start_time, timeout,
  min_activation_height, blocks_until_timeout, signaling_blocks,
  threshold, period_blocks, progress_percent. status can no longer be
  started, locked_in, or failed. activation_height now reports the
  exact activation height (previously a back-scan that could differ by one).

• getdeploymentinfo (and REST /deploymentinfo): the taproot,
  digidollar, and algolock entries are now rendered as buried
  deployments — {"type": "buried", "active": <bool>, "height": <N>} — with
  no bip9 sub-object. Anything reading
  deployments.digidollar.bip9.status must switch to active / height.

getblocktemplate

• rules now always contains "taproot", "digidollar", and "algolock"
  once active (hardcoded, like "csv"; no ! prefix, so clients that do not
  understand them may safely proceed).
• vbavailable no longer mentions them, and the template version never sets
  bits 2...

DigiByte Core version 9.26.4

DigiByte Core v9.26.4 is a patch release on top of v9.26.3. It lets mining pools
and users run a pruned node with DigiDollar — a full-validating node that keeps
only a few gigabytes of blocks instead of the entire ~12-year, ~40 GB block history.

In one line: add prune=2000 to your digibyte.conf, upgrade, and your node
runs DigiByte + everything DigiDollar needs on a fraction of the disk.

This release adds one narrowly scoped consensus rule. Redemption collateral
classification is now gated on the DigiDollar activation floor: a coin created below
the floor is never treated as vault collateral, whether it appears as the redemption's
input 0 (rejected as bad-collateral-release-not-vault) or as a fee input (see
ValidateCollateralReleaseAmount in src/digidollar/validation.cpp). This rule is
what keeps pruned and full nodes in agreement, and the pre-release mainnet scan found
no existing coins it affects (V9.26.4_MAINNET_VALIDATION.md). v9.26.2's Groestl
algolock and the DigiDollar BIP9 deployment are carried forward unchanged, and a
pruned v9.26.4 node accepts and rejects exactly the same blocks and transactions as a
full node. Upgrading is optional — a node that does not set -prune behaves like
v9.26.3 except for this one rule; node operators, pools, and exchanges should treat it
as a consensus rule addition when assessing upgrade urgency.

How to Upgrade

Shut down DigiByte Core, replace the binaries, and restart. A reindex is not
required to upgrade a normal (full) node.

To run in pruned mode, add one line to digibyte.conf:

prune=2000
# no txindex line — prune turns the transaction index off automatically

prune=N is a target size in MiB (minimum 550; 2000 gives comfortable headroom).
See "How to enable pruning" below for the full steps.

Background: where v9.26.4 fits in the v9.26 line

If you are new to DigiByte v9, this section explains the moving parts. Nothing here
is new in v9.26.4 — it is the context every v9.26 node already runs under.

DigiByte v9 = Bitcoin Core v26.2 base + DigiDollar. The v9 line rebased DigiByte
onto the Bitcoin Core v26.2 generation and added DigiDollar, a native USD-pegged
stablecoin, together with a multi-oracle DGB/USD price feed secured by MuSig2 Schnorr
threshold signatures (35 oracle slots, 7 signatures required for consensus on
mainnet and testnet).

DigiDollar is not active yet, and installing this software does not activate it.
DigiDollar turns on through BIP9 miner signaling (deployment bit 23). Until the
network signals it in, all DigiDollar consensus, RPC, and P2P surface stays dormant;
the node follows the deployment automatically via IsDigiDollarEnabled(). The
-digidollar flag is not required and only affects regtest. Activation status:
https://digibyte.io/activation

The activation floor. DigiDollar can never activate below a fixed minimum height:
23,627,520 on mainnet (block 600 on testnet26). This single number is the key to
this release — see "Why pruning is safe" below. On mainnet the oracle, MuSig2, and
DigiDollar height gates all collapse to that same height.

What each v9.26 patch added:

• v9.26.2 — the formal DigiDollar mainnet release, and an urgent consensus
  security fix: the Groestl algolock, which re-enforces the rejection of the
  retired Groestl mining algorithm (accidentally dropped during the v8 rebase, then
  exploited in June 2026). This was a mandatory, network-wide upgrade. It is carried
  forward unchanged in v9.26.4 and continues to reject retired-algorithm blocks.
• v9.26.3 — fixed a fresh-node header-sync loop (mainnet nMinimumChainWork
  reverted to 0x00) and made -txindex on by default so DigiDollar nodes start
  out of the box.
• v9.26.4 (this release) — makes DigiDollar compatible with pruning, so the
  txindex-and-full-history requirement introduced by v9.26.3 is no longer forced on
  operators who want a small node.

Notable changes

Pruning with DigiDollar

Before v9.26.4, a DigiDollar node had to run -txindex and could not prune. The two
are mutually exclusive in Bitcoin Core, and DigiDollar validation resolved a spent
DigiDollar output's amount and lock term through the transaction index — which needs
the full chain. That meant every DigiDollar node, including a mining pool that only
cares about the tip, had to store the entire history plus the index. v9.26.4 removes
that restriction.

Why pruning is safe (the core idea). A DigiDollar coin can only be created at or
after DigiDollar activates, and activation can never happen below the activation floor
(mainnet 23,627,520). Therefore every block that DigiDollar validation will ever need
to read lives in the window from that floor to the chain tip. Everything below the
floor is ordinary pre-DigiDollar history that DigiDollar never needs — so it is safe to
delete forever. A pruned v9.26.4 node keeps the [floor, tip] window and prunes the
rest, using three small pieces of wiring:

1. A prune lock at the activation floor. At startup the node registers a
   "digidollar" prune lock at the floor height. Both automatic (size-target) pruning
   and the pruneblockchain RPC are clamped below it, so a pruned node can never
   delete a DigiDollar-era block — even if you explicitly ask it to.

2. No transaction index needed under prune. DigiDollar amount/lock lookups read the
   creating transaction directly from the retained block at the coin's height instead
   of from the index. Every lookup fails closed: if data cannot be found, the
   transaction or block is rejected — the node never accepts something it could not
   verify.

3. A startup safety guard. If a pruned data directory is ever missing or cannot
   read a DigiDollar-era block (for example, it was pruned under different rules or a
   block file is damaged), the node refuses to start and asks you to restart with
   -reindex, rather than validating DigiDollar with incomplete data.

Result: a pruned node validates, mines, mints, sends, redeems, and can even run a
DigiDollar oracle exactly like a full node, on a fraction of the disk.

Pruned nodes validate identically to full nodes. DigiDollar's collateral checks
are gated on the activation floor so a pruned node (which does not keep pre-floor
blocks) and a full node (which does) reach the same verdict on every redeem. A coin
created below the floor can never be real collateral, and both node types now treat it
that way. There is no reachable state in which a pruned node accepts or rejects a
DigiDollar transaction differently from a full node.

How to enable pruning (digibyte.conf)

Upgrading an existing v9.26.3 node (the mining-pool path):

1. Shut the node down.

2. Edit digibyte.conf: add prune=2000, and remove any txindex=1 line.
   With no txindex line present, v9.26.4 turns the index off automatically under
   prune. (Testnet options go under a [test] section — remove txindex=1 there too.)

3. Replace the binaries with v9.26.4 and start. The node prunes in place — no
   resync and no reindex. The first start spends a few extra minutes, one time, marking
   the old blocks as pruned. Confirm it worked by looking for this line in debug.log:

   DigiDollar: pruning enabled; retaining all blocks at/above height 23627520 (DigiDollar activation floor)
   

A fresh node: use the same config; it syncs from the network and prunes as it goes.

Notes: prune=1 selects manual mode (pruning only happens when you call the
pruneblockchain RPC). Wallets and getblocktemplate mining work normally. To return
to a full archival node later, remove prune=, set txindex=1, and restart with
-reindex (the node re-downloads the full chain).

Notes and limitations for pruned nodes

• Disk grows after activation. A pruned node keeps the DigiDollar-era window plus
  the chainstate instead of the full chain plus a transaction index. That window grows
  with the chain: once DigiDollar activates, every block from just below the activation
  height to the tip is retained permanently, so disk usage grows over time and can
  exceed the prune=N target. What pruning saves is the ~12 years of pre-DigiDollar
  history (and the index) — a one-time saving, not a fixed size cap.
• Serving history. A pruned node advertises NODE_NETWORK_LIMITED and serves only
  the most recent blocks to peers; it does not help new nodes with their initial sync.
  The network's full (archival) nodes continue to do that. Older DigiByte peers
  (v9.26.2/v9.26.3/v8) understand this service bit and interoperate normally.
• getrawtransaction for a transaction in a deleted (pre-DigiDollar-era) block is
  unavailable without a transaction index, as on any pruned node. Use -txindex on an
  archival node for arbitrary historical lookups.
• getdigidollarstats still reports current supply / collateral / health / position
  counts on a pruned node via a live UTXO scan; the optional DigiDollar stats index
  (used only for historical per-height queries) is left off under -prune. That scan
  walks the whole UTXO set on each call, so avoid polling it at high frequency on a
  pruned node.
• Wallets. A wallet whose birthday predates the pruned history requires -reindex
  to rescan (standard pruned-node behavior). Wallets created on or after DigiDollar
  activation are entirely within the retained window and rescan normally.
• -reindex on a pruned node redownloads from the network. It deletes local block
  files ...

DigiByte Core version 9.26.3

DigiByte Core v9.26.3 is a patch release on top of v9.26.2. It fixes a
fresh-node header synchronization regression and makes the transaction index
on by default so DigiDollar nodes start cleanly. All v9.26.2 users — and
anyone setting up a new node — should upgrade. It contains no consensus rule
changes; v9.26.2's Groestl algolock and the DigiDollar BIP9 deployment are
carried forward unchanged.

How to Upgrade

Shut down DigiByte Core, replace the binaries, and restart. A reindex is not
required for this release.

Notable changes

Fresh-node header sync fixed (nMinimumChainWork)

A fresh v9.26.2 node could pre-synchronize block headers to ~99.98% and then
reset back to a lower height, looping forever with headers=0 and never leaving
initial block download.

Root cause: the v9.26.2 release metadata refresh set mainnet
consensus.nMinimumChainWork to a value derived from the node's real chainwork
(~98.68% of the tip). DigiByte's header pre-synchronization, however, measures
work from a contextless CBlockIndex (no height or previous-block context), which
in DigiByte's multi-algorithm work model only accumulates to roughly 28% of the
real chainwork. The pre-sync work total therefore could never cross the threshold,
so the node aborted and restarted pre-sync indefinitely.

Fix: mainnet nMinimumChainWork is reverted to 0x00 — the value mainnet used
for its entire history before the v9.26.2 refresh, and a value the pre-sync always
reaches. This is a chain-metadata fix only; it does not change consensus, chain
selection, or anti-DoS posture relative to mainnet's prior behavior. Testnet,
signet and regtest are unaffected (their values were already pre-sync-reachable).

Background and a full validation plan are in HEADERS_SYNC_FIX_PLAN.md.

Transaction index on by default

-txindex now defaults to on (DEFAULT_TXINDEX = true). DigiDollar requires a
full transaction index (mint/transfer/redeem scanning, collateral lookups,
getrawtransaction), and the node already refuses to start with DigiDollar active
and -txindex off. Defaulting it on lets DigiDollar nodes start out of the box.
Operators who do not want a transaction index can still set -txindex=0 on
non-DigiDollar configurations.

Note: the -digidollar startup flag is not required and is not enabled by
default. DigiDollar consensus, RPC, and P2P all follow the BIP9 deployment
automatically (IsDigiDollarEnabled()); the flag only affects regtest.

Credits

Thanks to everyone who diagnosed the fresh-node sync issue against live nodes.

Read This First

DigiByte v9 is a major new release line since v8.26.2. It updates the DigiByte
Core base to the Bitcoin Core v26.2 generation and adds the DigiDollar soft-fork
deployment.

DigiDollar does not become usable on mainnet simply because this software is
released. It activates through BIP9 miner signaling. You can follow deployment
status at:

https://digibyte.io/activation

Mainnet is normal mainnet:

Do not use the old pre-mainnet test ports, temporary data directories, or
modified activation settings with this release.

Critical Consensus Fix: Retired-Algorithm Enforcement (Groestl)

Separately from DigiDollar, v9.26.3 ships an urgent consensus security fix.
Every node on the DigiByte network must upgrade to v9.26.3. This is not
optional and is independent of whether you use DigiDollar.

What Happened

DigiByte secures the chain with five mining algorithms (SHA256d, Scrypt, Skein,
Qubit, Odocrypt). A sixth algorithm, Groestl, was retired in 2019 at the Odocrypt
fork. The rule that rejected retired-algorithm blocks existed in the v7.17.3-era
software, but it was accidentally dropped during the v8 Bitcoin Core rebase in
2021/2022. The function that knew Groestl was retired still existed and was used
for difficulty and display, but the single line that enforced it when accepting a
block was gone. Because nobody mined Groestl, its difficulty fell to the lowest
possible setting and the gap stayed dormant for years.

Starting 2026-06-28 16:40:05 UTC, at block 23,751,096, an actor — using AI to
analyze DigiByte's consensus rules — reactivated Groestl and began mining a sixth
algorithm at floor difficulty.

No coins were stolen and no confirmed transactions were reversed. There is no
evidence of a successful 51% attack, though the cheap mining is consistent with an
attempt: across every competing branch the network has seen, none ever accumulated
more total work than the honest chain, and the deepest reorganization of the
active chain was 4 blocks. The damage was instability and a network split. Block
times dropped from the 15-second target to roughly 12-13 seconds, and the network
divided, because v8/v9 software accepted the Groestl blocks while old v7.17.3
software rejected them and forked onto a separate, slower chain.

The Fix

v9.26.3 restores retired-algorithm enforcement, the right way:

• Blocks using a retired (Groestl) or unknown mining algorithm are rejected.
• The rule is enforced in both header validation and block connection, so that
  -reindex and -reindex-chainstate also enforce it. A node cannot carry a
  post-activation retired-algorithm block forward after upgrading.
• Existing Groestl blocks already buried in the chain are grandfathered (kept).
  No history is rewritten and no transactions are reversed.

Mainnet Activation Parameters (Groestl Deactivation)

The algolock versionbit is a readiness signal that lets miners advertise they
have upgraded; you can watch adoption with getdeploymentinfo. The rule activates
at block 23,808,000 regardless of signaling, giving the network roughly seven days
to upgrade before retired-algorithm blocks are rejected.

All Nodes Must Upgrade

Every full node, miner, pool, exchange, explorer, wallet, and service must upgrade
to v9.26.3. The majority of mining power is currently on the v8 line. That is fine,
but all of it must move to v9.26.3 so that the upgraded chain is the strongest
chain at activation and the network converges back onto a single chain.

v7.17.3 And Older Nodes Must Reindex On Upgrade

Nodes running the ~7-year-old v7.17.3 line reject every post-Odocrypt Groestl
block, including the grandfathered blocks the healed chain keeps. They therefore
cannot follow the unified chain on their own. Operators on v7.17.3 (or older) must:

1. Upgrade to v9.26.3.
2. Reindex or resync (start with -reindex, or perform a fresh sync) so the node
   accepts the existing chain history and reorganizes onto the correct chain.

Upgrading also provides Taproot, DigiDollar, and every other improvement added
since v7.17.3.

Miners And Pools: The 7-Day Window

• Upgrade to v9.26.3 within the ~7-day window before block 23,808,000.
• Use the block version returned by DigiByte Core and do not strip the algolock
  readiness signal.
• Once the majority of mining power is upgraded, retired-algorithm blocks are
  orphaned, the attack ends, and the network heals into one chain.
• Optional, during the window only: miners who wish to actively push back can point
  hash power at Groestl themselves. This captures block rewards that would
  otherwise go to the attacker and drives Groestl difficulty up, removing the
  cheap-mining advantage. This is secondary to upgrading and keeps block times fast
  while it lasts; after activation, Groestl is rejected regardless.

Forensic detail (as of this release, mining was still ongoing): the Groestl blocks
account for roughly 14-15% of all blocks since onset and are paid to two attacker
payout addresses — dgb1qy5epvfs535a96tygn945a3a85lauh3ddu9v63y (coinbase tag
SORG) and D8S5JWaCrpFsryGG1c9AzWKhbS7e7VZ4r8. Exchanges and custodians should
flag deposits originating from these addresses until the network has healed.

Who Should Upgrade

All full nodes, miners, mining pools, exchanges, explorers, wallets, service
providers, and oracle operators should upgrade.

Old nodes can continue to see normal DigiByte blocks, but they are not
DigiDollar-aware. They cannot fully validate, display, index, mine, or serve the
new DigiDollar functionality. Miners and pools must upgrade and signal for the
soft fork if they want DigiDollar to activate.

Back up wallets before upgrading, especially wallets that hold oracle keys or
will hold DigiDollar positions.

What Is DigiDollar?

DigiDollar is a native USD-denominated asset system built into DigiByte Core.
Each DD is designed to track one US dollar by using over-collateralized DGB
vaults, live oracle pricing, Dynamic Collateral Adjustment (DCA), Emergency
Reserve Ratio (ERR), and volatility protections.

DigiDollar is not an external smart contract, wrapped token, or custodial bank
reserve product. It is built into DigiByte consensus and wallet logic. Users
keep their own keys. DGB remains the collateral and the fee asset.

The basic user flow is:

1. Mint DD by locking DGB collateral in a Taproot vault.
2. ...

DigiByte Core v9.26.2 DigiDollar Release Notes

DigiByte Core v9.26.2 is the formal DigiByte v9 release and the official
DigiDollar mainnet activation release.

This is not another RC, PRE build, modified-mainnet rehearsal, or oracle-only
test build. This release returns to normal DigiByte mainnet settings and is
intended for the full public network. Everyone running DigiByte infrastructure
should upgrade from v8.26.2 or older.

Read This First

DigiByte v9 is a major new release line since v8.26.2. It updates the DigiByte
Core base to the Bitcoin Core v26.2 generation and adds the DigiDollar soft-fork
deployment.

DigiDollar does not become usable on mainnet simply because this software is
released. It activates through BIP9 miner signaling. You can follow deployment
status at:

https://digibyte.io/activation

Mainnet is normal mainnet:

Do not use the old pre-mainnet test ports, temporary data directories, or
modified activation settings with this release.

Critical Consensus Fix: Retired-Algorithm Enforcement (Groestl)

Separately from DigiDollar, v9.26.2 ships an urgent consensus security fix.
Every node on the DigiByte network must upgrade to v9.26.2. This is not
optional and is independent of whether you use DigiDollar.

What Happened

DigiByte secures the chain with five mining algorithms (SHA256d, Scrypt, Skein,
Qubit, Odocrypt). A sixth algorithm, Groestl, was retired in 2019 at the Odocrypt
fork. The rule that rejected retired-algorithm blocks existed in the v7.17.3-era
software, but it was accidentally dropped during the v8 Bitcoin Core rebase in
2021/2022. The function that knew Groestl was retired still existed and was used
for difficulty and display, but the single line that enforced it when accepting a
block was gone. Because nobody mined Groestl, its difficulty fell to the lowest
possible setting and the gap stayed dormant for years.

Starting 2026-06-28 16:40:05 UTC, at block 23,751,096, an actor — using AI to
analyze DigiByte's consensus rules — reactivated Groestl and began mining a sixth
algorithm at floor difficulty.

No coins were stolen and no confirmed transactions were reversed. There is no
evidence of a successful 51% attack, though the cheap mining is consistent with an
attempt: across every competing branch the network has seen, none ever accumulated
more total work than the honest chain, and the deepest reorganization of the
active chain was 4 blocks. The damage was instability and a network split. Block
times dropped from the 15-second target to roughly 12-13 seconds, and the network
divided, because v8/v9 software accepted the Groestl blocks while old v7.17.3
software rejected them and forked onto a separate, slower chain.

The Fix

v9.26.2 restores retired-algorithm enforcement, the right way:

• Blocks using a retired (Groestl) or unknown mining algorithm are rejected.
• The rule is enforced in both header validation and block connection, so that
  -reindex and -reindex-chainstate also enforce it. A node cannot carry a
  post-activation retired-algorithm block forward after upgrading.
• Existing Groestl blocks already buried in the chain are grandfathered (kept).
  No history is rewritten and no transactions are reversed.

Mainnet Activation Parameters (Groestl Deactivation)

The algolock versionbit is a readiness signal that lets miners advertise they
have upgraded; you can watch adoption with getdeploymentinfo. The rule activates
at block 23,808,000 regardless of signaling, giving the network roughly seven days
to upgrade before retired-algorithm blocks are rejected.

All Nodes Must Upgrade

Every full node, miner, pool, exchange, explorer, wallet, and service must upgrade
to v9.26.2. The majority of mining power is currently on the v8 line. That is fine,
but all of it must move to v9.26.2 so that the upgraded chain is the strongest
chain at activation and the network converges back onto a single chain.

v7.17.3 And Older Nodes Must Reindex On Upgrade

Nodes running the ~7-year-old v7.17.3 line reject every post-Odocrypt Groestl
block, including the grandfathered blocks the healed chain keeps. They therefore
cannot follow the unified chain on their own. Operators on v7.17.3 (or older) must:

1. Upgrade to v9.26.2.
2. Reindex or resync (start with -reindex, or perform a fresh sync) so the node
   accepts the existing chain history and reorganizes onto the correct chain.

Upgrading also provides Taproot, DigiDollar, and every other improvement added
since v7.17.3.

Miners And Pools: The 7-Day Window

• Upgrade to v9.26.2 within the ~7-day window before block 23,808,000.
• Use the block version returned by DigiByte Core and do not strip the algolock
  readiness signal.
• Once the majority of mining power is upgraded, retired-algorithm blocks are
  orphaned, the attack ends, and the network heals into one chain.
• Optional, during the window only: miners who wish to actively push back can point
  hash power at Groestl themselves. This captures block rewards that would
  otherwise go to the attacker and drives Groestl difficulty up, removing the
  cheap-mining advantage. This is secondary to upgrading and keeps block times fast
  while it lasts; after activation, Groestl is rejected regardless.

Forensic detail (as of this release, mining was still ongoing): the Groestl blocks
account for roughly 14-15% of all blocks since onset and are paid to two attacker
payout addresses — dgb1qy5epvfs535a96tygn945a3a85lauh3ddu9v63y (coinbase tag
SORG) and D8S5JWaCrpFsryGG1c9AzWKhbS7e7VZ4r8. Exchanges and custodians should
flag deposits originating from these addresses until the network has healed.

Who Should Upgrade

All full nodes, miners, mining pools, exchanges, explorers, wallets, service
providers, and oracle operators should upgrade.

Old nodes can continue to see normal DigiByte blocks, but they are not
DigiDollar-aware. They cannot fully validate, display, index, mine, or serve the
new DigiDollar functionality. Miners and pools must upgrade and signal for the
soft fork if they want DigiDollar to activate.

Back up wallets before upgrading, especially wallets that hold oracle keys or
will hold DigiDollar positions.

What Is DigiDollar?

DigiDollar is a native USD-denominated asset system built into DigiByte Core.
Each DD is designed to track one US dollar by using over-collateralized DGB
vaults, live oracle pricing, Dynamic Collateral Adjustment (DCA), Emergency
Reserve Ratio (ERR), and volatility protections.

DigiDollar is not an external smart contract, wrapped token, or custodial bank
reserve product. It is built into DigiByte consensus and wallet logic. Users
keep their own keys. DGB remains the collateral and the fee asset.

The basic user flow is:

1. Mint DD by locking DGB collateral in a Taproot vault.
2. Send DD between DigiDollar addresses.
3. Redeem DD by burning it and unlocking the corresponding DGB collateral under
   the consensus rules.

Major Changes Since v8.26.2

DigiByte Core v26.2 Foundation

v9.26.2 moves DigiByte onto the Bitcoin Core v26.2 generation of code. That
brings a large base-layer modernization compared with v8.26.2, including newer
networking, wallet, descriptor, RPC, mempool, build, and testing
infrastructure.

Notable inherited Core-era changes include BIP324 v2 transport support,
descriptor and Taproot wallet improvements, Taproot Miniscript support,
stricter wallet loading behavior, newer package/RPC tools such as
submitpackage, importmempool, getaddrmaninfo,
getprioritisedtransactions, and the v26-era RPC deprecations and serialization
cleanup.

DigiByte-specific consensus history remains intact. Historical DigiByte fork
heights, multi-algo behavior, DigiShield, MultiShield, DigiSpeed, Odocrypt, and
existing mainnet identity are not reset by this release.

DigiDollar V1

v9.26.2 adds the first mainnet DigiDollar release:

• Native DD, TD, and RD DigiDollar address formats.
• Mint, send, batch-send, and redeem flows.
• Taproot collateral vaults.
• Confirmed-only DigiDollar UTXO spending.
• Canonical lock tiers, including the current short and long lock options.
• Minimum mint, maximum mint, output floor, and maximum transfer enforcement.
• DCA, ERR, and volatility protection logic.
• Network-wide DigiDollar statistics and optional stats indexing.
• Wallet restore, rescan, reindex, and reorg handling for DigiDollar state.
• OP_CHECKPRICE reserved and disabled for V1.

Mainnet mint/redeem safety depends on fresh MuSig2 oracle price bundles.
DigiDollar transfers are price-independent, but still require valid DD inputs
and DGB fee inputs.

Oracle And MuSig2 System

DigiDollar mainnet uses a 7-of-35 oracle quorum. The oracle set publishes DGB/USD
price data using MuSig2 v0x03 aggregate bundles. The aggregate signature is
committed into the mined block when price-dependent DigiDollar mint or redeem
transactions need it.

Mainnet oracle parameters:

DigiByte Core v8.26.2 — Formal Full Release

This is the official full release of DigiByte Core version 8.26.2
All DigiByte exchanges, wallets, mining pools, explorers, and infrastructure services using DigiByte Core as a backend are strongly advised to upgrade immediately for full Taproot support, enhanced test infrastructure, and improved cross-platform UI performance.

This release represents the culmination of the v8.26 development cycle and is now the stable reference version for all DigiByte Core deployments.

DigiByte Core v8.26.2 Release Notes

Release Date: January 2026
Full Changelog: v8.26.1...v8.26.2

Summary

DigiByte Core v8.26.2 is a maintenance release containing critical bug fixes for RPC performance and correctness issues. All users are strongly encouraged to upgrade.

This release addresses two bugs that were introduced during the Bitcoin Core v26.2 merge:

1. Performance regression in getblockchaininfo RPC (6-10x slowdown)
2. Incorrect difficulty reporting in getmininginfo RPC

Notable Changes

Fix: getblockchaininfo RPC Performance Regression (#345)

Issue: The getblockchaininfo RPC call was taking approximately 3 seconds to complete on nodes with fully synced chains, compared to sub-second responses in previous versions.

Root Cause: The Bitcoin Core v26.2 merge inadvertently changed the difficulty calculation to use GetLastBlockIndexForAlgo(), which performs an O(n) linear search through the blockchain to find the last block for each mining algorithm. With DigiByte's ~23 million blocks and 5-6 difficulty lookups per RPC call, this caused significant latency.

Fix: Changed to use GetLastBlockIndexForAlgoFast(), which uses DigiByte's pre-existing O(1) cached algorithm lookup infrastructure. This function is already proven in PoW validation code paths.

Impact:

• Before: ~3 seconds per RPC call
• After: ~0.3-0.5 seconds per RPC call
• 6-10x performance improvement

Fix: getmininginfo Difficulty Returns Wrong Algorithm (#346)

Issue: The difficulty field in getmininginfo RPC was returning a fixed value that didn't change regardless of the current mining algorithm. Investigation revealed it was always returning Groestl's difficulty (algo=2).

Root Cause: During the Bitcoin Core v26.2 merge, the miningAlgo parameter was accidentally omitted from the GetDifficulty() call, causing it to default to algorithm 2 (Groestl) instead of using the node's configured mining algorithm.

Fix: Restored the miningAlgo parameter to the GetDifficulty() call so that the reported difficulty correctly reflects the current mining algorithm.

Impact: Mining pools and monitoring tools now receive correct difficulty values for their configured algorithm.

Files Changed

Upgrade Instructions

For Node Operators

1. Stop your DigiByte node: digibyte-cli stop
2. Replace binaries with v8.26.2 release
3. Start node: digibyted

No configuration changes or reindex required.

For Miners and Mining Pools

This release is critical for mining operations. The getmininginfo bug caused incorrect difficulty reporting which could affect stratum difficulty calculations.

1. Update to v8.26.2 immediately
2. Verify correct difficulty reporting: digibyte-cli getmininginfo
3. Confirm the difficulty field matches your configured mining algorithm

For Exchanges and Services

The performance improvement in getblockchaininfo may significantly reduce RPC latency for monitoring and status checks. No action required beyond the standard upgrade process.

Testing

Both fixes include regression tests to prevent future occurrences:

• Performance benchmarks for getblockchaininfo RPC
• Algorithm-specific difficulty verification in feature_digibyte_multialgo_mining.py

Credits

Thanks to the community members who reported these issues and contributed to the investigation:

• Issue #345 reported by community members experiencing RPC slowdowns
• Issue #346 reported by mining pool operators noticing incorrect difficulty values

Previous Release

For changes in v8.26.1, see: https://github.com/DigiByte-Core/digibyte/releases/tag/v8.26.1

DigiByte Core v8.26.1 — Formal Full Release

This is the official full release of DigiByte Core version 8.26.
All DigiByte exchanges, wallets, mining pools, explorers, and infrastructure services using DigiByte Core as a backend are strongly advised to upgrade immediately for full Taproot support, enhanced test infrastructure, and improved cross-platform UI performance.

This release represents the culmination of the v8.26 development cycle and is now the stable reference version for all DigiByte Core deployments.

Overview

Version: v8.26.1
Previous Version: v8.26.0
Release Type: Formal Stable Release
Release Date: October 30, 2025

This release includes:

• Full Taproot activation support for DigiByte Mainnet
• Critical test infrastructure updates
• Major UI rendering fixes across Windows, macOS, and Linux
• Updated translations for multiple global languages
• Integration of BIP324 (V2 Transport Protocol) functional testing

Version Summary

• Formal release of DigiByte Core 8.26

  • This marks the stable build to replace all previous 8.25.x and 8.26.0-beta releases.
  • All production environments should migrate to this version.

• Version bump: 8.26.0 → 8.26.1

• Fixed macOS build issues after latest SDK and Xcode updates

• Fixed Test Runner QT URL issue affecting test suite integrity

Translation & Localization Updates

Ensuring consistent global branding across all translated wallets and interfaces, matching official usage on https://digibyte.org:

V2 Transport Protocol (BIP324) Testing

The DigiByte Core v8.26.1 release introduces full testing support for BIP324 (Transport V2) — the next-generation encrypted peer-to-peer communication layer.

• Added functional test suite coverage for V2 transport negotiation
• V2 transport remains disabled by default
  (Enable using -v2transport=1 in digibyte.conf or command line)
• Removed obsolete RPC planning documents
• Updated test_runner.py to include V2 transport test variants

BIP324 enhances DigiByte’s P2P layer with optional end-to-end encryption between nodes, improving privacy, reducing metadata exposure, and paving the way for future network-level protocol advancements.

Qt Wallet — Cross-Platform UI Fixes

Comprehensive fixes for both dark and light modes, ensuring proper rendering and readability across all supported platforms.

Dark Mode Improvements

• Fixed invisible transaction text on Linux caused by light backgrounds
• Corrected alternating row colors in transaction tables
• Removed invalid CSS syntax (!important) causing macOS issues
• Improved visibility with dark blue backgrounds for transaction lists

Light Mode Improvements

• Fixed File menu dropdown text rendering on dark backgrounds
• Improved transaction hash label visibility
• Restored proper color-coded amounts (green = received, red = sent)
• Removed redundant overrides breaking color mapping

Developer Infrastructure Enhancements

Introduced an external CSS hot-loading system to accelerate wallet UI development:

• Added optional external CSS reloader (disabled by default)
• Activate by uncommenting in digibyte.cpp
• Loads styles from ~/.digibyte-dev/css/
• Integrated QFileSystemWatcher for automatic refresh on file change
• Disabled by default

This enables real-time theming and testing for developers without recompiling.

Technical Summary

Upgrade Instructions

All DigiByte Core operators must upgrade to v8.26.1 to maintain full compatibility and consensus validation with Taproot-enabled blocks.

Recommended upgrade path:

1. Stop all DigiByte Core or daemon instances.
2. Backup your wallet.dat and configuration files.
3. Install DigiByte Core v8.26.1.
4. Restart with existing blockchain data — no reindex required unless otherwise indicated.
5. Verify your node version via getnetworkinfo → subversion: /DigiByte:8.26.1/.

Exchanges, explorers, and pools must upgrade immediately to ensure full Taproot validation and P2P compatibility.

Acknowledgements

Massive thanks to all DigiByte Core contributors, translators, and testers who have helped ensure this release is stable, secure, and globally accessible.

Useful Links

• Source Code: https://github.com/DigiByte-Core/digibyte
• Website: https://digibyte.org
• Community: https://t.me/DigiByteCoin
• Documentation: https://docs.digibyte.org

Final Statement

DigiByte Core v8.26.1 is the official, fully stable release of the v8.26 branch.
It finalizes the integration of Taproot, extends network privacy via BIP324, enhances global language support, and modernizes wallet visuals for a cleaner, consistent experience.

Upgrade now to ensure full compatibility with the DigiByte main network and to support the continued decentralization, speed, and security of DigiByte — the world’s longest-running, most secure UTXO blockchain.

What's Changed

• v8.26.1 Release - Fix GUI Issues, Enable V2 Transport Tests by @JaredTate in #338

Full Changelog: v8.26.0...v8.26.1