Kava 3 Chain Advisory

Kevin Davis

TLDR: There is a minor bug that affects changing the BEP3 asset supply, which means that the current value of 40000 BNB cannot be currently updated. No user funds are at risk due to this minor bug.

We’ve coded ourselves into a knot

The kava-3 blockchain uses parameters to govern the state of the blockchain. By changing parameters via governance, Kava can manage how the chain functions and respond to changing conditions in a time-sensitive manner. One of those parameters, the asset supply limit for BEP3 assets, has a minor bug which causes changes in the parameter value not to take effect, which means that the current supply limit, 40000BNB, cannot be updated.

The fix required is a few lines of code which enforce that when the parameter value for supply limit is updated, the state of the application is updated at that time. Importantly, this is a breaking change so we can’t just release a new version of v0.8 to fix this.

Asynchronous network update

A version of the software has been written that fixes the minor bug. In the bug fix, a time is specified when that code will take effect. Validators update their nodes before the specified time and the network will update smoothly without service interruption. Any nodes left on the previous version of the software will be forked off at that time. This is essentially the process used by the Ethereum core developers during what they call ‘network upgrades’.

This section gives a breakdown of where the minor bug is in the kava code. The code in question is in the bep3 module on kava. In the Params for the module, the assets which are supported are specified as follows:

Each asset specifies a limit — which is the number of units of that asset that can exist before further incoming swaps are disallowed. When the chain starts, the following code sets the initial limit for each asset:

The function SetAssetSupply sets the limit for each asset at the prefix 0x02 in the application database.

When the parameter value for AssetParam.Limit is updated, there is no corresponding function that updates the value in the store (by calling SetAssetSupply ). Thus, updating the parameters does not propagate to the application state.

When a new swap is created, the function IncrementIncomingAssetSupply is called, which checks that the swap is not over the asset limit stored at prefix 0x02 . Because this value has not been updated, the swap fails this check:

The fix is to add a function to the bep3 begin blocker that updates the value of AssetSupply when the value is updated in the parameters:

The UpdateAssetSupply function reconciles differences between the parameters and what’s in the store, setting the store to match the parameters.

To implement this as an asynchronous network fork, we add an activationTime argument to the function which specifies when UpdateAssetSupplies should run. For example, we specify that UpdateAssetSupply only run if ctx.BlockTime().After(activationTime) and set activation time to be one week after the bugfix release is published. Note that ctx.BlockTime() is the value of the block time agreed by the validator set, and is not subject to wall clock drift.


What do you think?


电子邮件地址不会被公开。 必填项已用*标注





How Curve.fi Works (Explainer Video)

Plutus DeFi AMA with Arnie Hill and Ali Hararwala at the t.me/amaroom