06 Mar 16:24

ericpassmore

9ce19b3

EOS System Contracts v3.3.0 Release Notes Latest

Latest

This release contains new features.

Usecases

Ram Transfer Usecases

Improves EOS account creation:
a. Create newaccount using ramtransfer instead of buyram or buyrambytes
Improves RAM token wrapper development:
a. Receive RAM without buy/sell actions (no fees to transferring RAM)
b. Existing RAM supply can be transferred to existing RAM token wrappers
c. DeFi composability using memo field

New Ram Actions

PRs

New ram_actions functions.

Ram Transfer

New RAM system contract action to transfer RAM from one account to another without any fees.

Charges 0% fee to transfer
Only uncommited RAM can be transferred
Notify to & from using require_recipient
Memo cannot exceed 256 bytes
returns struct action_return_ramtransfer

Ram Burn

New RAM system contract action to burn RAM from owner account.

Burned RAM is transferred to eosio.null account
Should have no impact on RAM Bancor market, RAM supply should remain unchanged
returns struct action_return_ramtransfer

Ram Logging

Add buy RAM logging by including additional inline actions and notifications via the use of require_recipient.

bytes & quant are computed values based on Bancor algorithm market.

This allows payer or receiver to confirm exact bytes sent/received via notifications.

Buy Ram

returns struct action_return_buyram

Buy Ram Bytes

returns struct action_return_buyram

Buy Ram Self

returns struct action_return_buyram

Sell Ram

returns struct action_return_sellram

API Changes

Add require_recipient(receiver) on buyram & buyrambytes actions

ACTION: `ramtransfer`

from {name}
to {name}
bytes {int64}
memo {string}

ACTION: `ramburn`

owner {name}
bytes {int64}
memo {string}

ACTION: `logbuyram`

/**
 * Logging for buyram & buyrambytes action
 *
 * @param payer - the ram buyer,
 * @param receiver - the ram receiver,
 * @param quantity - the quantity of tokens to buy ram with.
 * @param bytes - the quantity of ram to buy specified in bytes.
 * @param ram_bytes - the ram bytes held by receiver after the action.
 */
[[eosio::action]]
void logbuyram( const name& payer, const name& receiver, const asset& quantity, int64_t bytes, int64_t ram_bytes );

ACTION: `buyram` `buyrambytes` `buyramself`

return struct action_return_buyram

"name": "action_return_buyram",
"base": "",
 "fields": [
                 {
                     "name": "payer",
                     "type": "name"
                 },
                 {
                     "name": "receiver",
                     "type": "name"
                 },
                 {
                     "name": "quantity",
                     "type": "asset"
                 },
                 {
                     "name": "bytes_purchased",
                     "type": "int64"
                 },
                 {
                     "name": "ram_bytes",
                     "type": "int64"
                 }
]

ACTION: `ramtransfer` `ramburn`

returns struct action_return_ramtransfer

"name": "action_return_ramtransfer",
"base": "",
"fields": [
            {
               "name": "from",
               "type": "name"
            },
            {
               "name": "to",
               "type": "name"
            },
            {
               "name": "bytes",
               "type": "int64"
            },
            {
               "name": "from_ram_bytes",
               "type": "int64"
            },
            {
               "name": "to_ram_bytes",
               "type": "int64"
            }
]

ACTION: `sellram`

returns struct action_return_sellram

"name": "action_return_sellram",
"base": "",
"fields": [
                 {
                     "name": "account",
                     "type": "name"
                 },
                 {
                     "name": "quantity",
                     "type": "asset"
                 },
                 {
                     "name": "bytes_sold",
                     "type": "int64"
                 },
                 {
                     "name": "ram_bytes",
                     "type": "int64"
                 }
]

Preconditions

Ram Transfer Preconditions

from must have sufficient ram_bytes prior to transfer
from decrease ram_bytes by bytes
to must exists
to account can be a contract
to account can have zero available RAM bytes
to increase ram_bytes by bytes
handle ram_managed accounts

Ram Burn Preconditions

Same conditions as ramtransfer action

Further details on changes since last release

Special thanks to the contributors that worked on this release:

Full list of changes since last release

PRs

Set version to rc1 for release of ram_actions by ericpassmore in #114
Bump release to next version v3.3.0-dev by ericpassmore in #94
New ram_actions functions by DenisCarriere in #112

Full Changelog: v3.2.0...v3.3.0

Contributors

DenisCarriere and ericpassmore

Assets 2

