EOS System Contracts v3.6.0 Release Notes

This release of EOS System Contracts introduced support for managing BLS keys and the associated finalizer policies.

Overview

In this release we introduce 4 new System Contract Actions, and 2 new Tables.

The current version of system contracts ties the role of the finalize to the top 21 producers. All producers are expected to be finalizers, and have registered finalizer keys. For more information on managing finalizer keys see Managing Finalizer Keys

Version 3.6.0 of the EOS System Contracts requires the host function provided in CDT v4.1.0 and later and must be run using Spring v1.0.0 or later. In addition, all protocol features available in Spring v1.0.0 including SAVANNA must be activated prior to applying version 3.6.0 of the EOS System Contracts. See Switch to Savanna for a full guide on the requirements and the process of switching the Savanna consensus algorithm.

Actions

regfinkey

Action to register a finalizer key by a registered producer. If this was registered before (and still exists) even by other block producers, the registration will fail. If this is the first registered finalizer key of the producer, it will also implicitly be marked active. A registered producer can have multiple registered finalizer keys.

Params

• finalizer_name - account registering finalizer_key,
• finalizer_key - key to be registered. The key is in base64url format.
• proof_of_possession - a valid Proof of Possession signature to show the producer owns the private key of the finalizer_key. The signature is in base64url format.

PreRequisites

• finalizer_name must be a registered producer
• finalizer_key must be in base64url format
• proof_of_possession must be a valid of proof of possession signature
• Authority of finalizer_name to register. linkauth may be used to allow a lower authority to execute this action.

actfinkey

Action to activate a finalizer key. If the finalizer is currently an active block producer (in top 21), then immediately change Finalizer Policy. A finalizer may only have one active finalizer key. Activating a finalizer key implicitly deactivates the previously active finalizer key of that finalizer.

Params

• finalizer_name - account activating finalizer_key,
• finalizer_key - key to be activated.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• Authority of finalizer_name

delfinkey

Action to delete a finalizer key. An active finalizer key may not be deleted unless it is the last registered finalizer key. If it is the last one, it will be deleted.

Params

• finalizer_name - account deleting finalizer_key,
• finalizer_key - key to be deleted.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• finalizer_key must not be active, unless it is the last registered finalizer key
• Authority of finalizer_name

switchtosvnn

Action to permanently transition to Savanna consensus. Create the first generation of finalizer policy and activate the policy by using set_finalizers host function

PreRequisites

• Require the authority of the contract itself, typically eosio
• A sufficient number of the top 21 block producers have registered a finalizer key

Tables

finalizers

List of finalizers and currently active BLS key.

finkeys

List of all BLS Public Keys registered by finalizer

EOS System Contracts v3.6.0-rc2 Release Notes

This release of EOS System Contracts introduced support for managing BLS keys and the associated finalizer policies.

Overview

In this release we introduce 4 new System Contract Actions, and 2 new Tables.

The current version of system contracts ties the role of the finalize to the top 21 producers. All producers are expected to be finalizers, and have registered finalizer keys. For more information on managing finalizer keys see Managing Finalizer Keys

Actions

regfinkey

Action to register a finalizer key by a registered producer. If this was registered before (and still exists) even by other block producers, the registration will fail. If this is the first registered finalizer key of the producer, it will also implicitly be marked active. A registered producer can have multiple registered finalizer keys.

Params

• finalizer_name - account registering finalizer_key,
• finalizer_key - key to be registered. The key is in base64url format.
• proof_of_possession - a valid Proof of Possession signature to show the producer owns the private key of the finalizer_key. The signature is in base64url format.

PreRequisites

• finalizer_name must be a registered producer
• finalizer_key must be in base64url format
• proof_of_possession must be a valid of proof of possession signature
• Authority of finalizer_name to register. linkauth may be used to allow a lower authority to execute this action.

actfinkey

Action to activate a finalizer key. If the finalizer is currently an active block producer (in top 21), then immediately change Finalizer Policy. A finalizer may only have one active finalizer key. Activating a finalizer key implicitly deactivates the previously active finalizer key of that finalizer.

Params

