Conversation
Codama defaults any account named `tokenProgram` to the legacy SPL Token program. Three bridge instructions declare theirs as `Program<Token2022>` onchain, so Anchor rejects that default and the instruction fails for any caller who omits the account. Pins the default through a generator visitor rather than editing the generated files, so it survives regeneration. The `bridge_spl` instructions keep the legacy default: they take `Interface<TokenInterface>` and accept either program. Co-authored-by: Cursor <cursoragent@cursor.com>
Collaborator
🟡 Heimdall Review Status
|
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.
Independent of the wrapped-token-uri stack (#199 → #200 → #201), though it touches the same generator file. See the note at the bottom.
The bug
Codama defaults any account named
tokenProgramto the legacy SPL Token program,TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA. Three bridge instructions declare that account asProgram<'info, Token2022>onchain:wrap_tokenProgram<'info, Token2022>bridge_wrapped_tokenProgram<'info, Token2022>bridge_wrapped_token_with_buffered_callProgram<'info, Token2022>Anchor validates that account's key against the Token-2022 program ID, so the generated default can never work. Any caller who relies on it gets an instruction that fails. All three deal exclusively with wrapped mints, which are always Token-2022.
The two
bridge_splinstructions also carry the legacy default and are deliberately left alone: they takeInterface<'info, TokenInterface>and accept either program, so defaulting to legacy SPL Token is a reasonable choice there.The fix
Pinned through a Codama
setInstructionAccountDefaultValuesVisitoringenerate-client.handler.tsrather than by editing the generated files, so it survives the next regeneration.Verification
Confirmed before changing anything that regenerating
main's client produces no diff, so everything here is attributable to this change. The resulting diff is exactly the program address in those three files and nothing else. Both the bridge and base-relayer clients regenerate cleanly,clients/tsbuilds, andscriptstypechecks.Note for whoever merges second
#200 pins the same default for
wrapTokenV2and so touches the same two regions ofgenerate-client.handler.ts. Whichever lands second will conflict there. The resolution is to add"wrapTokenV2"to theTOKEN_2022_ONLY_INSTRUCTIONSlist introduced here — one line, no second visitor block. Happy to rebase whichever way suits.