v14.0.0-rc4 - 2023-08-30

State Machine Breaking

• (evm) #1727 Return an error when calling inactive EVM extensions
• (deps) #1732 Bump ibc-go version with error message fix.
• (vesting) #1730 Remove smart contract conversion to ClawbackVestingAccount

Full Diff: v14.0.0-rc3...v14.0.0-rc4

v14.0.0-rc3 - 2023-08-22

Improvements

• (cli) #1714 Use empty string as default value in chain-id flag to use the chain id from the genesis file when not specified.

Bug Fixes

• (proto) #1713 Add proto file for v1 vesting module account
• (deps) #1718 Update rosetta types import.

Full Diff: v14.0.0-rc2...v14.0.0-rc3

v14.0.0-rc2 - 2023-08-21

State Machine Breaking

• (deps) #1662 Bump Cosmos-SDK to v0.47.4 and ibc-go to v7.2.0.

Improvements

• (ics20) #1688 Change authorization names to grantee / granter in the ICS20 precompile
• (staking) #1702 Change authorization names to grantee / granter in the staking precompile
• (mod) #1674 Update evmos module name to evmos/v14
• (cli) #1677 Update docs for vesting cli
• (proto) #1684 Update proto files to use evmos/v14
• (deps) #1682 Migrate evmos-ledger-go logic to this repository
• (vesting) #1708 Minor improvements to vesting module
• (vesting) #1709 Add clawed back coins to MsgClawbackResponse
• (cli) #1706 Update DefaultGasAdjustment factor used in transactions.

Bug Fixes

• (e2e) #1678 Fix e2e tests after recent changes to evmosd start default flags
• (evm) #1703 Prevent panic on uint64 conversion in EVM keeper ApplyMessageWithConfig function.

Full Diff: v14.0.0-rc1...v14.0.0-rc2

v14.0.0-rc1 - 2023-08-01

Improvements

• (vesting)#1672 Port vesting precompile code and refactor integration tests
• (vesting)#1667 Add support for vesting precompile in the evm module
• (vesting) Add FundVestingAccount transaction and refactor vesting flow
• (cli) #1647 Update defaults on evmosd start flags.

Bug Fixes

• (vesting) Fix in vesting account.
• (rpc) #1650 Fix racing conditions on RPC PubSub logic
• (rpc) #1655 Avoid channel get changed when concurrent subscribe happens.
• (revenue) #1659 Check if DevelopersShares are set to 0
• (rpc) #1663 Fix block number returned in opcode for debug trace related api.

Full Diff: https://github.com/evmos/evmos/compare/v13.0.2..v14.0.0-rc1

v13.0.2 (Apeiron) - 2023-07-05

Bug Fixes

• (upgrade) #1644 Adjust upgrade constants
• (ci) #1642 Fix target folder in GH action to push to the Buf Schema Registry upon release

Full Diff: v13.0.1...v13.0.2

v13.0.1 (Apeiron) - 2023-07-04

Improvements

• (deps) #1635 Update cometbft v0.34.29 with several minor bug fixes and low-severity security-fixes.

Full Diff: v13.0.0...v13.0.1

v12.1.6 - 2023-07-04

Improvement

• (deps) #1635 Update cometbft v0.34.29 with several minor bug fixes and low-severity security-fixes

Full Diff: v12.1.5...v12.1.6

v13.0.0 (Apeiron) - 2023-07-03

Improvements

• (app) #1623 Adjust default app config to disable all server options
• (app) #1619 Add snapshot commands to CLI
• (revenue) #1607 Route gas fees from calling EVM extensions to community pool
• (docker) #1606 Improve Dockerfile to reduce image size
• (deps) #1597 Bump geth fork
• (deps) #1595 Bump cometbft and goleveldb
• (evm) #1578 Add support of ICS20 transfer extension
• (test) #1486 Add benchmark tests for DeductFeeDecorator and EthGasConsumeDecorator ante handler decorators
• (deps) #1488 Bump btcd version to v0.23.3
• (deps) #1492 Bump Cosmos SDK version to v0.46.11-alpha.ledger & use cometbft v0.34.27 replacement for Tendermint import

State Machine Breaking

• (evm) #1625 Migrate updated EVM extensions
• (vesting) #1596 Add MsgCreateClawbackVestingAccount period validation
• (evm) #1535 Add EVM extensions support

Bug Fixes

• (evm) 1602 Fixed hard coded BaseDenom and wrong comparison for MaxUint256
• (deps) #1567 Bump cosmos-sdk version to v0.46.11-alpha.ledger.7.
  Fix memory leak in cosmos/iavl package.

Full Diff: v12.1.5...v13.0.0

Release Notes

This release aims to fix some issues with the staking and the authorization precompiles on the last RC.

Changelog

Bug Fixes

• (evm) 160 Fixed hard coded BaseDenom and wrong comparison for MaxUint256

Full Changelog: v13.0.0-rc2...v13.0.0-rc3

Release Notes

This release adds the ICS20 Transfer extension to the Evmos Testnet. Moreover, it adds optimizations and refactors to the existing distribution and staking extensions.

