I would like to report a bug in Tribeca's UI, in particular the "Issue Tokens" action, available through Tribeca proposals.
Today, the "Issue Tokens" action incorrectly assumes the address provided through the proposal creation UI is a wallet.
Indeed, providing a Token Account address (1) for the "Issue Tokens" action in the proposal creation UI results in a new Token Account (2) being created, owned by the provided Token Account address (1), aka "nested Token Account".
This behavior leads to the issued tokens being frozen in limbo & funds being innaccessible, as a Token Account (ie: 1) cannot sign for another Token Account (ie: 2), and a wallet cannot sign for a nested Token Account (ie: 2) as of today.
Furthermore, this behavior is not in line with the de facto standard to the spl-token CLI "transfer" command, which indicates:
If a token account address is provided, use it as the recipient.
Otherwise assume the recipient address is a user wallet and transfer to the associated token account
Other DAO UIs (governance-ui) allow treasury management through ATAs only.
Therefore, the only recommendable way for a DAO to be the recipient of Tribeca "Issue Tokens" action is to provide the treasury ATA address for the tokens being issued.
In order to solve this issue & effectively enable other DAOs to interact with Tribeca, "Issue Tokens" action, the expected behavior in Tribeca UI should be to:
check if the provided address is a Token Account (owned by the Token Account program)
if so, use this address directly as the recipient for the tokens to be issued & do not derive an ATA for this address
if not, derive the canonic ATA for the provided user wallet address, and use this derived ATA address as recipient for the tokens to be issued
in order to avoid possible confusion, explicitly state in the Tribeca UI that the provided address can be both a user wallet address or a Token Account address
PS: if I may, the above prettified production code snippet (specifically, lack of native async/await) indicates that the source code is overly transpiled, probably either to ES5 or ES6, which seems a very inneficient compilation target for modern browser target.
Using a tailored compilation target (ES2017+) would allow for significant build, load & runtime front-end performance gains (as well as easier debugging).
Hi,
I would like to report a bug in Tribeca's UI, in particular the "Issue Tokens" action, available through Tribeca proposals.
Today, the "Issue Tokens" action incorrectly assumes the address provided through the proposal creation UI is a wallet. Indeed, providing a Token Account address (1) for the "Issue Tokens" action in the proposal creation UI results in a new Token Account (2) being created, owned by the provided Token Account address (1), aka "nested Token Account". This behavior leads to the issued tokens being frozen in limbo & funds being innaccessible, as a Token Account (ie: 1) cannot sign for another Token Account (ie: 2), and a wallet cannot sign for a nested Token Account (ie: 2) as of today.
Furthermore, this behavior is not in line with the de facto standard to the spl-token CLI "transfer" command, which indicates:
https://github.com/solana-labs/solana-program-library/blob/master/token/cli/src/main.rs#L1966-L1975
This is also consistently true for the spl-token CLI "mint" command for example, which accepts a Token Account address as recipient.
https://github.com/solana-labs/solana-program-library/blob/master/token/cli/src/main.rs#L1966-L1975
Other DAO UIs (governance-ui) allow treasury management through ATAs only. Therefore, the only recommendable way for a DAO to be the recipient of Tribeca "Issue Tokens" action is to provide the treasury ATA address for the tokens being issued.
In order to solve this issue & effectively enable other DAOs to interact with Tribeca, "Issue Tokens" action, the expected behavior in Tribeca UI should be to:
See also:
Relevant Tribeca UI code:
Current Tribeca UI "Issue Tokens" action related prettified production code
PS: if I may, the above prettified production code snippet (specifically, lack of native
async
/await
) indicates that the source code is overly transpiled, probably either to ES5 or ES6, which seems a very inneficient compilation target for modern browser target. Using a tailored compilation target (ES2017+) would allow for significant build, load & runtime front-end performance gains (as well as easier debugging).Thank you in advance for your consideration.