cosmos / cosmos-multisig-ui Goto Github PK
View Code? Open in Web Editor NEWCreate multisigs and multisig transactions on Cosmos chains
Home Page: https://multisig.confio.run
Create multisigs and multisig transactions on Cosmos chains
Home Page: https://multisig.confio.run
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.
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.
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.
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.
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?
@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
this seems to be unused
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
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.
It's currently showing as 6
, when it should be 9
. I hope this is the place to have it corrected.
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.
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
makeMultisignedTxBytes
(cosmos/cosmjs#1176)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 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.
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.
@webmaster128 https://rpc.sentry-01.theta-testnet.polypore.xyz this testnet not working!
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?
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
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.
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.
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?
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:
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.
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 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
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.
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.
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 usertoken
is required and an aribrary numeric amount and arbitrary string denom (only one, no list here)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 timememo
in the message is a different memo than the transaction memo. Both can be set individually.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.
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.
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:
No specific reason other than going with the flow.
Next.js 11+ had some eslint plugin that migth be handy here.
There are a few pages where there's no navigation:
Just a "go back to x" button at the top should do it.
Would be cool if there was an option to create a vesting account. A few things to consider:
create-vesting-account
TxThis 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.
testnets is a folder with testnets that we probably want to exclude.
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.
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.
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?
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
.
When changing the account on the keplr extension, the app should automatically refresh its address, signer, etc., to reflect that change
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.
Part of #99
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.
We'll need this for claiming rewards from multiple validators in one tx but also allowing multiple sends would be nice.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.