demergent-labs / multisig_vault Goto Github PK

Should we make it a best practice to always surround mutations in a try catch? We need to ensure we never get into an inconsistent state?

Canisters need to be very careful when trapping, and I believe when an error is thrown in Boa then the canister will panic thus causing a trap. This could lead to inconsistent behavior if there have a been any cross-canister calls, as the state before the call will have been committed but not the state after the call.

For now I am doing all mutations after any cross-canister calls, so any uncaught errors should wipe clean, but we should be aware of this and possibly come up with best practices.

Whichever elements seem like they will be useful for other projects, make them completely modular

The step input is completely broken right now: SAP/ui5-webcomponents#5109

• Signer proposals
  • Non-signers cannot propose
• Threshold Proposals
  • Non-signers cannot propose
• Transfer Proposals
  • Non-signers cannot propose
• Signer voting
• Threshold voting
• Transfer voting

The biggest problem here is how much quicker we will burn through cycles, since we'll be doing an update call essentially every second

Also consider making a simple web component that anyone can pop in to show canister stats

I am hoping this isn't necessary if we aren't using npm link azle, try to remove it once we are on a fixed version of Azle.

Using a simple/robust state machine like Redux might really help us manage our state transitions

When signers and threshold change and there are open proposals, what should we do? For now I am not allowing signers or the threshold to be changed if there are open transfer proposals. As we continue to create more multisig applications, we should learn the most elegant way to handle this situation.

demergent-daos might be the highest-level components (both frontend and backend) that we want to maintain...multisig ICP vault, multisig NFT valut, multisig neuron, and SNS are all things we can have frontend components for, and the the multisigs can have a backend...we will need to modularize and componentize and generalize everything even further.

The Rust naming conventions are kind of nice, perhaps we should just use them everywhere in JS?

When the threshold changes, we should probably loop through all proposals and reevaluate them at that time, executing any that now should pass.

Frontend and backend canisters should have controller information too

We need to fix some things in Azle before being done with this section

• TransferError
• get mutator pattern with generator in abstracted function

This table can have the canister principal, address, link to source code, binary hash, cycles balance, etc

Don't forget stats and info for the frontend canister, that is very necessary as well

Could be fun to have a configurable timelock

Kind of want a black, grey, granite, etc color scheme

Here is what we need to do to feel comfortable with the first version of the Multisig:

• #27
• Make adopt/reject buttons the first thing
• Make little refresh buttons
• Remove signer button is weird
• Consider what happens when changing the threshold and changing the number of signers...this needs to be very robust...it is really starting to seem like the threshold and signers should be snapshotted into the proposal
• #33
• get rid of space on adopt/reject
• Update the threshold after a threshold proposal is adopted or rejected and when refreshing
• The threshold was 2 and we removed one signer and it worked, we need rules for removing signers
• Should non-signers be able to recalculate stats and see proposals?
• We actually need a margin between the adopt and reject buttons
• state index types on the backend
• Always pass in values from state, only mutate inside of a mutator
• #26
• #9
• #28
• #36
• #10
• #25
• #43
• #37
  • IILabs team needs to fix: recover from seed phrase on phone
  • IILabs team needs to fix: manually entire anchor on phone
• #35
• Personal security review
• Personal penetration test
• Good README that explains all steps for local and production deployment and all commands
• Create a make autonomous button...this should require the same threshold rules as currently set, and it simply removes all controllers from the frontend and backend canisters except for the backend canister
• Security reviews and audits using the known canister best practices

There should also be some kind of indicator when loading...probably on the button

Any known error types we should actually display as nice messages to the user.

not sure this is really that important for now

Just write a simple little command thing that sets up all of the automatically generated js/ts