List management

[tiago18c]

This PR is built on top of PR #21 , few changes were actually made here. Either: merge this and discard 21, or merge 21 and wait for rebase before merging.

Adds Wallet management methods to the sdk:

• add wallet to list
• remove wallet from list

Adds list fetching methods to the sdk:

• fetch list config
• fetch full list

---

Important

This PR adds list management capabilities to the SDK, including methods for wallet and list configurations, new CLI commands, and updates to existing functionalities.

• Behavior:
  • Adds methods to @mosaic/abl for adding/removing wallets from lists and fetching list configurations.
  • Introduces CLI commands create-list and set-extra-metas in abl.ts for list management.
  • Implements createConfig, setGatingProgram, thawPermissionless, and enablePermissionlessThaw commands in ebalts.ts.
• Models:
  • Defines ListConfig and List interfaces in list.ts for list configuration and wallet management.
  • Adds ABWallet and ListConfig types in abl_srfc37.json.
• Instructions:
  • Implements getCreateListInstructions and getCreateListTransaction in list.ts for list creation.
  • Adds getAddWalletInstructions and getRemoveWalletInstructions in wallet.ts for wallet management.
• Misc:
  • Updates package.json files to include new dependencies and scripts.
  • Configures Jest for testing in jest.config.js across multiple packages.
  • Adds error handling and utility functions in state.ts and pubkeyData.ts.

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

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 9d7e0d9 in 3 minutes and 6 seconds. Click for details.

• Reviewed 8468 lines of code in 86 files
• Skipped 6 files when reviewing.
• Skipped posting 16 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/tlv-account-resolution/src/seeds.ts:140

• Draft comment:
  Loop boundary in unpackSeeds uses a hardcoded limit (i < 32). Verify that this limit correctly covers all packed seed data or consider a more dynamic termination condition.
• 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 32 limit appears to be an intentional safety guard against infinite loops or malformed data. Using seeds.length could be dangerous if the input is malformed. The null termination check already handles proper loop termination. The 32 limit seems like a reasonable maximum number of seeds to process. I could be wrong about the 32 being an intentional safety guard - maybe it's an arbitrary number that should be larger or smaller. Without more context about the protocol requirements, I can't be certain. Even with uncertainty about the exact number, having some maximum limit is better than no limit for safety. The current code handles termination properly with both the limit and null check. The hardcoded 32 limit appears to be an intentional safety guard, and the suggested change could make the code less safe. The comment should be removed.

2. packages/ebalts/src/generated/instructions/createConfig.ts:200

• Draft comment:
  Ensure the memcmp filter in getList (offset: 40n, dataSize: 72n) matches the on‐chain data layout of the list configuration.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the author to ensure that a specific filter matches the on-chain data layout. It is not making a specific suggestion or pointing out a specific issue, but rather asking for confirmation. This violates the rule against asking the author to ensure behavior is intended.

3. packages/abl/idl/abl_srfc37.json:181

• Draft comment:
  Typo: The account name "ebalts_mint_config" appears to be misspelled. Please confirm if this should be "abl_mint_config" or another consistent name 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% Without more context about the codebase, we can't know if "ebalts_mint_config" is actually incorrect. The name could be intentional and reference something specific to the system. The file prefix is "abl" but that doesn't necessarily mean all account names must follow that pattern. Making assumptions about naming without full context could lead to incorrect suggestions. I could be wrong if there's a strict naming convention in the codebase that requires all accounts to be prefixed with "abl_". The presence of "ab_wallet" elsewhere might suggest some naming patterns. Even with those patterns, we can't be certain this is a typo without more context. The name could be intentionally different for a specific reason. We should delete this comment as it makes assumptions about naming without strong evidence that it's actually incorrect.

4. packages/abl/src/generated/instructions/setExtraMetasThaw.ts:55

• Draft comment:
  Typo alert: The type parameter name 'TAccountEbaltsMintConfig' seems unusual. Did you possibly mean something like 'TAccountExtraMintConfig'? Please verify the intended naming.
• 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% 1. This is an autogenerated file that shouldn't be manually edited. 2. The name 'ebalts' appears consistently throughout the code. 3. Since this is autogenerated, any naming changes would need to be made in the source that generates this code, not here. 4. The comment is suggesting a change that would make the code inconsistent with the rest of the codebase. I could be wrong about 'ebalts' being intentional - maybe it really is a typo that should be fixed in the code generator. Even if it is a typo, this autogenerated file is not the place to fix it - it would need to be fixed in the code generator. The comment is targeting the wrong place. Delete the comment because it's suggesting changes to an autogenerated file that shouldn't be manually edited, and the naming appears intentional and consistent throughout the code.