• finalizer_name - account activating finalizer_key,
• finalizer_key - key to be activated.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• Authority of finalizer_name

delfinkey

Action to delete a finalizer key. An active finalizer key may not be deleted unless it is the last registered finalizer key. If it is the last one, it will be deleted.

Params

• finalizer_name - account deleting finalizer_key,
• finalizer_key - key to be deleted.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• finalizer_key must not be active, unless it is the last registered finalizer key
• Authority of finalizer_name

switchtosvnn

Action to permanently transition to Savanna consensus. Create the first generation of finalizer policy and activate the policy by using set_finalizers host function

PreRequisites

• Require the authority of the contract itself, typically eosio
• A sufficient number of the top 21 block producers have registered a finalizer key

Tables

finalizers

List of finalizers and currently active BLS key.

finkeys

List of all BLS Public Keys registered by finalizer

EOS System Contracts v3.6.0-rc1 Release Notes

This release of EOS System Contracts introduced support for managing BLS keys and the associated finalizer policies.

Overview

In this release we introduce 4 new System Contract Actions, and 2 new Tables.

The current version of system contracts ties the role of the finalize to the top 21 producers. All producers are expected to be finalizers, and have registered finalizer keys. For more information on managing finalizer keys see Managing Finalizer Keys

Actions

regfinkey

Action to register a finalizer key by a registered producer. If this was registered before (and still exists) even by other block producers, the registration will fail. If this is the first registered finalizer key of the producer, it will also implicitly be marked active. A registered producer can have multiple registered finalizer keys.

Params

• finalizer_name - account registering finalizer_key,
• finalizer_key - key to be registered. The key is in base64url format.
• proof_of_possession - a valid Proof of Possession signature to show the producer owns the private key of the finalizer_key. The signature is in base64url format.

PreRequisites

• finalizer_name must be a registered producer
• finalizer_key must be in base64url format
• proof_of_possession must be a valid of proof of possession signature
• Authority of finalizer_name to register. linkauth may be used to allow a lower authority to execute this action.

actfinkey

Action to activate a finalizer key. If the finalizer is currently an active block producer (in top 21), then immediately change Finalizer Policy. A finalizer may only have one active finalizer key. Activating a finalizer key implicitly deactivates the previously active finalizer key of that finalizer.

Params

• finalizer_name - account activating finalizer_key,
• finalizer_key - key to be activated.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• Authority of finalizer_name

delfinkey

Action to delete a finalizer key. An active finalizer key may not be deleted unless it is the last registered finalizer key. If it is the last one, it will be deleted.

Params

• finalizer_name - account deleting finalizer_key,
• finalizer_key - key to be deleted.

PreRequisites

• finalizer_key must be a registered finalizer key in base64url format
• finalizer_key must not be active, unless it is the last registered finalizer key
• Authority of finalizer_name

switchtosvnn

Action to permanently transition to Savanna consensus. Create the first generation of finalizer policy and activate the policy by using set_finalizers host function

PreRequisites

• Require the authority of the contract itself, typically eosio
• A sufficient number of the top 21 block producers have registered a finalizer key

Tables

finalizers

List of finalizers and currently active BLS key.

finkeys

List of all BLS Public Keys registered by finalizer

EOS System Contracts v3.5.0 Release Notes

This release focuses on REX changes.

Overview

Following the tokenomics update this release changes some minor REX system mechanics to make it easier to use, enforce lockup, and have a longer lockup duration.

Bpay Contract

A new contract that gets deployed on top of the eosio.bpay account.
This contract allows the distribution of system fees that flow into it into the hands of the top 21 BPs.

claimrewards

Claim rewards for a block producer.
You must have been producing at the moment that rewards were catalogued in the contract.

void claimrewards( const name owner );

REX changes (system contract)

The core changes to REX are:

• Remove voting requirements
• Change 4 day lockup to dynamic lockup setting
  • Will be 21 days on first deployment MSIG
• Immediately move all REX to the savings bucket

setrexmature

Sets configuration options for REX.

void setrexmature(
    const std::optional<uint32_t> num_of_maturity_buckets, 
    const std::optional<bool> sell_matured_rex, 
    const std::optional<bool> buy_rex_to_savings 
);

