cosmos / cosmos-multisig-ui Goto Github PK

When I'm on a multisig address page, it would be great to have a link to get all details about the multisig address in an erplorer.

E.g. on this page:

you want a link to https://www.mintscan.io/cosmos/account/cosmos12jnhpa3kemykq5mg8er27lmkj39yksgf3nr9tw.

The explorer link should be configurable, so we need a new env variable similar to NEXT_PUBLIC_EXPLORER_LINK_TX.

There are a few pages where there's no navigation:

• In progress transaction -> should be able to go back to multisig view
• Multisig view -> can't go back to main page
• Create multisig -> can't go back to main page

Just a "go back to x" button at the top should do it.

When modifying tx related data fields, like adding or deleting msgs, or inputting memo, the msgs forms get cleared. Probably has to do with keyprop.

We should list the chain native token, which you can just get from querying the balance.

If a multisig somehow has multiple holdings, it would be great to display those as well, but that's a nice to have imo.

In this code we create an error when there are multiple assets:

      if (assetData.assets.length > 1) {
        denom = "";
        displayDenom = "";
        gasPrice = "";
        displayDenomExponent = 0;

        setChainError("Multiple token denoms available, enter manually");
        setShowSettings(true);
      } else {
        const asset: ChainRegistryAsset = assetData.assets[0];
        denom = asset.base;
        displayDenom = asset.symbol;
        gasPrice = `0.03${asset.base}`;
        const displayUnit = asset.denom_units.find((u) => u.denom == asset.display);
        displayDenomExponent = displayUnit?.exponent ?? 6;
      }

However, in cases like Osmosis this is very inconvenient. Most of the time you just one the first one (OSMO). It would be good to remove the error. The user can always override the values if they want a different asset.

Gotten some feedback from potential users that staking would be great to implement as well. So, together with other open issues, it looks like ideally there would be several actions that one could do with a multisig:

• Send tokens
• Staking (Claim, Delegate, Undelegate, Redelegate)
• Create vesting account #49
• Create authorization (pending ledger support)

So I'm wondering if perhaps we should just have the available actions listed, and once clicked, a new form pops up with the inputs that that Msg takes.

There's no direct feedback after pressing a button to create a multisig or transaction, but it can take a while before the next page loads. Could we get a simple loading icon in or around the button or something like that?

On the main landing page, it would be great to see a list of multisigs that you have created that are stored in the DB.
On the specific multisig page, seeing a list of transactions that have been created or have been completed could be useful as well.

Imo, the transactions should probably only be visible if you are a member of the multisig.

This will only work for multisigs and transactions created through this app, as there is no way to query for them on-chain afaik.

When changing the account on the keplr extension, the app should automatically refresh its address, signer, etc., to reflect that change

Right now the user sees this when a transaction was composed and sigened:

At this point it is unclear what needs to be done in order to let other users sign. Also it does not work great if the transaction composer is not in the signer set.

In order to clarify this in the UI, I propose the following screens:

1. Compose transaction
2. Confirm of compose, show signing link in UI. Composer can copy link or sign if in the signer set.
3. Signing screen

Right now I can sign a transaction for a multisig that I am not part of. It even shows "1 of 2 signatures complete" in that case. This is not dangerous because my signature is just worthless. However, it would be nice to tell the user earlier to avoid a hard to debug signature verification failure later on.

This case can happen easily if a user has multiple accounts.

For the raw HTTP requests

      const chainInfoUrl =
        "https://cdn.jsdelivr.net/gh/cosmos/chain-registry@master/" +
        chainOption.path +
        "/chain.json";
      const chainAssetUrl =
        "https://cdn.jsdelivr.net/gh/cosmos/chain-registry@master/" +
        chainOption.path +
        "/assetlist.json";

      const { data: chainData } = await axios.get(chainInfoUrl);
      const { data: assetData } = await axios.get(chainAssetUrl);

we should get interfaces to ensure we have type safety accessing the data.

This is already started in components/chainSelect/chainregistry.ts but should be reviewed and used to the above cases. We don't need all fields but the ones we use should be typed.

Great tool, I hope I can play around with it even more.

I've opened an issue on the Keplr extension source code because the transactions created by the tool are reporting an error from Keplr: "Insufficient available balance for transaction fee". Details are here: chainapsis/keplr-wallet#204

The current input looks like this:

This is cool and it works. It has a few flaw such as clearing the field every time you click in it.

I wonder if we find a better UI component for a list of existing options or a custom input. We could also go with something like a radio button that has the pre-defined options as well as a "Custom" option that comes with an input field.

• Bank
  • Send
