EBALTS and ABL integrations

[tiago18c]

Added Client Libs: TLV-Account-Resolution, EBALTS, ABL.
Integrated into the SDK and CLI

things to ignore:

• packages/abl/src/generated : generated by codama
• packages/ebalts/src/generated : generated by codama

Missing (next steps):

• adding and removing wallets to the block list
• reading the block list
• helper to create and thaw token account in the same transaction (permissionless thaw creation has been changed to accommodate token accounts being created on the same transaction )

---

Important

Added TLV-Account-Resolution, EBALTS, and ABL client libraries with SDK and CLI integration for enhanced account and transaction management.

• New Libraries:
  • Added TLV-Account-Resolution, EBALTS, and ABL client libraries.
  • Integrated libraries into SDK and CLI.
• SDK Changes:
  • Added getCreateListTransaction and getSetExtraMetasTransaction in abl for list and metadata management.
  • Added getCreateConfigTransaction, getEnablePermissionlessThawTransaction, and getSetGatingProgramTransaction in ebalts for configuration and permissionless operations.
• CLI Commands:
  • Added create-list and set-extra-metas commands in abl for list creation and metadata setting.
  • Added create, set-gating-program, thaw-permissionless, and enable-permissionless-thaw commands in ebalts for configuration and permissionless operations.
• Error Handling:
  • Added error types and handling in abl/src/generated/errors/ablSrfc37.ts.
• Miscellaneous:
  • Updated package.json files to include new dependencies and scripts.
  • Added Jest configuration for testing in jest.config.js files.

