根據該專案的時程表，允許電腦獨立驗證比特幣支付的開源軟體 Bitcoin Core 32.0 已於週一進入候選版本（release candidate）測試。候選版本是正式發布前釋出的測試版本，讓測試人員能在最終版本問世前找出剩餘問題。開發者目標在 10 月 10 日推出完成版本，但測試結果仍可能使時程變動。

此次更新主要影響使用該軟體運行錢包與其他服務的節點營運者和開發者，而非一般錢包應用程式的日常使用者。效能是核心重點：根據草案版發布說明，此次更新可透過並行讀取資料庫資訊來加快區塊檢查速度，且不會改變比特幣產出區塊的速度。更快的驗證之所以重要，是因為全節點的核心工作就是依據網路規則檢查每個新區塊——區塊大約每十分鐘產出一個——因此減少這項工作可減輕在無需信任第三方的情況下持續驗證支付的負擔。

四個錢包指令也將預設改用較新的格式，在錢包與簽署裝置之間交換部分簽署交易——此格式可讓未完成的交易在完成前於多個裝置上收集簽章——不過應用程式仍可依需求請求使用舊版格式。

資安是此次發布的另一項重點。其中一項修復可防止精心構造的錢包名稱在節點的電腦上觸發指令執行。該漏洞影響非 Windows 系統，在已驗證使用者可建立錢包、且 walletnotify 功能被設定為在錢包交易發生時執行指令的情況下會受到影響。這類錯誤之所以受到高度關注，是因為它模糊了資料與指令之間的界線：錢包名稱通常只是一個標籤，卻可能與 walletnotify 功能的指令執行產生互動，而此修補程式切斷了這條路徑。

另一項獨立的修補程式則解決專案新版 HTTP 伺服器中過度使用記憶體的問題，該伺服器負責處理來自已連線應用程式的請求。貢獻者 Matthew Zipkin（暱稱 pinheadmz）在其修補程式提案中描述了一個「記憶體耗盡情境」。他最初的評估將風險範圍限定於已驗證的用戶端。

Zipkin 表示，他是在使用 AI 模型 Kimi K3 審計 Bitcoin Core 新版 HTTP 伺服器時發現該漏洞，該模型也曾被比特幣紅隊用來搜尋比特幣軟體中的漏洞。他解釋，較早前的復已解決部分問題，但仍存在一種耗盡電腦可用記憶體的方式——即所謂的「OOM」（out-of-memory，記憶體耗盡）狀態。

在審查同一修補程式期間，GitHub 使用者 jeanpablojp 發現，在啟用 REST 介面的情況下，未提交憑證的請求也可能導致記憶體增長。Zipkin 修訂修補程式後，審查者回報，16 個未經驗證的連線在 90 秒內造成約 3 MB 的記憶體增長，相比之下，修改前為 3.2 GB。修訂後的修補程式已於 9 月 5 日併入 Bitcoin Core 32.0，作為持續改善該軟體資安工作的一部分。未經驗證的案例使擔憂範圍超出最初的評估，因為這類請求不需要受信任的已登入使用者。

此次修補程式落地之際，比特幣相關軟體正處於一波更廣泛的漏洞應對期。硬體錢包製造商 BitBox 於 8 月修補了兩個嚴重的韌體漏洞，並表示沒有證據顯示已被利用。另外，支付軟體 Core Lightning 的開發者也在準備修復的同時，就已確認的漏洞向節點營運者發出警告。從現在到 10 月 10 日之間的候選版本將顯示目標日期能否維持，而這些修復只有在營運者實際運行更新版本後才會生效。