Thanks for bringing this up and thinking so much about the problem. Certainly, the lack of composability with token programs is a huge hindrance to open development in the Solana ecosystem, and I would love to see a better solution than the current monolith of Tokenkeg....
I view this in a very similar way, but rather than having everything go through a centralized program, I’ve always preferred simply having programs that implement many interfaces. For example, Tokenkeg... can really be broken down into a program that contains many different interfaces:
- transferable:
transferandtransfer_checked - mintable:
mint_to - freezable:
freezeandthaw - closeable:
close_account - approvable:
approveandrevoke - burnable:
burn - initialize mint / account
If we can write and implement program interfaces for each of these, then we can re-compose everything. sRFC 00010: Program Trait - Transfer Spec is the first step towards this future.
In the interface specs, we can allow for an arbitrarily more accounts, to be implemented through an instruction, or through some sort of lookup account as in the “transfer-hook” interface created for token-2022 https://github.com/solana-labs/solana-program-library/pull/4147.
We also need to figure out “state interfaces”, ie for defining initialize_mint and initialize_account, similar to your example, but doing it through a spec / interface rather than a centralized program.
What do you think about this interface approach?