06 Dec 23:42

ericpassmore

v3.2.0

3d474ed

EOS System Contracts v3.2.0 Release Notes

This minor release contains removal of deferred transactions, test updates, and minor bug fixes.

Remove of Deferred Transactions

Removal of Deferred Transactions from System Contract

PRs

(56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
(88) Remove Deferred Transactions from System Contract

Within the system contracts the actions system_contract::bidname, system_contract::buyram, wrap::exec no longer issue deferred transactions. This is a change for the system_contract::bidname action, and failed bids will need an explict refund. For the system_contract::buyram action the default behavior remains unchanged. The wrap::exec action has been rewritten to use send instead of send_deferred.

Test Updates

PRs

(62) Minor cleanup of eosio.token tests
(67) Updated libtester removing no longer needed runtime.h libary
(68) Missed a referrence, updated libtester removing no longer needed runtime.h libary
(75) Fix powerup test to match leap update to explicit time_point_sec conversion
(78) Fix misspelling in wasmcfg

Libtester has been undated to no longer use Runtime.h

Continuous Integration Updates

PRs

(57) Github workflow update to automate triage lable.
(59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.

Documentation Updates

PRs

(63) Documentation cleanup to remove old reasource staking references

Further details on changes since last release

Special thanks to the contributors that submitted patches for this release:

Full list of changes since last release

PRs

(56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
(57) Github workflow update to automate triage lable.
(59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.
(62)) Minor cleanup of eosio.token tests
(63) Documentation cleanup to remove old reasource staking references
(67) Updated libtester removing no longer needed runtime.h libary
(68) Missed a referrence, updated libtester removing no longer needed runtime.h libary
(75) Fix powerup test to match leap update to explicit time_point_sec conversion
(78) Fix misspelling in wasmcfg
(88) Remove Deferred Transactions from System Contract

Full Changelog: v3.1.1...v3.2.0

Contributors

lparisc, ericpassmore, and 5 other contributors

Assets 2

20 Oct 01:58

ericpassmore

v3.2.0-rc1

f58eb79

EOS System Contracts v3.2.0 Pre-Release Notes Pre-release

Pre-release

This minor release contains removal of deferred transactions, test updates, and minor bug fixes.

Remove of Deferred Transactions

Removal of Deferred Transactions from System Contract

PRs

(56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
(88) Remove Deferred Transactions from System Contract

Test Updates

PRs

(62) Minor cleanup of eosio.token tests
(67) Updated libtester removing no longer needed runtime.h libary
(68) Missed a referrence, updated libtester removing no longer needed runtime.h libary
(75) Fix powerup test to match leap update to explicit time_point_sec conversion
(78) Fix misspelling in wasmcfg

Libtester has been undated to no longer use Runtime.h

Continuous Integration Updates

PRs

(57) Github workflow update to automate triage lable.
(59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.

Documentation Updates

PRs

(63) Documentation cleanup to remove old reasource staking references

Further details on changes since last release

Special thanks to the contributors that submitted patches for this release:

Full list of changes since last release

PRs

(56) Refactor msig to no longer utilize deferred transaction, and improved test coverage of msig actions.
(57) Github workflow update to automate triage lable.
(59) Github action updates to ignore leap version, needed to support Continuous Integration pipeline.
(62)) Minor cleanup of eosio.token tests
(63) Documentation cleanup to remove old reasource staking references
(67) Updated libtester removing no longer needed runtime.h libary
(68) Missed a referrence, updated libtester removing no longer needed runtime.h libary
(75) Fix powerup test to match leap update to explicit time_point_sec conversion
(78) Fix misspelling in wasmcfg
(88) Remove Deferred Transactions from System Contract

Full Changelog: v3.1.1...v3.2.0-rc1

Contributors

lparisc, ericpassmore, and 5 other contributors

Assets 2

27 Sep 19:00

stephenpdeos

v3.1.1

bd48a7a

EOS System Contracts v3.1.1 Release Notes

This patch release contains bug fixes.

Read on for details.

Bug fixes

Replace `std::deque` and `std::map` with `std::vector` in contract actions and tables

PRs

(46) [3.1] Replace usage of deque and map with vector in system contracts

Within the core contract, the fields rex_maturities and return_buckets within REX tables were unnecessarily utilizing std::deque and/or std::map to sequence objects. These have been replaced with std::vector with no change to the behavior of the core contract.

Update `ICON_BASE_URL` to a working address

PRs

(43) [3.1] Change ICON_BASE_URL to a working address

ICON_BASE_URL is a prefix used for the icon URLs captured in the generated Ricardians for the system contracts. ICON_BASE_URL was previously being to set http://127.0.0.1/ricardian_assets/eosio.contracts/icons, which was not functional. The address has been updated to https://raw.githubusercontent.com/eosnetworkfoundation/eos-system-contracts/main/contracts/icons.

Further details on changes since last release

Special thanks to the contributors that submitted patches for this release:

@linh2931

Full list of changes since last release

PRs

(43) [3.1] Change ICON_BASE_URL to a working address
(46) [3.1] Replace usage of deque and map with vector in system contracts

Full Changelog: v3.1.0...v3.1.1

Contributors

linh2931

Assets 2

08 Sep 19:58

arhag

v3.1.0

a408ba6

EOS System Contracts v3.1.0 Release Notes

Release 3.1.0 includes several changes to the core contract. It also introduces the boot contract. Other contracts remain unchanged in behavior since the last stable release.

Read on for details.

New features

Boot contract

PRs

(20) Add Boot Contract

The boot contract is a new contract introduced in this release that serves the purpose of bootstrapping a new blockchain, especially for testing purposes.

The core contract in its current state now depends on several host functions that are only made available on the blockchain after activation of certain protocol features. Without activation of the protocol features that make available the necessary host functions, it is not possible to deploy a contract that requires those host functions. However, activation of nearly all protocol features (with the exception of PREACTIVATE_FEATURE) require a privileged call to the preactivate_feature host function which is made accessible to users through the activate action within the core contract.

To break this Catch-22, the boot contract includes a similar activate action (which creates a dependency on the PREACTIVATE_FEATURE protocol feature), but it does not include any other features that would introduce dependencies on further protocol features. Therefore, it should always be possible to activate the PREACTIVATE_FEATURE protocol feature on a fresh EOSIO blockchain, deploy the boot contract to the privileged eosio account, and then use its activate action to activate additional protocol features that are needed for the deployment of the core contract.

Core contract

The core contract refers to the contract meant to be deployed to the privileged eosio account which provides many of the functions that users have come to expect from popular EOSIO blockchains, such as delegate proof of stake (DPoS), PowerUp, and more.

This release adds new functionality to the core contract.

Optionally restrict permission changes

PRs

(1) Limit auth changes

The new action limitauthchg allows an account to opt into or out of restrictions on permission changes to their account through authorization additional constraints on the actions updateauth, deleteauth, linkauth, and unlinkauth. Each of those four auth-related actions now have a new binary extension argument: authorized_by (which is the name of a permission on the account). This may be either absent or empty for accounts which have not opted into limitauthchg.

An account may opt into the new restrictions by calling limitauthchg with a non-empty allow_perms or a non-empty disallow_perms (both cannot be non-empty). They may opt out again by calling limitauthchg with both an empty allow_perms and an empty disallow_perms.

If allow_perms is non-empty for an account, then the authorized_by permission name of an auth-related action involving that account must be contained in the allow_perms list; otherwise the transaction will abort. If disallow_perms is non-empty for an account, then the authorized_by permission name of an auth-related action involving that account must not be contained in the disallow_perms list; otherwise the transaction will abort. In either case, the core contract verifies that the specific permission of the account named by authorized_by is the one that authorizes the auth-related action.

Among its several uses, the limitauthchg action enables protection against one of the denial of service attack vectors of a particular contract pays solution in which a private key with restricted access to the CPU/NET resources paid for by an application is publicly distributed with the application code.

Configure WASM limits

PRs

(9) Add configuration actions for new protocol features

Assuming CONFIGURABLE_WASM_LIMITS2=ON (which it is by default), the core contract will now include a new wasmcfg action which supports (and depends on) the CONFIGURABLE_WASM_LIMITS2 protocol feature.

This action allows increasing some of the limits enforced on WASM contracts by calling the action with wasmcfg("high"). The WASM limits can be restored back to the original values by calling the action with wasmcfg("low") or wasmcfg("default").

⚠️ Warning: Some of the limits are enforced at the time of deployment, so beware that users may have deployed contracts surpassing the low limits during the window of time that the high limits were enforced. In addition, some of the limits are enforced at run-time, so bringing the configuration back down from high to low may break the contracts that were deployed and tested while the configuration was at high.

Tracked recent block information

PRs

(19) Add blockinfo feature to system contract

The core contract has been updated to keep track within a blockinfo table the block height and timestamp of recent blocks in the blockchain's history. There is a rolling window tracking a maximum number of recent blocks (that max is currently hard-coded to 10), and the core contract will automatically garbage collect table entries for blocks that fall outside of that window.

The blockinfo table schema is a publicly specified interface and is versioned, so contracts are able to look into it to get information about recent blocks. The block_info.hpp header file is provided which can be included into other contracts to allow them to access information in the blockinfo table including via the convenient get_latest_block_batch_info function. The get_latest_block_batch_info can be used as an alternative means to get the current block height (under the assumption that the onblock has not failed) which can be useful in blockchains that have not activated the GET_BLOCK_NUM protocol feature.

Other changes

Core contract

The core contract also includes additional changes and bug fixes.

Memo field added to `setcode` and `setabi`

PRs

(2) setcode and setabi memo

This additional field can help contract authors track deployed contract versions.

Enhanced `setparams`

PRs

(9) Add configuration actions for new protocol features

Assuming SYSTEM_BLOCKCHAIN_PARAMETERS=ON (which it is by default), the setparams action is modified to take an augmented structure of parameters which now includes max_action_return_value_size (related to the ACTION_RETURN_VALUE protocol feature). The implementation of the action is also modified to use the new and more flexible set_parameters_packed host function, which is only available if the BLOCKCHAIN_PARAMETERS protocol feature has been activated.

REX rounding bug

PRs

(4) Backport rex workaround

This release includes a backport of EOSIO/eosio.system#54 (originally authored by @deckb) which works around the REX rounding bug that stopped accounts from selling REX.

Accounts may now use the voteupdate action to restore their account.

In addition, the bug has been fixed so it does not impact more accounts in the future.

Voting and vesting patches for b1 account

PRs

(6) Reapply b1 patches

The core contract change which was used by BPs on the EOS network to freeze vesting of core tokens to the b1 account has been reproduced in the core contract made available in this release.

Updated Ricardians

PRs

(31) [3.1] Updated ricardians

The Ricardians of the core contract now include the EOS User Agreement (EUA) as well as the Block Producer Agreement which is relevant to the regproducer and regproducer2 actions.

Building, compatibility, and upgrading

Building

Instructions for building the system contracts are provided in the README.

This release depends on on CDT 3.0 at a minimum. CDT 3.0.0 is available.

Building the tests also requires Leap 3.1 at a minimum. Leap 3.1.0 is available. Building the tests is optional; see README for how to build with or without tests.

For now, the Leap dependency must be satisfied with a build of Leap 3.1 from source. Alternatively, look into DUNE for another way to build the contracts without needing to build CDT or Leap from source.

Contributors

swatanabe, tbfleming, and 10 other contributors

Assets 2

19 Aug 00:04

arhag

v3.1.0-rc2

69b30f7

EOS System Contracts v3.1.0-rc2 Release Notes Pre-release

Pre-release

This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v1.9.2.

Release 3.1.0-rc2 includes Ricardians specific to EOS in the generated ABI file for the core contract. Other contracts remain unchanged in behavior since the last stable release.

Read on for details.

Changes

The name of the repository was changed to reflect the fact that these system contracts are made specific to the needs of the EOS blockchain.

Core contract

Updated Ricardians

PRs

(31) [3.1] Updated ricardians

The Ricardians of the core contract now include the EOS User Agreement (EUA) as well as the Block Producer Agreement which is relevant to the regproducer and regproducer2 actions.

The text of the Ricardians is included in the generated ABI file for the core contract. Note that CDT v3.0.0-rc1 had a regression which prevented the Ricardians from being included within the generated ABI file. To ensure the ABI files include the Ricardians, use CDT v3.0.0-rc2 at a minimum to compile the contracts.

Building, compatibility, and upgrading

Building

Instructions for building the system contracts are provided in the README.

This release depends on on CDT 3.0 at a minimum. A release candidate for CDT 3.0.0 is available.

Building the tests also requires Leap 3.1 at a minimum. A release candidate for Leap 3.1.0 is available. Building the tests is optional; see README for how to build with or without tests.

Note that this release has also simplified the build.sh script and dropped some options. You can still run it with no options provided if you have CDT installed on your system and do not wish to build the tests. The script allows you to specify a custom location for CDT if you wish to use a build of CDT that you have not installed on your system. It also allows you to specify the build directory of Leap to also build the tests.

Compatibility

By default, the core contract adds additional requirements (beyond what existed in v1.9.2) that the blockchain has activated the following two protocol features: BLOCKCHAIN_PARAMETERS and CONFIGURABLE_WASM_LIMITS2.

The BLOCKCHAIN_PARAMETERS protocol feature dependency is required for the enhanced setparams action. You can choose to keep the old behavior of the setparams action (and avoid this dependency on the BLOCKCHAIN_PARAMETERS protocol feature) by passing -DSYSTEM_BLOCKCHAIN_PARAMETERS=OFF to cmake.

The CONFIGURABLE_WASM_LIMITS2 protocol feature dependency is required for the new wasmcfg action. You can avoid introducing the wasmcfg action (and avoid this dependency on the CONFIGURABLE_WASM_LIMITS2 protocol feature) by passing -DSYSTEM_CONFIGURABLE_WASM_LIMITS=OFF to cmake.

Upgrading

The core contract can be upgraded on an account with an already deployed v1.9.2 core contract, or v3.1.0-rc1 core contract, by simply deploying the .wasm and .abi files to the account. No additional actions need to be taken to complete the upgrade.

However, the blockchain must have first activated the necessary protocol features which includes BLOCKCHAIN_PARAMETERS and CONFIGURABLE_WASM_LIMITS2.

Further details on changes since last release

Contributors

Special thanks to the contributors that submitted patches for this release:

@766C6164
@arhag

Full list of changes since last release

PRs

(31) [3.1] Updated ricardians
(35) [3.1] Remove references to mandel; update dependencies to use new CDT and Leap; and overall cleanup
(36) Bump version to 3.1.0-rc2

Full Changelog: v3.1.0-rc1...v3.1.0-rc2

Contributors

arhag and vladtr

Assets 2

08 Jul 00:14

arhag

v3.1.0-rc1

02fe258

Contracts v3.1.0-rc1 Release Notes Pre-release

Pre-release

This is a RELEASE CANDIDATE for version 3.1.0. The latest STABLE release is v1.9.2.

Release 3.1.0-rc1 includes several changes to the core contract. It also introduces the boot contract. Other contracts remain unchanged in behavior since the last stable release.

Read on for details.

New features

Boot contract

The boot contract [20] is a new contract introduced in this release that serves the purpose of bootstrapping a new blockchain, especially for testing purposes.

Core contract

This release adds new functionality to the core contract.

Optionally restrict permission changes [1]

Configure WASM limits [9]

Tracked recent block information [19]

Other changes

Core contract

The core contract also includes additional changes and bug fixes.

Memo field added to `setcode` and `setabi` [2]

This additional field can help contract authors track deployed contract versions.

Enhanced `setparams` [9]

REX rounding bug [4]

This release includes a backport of EOSIO/eosio.system#54 (originally authored by @deckb) which works around the REX rounding bug that stopped accounts from selling REX.

Accounts may now use the voteupdate action to restore their account.

In addition, the bug has been fixed so it does not impact more accounts in the future.

Voting and vesting patches for b1 account [6]

The core contract change which was used by BPs on the EOS network to freeze vesting of core tokens to the b1 account has been reproduced in the core contract made available in this release.

Building, compatibility, and upgrading

Building

Instructions for building the system contracts are provided in the README.

This release depends on on CDT 3.0 at a minimum. A release candidate for CDT 3.0.0 is available.

Building the tests also requires EOSIO 3.1 at a minimum. A release candidate for EOSIO 3.1.0 is available. Building the tests is optional; see README for how to build with or without tests.

For now, the EOSIO dependency must be satisfied with a build of EOSIO 3.1 from source. Alternatively, look into DUNE for another way to build the contracts without needing to build CDT or EOSIO from source.

Compatibility

Upgrading

The core contract can be upgraded on an account with an already deployed v1.9.2 core contract by simply deploying the .wasm and .abi files to the account. No additional actions need to be taken to complete to upgrade.

However, the blockchain mu...

Contributors

swatanabe, tbfleming, and 9 other contributors

Assets 2

31 Jan 15:36

tbfleming

v3.0.0-rc1

0d452a3

v3.0.0-rc1 Pre-release

Pre-release

Mandel Contracts v3.0.0-rc1 Release Notes

This is the first RELEASE CANDIDATE for the first Mandel Contracts release.

mandel-contracts is a fork of eosio.contracts, developed by ƒractally with funding from the EOS Network Foundation. mandel-contracts v3.0 is based on eosio.contracts v1.9.2, which is currently used (with modifications) on the EOS blockchain.

All contract changes in this release are in the eosio.system contract. The other contracts match v1.9.2.

PRs

#1: New action limitauthchg opts into or out of restrictions on updateauth, deleteauth, linkauth, and unlinkauth. This removes one of the attack vectors against contract-pays.
#2: Add memo field to setcode and setabi. This should help contract authors track deployed contract versions.
#4: Backport of EOSIO/eosio.system#54, which works around the REX rounding bug which stopped accounts from selling REX. Accounts may now use the voteupdate action to restore their account. In addition, 4 fixes the bug so it won't happen to more accounts in the future.
#5: Lighter-weight cicd system based on GitHub Actions. This runs the in-repo test suite using Ubuntu 20.04 (unpinned build).
#6: Reproduce the system contract change which BPs used to freeze b1 vesting.
#7: Remove duplicate readme file. This file had a different case which created problems with MacOS and Windows filesystems.
#9: setparams now includes a max_action_return_value_size field to support the ACTION_RETURN_VALUE hard fork; this uses the BLOCKCHAIN_PARAMETERS hard fork. A new action wasmcfg supports the CONFIGURABLE_WASM_LIMITS2 hard fork. These are gated behind build options (see below).
#10: Clarification to build instructions in readme.
#12: Bump version to v3.0.0-rc1.
#13: Fix tests to be compatable with Mandel.

Deployment notes

To install this release of the system contract on chains which have not activated the hard forks, use these options:

-DEOSIO_SYSTEM_CONFIGURABLE_WASM_LIMITS=no  Disable support for the `CONFIGURABLE_WASM_LIMITS2` hard fork.
-DEOSIO_SYSTEM_BLOCKCHAIN_PARAMETERS=no     Disable support for the `BLOCKCHAIN_PARAMETERS` hard fork.

Assets 2

Releases: eosnetworkfoundation/eos-system-contracts

EOS System Contracts v3.3.0 Release Notes

Usecases

Ram Transfer Usecases

New Ram Actions

Ram Transfer

Ram Burn

Ram Logging

Buy Ram

Buy Ram Bytes

Buy Ram Self

Sell Ram

API Changes

ACTION: ramtransfer

ACTION: ramburn

ACTION: logbuyram

ACTION: buyram buyrambytes buyramself

ACTION: ramtransfer ramburn

ACTION: sellram

Preconditions

Ram Transfer Preconditions

Ram Burn Preconditions

Further details on changes since last release

Full list of changes since last release

Contributors

EOS System Contracts v3.2.0 Release Notes

Remove of Deferred Transactions

Removal of Deferred Transactions from System Contract

Test Updates

Continuous Integration Updates

Documentation Updates

Further details on changes since last release

Full list of changes since last release

Contributors

EOS System Contracts v3.2.0 Pre-Release Notes

Remove of Deferred Transactions

Removal of Deferred Transactions from System Contract

Test Updates

Continuous Integration Updates

Documentation Updates

Further details on changes since last release

Full list of changes since last release

Contributors

EOS System Contracts v3.1.1 Release Notes

Bug fixes

Replace std::deque and std::map with std::vector in contract actions and tables

Update ICON_BASE_URL to a working address

Further details on changes since last release

Full list of changes since last release

Contributors

EOS System Contracts v3.1.0 Release Notes

New features

Boot contract

Core contract

Optionally restrict permission changes

Configure WASM limits

Tracked recent block information

Other changes

Core contract

Memo field added to setcode and setabi

Enhanced setparams

REX rounding bug

Voting and vesting patches for b1 account

Updated Ricardians

Building, compatibility, and upgrading

Building

Contributors

EOS System Contracts v3.1.0-rc2 Release Notes

Changes

Core contract

Updated Ricardians

Building, compatibility, and upgrading

Building

Compatibility

Upgrading

Further details on changes since last release

Contributors

Full list of changes since last release

Contributors

Contracts v3.1.0-rc1 Release Notes

ACTION: `ramtransfer`

ACTION: `ramburn`

ACTION: `logbuyram`

ACTION: `buyram` `buyrambytes` `buyramself`

ACTION: `ramtransfer` `ramburn`

ACTION: `sellram`

Replace `std::deque` and `std::map` with `std::vector` in contract actions and tables

Update `ICON_BASE_URL` to a working address

Memo field added to `setcode` and `setabi`

Enhanced `setparams`

Memo field added to `setcode` and `setabi` [2]

Enhanced `setparams` [9]