v13.0.0-rc2 Testnet Release Changes

This document aims to outline some of the changes we are bringing to
the upcoming v13.0.0-rc2 testnet release. It's a general document for any
smart contract developers but it's particularly important for developers who have already deployed contracts to Testnet or are participanting in the DoraHacks hackaton as your contracts will break after this new testnet upgrade so please update them as soon as possible with the changes outlined in this document.

Approvals

Calling the extension directly from an EOA

We have refactored the direct to extension calls from an EOA to NOT require authorization / grant so developers can directly create a transaction calling the extension. The extension addresses are listed below:

"0x0000000000000000000000000000000000000800", // Staking precompile
"0x0000000000000000000000000000000000000801", // Distribution precompile
"0x0000000000000000000000000000000000000802", // ICS20 transfer precompile

This change allows for frontend applications utilizing the extensions directly from an EOA to have a more streamlined UX.

Calling the extension from a smart contract

In the previous testnet we were using the spender in the approval interface incorrectly. We were always assuming the spender as the msg.sender or granter and hardcoding the CallerAddress as the grantee. We want to mimic the IERC20 contract flow as closely as possible so now the spender will be the smart contract you want to authorize from the origin EOA signing the transaction.

The Interface

  function approve(
        address spender,
        uint256 amount,
        string[] calldata methods
    ) external returns (bool approved);

Before
You would pass the user or contract as msg.sender to the spender and assuming the contract to be the spendee

contract StakingManager {
    string[] private stakingMethods = [MSG_DELEGATE, MSG_UNDELEGATE, MSG_REDELEGATE, MSG_CANCEL_UNDELEGATION];
    function approveAllStakingMethodsWithMaxAmount() public {
        bool success = STAKING_CONTRACT.approve(msg.sender, type(uint256).max, stakingMethods);
        require(success, "Failed to approve staking methods");
    }
}

With v13.0.0-rc2
Now the spender has to be the contract you are trying to authorize the origin against. The origin will always be hardcoded into the grant even if the contract hops calls. So a generally good practice is to always create an authorization to contract that calls into the extension.

contract StakingManager {
    string[] private stakingMethods = [MSG_DELEGATE, MSG_UNDELEGATE, MSG_REDELEGATE, MSG_CANCEL_UNDELEGATION];
    function approveAllStakingMethodsWithMaxAmount() public {
        bool success = STAKING_CONTRACT.approve(address(this), type(uint256).max, stakingMethods);
        require(success, "Failed to approve staking methods");
    }
}

New Distribution Authorization interface

With v13.0.0-rc2 we decided to extend the distribution module's authorization struct to include an AllowedList which represents the different addresses that can be used in each of the transactions present on the interface.

The Interface
You can find the full interface HERE
For the Cosmos SDK authz changes you can find the changes HERE

function approve(
        address spender,
        string[] calldata methods,
        string[] calldata allowedList
    ) external returns (bool approved);

Before
As with the staking authorization here we were passing the msg.sender as the spender which should be replaced with the contract address of the smart contract that will be calling into the extensions. Furthermore you will notice it only took 2 parameters namely the spender and the methods.

    function _approveRequiredMsgs(uint256 _amount) internal {
        bool successDist = DISTRIBUTION_CONTRACT.approve(msg.sender, distributionMethods);
        require(successDist, "Distribution Approve failed");
    }

With v13.0.0-rc2
The new interface now enforces the correct spender parameter to be the contract address and hardcodes the tx.origin as the spendee. Additionally there is a new parameter allowedList which will always include the tx.origin if it is not passed in manually.

    function _approveRequiredMsgs(uint256 _amount) internal {
        string[] memory allowedList = new string[](0); // Will always add tx.origin address if it's not passed in manually
        bool successDist = DISTRIBUTION_CONTRACT.approve(address(this), distributionMethods, allowedList);
        require(successDist, "Distribution Approve failed");
    }

The Allowed List in transactions
Below is outlined what you can expect when passing addresses in the allowedList parameter in terms of effects on the transactions in distribution

1. MsgSetWithdrawAddress - if you wish to change the withdraw address for a user the new withdrawerAddress should be present in the allowedList.

Changelog

State Machine Breaking

(backport) #1599 Backport changes from main to v13.0.x
(vesting) #1596 Add MsgCreateClawbackVestingAccount period validation
(evm) #1535 Add EVM extensions support

Improvements

(deps) #1597 Bump geth fork
(deps) #1595 Bump cometbft and goleveldb
(evm) #1578 Add support of ICS20 transfer extension
(test) #1486 Add benchmark tests for DeductFeeDecorator and EthGasConsumeDecorator ante handler decorators
(deps) #1488 Bump btcd version to v0.23.3
(deps) #1492 Bump Cosmos SDK version to v0.46.11-alpha.ledger & use cometbft v0.34.27 replacement for Tendermint import

Bug Fixes

(deps) #1567 Bump cosmos-sdk version to v0.46.11-alpha.ledger.7.
Fix memory leak in cosmos/iavl package.
Full Changelog: v13.0.0-rc1...v13.0.0-rc2