rename docs, help, and examples to Vaulta

.cspell/eos-system-contracts-custom-dictionary.txt → .cspell/system-contracts-custom-dictionary.txt

@@ -117,6 +117,7 @@ updateauth
 updaterex
 updtrevision
 userres
+core.vaulta
 vitr
 vmtype
 vmversion

CMakeLists.txt

@@ -13,7 +13,7 @@ else()
   set(VERSION_FULL "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_PATCH}")
 endif()
 
-message(STATUS "Building eos-system-contracts v${VERSION_FULL}")
+message(STATUS "Building system-contracts v${VERSION_FULL}")
 
 include(ExternalProject)
 

CONTRIBUTING.md

@@ -1,12 +1,12 @@
-# Contributing to eos-system-contracts
+# Contributing to system-contracts
 
 Interested in contributing? That's awesome! Here are some guidelines to get started quickly and easily:
 
 - [Reporting An Issue](#reporting-an-issue)
   - [Bug Reports](#bug-reports)
   - [Feature Requests](#feature-requests)
   - [Change Requests](#change-requests)
-- [Working on eos-system-contracts](#working-on-eos-system-contracts)
+- [Working on system-contracts](#working-on-system-contracts)
   - [Feature Branches](#feature-branches)
   - [Submitting Pull Requests](#submitting-pull-requests)
   - [Testing and Quality Assurance](#testing-and-quality-assurance)
@@ -16,7 +16,7 @@ Interested in contributing? That's awesome! Here are some guidelines to get star
 
 ## Reporting An Issue
 
-If you're about to raise an issue because you think you've found a problem with eos-system-contracts, or you'd like to make a request for a new feature in the codebase, or any other reason… please read this first.
+If you're about to raise an issue because you think you've found a problem with system-contracts, or you'd like to make a request for a new feature in the codebase, or any other reason… please read this first.
 
 The GitHub issue tracker is the preferred channel for [bug reports](#bug-reports), [feature requests](#feature-requests), and [submitting pull requests](#submitting-pull-requests), but please respect the following restrictions:
 
@@ -34,12 +34,12 @@ Guidelines for bug reports:
    reported.
 
 1. **Check if the issue has been fixed** — look for [closed issues in the
-   current milestone](https://github.com/eosnetworkfoundation/eos-system-contracts/issues?q=is%3Aissue+is%3Aclosed) or try to reproduce it
+   current milestone](https://github.com/VaultaFoundation/system-contracts/issues?q=is%3Aissue+is%3Aclosed) or try to reproduce it
    using the latest `main` branch.
 
 A good bug report shouldn't leave others needing to chase you up for more information. Be sure to include the details of your environment and relevant tests that demonstrate the failure.
 
-[Report a bug](https://github.com/eosnetworkfoundation/eos-system-contracts/issues/new?title=Bug%3A)
+[Report a bug](https://github.com/VaultaFoundation/system-contracts/issues/new?title=Bug%3A)
 
 ### Feature Requests
 
@@ -51,24 +51,24 @@ Feature requests are welcome. Before you submit one be sure to have:
 
 ### Change Requests
 
-Change requests cover both architectural and functional changes to how eos-system-contracts works. If you have an idea for a new or different dependency, a refactor, or an improvement to a feature, etc - please be sure to:
+Change requests cover both architectural and functional changes to how system-contracts works. If you have an idea for a new or different dependency, a refactor, or an improvement to a feature, etc - please be sure to:
 
 1. **Use the GitHub search** and check someone else didn't get there first
 1. Take a moment to think about the best way to make a case for, and explain what you're thinking. Are you sure this shouldn't really be
    a [bug report](#bug-reports) or a [feature request](#feature-requests)?  Is it really one idea or is it many? What's the context? What problem are you solving? Why is what you are suggesting better than what's already there?
 
-## Working on eos-system-contracts
+## Working on system-contracts
 
-Code contributions are welcome and encouraged! If you are looking for a good place to start, check out the [good first issue](https://github.com/eosnetworkfoundation/eos-system-contracts/labels/good%20first%20issue) label in GitHub issues.
+Code contributions are welcome and encouraged! If you are looking for a good place to start, check out the [good first issue](https://github.com/VaultaFoundation/system-contracts/labels/good%20first%20issue) label in GitHub issues.
 
 Also, please follow these guidelines when submitting code:
 
 ### Feature Branches
 
 To get it out of the way:
 
-- **[main](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main)** is the development branch. All work on the next release happens here so you should generally branch off `main`. Do **NOT** use this branch for a production site.
-- **release/** branches contain stable releases of eos-system-contracts. Some of these branches may be obsolete, a prerelease (release candidate), or designated as stable and ready for use in production. Generally do **NOT** use these branches to work on eos-system-contracts' source unless you are working on a defect or change that would apply to a current stable release or release candidate. If in doubt, branch off of `main` and an eos-system-contracts maintainer will chime in if you should switch to a release branch.
+- **[main](https://github.com/VaultaFoundation/system-contracts/tree/main)** is the development branch. All work on the next release happens here so you should generally branch off `main`. Do **NOT** use this branch for a production site.
+- **release/** branches contain stable releases of system-contracts. Some of these branches may be obsolete, a prerelease (release candidate), or designated as stable and ready for use in production. Generally do **NOT** use these branches to work on system-contracts' source unless you are working on a defect or change that would apply to a current stable release or release candidate. If in doubt, branch off of `main` and an system-contracts maintainer will chime in if you should switch to a release branch.
 
 ### Submitting Pull Requests
 
@@ -78,7 +78,7 @@ Pull requests are awesome. If you're looking to raise a PR for something which d
 
 Never underestimate just how useful quality assurance is. If you're looking to get involved with the code base and don't know where to start, checking out and testing a pull request is one of the most useful things you could do.
 
-Essentially, [check out the main branch](#working-on-eos-system-contracts), take it for a spin, and if you find anything odd, please follow the [bug report guidelines](#bug-reports) and let us know!
+Essentially, [check out the main branch](#working-on-system-contracts), take it for a spin, and if you find anything odd, please follow the [bug report guidelines](#bug-reports) and let us know!
 
 ## Conduct
 

README.md

@@ -1,6 +1,6 @@
-# EOS system contracts
+# Vaulta system contracts
 
-EOS system contracts are a collection of contracts specifically designed for the EOS blockchain, which implements a lot of critical functionality that goes beyond what is provided by the base Antelope protocol, the protocol on which EOS blockchain is built on.
+Vaulta system contracts are a collection of contracts specifically designed for the Vaulta blockchain, which implements a lot of critical functionality that goes beyond what is provided by the base Antelope protocol, the protocol on which Vaulta blockchain is built on.
 
 The Antelope protocol includes capabilities such as:
 
@@ -32,7 +32,7 @@ The collection of system contracts consists of the following individual contract
 
 ## Repository organization
 
-The `main` branch contains the latest state of development; do not use this for production. Refer to the [releases page](https://github.com/eosnetworkfoundation/eos-system-contracts/releases) for current information on releases, pre-releases, and obsolete releases as well as the corresponding tags for those releases.
+The `main` branch contains the latest state of development; do not use this for production. Refer to the [releases page](https://github.com/VaultaFoundation/system-contracts/releases) for current information on releases, pre-releases, and obsolete releases as well as the corresponding tags for those releases.
 ## Supported Operating Systems
 
 [CDT](https://github.com/AntelopeIO/cdt) is required to build contracts. Any operating systems supported by CDT is sufficient to build the system contracts.

contracts/eosio.bpay/include/eosio.bpay/eosio.bpay.hpp

@@ -18,15 +18,15 @@ namespace eosio {
          * ## TABLE `rewards`
          *
          * @param owner - block producer owner account
-         * @param quantity - reward quantity in EOS
+         * @param quantity - reward quantity in SYS (or other token)
          *
          * ### example
          *
          * ```json
          * [
          *   {
          *     "owner": "alice",
-         *     "quantity": "8.800 EOS"
+         *     "quantity": "8.800 SYS"
          *   }
          * ]
          * ```

contracts/eosio.fees/include/eosio.fees/eosio.fees.hpp

@@ -18,7 +18,7 @@ namespace eosio {
     *
     * This contract serves as an essential component for inclusion in system-level unit tests.
     *
-    * A comprehensive implementation of the eosio.fees contract can be accessed at EOS Network Foundation GitHub repository.
+    * A comprehensive implementation of the eosio.fees contract can be accessed at Vaulta Foundation GitHub repository.
     * https://github.com/eosnetworkfoundation/eosio.fees
     */
    class [[eosio::contract("eosio.fees")]] fees : public contract {

contracts/eosio.system/include/eosio.system/eosio.system.hpp

@@ -1396,7 +1396,7 @@ namespace eosiosystem {
          /**
           * The buyramself action is designed to enhance the permission security by allowing an account to purchase RAM exclusively for itself.
           * This action prevents the potential risk associated with standard actions like buyram and buyrambytes,
-          * which can transfer EOS tokens out of the account, acting as a proxy for eosio.token::transfer.
+          * which can transfer tokens out of the account, acting as a proxy for eosio.token::transfer. Token must include symbole, example SYS.
           *
           * @param account - the ram buyer and receiver,
           * @param quant - the quantity of tokens to buy ram with.
@@ -1678,7 +1678,7 @@ namespace eosiosystem {
           * @pre If proxy is set then proxy account must exist and be registered as a proxy
           * @pre Every listed producer or proxy must have been previously registered
           * @pre Voter must authorize this action
-          * @pre Voter must have previously staked some EOS for voting
+          * @pre Voter must have previously staked tokens for voting (example SYS tokens)
           * @pre Voter->staked must be up to date
           *
           * @post Every producer previously voted for will have vote reduced by previous vote weight

contracts/eosio.system/src/rex.cpp

@@ -1042,7 +1042,7 @@ namespace eosiosystem {
    asset system_contract::add_to_rex_pool( const asset& payment )
    {
       /**
-       * If CORE_SYMBOL is (EOS,4), maximum supply is 10^10 tokens (10 billion tokens), i.e., maximum amount
+       * If CORE_SYMBOL is (XYZ,4), maximum supply is 10^10 tokens (10 billion tokens), i.e., maximum amount
        * of indivisible units is 10^14. rex_ratio = 10^4 sets the upper bound on (REX,4) indivisible units to
        * 10^18 and that is within the maximum allowable amount field of asset type which is set to 2^62
        * (approximately 4.6 * 10^18). For a different CORE_SYMBOL, and in order for maximum (REX,4) amount not

docs/01_key-concepts/01_system.md

@@ -2,24 +2,24 @@
 title: System contracts, system accounts, privileged accounts
 ---
 
-At the genesis of the EOS blockchain, there was only one account present, `eosio` account, which was and still is the main `system account`. During the EOS blockchain bootstrap process other `system account`s, were created by `eosio` account, which control specific actions of the `system contract`s. You can see them listed in the [About System Contract](../index.md#system-contracts-defined-in-eos-system-contracts) section.
+At the genesis of the Vaulta blockchain, there was only one account present, `eosio` account, which was and still is the main `system account`. During the Vaulta blockchain bootstrap process other `system account`s, were created by `eosio` account, which control specific actions of the `system contract`s. You can see them listed in the [About System Contract](../index.md#system-contracts-defined-in-system-contracts) section.
 
 __Note__ the terms `system contract` and `system account`. `Privileged accounts` are accounts which can execute a transaction while skipping the standard authorization check. To ensure that this is not a security hole, the permission authority over these accounts is granted to `eosio.prods` system account.
 
 As you just learned the relation between a `system account` and a `system contract`, it is also important to remember that not all system accounts contain a system contract, but each system account has important roles in the blockchain functionality, as follows:
 
 |Account|Privileged|Has contract|Description|
 |---|---|---|---|
-|eosio|Yes|It contains the `eosio.system` contract|The main system account on the EOS blockchain.|
+|eosio|Yes|It contains the `eosio.system` contract|The main system account on the Vaulta blockchain.|
 |eosio.msig|Yes|It contains the `eosio.msig` contract|Allows the signing of a multi-sig transaction proposal for later execution if all required parties sign the proposal before the expiration time.|
 |eosio.wrap|Yes|It contains the `eosio.wrap` contract.|Simplifies block producer superuser actions by making them more readable and easier to audit.|
-|eosio.token|No|It contains the `eosio.token` contract.|Defines the structures and actions allowing users to create, issue, and manage tokens on the EOS blockchain.|
+|eosio.token|No|It contains the `eosio.token` contract.|Defines the structures and actions allowing users to create, issue, and manage tokens on the Vaulta blockchain.|
 |eosio.names|No|No|The account which is holding funds from namespace auctions.|
 |eosio.bpay|No|No|The account that pays the block producers for producing blocks. It assigns 0.25% of the inflation based on the amount of blocks a block producer created in the last 24 hours.|
 |eosio.prods|No|No|The account representing the union of all current active block producers permissions.|
-|eosio.ram|No|No|The account that keeps track of the EOS balances based on users actions of buying or selling RAM.|
+|eosio.ram|No|No|The account that keeps track of the Vaulta balances based on users actions of buying or selling RAM.|
 |eosio.ramfee|No|No|The account that keeps track of the fees collected from users RAM trading actions: 0.5% from the value of each trade goes into this account.|
 |eosio.saving|No|No|The account which holds the 4% of network inflation.|
-|eosio.stake|No|No|The account that keeps track of all EOS tokens which have been staked for voting.|
+|eosio.stake|No|No|The account that keeps track of all Vaulta tokens which have been staked for voting.|
 |eosio.vpay|No|No|The account that pays the block producers accordingly with the votes won. It assigns 0.75% of inflation based on the amount of votes a block producer won in the last 24 hours.|
 |eosio.rex|No|No|The account that keeps track of fees and balances resulted from REX related actions execution.|

docs/01_key-concepts/02_system_resources.md

@@ -2,7 +2,7 @@
 title: System Resources
 ---
 
-The EOS blockchain works with three system resources: CPU, NET and RAM. The EOS accounts need sufficient system resources to interact with the smart contracts deployed on the blockchain.
+The Vaulta blockchain works with three system resources: CPU, NET and RAM. The Vaulta accounts need sufficient system resources to interact with the smart contracts deployed on the blockchain.
 
 * [RAM Resource](./05_ram.md)
 * [CPU Resource](./03_cpu.md)

docs/01_key-concepts/03_cpu.md

@@ -2,14 +2,14 @@
 title: CPU as system resource
 ---
 
-As NET and RAM, the CPU resource is a very important system resource in the EOS blockchain. The CPU system resource provides processing power to blockchain accounts. When the blockchain executes a transaction, it consumes CPU and NET. For transactions to complete, sufficient CPU must be allocated to the payer account. The amount of CPU an account has is measured in microseconds and it is referred to as `cpu bandwidth` on the `dune -- cleos get account` command output.
+As NET and RAM, the CPU resource is a very important system resource in the Vaulta blockchain. The CPU system resource provides processing power to blockchain accounts. When the blockchain executes a transaction, it consumes CPU and NET. For transactions to complete, sufficient CPU must be allocated to the payer account. The amount of CPU an account has is measured in microseconds and it is referred to as `cpu bandwidth` on the `cleos get account` command output.
 
 ## How Is CPU Calculated
 
-Transactions executed by the blockchain contain one or more actions. Each transaction must consume an amount of CPU within the limits predefined by the minimum and maximum transaction CPU usage values. For EOS blockchain these limits are set in the blockchain's configuration. You can find out these limits by running the following command and consult the `min_transaction_cpu_usage` and the `max_transaction_cpu_usage` which are expressed in microseconds:
+Transactions executed by the blockchain contain one or more actions. Each transaction must consume an amount of CPU within the limits predefined by the minimum and maximum transaction CPU usage values. For Vaulta blockchain these limits are set in the blockchain's configuration. You can find out these limits by running the following command and consult the `min_transaction_cpu_usage` and the `max_transaction_cpu_usage` which are expressed in microseconds:
 
 ```shell
-dune -- cleos get consensus_parameters
+cleos get consensus_parameters
 ```
 
 For accounts that execute transactions, the blockchain calculates and updates the remaining resources with each block before each transaction is executed. When a transaction is prepared for execution, the blockchain determines whether the payer account has enough CPU to cover the transaction execution. To calculate the necessary CPU, the node that actively builds the current block measures the time to execute the transaction. If the account has enough CPU, the transaction is executed; otherwise it is rejected. For technical details please refer to the following links:
@@ -21,7 +21,7 @@ For accounts that execute transactions, the blockchain calculates and updates th
 
 ## Subjective CPU Billing
 
-Subjective billing is an optional feature of the EOS blockchain. It allows nodes to bill account resources locally in their own node without sharing the billing with the rest of the network. Since its introduction, subjective billing benefited the nodes that adopted it because it reduced the node CPU usage by almost 90%. But it can result in failed transactions or lost transactions. Subjective billing can trigger transaction failure when a smart contract code uses a "check" function, like `assert()` or `check()` command to verify data. When this situation occurs, assert or check earlier in the system contract execution to reduce the applied billing. If the lack of an error message does not affect the user experience, a system contract may benefit by replacing some asserts and checks with a return statement. This replacement ensures their transactions succeed and are billed objectively on-chain.
+Subjective billing is an optional feature of the Vaulta blockchain. It allows nodes to bill account resources locally in their own node without sharing the billing with the rest of the network. Since its introduction, subjective billing benefited the nodes that adopted it because it reduced the node CPU usage by almost 90%. But it can result in failed transactions or lost transactions. Subjective billing can trigger transaction failure when a smart contract code uses a "check" function, like `assert()` or `check()` command to verify data. When this situation occurs, assert or check earlier in the system contract execution to reduce the applied billing. If the lack of an error message does not affect the user experience, a system contract may benefit by replacing some asserts and checks with a return statement. This replacement ensures their transactions succeed and are billed objectively on-chain.
 
 Find more details about subjective billing in the [Introduction to subjective billing and lost transactions](https://eosnetwork.com/blog/api-plus-an-introduction-to-subjective-billing-and-lost-transactions/) article.