• num_of_maturity_buckets - Sets the number of days for lockup
• sell_matured_rex - Whether or not matured REX is sold immediately
• buy_rex_to_savings - Whether or not bought REX is moved immediately to savings

Reward contract

A new contract that gets deployed on top of the eosio.reward account.
This contract distributes rewards from the staking rewards bucket to a given set of strategies.

This new contract handles the distribution of fees to configurable destinations and rates.

This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.

Tables

struct strategies_row {
    name       strategy;
    uint16_t   weight;

    uint64_t primary_key() const { return strategy.value; }
};

The strategies table is always scoped to self (eosio.reward).

setstrategy

Available strategies:

• eosio.rex - Distributes to the REX system
• eosio.bonds - Distributes to EOS bonds

void setstrategy( 
    const name strategy, 
    const uint16_t weight 
)

Sets (create or update) a strategy's weight into effect for subsequent distributions.

• strategy - Must be one of the predefined strategies above
• weight - A number proportional to the total weight of all strategies

delstrategy

void delstrategy( const name strategy );

Removes a strategy from distributions.

distribute

void distribute();

Claims its rewards from eosio.saving and distributes them to the designated strategies based on their weights.

Static methods

static uint32_t get_total_weight( 
    const name contract = "eosio.reward"_n 
);

The get_total_weight static method returns the sum of all weights for all configured strategies.

WASM Hashes

eosio.system - ad12d594b75bdb4ab84c568f29d97f1ce82f50cca55a1f8a7d0406d4728d0e4b
eosio.bpay - 90a0db1f7a4d1a7bccc5a5400edaa489ae685e0cd5b052de8440096139638efc
eosio.reward - 49155e7e98991d9dad21970bb1d1cfec0d5ab77e842feaaa0dac1d1a91180cc7

Contributors

Special thanks to the contributors that worked on this release:

• @DenisCarriere
• @ericpassmore
• @nsjames

Full Changelog: v3.4.0...v3.5.0

EOS System Contracts v3.5.0 Pre-Release Notes (RC2)

A patch release to align bpay reward split by actual producer count.

WASM Hashes

eosio.bpay - 90a0db1f7a4d1a7bccc5a5400edaa489ae685e0cd5b052de8440096139638efc

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

EOS System Contracts v3.5.0 Pre-Release Notes

This release focuses on REX changes.

Overview

Following the tokenomics update this release changes some minor REX system mechanics to make it easier to use, enforce lockup, and have a longer lockup duration.

Bpay Contract

A new contract that gets deployed on top of the eosio.bpay account.
This contract allows the distribution of system fees that flow into it into the hands of the top 21 BPs.

claimrewards

Claim rewards for a block producer.
You must have been producing at the moment that rewards were catalogued in the contract.

void claimrewards( const name owner );

REX changes (system contract)

The core changes to REX are:

• Remove voting requirements
• Change 4 day lockup to dynamic lockup setting
  • Will be 21 days on first deployment MSIG
• Immediately move all REX to the savings bucket

setrexmature

Sets configuration options for REX.

void setrexmature(
    const std::optional<uint32_t> num_of_maturity_buckets, 
    const std::optional<bool> sell_matured_rex, 
    const std::optional<bool> buy_rex_to_savings 
);

• num_of_maturity_buckets - Sets the number of days for lockup
• sell_matured_rex - Whether or not matured REX is sold immediately
• buy_rex_to_savings - Whether or not bought REX is moved immediately to savings

Reward contract

A new contract that gets deployed on top of the eosio.reward account.
This contract distributes rewards from the staking rewards bucket to a given set of strategies.

This new contract handles the distribution of fees to configurable destinations and rates.

This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.

Tables

struct strategies_row {
    name       strategy;
    uint16_t   weight;

    uint64_t primary_key() const { return strategy.value; }
};

The strategies table is always scoped to self (eosio.reward).

setstrategy

Available strategies:

• eosio.rex - Distributes to the REX system
• eosio.bonds - Distributes to EOS bonds