5. packages/abl/src/generated/programs/ablSrfc37.ts:61

• Draft comment:
  Typographical error: consider changing "a ablSrfc37 account" to "an ablSrfc37 account" in the error message for better 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 explicitly states it's auto-generated and warns not to edit it directly. Instead, changes should be made through visitors and then regenerated. Making direct edits to this file would be against the documented process. Additionally, this is a minor grammatical issue that doesn't affect functionality. The grammar error could propagate to user-facing error messages, potentially affecting professionalism. The fix is technically correct. While the grammar fix would be nice, making direct edits to auto-generated files is the wrong approach and could be lost on the next generation. The fix should be made in the generation code instead. Delete the comment since it suggests directly editing an auto-generated file, which is explicitly discouraged in the file header.

6. packages/abl/src/generated/programs/ablSrfc37.ts:157

• Draft comment:
  Typographical error: consider changing "a ablSrfc37 instruction" to "an ablSrfc37 instruction" in the error message for better 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 explicitly states it's auto-generated and warns not to edit it directly. Instead, changes should be made through visitors and then regenerated. Making direct edits to the file would be against the documented process. The grammar issue, while valid, should be fixed in the generation code, not in this file. The grammar correction is technically correct and would improve the code quality. Maybe it's worth keeping to alert the developers to fix the generator. While the grammar correction is valid, making changes directly to auto-generated files is explicitly discouraged and could be lost on the next generation. The issue should be raised against the generator codebase instead. Delete the comment since it suggests editing an auto-generated file, which goes against the file's explicit instructions. The grammar issue should be addressed in the generator instead.

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

• Draft comment:
  Typo: In the error message, "Expected a Address." should use the correct article. Consider changing it 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% Since this is an auto-generated file, making manual edits to it would be inappropriate and against the file's explicit instructions. Any fixes should be made to the generation code/templates instead. Additionally, this is a very minor grammatical issue that doesn't affect functionality. The grammar error could make the error message slightly confusing to users encountering it. The fix is technically correct. While the grammar fix is valid, making manual edits to auto-generated code is not the right approach. Such fixes should be made in the code generation tool instead. Delete the comment since it suggests manually editing an auto-generated file, which is explicitly forbidden in the file header.

8. packages/cli/src/commands/abl/createList.ts:19

• Draft comment:
  Typographical error: The spinner message on line 19 says "Creating ebalts config...". It seems like "ebalts" might be a typo. Please confirm if it should be "ABL" or a different term.
• Reason this comment was not posted:
  Marked as duplicate.

9. packages/cli/src/commands/ebalts/thawPermissionless.ts:20

• Draft comment:
  The command description reads "Thaw permissionless eoas for an existing mint". The term "eoas" might be a typo; if it’s meant to be an acronym (e.g. "EOAs" for Externally Owned Accounts), consider capitalizing it 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% While the comment is technically correct about acronym capitalization, it's a very minor stylistic suggestion. The meaning is still clear either way. According to the rules, we should not make purely informative comments or comments that are obvious/unimportant. This seems to fall into that category - it's not pointing out a functional issue that requires fixing. Perhaps in some contexts, proper capitalization of technical terms is important for documentation and clarity. The current lowercase form could be confusing to new users. While proper capitalization is good practice, this is not a critical issue that requires a code change. The meaning is still clear, and this is the kind of minor stylistic feedback that adds noise to the review process. Delete this comment as it's a minor stylistic suggestion that doesn't point out a significant issue requiring a code change.

10. packages/cli/src/index.ts:34

• Draft comment:
  Typo check: 'ebaltsCommand' might be misspelled. Please confirm if this is the intended command name.
• 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 fact that there's a dedicated directory and file with the same name strongly suggests this is intentional naming. The automated tool is likely flagging this because 'ebalts' isn't a common English word, but that doesn't mean it's misspelled. In a CLI context, command names are often domain-specific terms or abbreviations. I could be wrong if 'ebalts' is actually a typo of something else. Maybe there's documentation elsewhere that shows the correct spelling. The consistent use of 'ebalts' in both the directory name and import path makes it extremely unlikely to be a typo. If it were misspelled, it would have required the developer to make the same typo multiple times in different places. Delete this comment. The name appears to be intentional, and asking for spelling confirmation adds no value.

