EOSIO.Contracts v1.7.0-rc1 Release Notes

This is a RELEASE CANDIDATE for version 1.7.0 of EOSIO.Contracts. The latest STABLE release is v1.6.0.

The EOSIO.Contracts v1.7.0-rc1 is required to support EOSIO v1.8.0-rc1 and should be deployed only after the PREACTIVATE_FEATURE consensus protocol upgrade has been activated on the EOSIO chain.

System contract

This release adds a new action activate to the system contract (#220). The activate action pre-activates (which then subsequently activates at the start of the next block) the protocol feature represented by the digest (hash) provided in the action data.

The implementation of the activate action requires linking against a new intrinsic function which is only made available after the PREACTIVATE_FEATURE protocol feature is activated on the EOSIO blockchain. This means that until that protocol feature is activated, it will not be possible to deploy this system contract to the chain.

In addition, the implementation of the Bancor algorithm behind buying and sell RAM has been simplified while maintaining the same behavior (#222). Both mathematical and empirical analyses have shown that the change in the implementation does not materially change the behavior of the actions to buy and sell RAM.

Token contract

After activation of the RESTRICT_ACTION_TO_SELF protocol feature, the eosio.token::issue action will no longer be able send an inline transfer when issuing tokens to an account other than the issuer. In preparation for this change in capabilities, the eosio.token::issue action's behavior has been modified to explicitly disallow issuing tokens to any account other than the issuer (#232). Token managers who use the eosio.token reference contract and wish to continue issuing tokens to other accounts will need to replace the single eosio.token::issue action with a transaction with two actions: one that first issues tokens to the issuer and then the second one that transfer that same quantity of tokens from the issuer to the intended recipient.

Bios contract

The same activate action added to the system contract has also been added to the bios contract (#220). The bios contract also has a new action reqactivated which asserts that the protocol feature represented by the provided digest has been activated.

Other changes

• (#188) Created Buildkite Pipeline with Docker Build
• (#202) Producer pay vars update
• (#201) Fix/update votes
• (#197) Contracts Pipeline: Add Test Steps and Use Pre-Built EOSIO Docker Images
• (#223) Annotate all public EOSIO system contracts' classes, structs, methods, actions
• (#230) Change add_eosio_test to add_eosio_test_executable
• (#228) Fix broken links in README.md
• (#226) fix description comment typo
• (#231) Added ctest Error Handling
• (#218) Deleted docker files and scripts used by old contracts pipeline

Dependencies

This release depends on eosio.cdt v1.6.x and eosio v1.8.x. To compile the contracts in this release, first build and install eosio.cdt v1.6.1 and eosio v1.8.0-rc1.

Thanks!

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

• @basarrcan
• @wuyahuang
• @hqueue
• @ysoftware

Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability.

EOSIO Contracts v1.6.0 Release Notes

The Resource Exchange, REX (#94, #182, #196, #208)

This release provides an example of a system contract that provides the resource exchange (REX) functionality for the community to review, adapt, and build on. The contract functionality is provided within the eosio.system contract while the corresponding user interfaces, deployment choices, etc. are not provided. As designed, REX is a CPU and Network resource rental market in which holders of the core token of the blockchain can lend portions of their existing resource allocations by buying and selling REX tokens into the REX pool. Core token holders are allowed to participate in the REX pool only after having voted for at least 21 Block Producers or have delegated their votes to one proxy. Blockchain users can then rent CPU and Network resources from the REX pool to meet their resource needs. The duration of each loan, as designed, is 30 days and the loan price is determined by an automated market maker. Note that a REX token is not tradable, it is merely a convenient accounting unit and helps determine the return rate available to REX holders as determined by the level of rental activity. Optionally, proceeds from RAM trading fees and account name auctions can also be channeled to the REX pool, thus providing an additional source of return to REX holders.

For more information about REX see the description in issue #117.

Channeling system fees to REX

The source code of the eosio.system contract is by default set up to channel the account name auction fees and the fees collected from buying and selling RAM to the REX pool. The channeling of these fees only occurs for new fees collected; it does not impact any of the funds already collected in the eosio.ramfee and eosio.names accounts.

The channeling of these fees can be disabled in the source code by setting the CHANNEL_RAM_AND_NAMEBID_FEES_TO_REX macro (defined in eosio.system.hpp) to 0.

Deployment

The REX introduces new setup requirements for initializing the system contract.

The account eosio.rex must now be created in addition to all the other existing system accounts prior to deploying the new system contract. eosio.rex must not be a privileged account.

The eosio::init action, which is only needed when deploying the system contract to a blockchain for the first time, was introduced in v1.4.0 of eosio.contracts. In this release, it has further been modified to send an inline eosio.token::open action to open a zero-balance entry corresponding to the core token symbol for the eosio.rex account. The eosio.token::open action was first introduced to the eosio.token contract in v1.3.0 of eosio.contracts. It is recommended to deploy a recent version of the token contract (at a minimum version 1.3.1) to the eosio.token account prior to deploying the new system contract. If an older version of the token contract is deployed, the eosio::init action will still succeed, however when the inline eosio.token::open action executes it may do nothing.

If this version of the system contract is replacing an existing deployment of an older version of the eosio.system contract, then no eosio::init action is necessary or even allowed. Block Producers can optionally execute the eosio.token::open action to create the zero-balance entry to the core token symbol for the eosio.rex account.

ABI file rex.results.abi (generated automatically) needs to be deployed on account eosio.rex. The corresponding contract rex.results.wasm must NOT be deployed. The actions buyresult, sellresult, rentresult, and orderresult of rex.results are all no-ops. They are added as inline convenience actions to rentnet, rentcpu, buyrex, unstaketorex, and sellrex. An inline convenience action does not have any effect, however, its data includes the result of the parent action and appears in its trace.

Adjusting REX pool virtual balance

Action setrex allows Block Producers to reset the total_rent balance of the REX pool to a given value, if the need arises. It is important to note that this action is NOT required to initialize the REX system and is not recommended to be used more than once. It is a backup mechanism that allows Block Producers to balance the renting market prices in case the initial settings were impractical and not in line with the amount of tokens lent to REX. total_rent is a virtual balance and no real tokens will be added or removed in this action.

Dependencies

This release depends on eosio.cdt v1.5.x and eosio v1.6.x or v1.7.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0 and eosio v1.7.0.

Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate.

[CANDIDATE] EOSIO Contracts v1.6.0-rc3 Release Notes

This is a RELEASE CANDIDATE for 1.6.0. The latest STABLE release is v1.5.2.

These changes build on the changes outlined in the Release Candidate 2 (v1.6.0-rc2).

System Contract

REX

This release candidate includes fixes to bugs found in the v1.6.0-rc2 release of REX, in addition to minor new features:

1. Added a check to ensure that REX loan price is in favor of renting as opposed to staking tokens directly to CPU or Network resources. If the condition is not satisfied, renting actions fail and loans are not renewed.
2. Fixed error in rex_loans_available() function. If the queue is non-empty but all the orders have been filled, users can rent CPU and Network resources again.
3. Added ABI support to inline convenience actions. In order for the data of these actions to be deserialized, the ABI of contract rex.results which is in the file rex.results.abi must be deployed on the account eosio.rex. The actions buyresult, sellresult, and orderresult of rex.results are all no-ops. The corresponding contract rex.results.wasm must NOT be deployed.
4. Created action setrex which allows producers to reset total_rent balance of the REX pool to a given value, if the need arises. It is important to note that this action is NOT required to initialize the REX system and is not recommended to be used more than once. It is a backup mechanism that allows producers to balance the renting market prices in case the initial settings were impractical and not in line with the amount of tokens lent to REX. total_rent is a virtual balance and no real tokens will be added or removed in this action.
5. Decreased the lower bound of total_unlent balance of REX pool back to the value set in RC1 following the results of testing RC2.
6. Minor code refactoring.

For details, see PR #196.

Deployment Changes

ABI file rex.results.abi (generated automatically) needs to be deployed on the account eosio.rex. The corresponding contract rex.results.wasm must NOT be deployed.

API Changes

Added action setrex described above.

Dependencies

This release depends on eosio.cdt v1.5.x and eosio v1.4.x or v1.5.x or v1.6.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0 and eosio v1.6.3.

Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein, the related GitHub release, the EOSIO software or any documentation related to any of the foregoing, whether expressed or implied, and disclaim all liability that may arise from any use of the software or documentation for any purpose. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one.

[CANDIDATE] EOSIO Contracts v1.6.0-rc2 Release Notes

This is a RELEASE CANDIDATE for 1.6.0. The latest STABLE release is v1.5.2.

System contract

The proxy account is no longer notified as a recipient when the stake or votes of those proxying to them change. This change may effect the existing behavior of a contract deployed on an account registered as a proxy if the contract relies on receiving such a notification. Despite the potentially breaking change, the notification to recipients was removed from the system contract because malicious proxies could potentially utilize the notification mechanism to cause a limited denial of certain services to the accounts that have selected them as a proxy.

Three new actions have been added to the system contract to enable explicit management of system resources: setacctram, setacctnet, setacctcpu. These new actions can enable authorized entities, e.g. active block producers, to override the automatic management of particular types of resources limits for specific accounts by pinning the resource quota amount to a provided value. The actions also enable undoing the override by unpinning the resource quotas and allowing them to again be automatically managed by the appropriate system contract mechanism such as the RAM market or staking/delegating CPU and/or network bandwidth resources.

When a particular resource quota of an account is pinned to some value, the typical system contract mechanisms that would change that quota are still allowed to work as usual with the one exception that they would no longer adjust the quotas recognized by the native EOSIO blockchain system. For example, setacctram makes it possible for a two-thirds supermajority of active block producers to pin the RAM quota of an account to some appropriate limit and then sell the existing RAM balance held by account in the RAM market. Or it can allow pinning the CPU and network bandwidth limits of a critical system account such as eosio to unlimited to ensure that critical functions like the eosio::onblock action (which are billed to the eosio account) are not disrupted. For more information about this feature see #172.

REX

This release candidate includes fixes to bugs found in the v1.6.0-rc1 release of REX. For details about the bug fixes, see PR #182.

Changed initial Bancor connector balance to a lower value. This lowers initial renting costs.

Added inline convenience actions to buyrex, unstaketorex, and sellrex. An inline convenience action does not have any effect, however, its data includes the result of the parent action and appears in its action trace. Thus it makes it easier to read the amount of purchased REX or proceeds gained from selling REX.

This release candidate also introduces the concept of a REX savings bucket. In addition to maturity buckets introduced before, a REX owner can now utilize a special bucket which we call the "savings bucket". REX held in this bucket does not mature and cannot be sold directly. Users can move already purchased REX from other buckets to their savings bucket at will using the new action mvtosavings. This action moves REX out from the user's buckets as necessary starting with the bucket with the furthest maturity date. In order to sell REX in the savings bucket, the user must first explicitly move tokens out of it using the new action mvfrsavings which can be executed at any time. The mvfrsavings action moves REX from the savings bucket to a bucket with a maturity date that is 4 days after the end of the day.

Dependencies

This release depends on eosio.cdt v1.5.x and eosio v1.4.x or v1.5.x or v1.6.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0 and eosio v1.6.1.

EOSIO Contracts v1.5.2 Release Notes

System contract

The proxy account is no longer notified as a recipient when the stake or votes of those proxying to them change (#173). This change may effect the existing behavior of a contract deployed on an account registered as a proxy if the contract relies on receiving such a notification. Despite the potentially breaking change, the notification to recipients was removed from the system contract because malicious proxies could potentially utilize the notification mechanism to cause a limited denial of certain services to the accounts that have selected them as a proxy.

Three new actions have been added to the system contract to enable explicit management of system resources: setacctram, setacctnet, setacctcpu. These new actions can enable authorized entities, e.g. active block producers, to override the automatic management of particular types of resources limits for specific accounts by pinning the resource quota amount to a provided value. The actions also enable undoing the override by unpinning the resource quotas and allowing them to again be automatically managed by the appropriate system contract mechanism such as the RAM market or staking/delegating CPU and/or network bandwidth resources.

When a particular resource quota of an account is pinned to some value, the typical system contract mechanisms that would change that quota are still allowed to work as usual with the one exception that they would no longer adjust the quotas recognized by the native EOSIO blockchain system. For example, setacctram makes it possible for a two-thirds supermajority of active block producers to pin the RAM quota of an account to some appropriate limit and then sell the existing RAM balance held by account in the RAM market. Or it can allow pinning the CPU and network bandwidth limits of a critical system account such as eosio to unlimited to ensure that critical functions like the eosio::onblock action (which are billed to the eosio account) are not disrupted. For more information about this feature see #171.

Dependencies

This release depends on eosio.cdt v1.4.x or v1.5.x and eosio v1.4.x or v1.5.x or v1.6.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0 and eosio v1.6.1.

[CANDIDATE] EOSIO Contracts v1.6.0-rc1 Release Notes

This is a RELEASE CANDIDATE for 1.6.0. The latest STABLE release is v1.5.1.

All contracts

The minimum dependency on eosio.cdt is now v1.5.x. The 1.5 version of eosio.cdt (currently only available as a release candidate v1.5.0-rc1) introduces a new pattern for building smart contracts (uses a new CMake toolchain file and builds the contract code within an external CMake project) which all contracts in eosio.contracts have been updated to take advantage of. All the contracts have also been updated to use the more efficient eosio::check function which is a drop-in replacement for eosio_assert.

System contract

REX (Resource Exchange)

We are excited to introduce REX into the eosio.system contract. It is a CPU and Network resource rental market in which holders of the core token of the blockchain can buy and sell slices of the REX pool in the form of REX tokens. Note that a REX token is not tradable, it is merely a convenient accounting unit. Its value in terms of the core token always increases, but the return rate is determined by the level of rental activity. Proceeds from RAM trading fees and account name auctions can be channeled to the pool, thus providing an additional return to REX holders. Blockchain users can rent CPU and Network resources from the REX pool. The duration of each loan is 30 days and its price is determined by an automated market maker.

We look forward to the community thoroughly testing REX in test networks. The insights gained from the testing can help us improve REX prior to the official release of v1.6.0 of eosio.contracts.

For more information about REX see the description in issue #117.

Channeling system fees to REX

The source code of the eosio.system contract is by default set up to channel the account name auction fees and the fees collected from buying and selling RAM to the REX pool. The channeling of these fees only occurs for new fees collected; it does not touch any of the funds already collected in the eosio.ramfee and eosio.names accounts.

The channeling of these fees can be easily disabled in the source code by setting the CHANNEL_RAM_AND_NAMEBID_FEES_TO_REX macro (defined in eosio.system.hpp) to 0.

Deployment

The REX introduces new setup requirements for initializing the system contract.

The account eosio.rex must now be created in addition to all the other existing system accounts prior to deploying the new system contract.

The eosio::init action, which is only needed when deploying the system contract to a blockchain for the first time, was introduced in v1.4.0 of eosio.contracts. In this release, it has further been modified to send an inline eosio.token::open action to open a zero-balance entry corresponding to the core token symbol for the eosio.rex account. The eosio.token::open action was first introduced to the eosio.token contract in v1.3.0 of eosio.contracts. It is recommended to deploy a recent version of the token contract (at a minimum version 1.3.1) to the eosio.token account prior to deploying the new system contract. If an older version of the token contract is deployed, the eosio::init action will still succeed, however when the inline eosio.token::open action executes it may do nothing.

If this version of the system contract is replacing an existing deployment of an older version of the eosio.system contract, then no eosio::init action is necessary or even allowed. Block producers can optionally execute the eosio.token::open action to create the zero-balance entry to the core token symbol for the eosio.rex account. However, even if this is not done, REX will still be able to fully operate.

Dependencies

This release depends on eosio.cdt v1.5.0-rc1 and eosio v1.4.x or eosio v1.5.x. To compile the contracts in this release, first build and install eosio.cdt v1.5.0-rc1 and eosio v1.5.0.

EOSIO Contracts v1.5.1 Release Notes

System contract

This release fixes a bug in the generated ABI of the system contract #129. In the v1.4.0 release of eosio.contracts, the ABI definition of the new account action slightly changed causing the name field (represent the name of the new account to create) to be renamed to newact. This could possibly have adverse effects to clients using the eosio::newaccount action that were developed based on eosio.system ABIs of earlier versions. This release renames the field back to name as it originally was.

BIOS contract

This release also modifies the generated ABI of the eosio.bios contract to include the native EOSIO actions as well.

Dependencies

This release depends on eosio.cdt v1.4.x and eosio v1.4.x. To compile the contracts in this release, first build and install eosio.cdt v1.4.1 and eosio v1.4.4.

EOSIO Contracts v1.4.1 Release Notes

System contract

This patch release in the v1.4.x release series fixes a bug in the generated ABI of the system contract #130. In the v1.4.0 release of eosio.contracts, the ABI definition of the new account action slightly changed causing the name field (represent the name of the new account to create) to be renamed to newact. This could possibly have adverse effects to clients using the eosio::newaccount action that were developed based on eosio.system ABIs of earlier versions. This release renames the field back to name as it originally was.

BIOS contract

This release also modifies the generated ABI of the eosio.bios contract to include the native EOSIO actions as well.

Dependencies

This release depends on eosio.cdt v1.3.x and eosio v1.3.x. To compile the contracts in this release, first build and install eosio.cdt v1.3.2 and eosio v1.3.2.

EOSIO Contracts v1.5.0 Release Notes

This release includes an unintentional backwards incompatible change to the eosio.system ABI which was introduced in the v1.4.0 release. Please use v1.5.1 instead to avoid this specific backwards incompatibility.

All contracts

Changes related to the new eosio.cdt dependency

The minimum dependency on eosio.cdt is now v1.4.x. The 1.4 version of eosio.cdt will now generate eosio::abi/1.1 version-compatible ABIs, and therefore all contracts in this release (whether their source has been updated or not) will generate different ABI files compared to the previous release.

Version 1.1 of EOSIO ABIs support binary extensions (EOSIO/eos#5600) and variants (EOSIO/eos#5599). The ABI serialization/deserialization libraries contained within nodeos and cleos have supported version 1.1 of EOSIO ABI since the v1.3.0 release of eosio. Tools/libraries such as abieos and eosjs2 have also been updated to support version 1.1 of EOSIO ABI.

Keep in mind that other tools may still only have support for version 1.0 of EOSIO ABI, and these tools might have problems interacting with the contracts in this release deployed with version 1.1 of the generated ABI file. If the tools are permissive enough to accept an ABI version string of eosio::abi/1.x (where x can be any digit), then the tools will likely not have any problems pushing actions to or getting tables from any of the contracts in this release other than eosio.msig. However, the eosio.msig contract source has been modified to use binary extensions for the eosio.msig::approve action, and so tools that only understand version 1.0 of EOSIO ABI will likely have problems pushing the eosio.msig::approve action.

Changes related to the new eosio dependency

The minimum dependency on eosio is now v1.4.x. The 1.4 release of eosio is set up to allow CMake find_package to be used by other projects (such as eosio.contract) that need to use it as a dependency. With this release, eosio.contracts has been updated (#119) to just use find_package in its build system for both the eosio.cdt and eosio dependencies. Therefore, this release of eosio.contract will no longer build with eosio v1.3.x.

System contract

Improvements to the assertion checks in eosio::init (#114).

Multisig contract

The eosio.msig::approve action arguments have been augmented with a binary extension to optionally take a proposal_hash (of the builtin checksum256 ABI type) and check that against the hash of the current proposed transaction (i.e. the transaction ID of the proposed transaction) prior to approval (#121). Due to the use of binary extensions, the new eosio.msig::approve action is backwards compatible with any smart contract that may be sending it as an inline action or including it in a sent deferred transaction. It should also be backwards compatible with any tools that push the eosio.msig::approve action (such as cleos) as long as the tool supports EOSIO ABI version 1.1.

Users are recommended to use the new proposal_hash argument of the eosio.msig::approve action when approving proposed transactions to avoid being vulnerable to issues like the one discussed in #87. The JSON representation of the eosio.msig::approve action payload simply needs to have the proposal_hash field set to a string consisting of transaction ID (as a hex string) of the proposed transaction that the user believes they are approving. If the proposal_hash does not match, the transaction will fail and the approval will not occur. While it is possible to use tools like cleos push action to do this now (assuming the new eosio.msig was deployed), it is not convenient and requires manually calculating the SHA256 hash of the packed_transaction in the current retrieved proposal. A future release of eosio should enhance the cleos multisig sub-commands to make it much easier to use this new feature.

Dependencies

This release depends on eosio.cdt v1.4.x and eosio v1.4.x. To compile the contracts in this release, first build and install eosio.cdt v1.4.0 and eosio v1.4.3.

EOSIO Contracts v1.4.0 Release Notes

This release unintentionally introduced a backwards incompatible change to the eosio.system ABI. Please use v1.4.1 instead to avoid this specific backwards incompatibility.

All contracts

All of the contracts have been updated to be compatible with eosio.cdt v1.3.x. The 1.3 version of eosio.cdt introduced breaking changes to eosiolib which required the source code of all contracts to be modified so that they could continue to build.

The latest release of eosio.cdt also introduces new features like updated attributes to help with ABI generation and the ignore template to enable optimization of action argument deserialization without sacrificing automatic ABI generation. All contracts have been updated to use the new attributes for ABI generation, and furthermore the eosio.system, eosio.msig, and eosio.wrap (formerly known as eosio.sudo) contracts in particular have also been updated to use the ignore feature.

While the code for all of the contracts in this repository have been modified due to the reasons stated above, the only contracts that have had functional changes since the prior release are eosio.system and eosio.token.

Automatic ABI generation

The contracts have been updated to leverage the automatic ABI generation functionality of the latest eosio.cdt release. ABI files are no longer manually created and committed to the repository. Instead the build system will generate the ABI files and place them in the same directory as the generated WASM file.

Relaxed dependency checks

The dependency checks of prior releases of eosio.contracts were very strict. With each new minor release of eosio, users trying to build an existing eosio.contracts release with the new version of the eosio dependency found that the build would fail with a dependency version failure. The problem would eventually be fixed with the new minor release of eosio.contracts only to break again when one of its dependencies had another minor release.

With v1.4.0 of eosio.contracts, this frustrating problem should be resolved since the dependency version checker is now far more permissive. It will refuse to build with dependency versions that are known to be incompatible at the time of the release, however, now the build will continue (although with a warning) if the dependency has a higher minor (but not major) version than what was known to be good at the time of the eosio.contracts release. For details on the version checking logic, see #89.

Wrap contract (formerly know as the sudo contract)

The eosio.sudo contract has been renamed to eosio.wrap. There is no functionality change to the contract.

Token contract

The eosio.token::open action will now verify that the symbol provided to the action actually exists before attempting to open a new zero-balance table row for the symbol (#102).

System contract

Core symbol no longer needed during build

The concept of a core symbol has been entirely removed with the v1.3.0 release of eosio.cdt. There is no longer a core_symbol.hpp header file and the eosio::asset struct requires a symbol to always be explicitly provided to the non-default constructor.

In prior versions of eosio.contracts, the core symbol that was needed for the system contract was pulled in from eosio.cdt. Now, with the changes in eosio.cdt, the system contract alone is responsible determining what the core (or system) token symbol should be.

However, this change has also not required a core symbol to be provided as a build parameter when compiling the system contract. Instead the system contract has been updated to determine the core (or system) token dynamically rather than hard-coding it into the contract.

When the system contract is deployed to a blockchain for the very first time, a call to the eosio::init action should immediately follow to set up the initial parameters and tables of the system contract (the contract will not be fully functional without the initialization). The core token symbol is provided as an argument to this eosio::init action.

Further updates to the system contract code do not require an eosio::init action; in fact it is disallowed to call eosio::init a second time.

If version 1.4.0 of the system contract is replacing an existing deployment of older versions of the eosio.system contract, then no eosio::init action is necessary. The necessary tables should already be setup to allow v1.4.0 of the eosio.system contract to dynamically retrieve the core token symbol.

Dependencies

This release depends on eosio.cdt v1.3.x and eosio v1.3.x. To compile the contracts in this release, first build and install eosio.cdt v1.3.0 and eosio v1.3.2.