void setstrategy( 
    const name strategy, 
    const uint16_t weight 
)

Sets (create or update) a strategy's weight into effect for subsequent distributions.

• strategy - Must be one of the predefined strategies above
• weight - A number proportional to the total weight of all strategies

delstrategy

void delstrategy( const name strategy );

Removes a strategy from distributions.

distribute

void distribute();

Claims its rewards from eosio.saving and distributes them to the designated strategies based on their weights.

Static methods

static uint32_t get_total_weight( 
    const name contract = "eosio.reward"_n 
);

The get_total_weight static method returns the sum of all weights for all configured strategies.

WASM Hashes

eosio.system - ad12d594b75bdb4ab84c568f29d97f1ce82f50cca55a1f8a7d0406d4728d0e4b
eosio.bpay - 32181be084b539d882d92ff85a3d0b9962c8cb7292902cc558bc9a77dedd8fa9
eosio.reward - 49155e7e98991d9dad21970bb1d1cfec0d5ab77e842feaaa0dac1d1a91180cc7

Contributors

Special thanks to the contributors that worked on this release:

• @DenisCarriere
• @ericpassmore
• @nsjames

Full Changelog: v3.4.0...v3.5.0-rc1

EOS System Contracts v3.4.0 Release Notes

This release focuses on tokenomic changes.

Overview

Following a discussion around a tokenomics proposal this release introduces changes required to support a significant update in EOS tokenomics that changes the way EOS inflation and distribution function. These system smart contract changes are required to create an onchain multi-sig that block producers will vote on to approve or oppose the proposal.

Token Changes

The proposal centers around a lowering of the maximum supply to 2.1b tokens, and an issuing up to that target number instead of a slow inflation in order to create a fixed supply.

New actions on the eosio.token contract are required to make that possible, as well as some core changes to the way that block producers are paid when the token's maximum supply equals the current supply.

View Token Changes PR

setmaxsupply

void setmaxsupply( 
    const name& issuer, 
    const asset& maximum_supply 
);

Sets the maximum supply of the token to maximum_supply.
The issuer must match the original issuer of the token.

issuefixed

void issuefixed( 
    const name& to, 
    const asset& supply, 
    const string& memo 
);

Issues the delta between the current supply and the supply parameter, and allocates those tokens to the to account.

A memo can also be included.

Changes to block producer rewards and eosio.saving

When a block producer calls claimrewards it will now check if the current supply is equal to
the maximum supply, and if so then it will use the tokens that the eosio account holds.

If not, then it will continue to inflate as it did prior to these changes.

New static methods

To make it easy for external parties to integrate with these changes, and to keep the contract clean internally two new static methods were introduced.

static asset get_max_supply( 
    const name& token_contract_account, 
    const symbol_code& sym_code 
);

static name get_issuer( 
    const name& token_contract_account, 
    const symbol_code& sym_code 
);

Vesting Schedules

In order to distribute the fixed tokens to the relevant parties a vesting schedule is introduced. This allows dynamically setting date/rate pairs that define how much of the existing supply is distributed to block producers and the eosio.saving contract.

View Vesting Schedules PR

schedules table

struct schedules_info {
  time_point_sec   start_time;
  double           continuous_rate;

  uint64_t primary_key() const { return start_time.sec_since_epoch(); }
};

The schedules table holds the time/rate pairs, and is always scoped to self (eosio).

setschedule

void setschedule( 
    const time_point_sec start_time, 
    double continuous_rate 
);

Adds or updates a scheduled vesting distribution rate at a given date to the schedules table.

• start_time - The date this rate can be applied
• continuous_rate - A percentage of the current supply divided by 100

An example of a 5% distribution rate:

{"start_time": "2024-06-01T00:00:00Z", "continuous_rate": 0.05}

delschedule

void delschedule( 
    const time_point_sec start_time 
);

Deletes a schedule if it exists, or fails.

execschedule

void execschedule();

Executes the next schedule sorted by closest date. The schedule's start_time must have already passed.

setpayfactor

void setpayfactor( 
    int64_t inflation_pay_factor, 
    int64_t votepay_factor 
);

