From 7e2014b4c90c864b70f71a0dc0d554b715ef8ea0 Mon Sep 17 00:00:00 2001 From: Ivan Shumkov Date: Thu, 5 Nov 2026 14:56:09 +0700 Subject: [PATCH 1/2] docs(book): describe asset unlock payload version 2 as a Core fork record consumer Co-Authored-By: Claude Opus 5.5 --- book/src/architecture/core-fork-activations.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/book/src/architecture/core-fork-activations.md b/book/src/architecture/core-fork-activations.md index a1e42bcd9c9..236d221b064 100644 --- a/book/src/architecture/core-fork-activations.md +++ b/book/src/architecture/core-fork-activations.md @@ -186,6 +186,18 @@ Code that depends on a Core fork reads the record through follows the rule in [The window after a protocol upgrade](#the-window-after-a-protocol-upgrade). +Withdrawals leave Platform as asset unlock transactions on Core, and Core +accepts asset unlock payload version 2 only once V24 is active. From protocol +version 15, withdrawal pooling (step 14 of the block, +`build_untied_withdrawal_transactions_from_documents` v1 under +`packages/rs-drive-abci/src/execution/platform_events/withdrawals/`) builds +version 2 once V24 is recorded. The exception is a withdrawal whose amount is +below Core's dust threshold: Core can never relay it, so Platform may eventually +mark it failed, which is safe only for version 1. Pooling runs after +`update_core_info`, so a withdrawal pooled in the block that records V24 is +already version 2. In the window before the record, withdrawals stay at version +1, which Core always accepts. Pooling never asks Core about V24. + One piece of code still asks Core about V24 directly: the masternode list update's `drop_unchanged_operator_keys`, which keeps a masternode's operator key when Core re-encodes it after V24. It runs under every protocol version, and From 60c378bc3accf666783bd0b94b8f4a9aae2f3fc9 Mon Sep 17 00:00:00 2001 From: Ivan Shumkov Date: Thu, 5 Nov 2026 18:20:14 +0700 Subject: [PATCH 2/2] docs(book): qualify the dust relay claim and the same-block V24 sentence Co-Authored-By: Claude Opus 5.5 --- book/src/architecture/core-fork-activations.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/book/src/architecture/core-fork-activations.md b/book/src/architecture/core-fork-activations.md index 236d221b064..a54a34308f0 100644 --- a/book/src/architecture/core-fork-activations.md +++ b/book/src/architecture/core-fork-activations.md @@ -192,11 +192,12 @@ version 15, withdrawal pooling (step 14 of the block, `build_untied_withdrawal_transactions_from_documents` v1 under `packages/rs-drive-abci/src/execution/platform_events/withdrawals/`) builds version 2 once V24 is recorded. The exception is a withdrawal whose amount is -below Core's dust threshold: Core can never relay it, so Platform may eventually -mark it failed, which is safe only for version 1. Pooling runs after -`update_core_info`, so a withdrawal pooled in the block that records V24 is -already version 2. In the window before the record, withdrawals stay at version -1, which Core always accepts. Pooling never asks Core about V24. +below Core's dust threshold at Platform's configured dust relay fee: Core nodes +using the default relay policy do not relay it, so Platform may eventually mark +it failed, which is safe only for version 1. Pooling runs after +`update_core_info`, so a withdrawal above that threshold pooled in the block that +records V24 is already version 2. In the window before the record, withdrawals +stay at version 1, which Core always accepts. Pooling never asks Core about V24. One piece of code still asks Core about V24 directly: the masternode list update's `drop_unchanged_operator_keys`, which keeps a masternode's operator key