• Staking
  • Delegate (fixed in #89)
  • Claim rewards, Undelegate, Redelegate (#95)
  • Set Withdraw address (#123)
• Vesting
  • Create vesting accounts (#126)
• IBC
  • MsgTransfer (#127)
• Governance
  • MsgVote
• CosmWasm (#158)
  • Execute
  • Instantiate/Instantiate2
  • Migrate
• Create authorization (CosmJS/Ledger support ready?)

The "enable err:" in

  connectWallet = async () => {
    try {
      await window.keplr.enable(process.env.NEXT_PUBLIC_CHAIN_ID);
      const walletAccount = await window.keplr.getKey(
        process.env.NEXT_PUBLIC_CHAIN_ID
      );
      const hasSigned = this.props.signatures.some(
        (sig) => sig.address === walletAccount.bech32Address
      );
      this.setState({ walletAccount, hasSigned });
    } catch (e) {
      console.log("enable err: ", e);
    }
  };

happens when Keplr is not installed. It would be nice to propagate that error to the user.

This is a small UX change:

The display of Gas (example: https://cosmoshub-legacy-multisig.vercel.app/multi/cosmos16k579jk6yt2cwmqx9dz5xvq9fug2tekv6g34pl/transaction/317278883132998223)

shows that it is in uatom, which is incorrect. The gas has no denomination, it's just a counter.

The fee HAS denomination and if there is any in the transaction, it should be displayed. (Or 0uatom if there is none.)

Once released, we should upgrade @cosmjs/* to 0.29.x and

• Use makeMultisignedTxBytes (cosmos/cosmjs#1176)

Using Comdex as an example, the console printed an error that the the node was not available. I would suggest putting all RPC endpoints in an array, catching any error, and iterating over the list until there is a successful connection.

On failure at end of array, inform the user that none of the listed RPC endpoints are, available instead of the generic "failed to fetch" message.

We'll need this for claiming rewards from multiple validators in one tx but also allowing multiple sends would be nice.

• Organize UI to differentiate between message and transaction (#97)
• Allow creating multiple messages of the same type in the form
• Allow a mixed list of messages
• Automatically caclulate a reasonable gas limit for multi message transactions

No specific reason other than going with the flow.

Next.js 11+ had some eslint plugin that migth be handy here.

Part of #99

Right now the app only supports signing messages for sending tokens. It would be great if multisigs could create and sign any message type (even uploading or pasting in JSON).

I'm a little unclear as to whether this would mean adding support for protobuf message types, or if the Amino signer can handle any message type.

@webmaster128 Any ideas?

@webmaster128 https://rpc.sentry-01.theta-testnet.polypore.xyz this testnet not working!

As of now, it's possible to create new transactions. Besides that we should add a button "Import Transaction" which let's the user importing the JSON String of an existing transaction. Otherwise it's only possible to sign simple transfers.

E.g. in JUNO they need more advanced transactions to delegate stuff etc.

A simple textbox to import pre-formatted JSON should be enough.

gm, we're running into the following error whenever we try to broadcast a transaction:
Error: Broadcasting transaction failed with code 18 (codespace: sdk). Log: invalid delegation amount: invalid request

example signed transactions that experience this error when broadcasting:
#1
#2

The last multisig transaction that we were successfully able to execute (also a delegation tx) was on April 18th, and then both signers (ledgers) started experiencing this error.

NEXT_PUBLIC_MULTICHAIN can't be set to false, since it's always interpreted as a string. This means that if (process.env.NEXT_PUBLIC_MULTICHAIN ) is always true.

At the moment there is no tooling for linting and code formatting, right?

Yesterday I tried to setup eslint + prettier, which is a combination I'm very happy with for other projects. It was not easy to configure due to JSX/React and a bunch of other things. Also there are some unmaintained files in the folder that probably should be excluded.

Before I invest more work in this, I'd like to check if this is something we want here and if eslint is fine for you? This setup can easily be extended by a TypeScript plugin, such that we are prepared for a TS migration.

testnets is a folder with testnets that we probably want to exclude.

When you are viewing a multisig address from chain A and switch to chain B, the multisig address listed is still from chain A, while the addresses listed are from chain B. An error is produced:

This multisig address's pubkeys are not available, and so it cannot be used with this tool.

You can recreate it with this tool here, or sign and broadcast a transaction with the tool you used to create it. Either option will make the pubkeys accessible and will allow this tool to use this multisig fully.

I suggest we just redirect to the landing page when a user selects a new chain on any page (like viewing a transaction as well for example).

this seems to be unused

This repository is missing a LICENSE. Given that it has been developed for the Interchain Foundation in the past, I assume Apache 2 is the appropriate choice. At least from Confio's perfective it is.

I'd like to ask the contributors of this repo to confirm they are happy with that

• @webmaster128 (Confio GmbH)
• @abefernan (Confio GmbH)
• @msteiner96 (Confio GmbH)
• @samepant
• @klk1236
• @nooomski
• @okwme

We have a lint command (npm run lint) but it is not part of CI checks. Would be good to get this into some GitHub Actions or CircleCI config.

The message looks like this:

export interface MsgTransfer {
  /** the port on which the packet will be sent */
  sourcePort: string;
  /** the channel by which the packet will be sent */
  sourceChannel: string;
  /** the tokens to be transferred */
  token?: Coin;
  /** the sender address */
  sender: string;
  /** the recipient address on the destination chain */
  receiver: string;
  /**
   * Timeout height relative to the current block height.
   * The timeout is disabled when set to 0.
   */
  timeoutHeight?: Height;
  /**
   * Timeout timestamp in absolute nanoseconds since unix epoch.
   * The timeout is disabled when set to 0.
   */
  timeoutTimestamp: Long;
  /** optional memo */
  memo: string;
}

Some notes here:

• sourcePort should be pre-set to "transfer" by default, but can be changed by the user
• token is required and an aribrary numeric amount and arbitrary string denom (only one, no list here)
• We can use timeoutTimestamp only and put a date in the future. timeoutHeight can be set to undefined. Ideally we offer the user simple options like 12 hours from now, 1 day from now, 2 days from now, 3 days from now, 7 days from now, 10 days from now, 2 weeks from now, 3 weeks from now, 1 month from now, custom time
• The memo in the message is a different memo than the transaction memo. Both can be set individually.

The multisig account needs an account number on chain at compose time as shown in this example: https://github.com/cosmos/cosmjs/blob/v0.27.0/packages/stargate/src/multisignature.spec.ts#L177-L207

Now if I create a transaction for a newly created multisig address, there will be no account number and

    if (!accountOnChain) {
      accountOnChain = {};
    }
    accountOnChain.pubkey = pubkey;

will be used from now on. However, due to the missing accountNumber, signing will fail later on with some hard to debug error message:

Error creating signature: TypeError: Cannot read properties of undefined (reading 'toString') at makeSignDoc (signdoc.js?0bac:31:1)

I think it would make sense to not allow composing a transaction without an accountNumber.

Looks like it fails on looping through the array of addresses and needs an error catch.

Would be great if this error could be thrown at input already: "This is not a valid multisig address" or something.

When a transaction is broadcasted, it would be nice to have the transaction hash easily available in the UI.
Right now only a Mintscan Cosmos Hub link is available (that fortunately contains the hash). With the hash in the UI it is easier to use it in other tools.

@samepant any chance we could include testnets as well for testing this tool? My accountant would appreciate it if I could not use real ATOMs ;)

I've updated my chain registry repo to include testnets, I think you can probably copy a bunch: https://github.com/nooomski/registry-ui

Would be cool if there was an option to create a vesting account. A few things to consider:

• To create a vesting account, the address needs to not have been initialised on-chain already (i.e. never received a balance)
• To create a vesting account, some tokens need to be transferred in that create-vesting-account Tx
• There are two ways to do vesting:
  • Delayed vesting: all tokens unlock at once at a specified time (the most common usage)
  • Continuous: all tokens unlock continuously until a specific time
• The spec seems to be out of date, as it is currently possible to create new vesting accounts (just tested it on theta testnet)

This is primarily aimed at funding organisations like the ICF.

If you'd like you can experiment with this on CLI on the Theta testnet using 'gaiad tx vesting create-vesting-account [receiving address] [amount] [unix epoch time] --chain-id theta-testnet-001 --node http://rpc.sentry-01.theta-testnet.polypore.xyz:26657 --from [sending key] --delayed`. Please ping me if you need testnet tokens.

I've been trying to test this tool out, but was unable to without putting some effort into converting my address to compressed Secp256k1.

In order to provide a smooth user experience for users on all expertise levels, it would be great if this tool would accept addresses as directly copied from wallets like Keplr. Are you able to implement a check, so that the tool auto-detects the pubkey type and converts where necessary?

This currently fails Netlify deployment.

I think Netlify requires a few adjustments to get Next.js serverless functions working on their platform. More info here

On the tx signing screen when you click "Connect Ledger (WebUSB)" and the Ledger is connected but the Cosmos app is not open, there is an error

Uncaught (in promise) Error: Please close BOLOS and open the Cosmos Ledger app on your Ledger device.

But this is not shown to the user. Instead nothing happens.

Right now the app assumes there is only 1 message per transaction and has one transaction form per message type. However, this creates a lot of duplication. Also it makes adding new message types harder than necessary.

It would be good to make a standard transaction form where you just pass the message type as an argument. Then each message type has its own form component for the input.

Some data (especially memo) can then more from the message form to the transaction form where it belongs.

We currently hardcode the gas price 0.03${firstAsset.base} which is often not what you want. However, in many cases the gas price is available in the chain registry.

It's currently showing as 6, when it should be 9. I hope this is the place to have it corrected.

It would be nice if the user could choose between signing with Keplr and signing with Ledger (via WebUSB). This has been developed and is tested in other places. It's just a matter of integrating it in the app.

Why is this relevant?

• choice
• more flexible use of different bowsers or user profiles
• easier for chains that are not yet integrated in Keplr

Trying to broadcast this Tx and getting the following error:

Broadcasting transaction failed with code 4 (codespace: sdk). Log: signature verification failed; please verify account number (1126996), sequence (0) and chain-id (cosmoshub-4): unauthorized

I can't tell for sure, but I believe this is from a multisig that I've used before and have submitted a tx for in the past, or even have unsubmitted txs in the DB somewhere. I'm guessing something is going wrong with the sequence number there.