This new action is identical to the setinflation action except that it does not allow changing the annual_rate which would then compute the continuous_rate, as that is now set through vesting schedules.

This allows modifying the block producer bpay, vpay, and eosio.saving splits.

For more information about how these parameters work, see the comments on the code here.

unvest

void unvest(
    const name account, 
    const asset unvest_net_quantity, 
    const asset unvest_cpu_quantity
);

This action retires the unvested tokens from the b1 account, enforces only the unvested tokens can be touched, and updates the locking logic to allow b1 to take any remaining tokens that have already vested after the unvested tokens have been retired.

Fees Upgrade

In order to allow distribution of system fees to new buckets (block producers, rex, and RAM) and pushing fees from new origins, changes to the system contracts have been made and a new eosio.fees contract will be deployed.

View Fees Upgrade PR

System contract changes and new actions

donatetorex

void donatetorex( 
    const name& payer, 
    const asset& quantity, 
    const std::string& memo 
);

This allows anyone to donate EOS into the REX markets. Since a new eosio.fees contract will be controlling the distribution of fees the system contract needs a way to accept donations from external entities as previously it was only possible internally.

Important to note that this does not require a token transfer, and instead EOS will be taken from the account the same way as the system does in other actions like buyram.

buyramburn

struct action_return_buyram {
  name payer;
  name receiver;
  asset quantity;
  int64_t bytes_purchased;
  int64_t ram_bytes;
  asset fee;
};

action_return_buyram buyramburn( 
    const name& payer, 
    const asset& quantity, 
    const std::string& memo 
);

This action buys ram and burns it within a single action instead of having to call multiple actions.

logsystemfee

void logsystemfee( 
    const name& protocol, 
    const asset& fee, 
    const std::string& memo 
);

The logsystemfee adds another log to the system contracts that helps track fees, where they are coming from and where they are going. It is called inline in every action that would incur fees (such as name auctions, or ram market trades).

Changes to return values and logs

Both logbuyram and logsellram now have a const binary_extension<asset>& fee at the end of their parameter lists. This helps track that fee for external parties.

The action_return_buyram and action_return_sellram return value structs have also been modified to add an asset fee;

Static methods

New methods are exposed on eosio.system.hpp to exposed if REX is available or not. These are aimed at helping integrators that want to use the new donatetorex action.

static bool rex_system_initialized(
    name system_account = "eosio"_n
);

static bool rex_available(
    name system_account = "eosio"_n
);

The get_core_symbol method was also modified to make it simpler to use.

static symbol get_core_symbol( 
    name system_account = "eosio"_n 
);

eosio.fees contract

This new contract handles the distribution of fees to configurable destinations and rates.

This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.

Tables

struct strategies_row {
    name       strategy;
    uint16_t   weight;

    uint64_t primary_key() const { return strategy.value; }
};

The strategies table is always scoped to self (eosio).

struct settings_row {
    uint32_t            epoch_time_interval = 600;
    time_point_sec      next_epoch_timestamp;
};

The settings table is always scoped to self (eosio).

init

void init( 
    const uint32_t epoch_time_interval 
);

Initializes the eosio.fees contract and sets the interval allowed for distributions (in seconds).

setstrategy

Available strategies:

• buyramburn - Buys ram and burns it
• buyramself - Buy ram for eosio.fees and holds it
• donatetorex - Sends fees to REX
• eosio.bpay - Sends fees to be paid to producers

void setstrategy( 
    const name strategy, 
    const uint16_t weight 
)

Sets (create or update) a strategy's weight into effect for subsequent distributions.

• strategy - Must be one of the predefined strategies above
• weight - A number proportional to the total weight of all strategies

delstrategy

void delstrategy( const name strategy );

Removes a strategy from distributions.

distribute

void distribute();

Distributes accumulated fees to the designated strategies based on their weights once every epoch period. The next epoch is updated to be a distance of epoch_time_interval from the second this action is called.

Static methods

static uint16_t get_total_weight( 
    const name contract = "eosio.fees"_n 
);

The get_total_weight static method returns the sum of all weights for all configured strategies.

WASM Hashes

