Releases: EOSIO/eosio.contracts
EOSIO v1.9.2 Release Notes
The eosio.system contract contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.
System contract
New Resource System (#536)
This new system will create a new optional NET and CPU marketplace which displaces (over time)
the existing staking system and REX market. Under the old model, system token holders
own NET and CPU and may choose to use it themselves, delegate it to others, or make
it available for others to rent using the REX market. Under this new model, the chain
owns almost all NET and CPU resources and the only way to access these resources is
through the new powerup action. It channels fees to the REX pool to enable token holders
to profit off the new market.
Renting resources
Users may use the powerup action to reserve resources:
void powerup(
name payer, // The resource buyer
name receiver, // The resource receiver
uint32_t days, // Number of days of resource availability.
// Must match market configuration.
int64_t net_frac, // Fraction of net (100% = 10^15) managed by this market
int64_t cpu_frac, // Fraction of cpu (100% = 10^15) managed by this market
asset max_payment // The maximum amount `payer` is willing to pay. Tokens
// are withdrawn from `payer`'s token balance.
);After the phase-in period, net_frac and cpu_frac will approximately represent the
fraction of total network resources. This should simplify resource planning since
the fraction will no longer depend on how much other accounts have staked or rented
from REX.
During the phase-in period, net_frac and cpu_frac represent the fraction managed
by the market at the time the action is called. Since the amount managed by the market
grows during phase-in, the percentage of total resources drops over the reservation period.
Processing Expired Loans
The resources in loans that expire do not automatically get reclaimed by the system. The expired loans sit in a queue that must be processed. Anyone calling the powerup action will help with processing this queue (limited to processing at most two expired loans at a time) so that normally the expired loans will be automatically processed in a timely manner. However, in some cases it may be necessary to manual process expired loans in the queue to make resources available to the system again and thus make prices cheaper. In such a scenario, any account may process up to an arbitrary number of expired loans by calling the powerupexec action.
Configuration
Operators of the blockchain can use the cfgpowerup to start the new resource system and tune its various parameters. It is possible to call cfgpowerup to change certain parameters even after the new resource system has already started. Chain operators can configure the new resource system to take over the old system immediately or they can configure it to gradually phase out the old system over a long period of time.
// configure the `powerup` market. The market becomes available the first time this action is invoked
void cfgpowerup( powerup_config& args );
struct powerup_config_resource {
std::optional<int64_t> current_weight_ratio; // Immediately set weight_ratio to this amount. 1x = 10^15. 0.01x = 10^13.
// Do not specify to preserve the existing setting or use the default;
// this avoids sudden price jumps. For new chains which don't need
// to gradually phase out staking and REX, 0.01x (10^13) is a good
// value for both current_weight_ratio and target_weight_ratio.
std::optional<int64_t> target_weight_ratio; // Linearly shrink weight_ratio to this amount. 1x = 10^15. 0.01x = 10^13.
// Do not specify to preserve the existing setting or use the default.
std::optional<int64_t> assumed_stake_weight; // Assumed stake weight for ratio calculations. Use the sum of total
// staked and total rented by REX at the time the power market
// is first activated. Do not specify to preserve the existing
// setting (no default exists); this avoids sudden price jumps.
// For new chains which don't need to phase out staking and REX,
// 10^12 is probably a good value.
std::optional<time_point_sec> target_timestamp; // Stop automatic weight_ratio shrinkage at this time. Once this
// time hits, weight_ratio will be target_weight_ratio. Ignored
// if current_weight_ratio == target_weight_ratio. Do not specify
// this to preserve the existing setting (no default exists).
std::optional<double> exponent; // Exponent of resource price curve. Must be >= 1. Do not specify
// to preserve the existing setting or use the default.
std::optional<uint32_t> decay_secs; // Number of seconds for the gap between adjusted resource
// utilization and instantaneous resource utilization to shrink
// by 63%. Do not specify to preserve the existing setting or
// use the default.
std::optional<asset> min_price; // Fee needed to reserve the entire resource market weight at the
// minimum price. For example, this could be set to 0.005% of
// total token supply. Do not specify to preserve the existing
// setting or use the default.
std::optional<asset> max_price; // Fee needed to reserve the entire resource market weight at the
// maximum price. For example, this could be set to 10% of total
// token supply. Do not specify to preserve the existing
// setting (no default exists).
};
struct powerup_config {
powerup_config_resource net; // NET market configuration
powerup_config_resource cpu; // CPU market configuration
std::optional<uint32_t> powerup_days; // `powerup` `days` argument must match this. Do not specify to preserve the
// existing setting or use the default.
std::optional<asset> min_powerup_fee; // Powerup fees below this amount are rejected. Do not specify to preserve the
// existing setting (no default exists).
};Definitions useful to help understand the above, including defaults:
inline constexpr int64_t powerup_frac = 1'000'000'000'000'000ll; // 1.0 = 10^15
struct powerup_state_resource {
static constexpr double default_exponent = 2.0; // Exponent of 2.0 means that the price to reserve a
// tiny amount of resources increases linearly
// with utilization.
static constexpr uint32_t default_decay_secs = 1 * seconds_per_day; // 1 day; if 100% of bandwidth resources are in a
// single loan, then, assuming no further powerup usage,
// 1 day after it expires the adjusted utilization
// will be at approximately 37% and after 3 days
// the adjusted utilization will be less than 5%.
uint8_t version = 0;
int64_t weight = 0; // resource market weight. calculated; varies over time.
// 1 represents the same amount of resources as 1
// satoshi of SYS staked.
int64_t weight_ratio = 0; // resource market weight ratio:
// assumed_stake_weight / (assumed_stake_weight + weight).
// calculated; varies over time. 1x = 10^15. 0.01x = 10^13.
int64_t assumed_stake_weight = 0; // Assumed stake weight for ratio calculations.
int64_t initial_weight_ratio = powerup_frac; // Initial weight_rati...EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch 3 Release Notes
This patch builds on top of EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch Release
Amendment (#519) of eosio.msig (#517)
The problem arose that the eosio.cdt tool abigen (see https://github.com/EOSIO/eosio.cdt/tree/master/tools/abigen) could not generate the appropriate annotations to the table structures for the introduced work-around class eosio_msig_binary_extension. The class has since been removed. In it's place, this change downgrades the eosio::binary_extension class requirements to that available in EOSIO/eosio.cdt/1.6.x so that abigen can now understand the eosio.msig contract and add the appropriate annotations to the table structures for the eosio::binary_extension class.
Dependencies
This patch release builds on top of EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch Release. Please refer to that document for required details.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch 2 Release Notes
This patch builds on top of EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch Release
Amendment (#517) of eosio.msig (#504)
An issue arises when a user proposes a transaction with non-zero delay_sec. Doing so will execute the deferred transaction instantly. To solve this problem we propose a way to emulate the behavior of a deferred transaction with this implementation.
eosio.msig Behavior (#517)
The changes are two-fold:
- The number of delay seconds is used to calculate the earliest possible execution time of the action
execonce the approvals of the proposal have been satisfied. The earliest execution time is the point in time at which the proposal has been satisfied plus the delayed seconds specified in the transaction header of the packed transaction. Also note, that if a proposal reverts its status of having the approvals satisfied, then unsatisfied, and then satisfied once again, the earliest execution time will get recalculated. - The given transaction (in the action
propose) is executed immediately upon the user performing the actionexecas a sequence of inline actions, but only if the the proposal has been approved and the given number of delay seconds has passed. Otherwise, the execution of the actionexecfails.
Dependencies
This patch release builds on top of EOSIO.Contracts v1.8.3 Inline Multi-Signature Patch Release. Please refer to that document for required details.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.8.3 Inline Multi-Signature Release Notes
eosio.msig (#505)
The existing implementation of the eosio.msig contract performs the exec action by use of a deferred transaction. On an EOSIO network with a typical amount of network traffic this will function as expected, but it poses an issue on EOSIO networks that have larger amounts of network traffic.
Due to the nature of deferred transactions, the transaction may expire without being executed, leading to the user having to manually invoke exec repeatedly until the transaction succeeds. This change now converts the exec action to executing inline.
Therefore the user can now be assured that the execution of the exec action has completed successfully, without the uncertainty of the transaction potentially being dropped.
Dependencies
Although not required, EOSIO/eos v2.0.7 is recommended due to the introduction of the configuration setting max-nonprivileged-inline-action-size to prevent any nonprivileged accounts from executing inline actions greater than the setting limit, which defaults to 4KB.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.9.1 Release Notes
The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.
System contract
A bug in the producer scheduling logic in v1.9.0 of the system contract has been fixed (#446). The bug may be triggered under certain circumstances when upgrading from system contract versions v1.8.x or earlier to v1.9.0. Observable side-effects of the bug, if triggered, including a pause in block producer payments, producer schedule changes, and the closing of name auction. Simply upgrading the system contract to the v1.9.1 version would resolve the issue and automatically resume those processes.
Other Changes
- (#431) [1.9.x] Wait for CDT binary.
- (#443) [1.9.x] Actions for community PRs.
- (#436) docs: clean up @details for release/1.9.x
Dependencies
This release depends on eosio.cdt v1.7.x and (optionally) on eosio v2.0.x. To compile the contracts in this release, first install eosio.cdt v1.7.0. To also compile the unit tests, first build and install eosio v2.0.1. The eosio.bios and eosio.system contracts in particular also require that the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade (first introduced in eosio v2.0.0) has been activated on the EOSIO blockchain before they can be deployed. When starting a fresh blockchain, an older version of the eosio.bios contract (v1.7.x or v1.8.x) could be used to first activate the WTMSIG_BLOCK_SIGNATURES protocol feature.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.9.0 Release Notes
The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.
System contract
New regproducer2 action
A new action regproducer2 has been added to the eosio.system contract (#349). This action acts an alternative to the existing regproducer (which still remains) to allow an account to register as a block producer candidate with a weighted threshold multi-signature (WTMsig) block signing authority (see the release notes for eosio v2.0.0) rather than just a single public key.
Note: The changes to the eosio.system contract introduce both binary extensions and variants (which are ABI 1.1 features) to the contract's ABI. Clients must support these ABI 1.1 features if they are to interact with the new eosio.system contract.
Changes to REX (#413)
In releases of the system contract prior to v1.8.3, the proceeds from CPU and NET loans, RAM trading fees, and name auction bids were immediately added to the REX pool which effectively distributed those proceeds pro rata to REX holders instantly. In this release, the proceeds are instead first collected into a staging pool within REX and then gradually distributed to REX holders linearly with time over a period of 30 days starting within 12 hours from the time at which the proceeds were collected into the REX staging pool.
REX tries to maintain a lower bound on the unlent balance to provide robustness in the rental price tracked by REX. To prevent a sell order from dropping the unlent percentage of the total tokens held by REX below a pre-determined fraction (thus violating the unlent balance lower bound), REX must delay the sell order by placing it in a sell queue to be processed at a later time when the sell order can be fulfilled without violating the lower bound. Any sell orders on the sell queue block further renting in order to satisfy the requirement that sell orders be fulfilled within 30 days of first entering the sell queue. Without an unlent balance lower bound, the REX rental price could become unstable under certain conditions and end up offering all available tokens to rent at too cheap of a price (click here to learn more about the mathematics behind the REX rental pricing algorithm). So while the unlent balance lower bound is necessary with the current REX rental pricing algorithm, there is some flexibility available in the particular choice of the pre-determined fraction value.
In releases of the system contract prior to v1.8.3, REX ensured that a sell order could not cause the amount of unlent tokens to become less than 20% of the amount of lent tokens (or equivalently that the unlent fraction of the total tokens held by REX could not go below one-sixth due to a sell order). This release lowers that threshold percentage from 20% to 10% which means that a larger fraction of tokens in REX can be lent out before further sell orders are forced into the sell queue.
Other changes within system contract
When someone outbids an existing account name, the system contract generates a deferred transaction containing the eosio::bidrefund action to return the funds of the account that was outbid. In releases of the system contract prior to v1.8.1, this action was authorized by the active permission of the eosio which meant the CPU/NET costs of the entire deferred transaction was billed to the eosio account. As of this release, the authorizer of the eosio::bidrefund action is the active permission of the account that was outbid (#383).
The system contract tracks a variable (total_activated_stake) to determine the first moment when 15% of all stake has voted so that it can trigger full activation of the system's features. After activation occurs, this variable is no longer needed. In releases of the system contract prior to v1.8.2, this variable continued to be updated even though it no longer had a purpose or even a well-defined meaning after activation. Furthermore, checks within the code that enable full functionality still referred to this variable. Since manipulation of this variable could potentially have adverse effects on the operation of the system contract, this release prevents further updates to the variable after activation and avoids depending on its value in the logic of the code after activation (#400).
Bios contract
The interface of the setprods action of the eosio.bios contract has been modified (#349) to take a producer schedule consisting of WTMsig block signing authorities rather than a producer schedule consisting only of single public keys per each block producer.
Other Changes
- (#328) Prevent overflow within claimrewards in cases of extreme inflation - develop
- (#334) [develop] Fix build breaking when specifying commit hash
- (#338) Wait for Base Image Build
- (#333) Update minimum CDT dependency to 1.7.x
- (#348) Update minimum EOSIO dependency to 2.0.x
- (#354) Change pronoun in buyrex Ricardian summary - v1.9.x
- (#360) [1.9.x] Test metrics fix
- (#356) Add eosio.contracts documentation content to release/1.9.x
- (#373) [1.9.x] Fix for forked PRs.
- (#379) [1.9.x] CI/CD: switch from gke to eks
Dependencies
This release depends on eosio.cdt v1.7.x and (optionally) on eosio v2.0.x. To compile the contracts in this release, first install eosio.cdt v1.7.0. To also compile the unit tests, first build and install eosio v2.0.0. The eosio.bios and eosio.system contracts in particular also require that the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed. When starting a fresh blockchain, an older version of the eosio.bios contract (v1.7.x or v1.8.x) could be used to first activate the WTMSIG_BLOCK_SIGNATURES protocol feature.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.8.4-rc1 Release Notes
System contract
This is a RELEASE CANDIDATE for version 1.8.4. The latest STABLE release is v1.8.3.
New Resource System (#397)
This new system will create a new optional NET and CPU rental market which displaces (over time)
the existing staking system and REX market. Under the old model, system token holders
own NET and CPU and may choose to use it themselves, delegate it to others, or make
it available for others to rent using the REX market. Under this new model, the chain
owns almost all NET and CPU resources and the only way to access these resources is
through the new rentbw action. It channels fees to the REX pool to enable token holders
to profit off the new market.
Renting resources
Users may use the rentbw action to rent resources:
void rentbw(
name payer, // The resource buyer
name receiver, // The resource receiver
uint32_t days, // Number of days of resource availability.
// Must match market configuration.
int64_t net_frac, // Fraction of net (100% = 10^15) managed by this market
int64_t cpu_frac, // Fraction of cpu (100% = 10^15) managed by this market
asset max_payment // The maximum amount `payer` is willing to pay. Tokens
// are withdrawn from `payer`'s token balance.
);After the phase-in period, net_frac and cpu_frac will approximately represent the
fraction of total network resources. This should simplify resource planning since
the fraction will no longer depend on how much other accounts have staked or rented
from REX.
During the phase-in period, net_frac and cpu_frac represent the fraction managed
by the market at the time the action is called. Since the amount managed by the market
grows during phase-in, the percentage of total resources drops over the rental period.
Processing Expired Loans
The resources in loans that expire do not automatically get reclaimed by the system. The expired loans sit in a queue that must be processed. Anyone calling the rentbw action will help with processing this queue (limited to processing at most two expired loans at a time) so that normally the expired loans will be automatically processed in a timely manner. However, in some cases it may be necessary to manual process expired loans in the queue to make resources available to the system again and thus make rental prices cheaper. In such a scenario, any account may process up to an arbitrary number of expired loans by calling the rentbwexec action.
Configuration
Operators of the blockchain can use the configrentbw to start the new resource system and tune its various parameters. It is possible to call configrentbw to change certain parameters even after the new resource system has already started. Chain operators can configure the new resource system to take over the old system immediately or they can configure it to gradually phase out the old system over a long period of time.
// Configure the `rentbw` market. The market becomes available the first time this
// action is invoked.
void configrentbw( rentbw_config& args );
struct rentbw_config_resource {
std::optional<int64_t> current_weight_ratio; // Immediately set weight_ratio to this amount. 1x = 10^15. 0.01x = 10^13.
// Do not specify to preserve the existing setting or use the default;
// this avoids sudden price jumps. For new chains which don't need
// to gradually phase out staking and REX, 0.01x (10^13) is a good
// value for both current_weight_ratio and target_weight_ratio.
std::optional<int64_t> target_weight_ratio; // Linearly shrink weight_ratio to this amount. 1x = 10^15. 0.01x = 10^13.
// Do not specify to preserve the existing setting or use the default.
std::optional<int64_t> assumed_stake_weight; // Assumed stake weight for ratio calculations. Use the sum of total
// staked and total rented by REX at the time the rentbw market
// is first activated. Do not specify to preserve the existing
// setting (no default exists); this avoids sudden price jumps.
// For new chains which don't need to phase out staking and REX,
// 10^12 is probably a good value.
std::optional<time_point_sec> target_timestamp; // Stop automatic weight_ratio shrinkage at this time. Once this
// time hits, weight_ratio will be target_weight_ratio. Ignored
// if current_weight_ratio == target_weight_ratio. Do not specify
// this to preserve the existing setting (no default exists).
std::optional<double> exponent; // Exponent of resource price curve. Must be >= 1. Do not specify
// to preserve the existing setting or use the default.
std::optional<uint32_t> decay_secs; // Number of seconds for the gap between adjusted resource
// utilization and instantaneous resource utilization to shrink
// by 63%. Do not specify to preserve the existing setting or
// use the default.
std::optional<asset> min_price; // Fee needed to rent the entire resource market weight at the
// minimum price. For example, this could be set to 0.005% of
// total token supply. Do not specify to preserve the existing
// setting or use the default.
std::optional<asset> max_price; // Fee needed to rent the entire resource market weight at the
// maximum price. For example, this could be set to 10% of total
// token supply. Do not specify to preserve the existing
// setting (no default exists).
};
struct rentbw_config {
rentbw_config_resource net; // NET market configuration
rentbw_config_resource cpu; // CPU market configuration
std::optional<uint32_t> rent_days; // `rentbw` `days` argument must match this. Do not specify to preserve the
// existing setting or use the default.
std::optional<asset> min_rent_fee; // Rental fees below this amount are rejected. Do not specify to preserve the
// existing setting (no default exists).
};Definitions useful to help understand the above, including defaults:
inline constexpr int64_t rentbw_frac = 1'000'000'000'000'000ll; // 1.0 = 10^15
struct rentbw_state_resource {
static constexpr double default_exponent = 2.0; // Exponent of 2.0 means that the price to rent a
// tiny amount of resources increases linearly
// with utilization.
static constexpr uint32_t default_decay_secs = 1 * seconds_per_day; // 1 day; if 100% of bandwidth resources are in a
// single loan, then, assuming no further renting,
// 1 day after it expires the adjusted utilization
// will be at approximately 37% and after 3 days
// the adjusted utilization will be less than 5%.
uint8_t version = 0;
int64_t weight = 0; // resource market weight. calculated; varies over time.
// 1 represents the same amount of resources as 1
// satoshi of SYS staked.
int64_t weight_ratio = 0; // resource market weight ratio:
// assumed_stake_weight / (assumed_stake_weight + weight).
// calculated; varies over time. 1x = 10^15. 0.01x = 10^13.
int64_t assumed_stake_weight = 0; // Assumed stake weight for ratio calculations.
int64_t initial_weight_ratio = rentbw_frac; // Initial weight_ratio used for linear shrinkage.
int64_t target_weight_ratio = rentbw_frac / 100; // Linearly shrink the weight_ratio to this amount.
time_point_sec initial_timestamp = {}; ...EOSIO.Contracts v1.9.0-rc4 Release Notes
This is a RELEASE CANDIDATE for version 1.9.0. The latest STABLE release is v1.8.3.
The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.
Changes to REX (#413)
In previous releases of the system contract, the proceeds from CPU and NET loans, RAM trading fees, and name auction bids were immediately added to the REX pool which effectively distributed those proceeds pro rata to REX holders instantly. In this release, the proceeds are instead first collected into a staging pool within REX and then gradually distributed to REX holders linearly with time over a period of 30 days starting within 12 hours from the time at which the proceeds were collected into the REX staging pool.
REX tries to maintain a lower bound on the unlent balance to provide robustness in the rental price tracked by REX. To prevent a sell order from dropping the unlent percentage of the total tokens held by REX below a pre-determined fraction (thus violating the unlent balance lower bound), REX must delay the sell order by placing it in a sell queue to be processed at a later time when the sell order can be fulfilled without violating the lower bound. Any sell orders on the sell queue block further renting in order to satisfy the requirement that sell orders be fulfilled within 30 days of first entering the sell queue. Without an unlent balance lower bound, the REX rental price could become unstable under certain conditions and end up offering all available tokens to rent at too cheap of a price (click here to learn more about the mathematics behind the REX rental pricing algorithm). So while the unlent balance lower bound is necessary with the current REX rental pricing algorithm, there is some flexibility available in the particular choice of the pre-determined fraction value.
In prior releases, REX ensured that a sell order could not cause the amount of unlent tokens to become less than 20% of the amount of lent tokens (or equivalently that the unlent fraction of the total tokens held by REX could not go below one-sixth due to a sell order). This release lowers that threshold percentage from 20% to 10% which means that a larger fraction of tokens in REX can be lent out before further sell orders are forced into the sell queue.
Dependencies
This release depends on eosio.cdt v1.7.x and (optionally) on eosio v2.0.x. To compile the contracts in this release, first install eosio.cdt v1.7.0-rc1. To also compile the unit tests, first build and install eosio v2.0.0-rc2. The eosio.bios and eosio.system contracts in particular also require that the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.8.3 Release Notes
System contract
Changes to REX (#412)
In previous releases of the system contract, the proceeds from CPU and NET loans, RAM trading fees, and name auction bids were immediately added to the REX pool which effectively distributed those proceeds pro rata to REX holders instantly. In this release, the proceeds are instead first collected into a staging pool within REX and then gradually distributed to REX holders linearly with time over a period of 30 days starting within 12 hours from the time at which the proceeds were collected into the REX staging pool.
REX tries to maintain a lower bound on the unlent balance to provide robustness in the rental price tracked by REX. To prevent a sell order from dropping the unlent percentage of the total tokens held by REX below a pre-determined fraction (thus violating the unlent balance lower bound), REX must delay the sell order by placing it in a sell queue to be processed at a later time when the sell order can be fulfilled without violating the lower bound. Any sell orders on the sell queue block further renting in order to satisfy the requirement that sell orders be fulfilled within 30 days of first entering the sell queue. Without an unlent balance lower bound, the REX rental price could become unstable under certain conditions and end up offering all available tokens to rent at too cheap of a price (click here to learn more about the mathematics behind the REX rental pricing algorithm). So while the unlent balance lower bound is necessary with the current REX rental pricing algorithm, there is some flexibility available in the particular choice of the pre-determined fraction value.
In prior releases, REX ensured that a sell order could not cause the amount of unlent tokens to become less than 20% of the amount of lent tokens (or equivalently that the unlent fraction of the total tokens held by REX could not go below one-sixth due to a sell order). This release lowers that threshold percentage from 20% to 10% which means that a larger fraction of tokens in REX can be lent out before further sell orders are forced into the sell queue.
Dependencies
This release depends on eosio.cdt v1.6.x and (optionally) on eosio v1.8.x. To compile the contracts in this release, first install eosio.cdt v1.6.3. To also compile the unit tests, first build and install eosio v1.8.6. The eosio.bios and eosio.system contracts in particular also require that the PREACTIVATE_FEATURE consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.
EOSIO.Contracts v1.9.0-rc3 Release Notes
This is a RELEASE CANDIDATE for version 1.9.0. The latest STABLE release is v1.8.2.
The eosio.system and eosio.bios contracts contained in this release can only be deployed on an EOSIO blockchain after the activation of the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade.
System contract
The system contract tracks a variable (total_activated_stake) to determine the first moment when 15% of all stake has voted so that it can trigger full activation of the system's features. After activation occurs, this variable is no longer needed. In previous releases, this variable continued to be updated even though it no longer had a purpose or even a well-defined meaning after activation. Furthermore, checks within the code that enable full functionality still referred to this variable. Since manipulation of this variable could potentially have adverse effects on the operation of the system contract, this release prevents further updates to the variable after activation and avoids depending on its value in the logic of the code after activation (#400).
Dependencies
This release depends on eosio.cdt v1.7.x and (optionally) on eosio v2.0.x. To compile the contracts in this release, first install eosio.cdt v1.7.0-rc1. To also compile the unit tests, first build and install eosio v2.0.0-rc2. The eosio.bios and eosio.system contracts in particular also require that the WTMSIG_BLOCK_SIGNATURES consensus protocol upgrade has been activated on the EOSIO blockchain before they can be deployed.
Disclaimer: All repositories and other materials are provided subject to this IMPORTANT notice and you must familiarize yourself with its terms. The notice contains important information, limitations and restrictions relating to our software, publications, trademarks, third-party resources, and forward-looking statements. By accessing any of our repositories and other materials, you accept and agree to the terms of the notice.