feat(sui): add init multisig command #349
Conversation
| @@ -153,13 +213,21 @@ if (require.main === module) { | |||
| addBaseOptions(program); | |||
|
|
|||
| program.addOption(new Option('--txBlockPath <file>', 'path to unsigned tx block')); | |||
| program.addOption(new Option('--action <action>', 'action').choices(['sign', 'combine', 'execute']).makeOptionMandatory(true)); | |||
| program.addOption(new Option('--action <action>', 'action').choices(['sign', 'combine', 'execute', 'init']).makeOptionMandatory(true)); | |||
There was a problem hiding this comment.
@blockchainguyy Refactor this to use Commands like we do for other Sui scripts
.github/workflows/test-sui.yaml
Outdated
|
|
||
| - name: Submit Signed Tx File | ||
| run: | | ||
| node sui/multisig.js --txBlockPath ./tx-upgrade.json --signatureFilePath ./combined.json --action combine --signatures signature-1.json signature-2.json |
There was a problem hiding this comment.
Test if gateway approve still works post upgrade
There was a problem hiding this comment.
Is the contract address being updated to the new package id after upgrade?
There was a problem hiding this comment.
@milapsheth Yes, it'll be upgraded to the new package id. Approval works with either the upgraded contract or the original contract. In this case, should we implement some mechanism to guard access to all prior versions of the package, because they're still exist on-chain?
There was a problem hiding this comment.
Foivos is looking into the upgrade mechanism to create a design for our contracts. We want some methods to be accessible on the old contract potentially, and some to not be depending on upgrade versioning
Description
This PR added the
initcommand tomultisig.js, in order to make the multisig flow smoother.The init command receives the following params from the cli options:
base64PublicKeysthresholdschemaTypesweightsThen, it constructs the
multisigobject save into the config file.