eosio.system - b78e2bfcceea88b337f195bb1e362a33cb5365aaaf02a2c32bcbf6698b1b832f
eosio.token - 0a16e1dac533c4558698c8754f41219839ba2a2b75e517e65ea2537f76681f49

Contributors

Special thanks to the contributors that worked on this release:

• @DenisCarriere
• @ericpassmore
• @timmwest
• @rdewilder
• @nsjames

Full Changelog: https://github.com/eosnetwork...

EOS System Contracts v3.4.0 Pre-Release Notes

This release focuses on tokenomic changes.

Overview

Following a discussion around a tokenomics proposal this release introduces changes required to support a significant update in EOS tokenomics that changes the way EOS inflation and distribution function. These system smart contract changes are required to create an onchain multi-sig that block producers will vote on to approve or oppose the proposal.

Token Changes

The proposal centers around a lowering of the maximum supply to 2.1b tokens, and an issuing up to that target number instead of a slow inflation in order to create a fixed supply.

New actions on the eosio.token contract are required to make that possible, as well as some core changes to the way that block producers are paid when the token's maximum supply equals the current supply.

View Token Changes PR

setmaxsupply

void setmaxsupply( 
    const name& issuer, 
    const asset& maximum_supply 
);

Sets the maximum supply of the token to maximum_supply.
The issuer must match the original issuer of the token.

issuefixed

void issuefixed( 
    const name& to, 
    const asset& supply, 
    const string& memo 
);

Issues the delta between the current supply and the supply parameter, and allocates those tokens to the to account.

A memo can also be included.

Changes to block producer rewards and eosio.saving

When a block producer calls claimrewards it will now check if the current supply is equal to
the maximum supply, and if so then it will use the tokens that the eosio account holds.

If not, then it will continue to inflate as it did prior to these changes.

New static methods

To make it easy for external parties to integrate with these changes, and to keep the contract clean internally two new static methods were introduced.

static asset get_max_supply( 
    const name& token_contract_account, 
    const symbol_code& sym_code 
);

static name get_issuer( 
    const name& token_contract_account, 
    const symbol_code& sym_code 
);

Vesting Schedules

In order to distribute the fixed tokens to the relevant parties a vesting schedule is introduced. This allows dynamically setting date/rate pairs that define how much of the existing supply is distributed to block producers and the eosio.saving contract.

View Vesting Schedules PR

schedules table

struct schedules_info {
  time_point_sec   start_time;
  double           continuous_rate;

  uint64_t primary_key() const { return start_time.sec_since_epoch(); }
};

The schedules table holds the time/rate pairs, and is always scoped to self (eosio).

setschedule

void setschedule( 
    const time_point_sec start_time, 
    double continuous_rate 
);

Adds or updates a scheduled vesting distribution rate at a given date to the schedules table.

• start_time - The date this rate can be applied
• continuous_rate - A percentage of the current supply divided by 100

An example of a 5% distribution rate:

{"start_time": "2024-06-01T00:00:00Z", "continuous_rate": 0.05}

delschedule

void delschedule( 
    const time_point_sec start_time 
);

Deletes a schedule if it exists, or fails.

execschedule

void execschedule();

Executes the next schedule sorted by closest date. The schedule's start_time must have already passed.

setpayfactor

void setpayfactor( 
    int64_t inflation_pay_factor, 
    int64_t votepay_factor 
);

This new action is identical to the setinflation action except that it does not allow changing the annual_rate which would then compute the continuous_rate, as that is now set through vesting schedules.

This allows modifying the block producer bpay, vpay, and eosio.saving splits.

For more information about how these parameters work, see the comments on the code here.

unvest

void unvest(
    const name account, 
    const asset unvest_net_quantity, 
    const asset unvest_cpu_quantity
);

This action retires the unvested tokens from the b1 account, enforces only the unvested tokens can be touched, and updates the locking logic to allow b1 to take any remaining tokens that have already vested after the unvested tokens have been retired.

Fees Upgrade

In order to allow distribution of system fees to new buckets (block producers, rex, and RAM) and pushing fees from new origins, changes to the system contracts have been made and a new eosio.fees contract will be deployed.

