Skip to content

docs: describe asset unlock payload version 2 as a Core fork record consumer #5772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shumkov merged 2 commits into from
Nov 6, 2026
Merged

docs: describe asset unlock payload version 2 as a Core fork record consumer #5772

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7e2014b
docs(book): describe asset unlock payload version 2 as a Core fork re…
shumkov Nov 5, 2026
60c378b
docs(book): qualify the dust relay claim and the same-block V24 sentence
shumkov Nov 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions book/src/architecture/core-fork-activations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -186,6 +186,19 @@ 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 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
when Core re-encodes it after V24. It runs under every protocol version, and
Expand Down
Loading