Codama IDLs can describe all sorts of program instructions, account types, errors, and they can describe how to generate program-derived addresses based on other accounts, but they don't specify how to derive an additional dynamic set of accounts.
For example, the SPL Transfer Hook Interface specifies how additional accounts required for a transfer are supposed to be fetched, based on account data. Other systems might have other methods of resolving additional accounts, ie. through instruction simulation.
Proposed solution
I don't have a specific idea unfortunately, but it would be good for the concept of "there may be additional dynamic accounts for this instruction" to be included in Codama IDLs.
After that, we could develop specs for account resolution schemes, which Codama could support.
Problem
Codama IDLs can describe all sorts of program instructions, account types, errors, and they can describe how to generate program-derived addresses based on other accounts, but they don't specify how to derive an additional dynamic set of accounts.
For example, the SPL Transfer Hook Interface specifies how additional accounts required for a transfer are supposed to be fetched, based on account data. Other systems might have other methods of resolving additional accounts, ie. through instruction simulation.
Proposed solution
I don't have a specific idea unfortunately, but it would be good for the concept of "there may be additional dynamic accounts for this instruction" to be included in Codama IDLs.
After that, we could develop specs for account resolution schemes, which Codama could support.