docs: correct Token-2022 extension policy and credit Moonsong Labs#151
Conversation
The README listed seven extensions as rejected during SA initialization, but the program only rejects a configured TransferHook (hook authority or program_id set). The other six error codes are reserved and never fire. Also add an Acknowledgments section crediting Moonsong Labs for the initial design and implementation.
Greptile SummaryThis PR corrects the README's Token-2022 extension policy and adds an Acknowledgments section. The previous text incorrectly listed seven rejected extensions; the actual
Confidence Score: 5/5Documentation-only change with no modifications to program logic, state, or client code — safe to merge. The updated README wording is consistent with both the actual validate_mint_extensions implementation in token.rs (which checks only extension type 14 and only rejects non-zero data) and the existing CLAUDE.md policy note. The Acknowledgments section is a straightforward prose addition. No code paths are touched. No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Token-2022 mint account] --> B{Has extensions?}
B -- No extensions --> C[✅ Accepted]
B -- Has extensions --> D[Iterate TLV entries]
D --> E{ext_type == 0?}
E -- Yes --> C
E -- No --> F{ext_type == TransferHook\next_type == 14?}
F -- No --> G[Skip extension]
G --> D
F -- Yes --> H{Any byte != 0 in\n64-byte extension data?}
H -- No --> I[Inert hook:\nboth authority and\nprogram_id are unset]
I --> C
H -- Yes --> J[❌ MintHasTransferHook error\nConfigured hook rejected]
Reviews (1): Last reviewed commit: "docs: correct Token-2022 extension polic..." | Re-trigger Greptile |
Compute Unit Report
Generated: 2026-06-03 |
Summary
Test Plan