chore(ckbtc): DEFI-2995: Proposals to set the memory allocation of the ckBTC canisters - #11481
Open
mbjorkqvist wants to merge 3 commits into
Open
chore(ckbtc): DEFI-2995: Proposals to set the memory allocation of the ckBTC canisters#11481mbjorkqvist wants to merge 3 commits into
mbjorkqvist wants to merge 3 commits into
Conversation
…e ckBTC canisters Four NNS UpdateCanisterSettings proposals setting `memory_allocation` on the ckBTC ledger (1 GiB), index (4 GiB), archive (1 GiB) and minter (1 GiB), from the current best-effort `0`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
These proposals change production canister settings, and the ledger text still overstates the duration of reservation protection.
Pull request overview
Adds NNS proposals reserving memory for four production ckBTC canisters to reduce storage-reservation failures.
Changes:
- Allocates 1 GiB each to the minter, ledger, and archive.
- Allocates 4 GiB to the index.
- Documents rationale, headroom, and cycle costs.
File summaries
| File | Description |
|---|---|
rs/bitcoin/ckbtc/mainnet/minter_settings_2026_09_08.md |
Proposes 1 GiB for the minter. |
rs/bitcoin/ckbtc/mainnet/ckbtc_ledger_settings_2026_09_08.md |
Proposes 1 GiB for the ledger; clarify that reservation protection ends once usage exceeds the allocation. |
rs/bitcoin/ckbtc/mainnet/ckbtc_index_settings_2026_09_08.md |
Proposes 4 GiB for the index. |
rs/bitcoin/ckbtc/mainnet/ckbtc_archive_settings_2026_09_08.md |
Proposes 1 GiB for the archive. |
Review details
Suppressed comments (1)
rs/bitcoin/ckbtc/mainnet/ckbtc_ledger_settings_2026_09_08.md:16
- The allocation only avoids storage reservations while usage remains below 1 GiB. Because this paragraph says ledger usage will keep growing, “without ever touching the reservation path” incorrectly implies permanent protection; once usage exceeds the allocation, subsequent growth is reservation-charged again. Please state that boundary explicitly so voters understand the finite headroom.
The canister currently uses 241 MiB, so a 1 GiB allocation leaves 783 MiB of headroom (4.26x current usage). The ledger holds unarchived blocks in stable structures, and block archiving is currently disabled, so its usage will keep stepping upwards; 1 GiB gives room for that growth to continue without ever touching the reservation path.
- Files reviewed: 4/4 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
… proposal The allocation only keeps growth off the reservation path while usage stays below it. Say so explicitly, and give the scale of a step, so voters can see the headroom is finite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…al texts Each text quoted only the per-GiB rate, leaving voters to work out the total. Give the per-canister figure too. Kept in cycles rather than USD, matching the convention in the existing mainnet proposal texts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
✅ No security or compliance issues detected. Reviewed everything up to 51b34b8. Security Overview
Detected Code Changes
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposal texts for four NNS
UpdateCanisterSettingsproposals settingmemory_allocationon the ckBTC ledger (1 GiB), index (4 GiB), archive (1 GiB) and minter (1 GiB), up from the current best-effort0.With a best-effort allocation, any memory growth on a subnet above its storage reservation threshold has to reserve cycles up front, and is rejected once the canister's
reserved_cycles_limitis exhausted. With a reserved allocation the amount charged is the change inmax(allocation, usage), which stays constant while usage is below the allocation, so growth within the allocation reserves nothing and cannot be rejected on those grounds. This complements #11479, which raises the ceiling on what may be reserved rather than taking the growth off the reservation path.Setting an allocation is itself charged in proportion to the subnet's storage saturation at the time, so it is cheapest while the fiduciary subnet is quiet; it currently sits at ~70 GiB against a 750 GiB threshold, where the charge is zero.
Ongoing cost. A reserved allocation is charged whether used or not, at ~26.2T cycles per GiB per year on this 34-node subnet:
That is ≈183 XDR/yr, or ≈$245/yr at ~1.33 USD/XDR — the index accounts for well over half of it. The individual proposal texts quote cycles only: the XDR/USD rate floats and those texts are permanent, and the existing mainnet proposal texts use USD for asset amounts but always cycles for cycle costs.