v3.10.0

This release marks a step forward in Vaulta's transition to the $A token by reinforcing the role of the core.vaulta contract as the canonical interface for staking and rewards on the Vaulta network.

Note

Learn how to integrate $A with your contracts.

---

Notable Changes

• Require $A for Stake, Unstake, and Claim Rewards
  Users can no longer stake, unstake, or claim rewards using $EOS. These actions must now be performed using $A via the core.vaulta contract.

• Redirect Reward Payments to $A
  The eosio.bpay::claimrewards action now gives rewards in $A instead of $EOS. If you are listening to token transfers from this action with a notification handler then you should update your handler.

---

Complete Change Log

• #208: Vaulta Transition

Contributors

• @nsjames

Full Changelog: v3.9.0...v3.10.0

Contracts v3.9.0

This System Contracts stable release adds two new eosio actions—regpeerkey and delpeerkey—to support on-chain peer key management for block producers.

---

Actions

• regpeerkey
  Registers (or replaces) a public peer key for the calling block producer’s account_name.

  • Each account may hold only one key at a time; a new call overwrites the previous key.

• delpeerkey
  Removes the registered peer key for the calling account, freeing the associated RAM and preventing stale entries in nodeos memory.

---

What's Changed

• Add support for storing public keys on-chain that will be used to validate a network peer's identity. by @greg7mdp in #185
• [3.9.0-rc1] Bump version to 3.9.0-rc1 by @heifner in #201
• rename docs, help, and examples to Vaulta by @ericpassmore in #204
• [3.9.0] Bump version to v3.9 by @heifner in #209

Contributors

• @greg7mdp
• @heifner
• @ericpassmore

Full Changelog: v3.8.0...v3.9.0

v3.9.0-rc1

This System Contracts release candidate adds two new eosio actions—regpeerkey and delpeerkey—to support on-chain peer key management for block producers.

---

Actions

• regpeerkey
  Registers (or replaces) a public peer key for the calling block producer’s account_name.

  • Each account may hold only one key at a time; a new call overwrites the previous key.

• delpeerkey
  Removes the registered peer key for the calling account, freeing the associated RAM and preventing stale entries in nodeos memory.

---

What's Changed

• Add support for storing public keys on-chain that will be used to validate a network peer's identity.

Contributors

• @greg7mdp
• @heifner

Full Changelog: v3.8.0...v3.9.0-rc1

EOS System Contracts v3.8.0 Release Notes

This release of System Contracts introduces a structured mechanism for blocking specific account name patterns. It utilizes a hash-based verification to conceal the blocked naming patterns. These changes strengthen the ability to enforce naming policies while maintaining accountability and verification mechanisms.

denyhashcalc

Computes a hash from a given vector of name patterns.This is a read-only action.

denyhashadd

Stores a computed hash on the blockchain. Requires eosio permission. This stored hash must exist before adding name patterns to the blacklist.

denyhashrm

Removes a previously stored hash. Triggers an exception if the hash does not exist or was already removed. Requires eosio permission.

denynames

Adds name patterns to the account_name_blacklist. Ensures new accounts cannot be created if their names match blacklisted patterns. Can be called by any account, but only succeeds if the corresponding hash was stored via denyhashadd.

undenynames

Removes name patterns from the account_name_blacklist. Requires eosio permission.

What's Changed

Contributions by @greg7mdp

• Fix warnings and improve error messages in #190
• Account Name Restriction in System Contract in #189
• Add a hash / reveal mechanism to avoid revealing the reserved account names when activating the blacklist in #191
• Silently ignore 13 character or empty patterns in the deny name vector in #192

Full Changelog: v3.7.0...v3.8.0

EOS System Contracts v3.8.0-rc1 Release Notes

This release of System Contracts introduces a structured mechanism for blocking specific account name patterns. It utilizes a hash-based verification to conceal the blocked naming patterns. These changes strengthen the ability to enforce naming policies while maintaining accountability and verification mechanisms.

denyhashcalc

Computes a hash from a given vector of name patterns.This is a read-only action.

denyhashadd