11. packages/cli/src/index.ts:35

• Draft comment:
  Typo check: 'ablCommand' may be a typo. Please confirm if the correct command name was intended.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

12. packages/ebalts/src/generated/pdas/freezeExtraMetasAccount.ts:31

• Draft comment:
  Typo: The literal string used for encoding the PDA seed is 'freeze_extra_account_metas', which seems inconsistent with the naming convention in the rest of the file (i.e., FreezeExtraMetasAccount). Please verify if the intended order should be 'freeze_extra_metas_account' and update if necessary.
• 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% 1. The file is explicitly marked as AUTOGENERATED. 2. PDA seeds are critical parts of the contract interface and changing them would break compatibility. 3. The actual string used in PDA seeds often doesn't match TypeScript naming conventions. 4. There's no evidence that the suggested change is correct - it's purely speculative based on TypeScript naming. The seed string might actually be incorrect, and catching naming inconsistencies could prevent bugs. Since this is an autogenerated file and PDA seeds are contract-level constants, we cannot safely suggest changes without knowing the contract's requirements. The TypeScript naming convention is irrelevant to PDA seed strings. Delete this comment. It's speculative, suggests changing a critical contract interface constant in an autogenerated file, and is based only on TypeScript naming conventions which don't apply to PDA seeds.

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

• Draft comment:
  Typo: In the error message, consider changing "Expected a Address." to "Expected an Address." for grammatical correctness.
• 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 explicitly states "DO NOT EDIT THIS FILE" at the top. Any changes to error messages should be made in the codama library that generates this code, not in the generated file directly. Making changes to auto-generated files is generally a bad practice as they'll be overwritten on the next generation. The grammatical error is real and the suggestion is technically correct. Poor error messages could impact developer experience. While the error is real, fixing it in the generated file would be the wrong approach. The fix needs to be made in the source templates/generator. Delete the comment since it suggests editing an auto-generated file, which explicitly warns against direct edits. The fix should be made in the codama library instead.

14. packages/sdk/src/index.ts:8

• Draft comment:
  Typo alert: The module path './ebalts' may be misspelled. Please verify that this is the intended module name.
• 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% Without access to the actual module being imported or broader codebase context, we can't verify if 'ebalts' is actually a typo or an intentional module name. The comment is speculative and asks for verification, which violates our rules. Module names can be unconventional and still be correct. The module name does look unusual, and if it is a typo, catching it early would prevent issues. Maybe we're being too quick to dismiss a potentially helpful warning? Even if it looks unusual, we can't be certain it's wrong. If it were a typo, it would fail to build immediately, making this comment unnecessary per our rules about not commenting on things caught by the build. Delete the comment because it violates multiple rules: it asks for verification, is speculative, and comments on something that would be caught by the build if incorrect.

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

• Draft comment:
  Typographical suggestion: Consider replacing 'contains' with 'contain' in the comment "Thrown if the transfer hook extra accounts contains an invalid account index" since 'extra accounts' is plural.
• 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 documentation change that doesn't affect functionality or clarity. The meaning is perfectly clear either way. The rules state not to make purely informative comments or obvious/unimportant changes. Documentation grammar tweaks like this fall into that category. The grammar correction is technically accurate. Poor grammar in documentation could be seen as unprofessional. The meaning is completely clear despite the minor grammar issue, and we're instructed to avoid purely informative comments that don't require code changes. This is exactly the kind of nitpicky comment we should avoid. Delete this comment as it's too minor and doesn't affect code functionality or documentation clarity.

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

• Draft comment:
  Typographical suggestion: Consider replacing 'contains' with 'contain' in the comment "Thrown if the transfer hook extra accounts contains an invalid seed" to match the plural subject 'extra accounts'.
• 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 documentation fix. The meaning is perfectly clear either way. The rules state not to make purely informative comments or obvious/unimportant changes. Grammar nitpicks in comments fall into this category unless they actually impair understanding. The grammar is technically incorrect in its current form. Documentation quality is important for developer experience. While correct grammar is good, this tiny fix doesn't materially improve code quality or documentation clarity. The meaning is clear either way. Delete this comment as it's too minor and doesn't require action. It falls under the rule about not making purely informative or unimportant comments.

Workflow ID: wflow_61F87oyQPjOjwTo2

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