^{This description was created by for 406e03c. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 406e03c in 3 minutes and 2 seconds. Click for details.

• Reviewed 8009 lines of code in 84 files
• Skipped 5 files when reviewing.
• Skipped posting 17 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. packages/cli/src/commands/abl/setExtraMetas.ts:37

• Draft comment:
  Remove debug logging of options and parentOpts to avoid noisy output in production.
• Reason this comment was not posted:
  Marked as duplicate.

2. packages/cli/src/commands/ebalts/thawPermissionless.ts:87

• Draft comment:
  Correct the failure message to indicate thawing failure (e.g. 'Failed to thaw permissionless') instead of 'Failed to create ebalts config'.
• Reason this comment was not posted:
  Marked as duplicate.

3. packages/sdk/src/issuance/createMint.ts:75

• Draft comment:
  Verify that withDefaultAccountState(false) (i.e. setting state to Frozen) is the intended behavior; if this is used for arcade tokens, consider adding a clarifying comment.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. packages/sdk/src/templates/arcadeToken.ts:70

• Draft comment:
  Confirm that setting default account state to false (i.e. Frozen/Allowlist mode) is correct for arcade tokens; consider a brief comment explaining the rationale.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This comment violates multiple rules. First, it asks for confirmation ("Confirm that...") which we explicitly don't want. Second, it's asking about intention and rationale, which we also don't want. The JSDoc already explains that arcade tokens use an allowlist, which implies frozen/default false state. The author clearly made this change intentionally. Maybe the change from true to false is significant enough that it deserves more documentation? The comment might be trying to prevent a potential bug. While documentation is good, asking for confirmation or rationale is not the right approach. The JSDoc already documents the allowlist nature, and we must trust the author's intention in making this change. Delete this comment as it violates our rules by asking for confirmation and rationale, and the context is already documented in the JSDoc.

5. packages/cli/src/index.ts:32

• Draft comment:
  Consider providing a default or clearer fallback for keypair paths if not supplied; ensure that command.parent?.parent?.opts() reliably returns necessary global options.
• Reason this comment was not posted:
  Comment was on unchanged code.

6. packages/abl/src/generated/accounts/index.ts:9

• Draft comment:
  Typo/Lexicographical issue: The export path './aBWallet' might have an inconsistent capitalization. Please verify if it should be './ABWallet' to match the naming conventions.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is an autogenerated file that explicitly states "DO NOT EDIT THIS FILE". Any naming conventions or capitalization issues should be addressed in the generator, not in the generated output. Making manual edits to this file would be against its intended usage. The capitalization might actually be intentional and correct according to the generator's rules. Also, this could be matching an actual filename that needs to be preserved. Even if the capitalization is wrong, this file should not be manually edited - any fixes need to happen in the code generation system. Delete this comment because it suggests manual edits to an autogenerated file, which is explicitly forbidden.

7. packages/abl/src/generated/shared/index.ts:45

• Draft comment:
  Typographical error: In the error message, "Expected a Address." should be corrected to "Expected an Address.".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The file header explicitly states "DO NOT EDIT THIS FILE" and indicates that changes should be made through visitors instead. The grammatical error, while real, should be fixed in the generation code rather than directly in this file. Making the suggested change would be overwritten on the next code generation. The comment correctly identifies a grammatical error. Maybe the generation code could be fixed by raising this issue. While the grammar correction is valid, making changes directly to this file violates the auto-generation principle and would be lost on next generation. The comment should be deleted because the file is auto-generated and direct edits are discouraged. The issue should be raised with the code generation tool instead.

8. packages/abl/src/index.ts:20

• Draft comment:
  Typo: The default program address string 'Eba1ts11111111111111111111111111111111111111' might be intended to be 'Ebalts11111111111111111111111111111111111111' (with an 'l' instead of the digit '1'). Please verify.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a speculative comment asking for verification of intention. Without deep knowledge of the Solana program this address refers to, we can't be certain this is actually a typo. The same address is used consistently in both functions, suggesting it's intentional. The comment is asking for verification rather than pointing out a definite issue. The address could genuinely be a typo that was copy-pasted to both locations. Solana addresses are critical for program functionality. While Solana addresses are important, we don't have strong evidence this is incorrect. The comment violates our rule about not asking for verification, and we should assume the author knows the correct address. Delete the comment as it's speculative and asks for verification without strong evidence of an actual issue.

9. packages/abl/src/index.ts:42

• Draft comment:
  Typo: The default program address string 'Eba1ts11111111111111111111111111111111111111' seems to use a digit '1' where an 'l' might be expected. Please double-check the intended spelling.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Solana addresses are base58 encoded and commonly use both letters and numbers. The number '1' is a valid character in base58. Without knowing the actual program address this refers to, we can't know if this is a typo or intentional. The fact it's used consistently twice suggests it's intentional. Making assumptions about program addresses without context is dangerous. I could be wrong if this is a known program address that should definitely use 'l' instead of '1'. The repetition could be copying a mistake. Even if it is a mistake, changing a program address without absolute certainty would be dangerous. Program addresses must be exact. Delete the comment. We cannot assume a program address contains a typo without strong evidence, as incorrect addresses could break functionality.

10. packages/cli/src/commands/abl/createList.ts:26

• Draft comment:
  Typographical consistency note: The term “ebalts” appears with different capitalization (e.g., in the spinner text “Creating ebalts config…” and later as “Ebalts config created successfully!” and “Failed to create ebalts config”). Consider standardizing the capitalization (for example, always using “EBALTS” or “ebalts”) for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is about UI text consistency, which falls under UI/styling changes according to our rules. The rules explicitly state "Do NOT comment on any pure frontend UI or styling changes". While consistency in user-facing messages is good, this is not a logic issue. Additionally, it's unclear if "ebalts", "Ebalts", and "ABL" are actually referring to the same thing - we'd need more context to be certain. Maybe inconsistent naming in user messages could lead to user confusion or indicate a deeper architectural naming issue that needs to be resolved? While naming consistency is important, this appears to be purely about UI text formatting. Per our rules, we should trust that the author has handled UI-related decisions appropriately. This comment should be deleted as it focuses on UI text formatting, which our rules explicitly exclude from review.

11. packages/cli/src/commands/ebalts/thawPermissionless.ts:31

• Draft comment:
  Typo noticed in the command description: "Thaw permissionless eoas for an existing mint". Is "eoas" intended to be "EOAs" or something else?
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically about a change (since it's a new file), the comment is about documentation/help text formatting rather than logic. The meaning is clear either way, and this is a very minor cosmetic issue. According to the rules, we should not make purely informative comments or comments about obvious/unimportant issues. The capitalization could potentially affect searchability or clarity for users of the CLI tool. Documentation quality does matter for user experience. While documentation is important, this change is too minor to warrant a comment. The meaning is clear either way, and this doesn't affect functionality. Delete this comment as it addresses a trivial documentation formatting issue that doesn't meaningfully impact users or code quality.

12. packages/cli/src/commands/ebalts/util.ts:4

• Draft comment:
  There's a missing newline at the end of the file. It is recommended to add a newline at the end for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Missing newlines at end of file are typically handled by IDE settings or prettier/formatting tools. This is an extremely minor issue that doesn't affect functionality. The rules state not to comment on obvious or unimportant issues. This seems like the kind of thing that should be handled by automated tooling rather than manual review comments. The missing newline could cause issues with some tools or make diffs less clean. It is a widely accepted convention to have newlines at end of files. While the convention is valid, this is exactly the kind of minor formatting issue that should be handled by automated tooling rather than PR comments. If it's important to the team, they should configure their formatters appropriately. Delete this comment as it's too minor of an issue and should be handled by automated tooling rather than PR comments.

13. packages/ebalts/src/generated/programs/ebalts.ts:42

• Draft comment:
  Typographical/naming suggestion: Consider capitalizing 'Ebalts' in the error message to match its usage elsewhere (e.g., 'Ebalts account') and use the correct article (e.g., 'an Ebalts account' rather than 'a ebalts account').
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The file is explicitly marked as auto-generated with a warning not to edit it directly. The comment suggests manual edits to the file. Any changes to the error message should be made in the generator code, not in this file directly. Making manual edits here would be overwritten on the next code generation. The capitalization inconsistency and grammar issue are real, but maybe they should be fixed in the code generator instead? Even though the issues are valid, suggesting edits directly to an auto-generated file violates the file's explicit instructions. This needs to be fixed upstream in the generator. Delete the comment because it suggests manual edits to an auto-generated file, which explicitly states "DO NOT EDIT THIS FILE" in the header.

14. packages/ebalts/src/generated/programs/ebalts.ts:90

• Draft comment:
  Typographical/naming suggestion: Consider capitalizing 'Ebalts' in the error message to match its usage elsewhere (e.g., 'Ebalts instruction') and use the correct article (e.g., 'an Ebalts instruction' rather than 'a ebalts instruction').
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is an autogenerated file as clearly stated in the header comments. The file explicitly says "DO NOT EDIT THIS FILE" and instructs to use visitors instead. Making direct edits to this file would be incorrect since they would be overwritten on the next generation. The proper fix would be to modify the code generation templates/visitors. The comment does point out a real inconsistency in capitalization and grammar that could be confusing to users seeing the error message. While the inconsistency is real, suggesting direct edits to an autogenerated file violates the file's explicit instructions and would not result in a lasting fix. Delete the comment since it suggests directly editing an autogenerated file, which is explicitly forbidden. The fix needs to happen in the code generation system instead.

15. packages/ebalts/src/generated/shared/index.ts:45

• Draft comment:
  Typo: In the error message, consider using 'Expected an Address.' instead of 'Expected a Address.' for correct grammar.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The file is explicitly marked as auto-generated with a warning not to edit it directly. The comment suggests a minor grammatical fix, but since this is an auto-generated file, any direct edits would be overwritten. The proper fix would need to be made in the code generation tool (codama) itself, not in this file. The grammar issue is technically correct, but I might be overlooking the value of reporting issues back to the code generation tool maintainers. While the grammar issue is valid, making changes directly to this file violates the auto-generated nature of the code. Such feedback should go to the codama tool maintainers instead. Delete the comment since the file is auto-generated and should not be edited directly. Grammar fixes should be addressed in the code generation tool instead.

16. packages/tlv-account-resolution/src/errors.ts:73

• Draft comment:
  Typographical suggestion: In the comment, consider using 'contain' instead of 'contains' for correct plural subject agreement in "Thrown if the transfer hook extra accounts contains an invalid account index".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct grammar, this is an extremely minor change that doesn't affect code functionality or documentation clarity. The meaning is perfectly clear either way. Both forms are arguably acceptable since "accounts" can be treated as a collective noun. Other comments in the file use similar constructions without issue. The grammar suggestion is technically correct. Poor documentation can lead to confusion and maintenance issues over time. While technically correct, this level of nitpicking on grammar in clear, understandable comments violates the rule about not making obvious or unimportant comments. The meaning is completely clear either way. Delete this comment as it's too minor and doesn't meaningfully improve the code or documentation.

17. packages/tlv-account-resolution/src/errors.ts:78

• Draft comment:
  Typographical suggestion: In the comment, consider using 'contain' instead of 'contains' for correct plural subject agreement in "Thrown if the transfer hook extra accounts contains an invalid seed".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct grammar, this is an extremely minor change that doesn't impact code functionality or documentation clarity. The meaning is perfectly clear either way. The rules state not to make purely informative comments or obvious/unimportant changes. This seems to fall into that category. Grammar correctness can contribute to code quality and maintainability. Consistent and correct documentation helps with professionalism. While correct grammar is good, this change is too minor to warrant a PR comment. It doesn't meaningfully improve understanding or maintainability. Delete this comment as it suggests an extremely minor grammatical change that doesn't meaningfully improve the code or documentation.

Workflow ID: wflow_ciEk7Je3ncZx0Xp2

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Clarify the magic number '32' in the loop condition (while(i < 32)) with a comment or constant to explain its significance.

Suggested change

	while (i < 32) {
	while (i < 32) { // Maximum of 32 seeds allowed per Solana program constraints