Stores a computed hash on the blockchain. Requires eosio permission. This stored hash must exist before adding name patterns to the blacklist.

denyhashrm

Removes a previously stored hash. Triggers an exception if the hash does not exist or was already removed. Requires eosio permission.

denynames

Adds name patterns to the account_name_blacklist. Ensures new accounts cannot be created if their names match blacklisted patterns. Can be called by any account, but only succeeds if the corresponding hash was stored via denyhashadd.

undenynames

Removes name patterns from the account_name_blacklist. Requires eosio permission.

EOS System Contracts v3.7.0 Release Notes

This release of EOS System Contracts enables support for gifting RAM.

Overview

Enables gifting of RAM which is useful for account creation.

Gift Ram Actions

This release includes new gift ram action, which transfers bytes of ram from gifter (from) to giftee (to), with the characteristic that the transfered ram is encumbered, meaning it can only be returned to the gifter via the ungiftram action. It cannot be traded, sold, re-gifted, or transfered otherwise. Its only use is for storing data.

Requires that giftee does not hold gifted ram by someone else than gifter, as one account can only hold gifted ram from one gifter at any time. Current gifter can gift additional ram to a giftee at any time (no restriction)
Receiving gifted ram does not add any restriction to an account, besides the usage restrictions on the gifted ram itself. For example, the account can purchase additional ram, and transfer, trade or sell this additional ram freely. The ram cost of adding a row in the gifted_ram table will be incurred by the gifter.

giftram(name from, name to, int64_t ram_bytes, std::string memo ); 
ungiftram(name from, name to, std::string memo );

Both giftram and ungiftram return the action_return_ramtransfer struct.

   struct action_return_ramtransfer {
      name    from;
      name    to;
      int64_t bytes;
      int64_t from_ram_bytes;
      int64_t to_ram_bytes;
   };

What's Changed

• Avoid database update when new ram is not issued with every block. by @greg7mdp in #167
• Add support for gifting RAM, which is encumbered and cannot be sold or transferred. by @greg7mdp in #168

New Contributors

• @greg7mdp made their first contribution in #167

Full Changelog: v3.6.1...v3.7.0

EOS System Contracts v3.7.0-rc1 Release Notes

This release of EOS System Contracts enables support for gifting RAM.

Overview

Enables gifting of RAM which is useful for account creation.

Gift Ram Actions

This release includes new gift ram action, which transfers bytes of ram from gifter (from) to giftee (to), with the characteristic that the transfered ram is encumbered, meaning it can only be returned to the gifter via the ungiftram action. It cannot be traded, sold, re-gifted, or transfered otherwise. Its only use is for storing data.

Requires that giftee does not hold gifted ram by someone else than gifter, as one account can only hold gifted ram from one gifter at any time. Current gifter can gift additional ram to a giftee at any time (no restriction)
Receiving gifted ram does not add any restriction to an account, besides the usage restrictions on the gifted ram itself. For example, the account can purchase additional ram, and transfer, trade or sell this additional ram freely. The ram cost of adding a row in the gifted_ram table will be incurred by the gifter.

giftram(name from, name to, int64_t ram_bytes, std::string memo ); 
ungiftram(name from, name to, std::string memo );

Both giftram and ungiftram return the action_return_ramtransfer struct.

   struct action_return_ramtransfer {
      name    from;
      name    to;
      int64_t bytes;
      int64_t from_ram_bytes;
      int64_t to_ram_bytes;
   };

What's Changed

• Avoid database update when new ram is not issued with every block. by @greg7mdp in #167
• Add support for gifting RAM, which is encumbered and cannot be sold or transferred. by @greg7mdp in #168

New Contributors

• @greg7mdp made their first contribution in #167

Full Changelog: v3.6.1...v3.7.0-rc1

EOS System Contracts v3.6.1 Release Notes

This release of EOS System Contracts restores Ricardian clauses that where mistakenly removed in the previous v3.6.0 release.

Overview

In this release we add back the on-chain user agreement and the block producer agreement. This is only an ABI change, there is no code change.

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