[\#591](https://github.com/Kava-Labs/kava/pull/591) Add a `raw-params` cli method to query raw parameter values for use in manual verification of gov proposals.
[\#629](https://github.com/Kava-Labs/kava/pulls/629) Add CDP collateral type as a field for CDPs and collateral parameters.
### Breaking changes
* CDPs have an additional field, Type, which is a string that represents the unique collateral type that this CDP holds. This enables, for example, a single denom such as 'bnb' to have two CDP types, 'bnb-a' and 'bnb-b'.
* CollateralParam has an additional field, Type, which is a string that represents the collateral type of CDPs that this collateral parameter governs. It must be non-empty at genesis or when altering CDP fields. It is UNSAFE to alter the type of an existing collateral param using unchain governance.
* CDP messages must specify the collateral type 'bnb-a', rather than the denom of the cdp.
* In the incentive module, fields previously named `Denom` have been changed to `CollateralType`. Previously, 'Denom' was validated to check that it satisfied `sdk.ValidateDenom`, now, the validation checks that the `CollateralType` is not blank.
* Incentive module messages now require the user to specify the collateral type ('bnb-a'), rather than the denom of the cdp ('bnb')
[\#598](https://github.com/Kava-Labs/kava/pulls/598) CLI and REST queries for committee proposals (ie `kvcli q committee proposal 1`) now query the historical state to return the proposal object before it was deleted from state
This version mitigates a memory leak in tendermint that was found prior to launching kava-3. It is fully compatible with v0.8.0 and is intended to replace that version as the canonical software version for upgrading the Kava mainnet from kava-2 to kava-3. Note that there are no breaking changes between the versions, but a safety check was added to this version to prevent starting the node with an unsafe configuration.
The default tendermint pruning strategy, `pruning="syncable"` is currently unsafe due to a [memory leak](https://github.com/tendermint/iavl/issues/256) that can cause irrecoverable data loss. This patch release prevents `kvd` from being started with the `pruning="syncable"` configuration. Until a patch for tendermint is released, the ONLY pruning strategies that are safe to run are `everything` (an archival node) or `nothing` (only the most recent state is kept). It is strongly recommended that validators use `pruning="nothing"` for kava-3. It is expected that a patch to tendermint will be released in a non-breaking manner and that nodes will be able to update seamlessly after the launch of kava-3.
The steps for upgrading to kava-3 can be found [here](https://github.com/Kava-Labs/kava/blob/master/contrib/kava-3/migration.md). Please note the additional section on [pruning](https://github.com/Kava-Labs/kava/blob/master/contrib/kava-3/migration.md#Pruning).
This version is intended to be the canonical software version for upgrading the Kava mainnet from kava-2 to kava-3. As a result, no subsequent versions of Kava will be released until kava-3 launches unless necessary due to critical state-machine faults that require a new version to launch successfully.
### Migration
The steps for upgrading to kava-3 can be found [here](https://github.com/Kava-Labs/kava/blob/master/contrib/kava-3/migration.md)
### Features
This is the first release that includes all the modules which comprise the [CDP system](https://docs.kava.io/).
### State Machine Breaking Changes
(sdk) Update Cosmos-SDK version to v0.38.4. To review cosmos-sdk changes, see the [changelog](https://github.com/cosmos/cosmos-sdk/blob/v0.38.4/CHANGELOG.md).
Bump tendermint version to 0.32.10 to address [cosmos security advisory Lavender](https://forum.cosmos.network/t/cosmos-mainnet-security-advisory-lavender/3511)
[\#266](https://github.com/Kava-Labs/kava/pulls/266) Bump tendermint version to 0.32.7 to address cosmos security advisory [Periwinkle](https://forum.cosmos.network/t/cosmos-mainnet-security-advisory-periwinkle/2911)
[\#253](https://github.com/Kava-Labs/kava/pulls/253) Add a new validator vesting account type, which releases coins on a periodic vesting schedule based on if a specific validator signed sufficient pre-commits. If the validator didn't sign enough pre-commits, the vesting coins are burned or sent to a return address.