Contract manager upgrades #952
Conversation
Some functions in xc_governance were moved and refactored in order to become usable in contract manager
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
| * @param sender based on the contract type, this can be a private key, a mnemonic, a wallet, etc. | ||
| * @param vaa the VAA to execute | ||
| */ | ||
| abstract executeGovernanceInstruction(sender: any, vaa: Buffer): Promise<any>; |
There was a problem hiding this comment.
the sender any concerns me a bit, as it's going to be confusing what info to provide where. A simple solution would be to make a type that contains the union of all private key information needed by any chain, then pass that here.
| * @param fee the new fee to set | ||
| * @param exponent the new fee exponent to set | ||
| */ | ||
| generateGovernanceSetFeePayload(fee: number, exponent: number): Buffer { |
There was a problem hiding this comment.
why are these governance payload methods on Chain? these are really operations that apply to specific contracts, even though the identification of those contracts is somewhat imprecise because it's using chain id.
There was a problem hiding this comment.
I was also a bit on the fence on where to put these. Putting them in the contract classes gives a false sense that it can only be executed on that specific contract whereas it can be executed on any contract deployed on that chain (as long as the governance data source matches). Also, I'm planning to add a GlobalChain with id 0 for global messages.
There was a problem hiding this comment.
Fun fact, in aptos and sui, the target chain id is the same for testnet/mainnet!
| import { Chains, CosmWasmChain } from "../src/chains"; | ||
| import { CosmWasmContract } from "../src/cosmwasm"; | ||
| import { DefaultStore } from "../src/store"; | ||
|
|
There was a problem hiding this comment.
it would be helpful for me to see an example for running a governance action also, as the flow is a little different.
Although the set of vaults used in testing/production is just 2 it's a good idea to not set them as predefined constants. So that for development purposes, we can create new vaults and test them on the fly without changing too many places.
|
Thanks for the comments. Addressed most of them. The rest would be on a different PR. |
No description provided.