sRFC 37: Efficient Block/Allow List Token Standard

[qtmoses]

@chris.ridmann

we need the Token Account (TA) owner to be included within the account list of “Permissionless Thaw” and “Permissionless Freeze”

We can easily get it in the Extra Account metas. For ease of use and given that it will be used frequently, I think it makes sense to be added as part of the baseline accounts.

@chris.ridmann

Moreover, we need the ability to store extra account metadata using the tlv-account-resolution library (specifically libraries/tlv-account-resolution/src/seeds.rs at main · solana-program/libraries · GitHub ) so that the “Extra Accounts” can load the aforementioned PDAs derived from the TA owner.

The User Defined Program has the responsibility of creating and managing the TLV PDA. The FAMP will only decode it to ensure all accounts are provided and order them correctly before executing the CPI.

@chris.ridmann

Lastly, I had a curiosity on the stated goals vs. the implementation chosen and wanted to seek clarification. In the background, you mention that the transfer hook interface leads protocols to have “account dependency hell”. I interpret this to mean its usage of the “Extra Accounts Metas” pattern, and see that you also have chosen this approach. But perhaps it does not suffer from the same fate because implementors of the transfer hook extension can include arbitrary code, whereas the goal of FAMP is to have a very constrained use case for custom code?

The largest goal was to shift the permissioning logic from the transfer execution time (by using transfer-hooks), to somewhere else. For protocols, this means not having to deal with extra accounts during transfers and heavily reduced CU usage compared to transfer-hooks (which is going to be even further reduced with the possible rewrite of T22 using pinocchio).