View Fees Upgrade PR

System contract changes and new actions

donatetorex

void donatetorex( 
    const name& payer, 
    const asset& quantity, 
    const std::string& memo 
);

This allows anyone to donate EOS into the REX markets. Since a new eosio.fees contract will be controlling the distribution of fees the system contract needs a way to accept donations from external entities as previously it was only possible internally.

Important to note that this does not require a token transfer, and instead EOS will be taken from the account the same way as the system does in other actions like buyram.

buyramburn

struct action_return_buyram {
  name payer;
  name receiver;
  asset quantity;
  int64_t bytes_purchased;
  int64_t ram_bytes;
  asset fee;
};

action_return_buyram buyramburn( 
    const name& payer, 
    const asset& quantity, 
    const std::string& memo 
);

This action buys ram and burns it within a single action instead of having to call multiple actions.

logsystemfee

void logsystemfee( 
    const name& protocol, 
    const asset& fee, 
    const std::string& memo 
);

The logsystemfee adds another log to the system contracts that helps track fees, where they are coming from and where they are going. It is called inline in every action that would incur fees (such as name auctions, or ram market trades).

Changes to return values and logs

Both logbuyram and logsellram now have a const binary_extension<asset>& fee at the end of their parameter lists. This helps track that fee for external parties.

The action_return_buyram and action_return_sellram return value structs have also been modified to add an asset fee;

Static methods

New methods are exposed on eosio.system.hpp to exposed if REX is available or not. These are aimed at helping integrators that want to use the new donatetorex action.

static bool rex_system_initialized(
    name system_account = "eosio"_n
);

static bool rex_available(
    name system_account = "eosio"_n
);

The get_core_symbol method was also modified to make it simpler to use.

static symbol get_core_symbol( 
    name system_account = "eosio"_n 
);

eosio.fees contract

This new contract handles the distribution of fees to configurable destinations and rates.

This simplifies the ability to control the flow of fees within EOS as well as making them easier to track and view on explorers and other tooling.

Tables

struct strategies_row {
    name       strategy;
    uint16_t   weight;

    uint64_t primary_key() const { return strategy.value; }
};

The strategies table is always scoped to self (eosio).

struct settings_row {
    uint32_t            epoch_time_interval = 600;
    time_point_sec      next_epoch_timestamp;
};

The settings table is always scoped to self (eosio).

init

void init( 
    const uint32_t epoch_time_interval 
);

Initializes the eosio.fees contract and sets the interval allowed for distributions (in seconds).

setstrategy

Available strategies:

• buyramburn - Buys ram and burns it
• buyramself - Buy ram for eosio.fees and holds it
• donatetorex - Sends fees to REX
• eosio.bpay - Sends fees to be paid to producers

void setstrategy( 
    const name strategy, 
    const uint16_t weight 
)

Sets (create or update) a strategy's weight into effect for subsequent distributions.

• strategy - Must be one of the predefined strategies above
• weight - A number proportional to the total weight of all strategies

delstrategy

void delstrategy( const name strategy );

Removes a strategy from distributions.

distribute

void distribute();

Distributes accumulated fees to the designated strategies based on their weights once every epoch period. The next epoch is updated to be a distance of epoch_time_interval from the second this action is called.

Static methods

static uint16_t get_total_weight( 
    const name contract = "eosio.fees"_n 
);

The get_total_weight static method returns the sum of all weights for all configured strategies.

Contributors

Special thanks to the contributors that worked on this release:

• @DenisCarriere
• @ericpassmore
• @timmwest
• @rdewilder
• @nsjames

Full Changelog: v3.3.0...v3.4.0-rc1

EOS System Contracts v3.3.0 Release Notes

This release contains new features.

Usecases

Ram Transfer Usecases

1. Improves EOS account creation:
   a. Create newaccount using ramtransfer instead of buyram or buyrambytes

2. 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:

• @DenisCarriere
• @ericpassmore

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

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:

• @lparisc
• @dimas1185
• @spoonincode
• @iamveritas
• @oschwaldp-oci
• @ericpassmore
• @vladtr

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