• verify deployment parameters.
• require fail - summoner can not be zero address.
• require fail - period duration can not be zero.
• require fail - voting period can not be zero.
• require fail - voting period exceeds limit.
• require fail - grace period exceeds limit.
• require fail - dilution bound can not be zero.
• require fail - dilution bound exceeds limit.
• require fail - need at least one approved token.
• require fail - too many tokens.
• require fail - deposit cannot be smaller than processing reward.
• require fail - approved token cannot be zero.
• require fail - duplicate approved token.

• happy case.
• require fail - insufficient tribute tokens.
• require fail - tribute token is not whitelisted.
• require fail - payment token is not whitelisted.
• require fail - applicant can not be zero.
• require fail - applicant address can not be reserved.
• failure - too many shares requested.
• failure - too many shares (just loot) requested.
• failure - too many shares (& loot) requested.
• happy case - second submitted proposal returns incremented proposalId.

• ragekick - happy case - can ragekick immediately after guild kick.
• ragekick - failure - member must have some loot.

• happy case - yes vote.
• happy case - no vote.
• require fail - proposal does not exist.
• require fail - vote must be less than 3.
• require fail - voting period has not started.
• voting period boundary.
  • require fail - voting period has expired.
  • success - vote 1 period before voting period expires.
• require fail - member has already voted.
• require fail - vote must be yes or no.
• modifier - delegate.
• submitVote modifying member.highestIndexYesVote.
  • require fail - voting period not starting yet.
  • happy case - yes vote, highestIndexYesVote is updated.
  • happy case - no vote, highestIndexYesVote not updated.

The size of submoloch is exceeded the limitation.

Possible Solutions

1 split submoloch to three small contracts,

1. guild :: to manage memberships;
2. grant :: to process proposals.
3. pool :: to transfer the funds

2 shrinking wasm size

1. Experiment wasm-opt optimization options suggested in (paritytech/cargo-contract#110)
2. Experiment methodologies suggested in https://github.com/johnthagen/min-sized-rust

3 Remove erc20 contract from submoloch build dependency. Use erc20-trait instead.

4 Convert error strings to custom Error types.

Leave client side decide which error strings should be printed.

5. Use types that take smaller spaces. (e.x.: u128 -> u8)

• happy case.
• failure - member does not exist.
• failure - proposal does not exist.

• happy case.
• require fail - applicant can not be zero.
• require fail - cannot add already have whitelisted the token.
• happy case - second submitted proposal returns incremented proposalId.

• happy case.
• failure - already sponsored.
• failure - already cancelled.
• failure - solely the proposer can cancel.

• happy path - pass - yes win.
• happy path - fail - no wins (proposer gets funds back).
• happy path - shares added to existing member.
• happy path - applicant is used as a delegate key so delegate key is reset.
• happy path - auto-fail if shares exceed limit.
• happy path - auto-fail if loot & shares exceed limit.
• happy path - token whitelist.
• happy path - guild kick member.
• edge case - paymentRequested more than funds in the bank.
• edge case - dilution bound is exceeded.
• require fail - proposal does not exist.
• require fail - proposal is not ready to be processed.
• require fail - proposal has already been processed.
• require fail - previous proposal must be processed.
• require fail - must be a whitelist proposal.
• require fail - must be a guild kick proposal.
• require fail - must be a standard process not a whitelist proposal.
• require fail - must be a standard process not a guild kick proposal.

• happy case.
• failure - can not be zero address.
• failure - cant overwrite existing members.
• failure - cant overwrite existing delegate keys.

• full ragequit -
  • happy path
• partial shares
  • happy path
• require fail -
  • not a member.
  • requesting more shares than you own.
  • requesting more loot than you own.
  • when a proposal is in flight
    • unable to quit when proposal in flight.
• withdraw balance
  • withdraw full balance (applicant, sponsor, processor.
  • withdraw some balance (applicant.
  • withdraw 0 balance (applicant).
  • require fail - insufficient balance.

reference: https://github.com/paritytech/ink/tree/master/examples/erc20.

• can still ragequit (justMember modifier.
• can still partial ragequit (justMember modifier.
• unable to update delegateKey (justShareholder modifier).
• unable to use delegate key to sponsor (justShareholder modifier).
• unable to use delegate key to vote (justDelegate modifier)'.

• happy path - sponsor add token to whitelist.
• with a second member besides the summoner.
• happy path - sponsor proposal.
• failure - proposal has already been sponsored.
• failure - proposal has been cancelled.
• failure - sponsor whitelist token proposal already proposed.
• require fail - insufficient deposit token.
• require fail - sponsor non-existant proposal fails.

The following is the quick note of my roughly idea, gonna be changed later.

#+begin_src rust
#[ink_error::ink_error_definition]
pub enum SubmitProposalError {
/// too many tribute tokens
TooManyTributeTokensError
}
#+end_src

will derive to

#+begin_src rust
#[derive(displaydoc::Display, Debug, scale::Encode, scale::Decode)]
pub enum Error {
/// too many tribute tokens
ProposalNotFound,
TransferFail(erc20::Erc20::error)
}
#+end_src

#+begin_src rust

fn sponsor_proposal(&mut self, args: bool) -> Result<(), Error> {
// exit early if input args are not good,
ink_error::ensure!(true, Error::ProposalNotFound);

// panic to revert the state on chain.
ink_error::assert!(true, Error::TransferFail(erc20::Erc20::error:InsuffienceBalances));

// real business logic

Ok(());

}
#+end_src

• happy case.
• failure - proposal does not exist.

• happy case.
• require fail - member must have at least one share.
• happy case - second submitted proposal returns incremented proposalId.

Reference: https://redspot.patract.io/en/tutorial/

• failure - member must be in jail.

• happy case - can ragekick after second membership proposal is processed.
• ragekick - boundary condition - must wait for highestIndexYesVote propopsal to be processed.

• cant process proposals for a jailed applicant.
• cant sponsor proposals for a jailed applicant.
• cant sponsor proposals for a jailed applicant.
• cant sponsor guild kick proposals for a jailed applicant.
• cant submit proposals for a jailed applicant.
• cant submit guild kick proposals for a jailed applicant.

• when the first whitelist proposal passes, the second can no longer be sponsored.
• when the first whitelist proposal fails, the second can still be sponsored.