You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: