x/feegrant Module Readiness Checklist

[clevinson]

x/fee_grant Module Readiness Checklist

This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release.

Prior to beta tag

• Completeness audit, fully implemented with tests (at least 1 person) (@blushi ) x/feegrant Completeness audit, fully implemented with tests #9030
  • Genesis import and export of all state
  • Query services
  • CLI methods
  • All necessary migration scripts are present (if this is an upgrade of existing module)
• API audit (at least 1 person) (@aleem1314 ) x/feegrant API audit #9028
  • Are Msg and Query methods and types well-named and organized?
  • Is everything well documented (inline godoc as well as /spec/ folder in module directory)
  • Check the proto definition - make sure everything is in accordance to ADR-29

Release Candidate Checklist

The following checklist should be gone through once the module has been fully implemented. This audit should be performed preferably on a alpha or beta release tag that includes the module.

The module should not be included in any Release Candidate tag until it has passed this checklist.

• State machine audit (at least 2 people) (@blushi @aleem1314 @technicallyty) x/feegrant State machine audit #9029
  • Read through MsgServer code and verify correctness upon visual inspection @blushi @aleem1314
  • Ensure all state machine code which could be confusing is properly commented @blushi @aleem1314
  • Make sure state machine logic matches Msg method documentation @blushi @aleem1314
  • Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) @technicallyty @blushi
  • Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to:
    • algorithmic complexity and places this could be exploited (ex. nested for loops)
    • charging gas complex computation (ex. for loops)
    • storage is safe (we don't pollute the state).
  • Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed @technicallyty @aleem1314
• Check correctness of simulation implementation if any (@aleem1314)

Published Release Checklist

After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary):

• Testnet / devnet testing (2-3 people) (@blushi @aleem1314 @technicallyty )
  • All Msg methods have been tested especially in light of any potential threats identified
  • Genesis import and export has been tested
• Nice to have (and needed in some cases if threats could be high): Official 3rd party audit

[clevinson]

One note from our Spring Review call today, we've decided that in particular the API Audit and Completeness Audit should be done first, and once completed, a beta release can be tagged.