TribecaHQ / tribeca

♜ An open standard and toolkit for launching DAOs on Solana.
https://tribeca.so
GNU Affero General Public License v3.0
132 stars 41 forks source link

"Issue Tokens" action should not assume provided address being a wallet #107

Open 0xCryptoSheik opened 2 years ago

0xCryptoSheik commented 2 years ago

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:

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

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.

The token account address of recipient"Issue Tokens" action should not assume provided address being a wallet

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:

c_("label", {
  css: Qee,
  htmlFor: "destination",
  children: [
    u_("span", { css: Xee, children: "Recipient" }),
    u_(nq, {
      id: "destination",
      placeholder: "Address to give tokens to.",
      value: h,
      onChange: function (e) {
        m(e.target.value);
      },
    }),
  ],
}),
case 19:
  return (
    (e.next = 21),
    k(
      n.provider.newTX(r),
      "Create token accounts"
    )
  );

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.

0xCryptoSheik commented 2 years ago

While we still believe this should be fixed, we're ready to work around this in our governance-ui fork: https://github.com/UXDProtocol/governance-ui/pull/40