Kava-4 Asynchronous Network Upgrade

A permissions issue has been discovered in the bep3 module that prevents atomic swaps from completing successfully. No user funds are at risk, but the bep3 module needs to be updated in order for atomic swap functionality to resume.

Proposal

A patch version of the kava software, v0.12.0, has been released that fixes the issue. The patch will take effect at Tuesday Nov 3rd, 2020 at 10:00UTC.

Updating

Validators should install this version of the kava software anytime prior to the upgrade activation time.

# from the kava directory 
git fetch
git checkout v0.12.0
# verify version
kvd version --long
# name: kava
# server_name: kvd
# client_name: kvcli
# version: 0.12.0
# commit: 35a82acbd07ecd51cb22c6621760ba64f46eca90
# build_tags: netgo,ledger
# go: go version go1.15.2 linux/amd64
# Install
make install

# restart the kava process
# example shown using systemd 
sudo systemctl restart kvd 

Technical Details

As part of our updated bep3 architecture, the bep3 module account is now responsible for minting coins for incoming atomic swaps and burning coins for outgoing atomic swaps. As part of the kava-4 upgrade, the bep3 module account was granted these permissions in the application. However, these permissions are not automatically applied for existing module accounts. Because the bep3 module account existed on kava-3 and did not have minting/burning permissions, the account did not inherit the updated permissions.

Currently, the bep3 module account returns:

kvcli q account kava1eyugkwc74zejgwdwl7mvm7pad4hzdnka4wmdmu
|
  address: kava1eyugkwc74zejgwdwl7mvm7pad4hzdnka4wmdmu
  coins: []
  public_key: ""
  account_number: 8560
  sequence: 0
  name: bep3
  permissions: []

As shown, the permissions are empty. When activated, the patch will update the permissions to

permissions:
  - minter
  - burner

Analysis

This is a frustrating bug, as the x/supply module in the cosmos-sdk should validate that the application level module account permissions match the individual account permissions and panic on startup if they don’t. This type of design pattern where the same information is stored in multiple places and not cross-validated leads to bugs like this where unresolved conflicts in permissions persist at runtime. The bugfix is simple, and we have filed an issue on the cosmos-sdk to include this type of validation at application startup.

We’re disappointed that this bug was not caught prior to mainnet launch, as we are constantly improving our engineering process to balance the need to ship new products in a safe and efficient manner. While this bug is minor and does not put user funds at risk, we take it very seriously and will use this opportunity to review or internal practices and increase the likelihood of catching this bugs in pre-release testing.

Stay in touch!

• Follow us on Twitter: https://twitter.com/kava_labs
• Join the conversation on Telegram: https://t.me/kavalabs
• Checkout our code: https://github.com/kava-labs

Disclaimer: This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making investment decisions.