ICRC-153: Standardizing Privileged Freeze & Unfreeze Controls#157
Merged
ICRC-153: Standardizing Privileged Freeze & Unfreeze Controls#157
Conversation
bogwar
changed the title
bogwar
changed the title
…ix typos - Replace `tx.op` with `tx.mthd` as method discriminator (ICRC-3 alignment) - Fix btype values to match ICRC-123: `123freezeaccount` not `123freeze_account` (same for unfreezeaccount, freezeprincipal, unfreezeprincipal) - Fix typo: `iicrc153_unfreeze_account` → `icrc153_unfreeze_account` - Fix typo: `rsults` → `results`, wrong btype `122freeze_account` → `123freezeaccount` Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…on-wins semantics The Effective Freeze Model section previously described a compositional OR rule, which contradicted ICRC-123's latest-action-wins semantics. Updated to use block-index comparison: the most recent freeze/unfreeze action affecting an account (at either account or principal level) determines its effective status. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Unfreeze calls must succeed even when the target is not frozen at that level, because under ICRC-123 latest-action-wins, a principal unfreeze can lift account-level freezes. Removed NotFrozen from both UnfreezeAccountError and UnfreezePrincipalError variants. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add TooOld/CreatedInFuture to FreezeAccountError and FreezePrincipalError - Fix duplicate TooOld/CreatedInFuture lines in freeze_account error cases - Add TooOld/CreatedInFuture to all four normative error-cases sections - Add ICRC-153.did with all four method types and query methods - Merge Introduction sections, fix compliance encoding, principal blobs, Nat64→Nat - Add icrc153_is_frozen_account and icrc153_is_frozen_principal query methods Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Rename `## Reporting Compliance` → `## Compliance Reporting` (match ICRC-122/123/124) - Make icrc1_supported_standards conditional on ICRC-1 implementation (match ICRC-152/154) - .did: add FrozenAccountsRequest/Response, FrozenPrincipalsRequest/Response types and icrc153_list_frozen_accounts, icrc153_list_frozen_principals query methods defined in the spec Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Deduplication: add justification for required created_at_time in all four Semantics sections (matches ICRC-152 rationale) - list_frozen_accounts: add prominent warning that it returns only account-level freezes, not effectively-frozen accounts (direct readers to is_frozen_account and Effective Freeze Model for full picture) - list_frozen_principals: add parallel warning clarifying it lists principal-level freezes only - Ensure final newline at end of file Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The warning I added suggested there's a distinction between "principal-level freezes" and "effectively frozen principals", but no such distinction exists — only 123freezeprincipal/123unfreezeprincipal blocks affect principal-level state, so list_frozen_principals is already exhaustive. The warning on list_frozen_accounts remains; that one is correct because account-level lists don't include accounts frozen via principal-level freezes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previous semantics could return accounts that were effectively unfrozen by a later principal-level unfreeze — unacceptable behavior for a method whose name implies it returns frozen accounts. - Update list_frozen_accounts to return only accounts where the most recent account-level freeze has NOT been superseded by a later 123unfreezeprincipal on the owner. - Guarantee every returned account satisfies is_frozen_account = true. - Retain the intentional behavior of not expanding principal-level freezes into per-account entries (false negatives acceptable). - Update Effective Freeze Model and Integrator Guidance to reflect that both list endpoints are individually sound; integrators take their union for complete coverage. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
marc0olo
approved these changes
Apr 22, 2026
Member
marc0olo
left a comment
marc0olo
left a comment
There was a problem hiding this comment.
All issues resolved — .did file now includes the list methods and their request/response types, deduplication rationale added to all four methods, icrc153_list_frozen_accounts carries a prominent warning about not being exhaustive, trailing newline fixed. Approving.
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
2 participants
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.
This PR introduces ICRC-523, a standard API for freezing and unfreezing accounts and principals. It defines four privileged methods, canonical tx mapping, and use of the block kinds from ICRC-123. The standard provides auditors, wallets, and integrators with a consistent way to determine whether funds are frozen and to attribute freezes/unfreezes to authorized actors.