diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index f991d18c..b68a63b0 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,14 +1,14 @@
-# Contributing to EOS Docs
+# Contributing to Vaulta Docs
First, the fact you're even here right now means you're awesome. Thanks!
Contributing can be as easy or as hard as you want it to be.
We're happy to accept anything from small typo corrections to entirely new documents.
-If you're looking for a place to start, consider [taking an item from our backlog](https://github.com/orgs/eosnetworkfoundation/projects/18/views/10)
+If you're looking for a place to start, consider [taking an item from our backlog](https://github.com/orgs/vaultafoundation/projects/18/views/10)
that doesn't have a `🔥 crit` priority (we usually take those in our upcoming iteration)
Some ways you can contribute:
-- [Reporting an issue](https://github.com/eosnetworkfoundation/docs/issues)
+- [Reporting an issue](https://github.com/vaultafoundation/docs/issues)
- [Creating new documents](#creating-a-new-document)
- Updating existing documents (same process as creating a new document)
@@ -24,7 +24,7 @@ Some ways you can contribute:
## Creating a new document
Here is the process for creating a new document:
-- [Fork the repository](https://github.com/eosnetworkfoundation/docs/fork)
+- [Fork the repository](https://github.com/vaultafoundation/docs/fork)
- Switch to the `staging` branch (`git checkout staging`)
- Create a new branch (`git checkout -b doc/my-new-document`)
- Create your document in the `native` or `evm`
diff --git a/LICENSE b/LICENSE
index 61f99775..a717011e 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,6 +1,6 @@
MIT License
-eosnetworkfoundation/docs
-Copyright (c) 2021-2022 EOS Network Foundation (ENF) and its contributors. All rights reserved.
+vaultafoundation/docs
+Copyright (c) 2021-2025 Vaulta Foundation (VF) and its contributors. All rights reserved.
This ENF software is based upon:
EOSIO/welcome
diff --git a/README.md b/README.md
index 32de2cea..df4160a8 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
# Welcome
-This repository contains the source of truth for the [EOS documentation site](http://docs.eosnetwork.com/welcome/latest/).
+This repository contains the source of truth for the [Vaulta documentation site](http://docs.vaulta.com/).
Interested in contributing? That's awesome!
[Here are some guidelines to get started quickly and easily](CONTRIBUTING.md).
diff --git a/evm/10_quick-start/01_introduction.md b/evm/10_quick-start/01_introduction.md
index fabd2484..9975a8c0 100644
--- a/evm/10_quick-start/01_introduction.md
+++ b/evm/10_quick-start/01_introduction.md
@@ -2,11 +2,11 @@
title: Introduction
---
-EOS EVM is a fully compatible Ethereum Virtual Machine (EVM) that runs on the EOS Network. This opens
-up the EOS Network to the entire Ethereum developer community and tooling.
+Vaulta EVM is a fully compatible Ethereum Virtual Machine (EVM) that runs on Vaulta. This opens
+up Vaulta to the entire Ethereum developer community and tooling.
-You can now take advantage of the EOS Network's high throughput and low latency by deploying and running
-smart contracts written for the EVM on the EOS Network.
+You can now take advantage of Vaulta's high throughput and low latency by deploying and running
+smart contracts written for the EVM on Vaulta.
## Features
diff --git a/evm/10_quick-start/02_setup-metamask.md b/evm/10_quick-start/02_setup-metamask.md
index f3d5b223..6b30b997 100644
--- a/evm/10_quick-start/02_setup-metamask.md
+++ b/evm/10_quick-start/02_setup-metamask.md
@@ -2,7 +2,7 @@
title: Setup MetaMask
---
-Click either of these buttons to instantly add EOS EVM to your MetaMask.
+Click either of these buttons to instantly add Vaulta EVM to your MetaMask.
@@ -21,7 +21,7 @@ manually with the information below.
### Mainnet
-* `Network Name`: EOS EVM
+* `Network Name`: Vaulta EVM
* `Chain ID`: 17777
* `New RPC URL`: https://api.evm.eosnetwork.com/
* `Currency Symbol`: EOS
@@ -30,7 +30,7 @@ manually with the information below.
### Testnet
-* `Network Name`: EOS EVM Testnet
+* `Network Name`: Vaulta EVM Testnet
* `Chain ID`: 15557
* `New RPC URL`: https://api.testnet.evm.eosnetwork.com/
* `Currency Symbol`: EOS
diff --git a/evm/10_quick-start/03_evm-tokens.md b/evm/10_quick-start/03_evm-tokens.md
index 480bbb4e..017946a4 100644
--- a/evm/10_quick-start/03_evm-tokens.md
+++ b/evm/10_quick-start/03_evm-tokens.md
@@ -2,14 +2,12 @@
title: EVM Tokens
---
-The `EOS` tokens on the `EOS EVM` are the exact same tokens as the ones on the `EOS Network`.
-
-This means that `EOS` tokens you see on exchanges are the same as the ones you use on `EOS EVM`. However, since most
-exchanges only support the native version of those tokens, you must *bridge* your tokens to use them on the EVM.
+The `Vaulta EVM` uses EOS tokens as the gas token.
+You can bridge those tokens from Vaulta to EOS and back again by using the `Vaulta EVM Bridge`.
## Testnet faucet
-Want some EOS tokens to play with? Click the button below to get some from the testnet faucet.
+Want some Vaulta EVM tokens to play with? Click the button below to get some from the testnet faucet.
@@ -19,59 +17,79 @@ import FaucetTokens from '@site/src/components/FaucetTokens/FaucetTokens';
-## Bridge from EOS to EOS EVM
+## Bridge from Vaulta to Vaulta EVM
### Bridge tokens yourself
-If you have **EOS** tokens on the `EOS Mainnet` or `Jungle Testnet`, you can send **EOS** directly to your EVM address.
-Open your wallet and send **EOS** tokens to `eosio.evmin` with your EVM address as the `memo`.
+If you have **Vaulta** tokens on Vaulta or Jungle Testnet, you will need to swap your Vaulta to EOS and then send
+**EOS** directly to your EVM address.
+
+> âš **Disclaimer:**
+>
+> If you have Vaulta tokens and need EOS tokens you can send your Vaulta tokens to `core.vaulta` and it will be swapped and sent back to you.
+Open your wallet and send **EOS** tokens to `eosio.evmin` with your EVM address as the `memo`.
### Bridge tokens from an exchange
+Depending on whether the exchange supports Vaulta or EOS you might have to swap your tokens.
+
> âš **Disclaimer:**
>
> Not all exchanges support sending tokens to a smart contract. Depending on the exchange you are using you might need
> to first send the tokens to your own wallet and then follow the directions in the previous section.
-To withdraw EOS tokens from a centralized exchange (CEX) to an EOS EVM address:
+To withdraw EOS tokens from a centralized exchange (CEX) to a Vaulta EVM address:
1. Visit the withdrawal screen of the Exchange's app
2. Select EOS as Coin
3. Select EOS as Network
-4. Enter `eosio.evmin` as Wallet Address
-5. Enter your EOS EVM public key as Memo
+4. Open your wallet and transfer your EOS tokens
+ 1. Enter `eosio.evmin` as Wallet Address
+ 2. Enter your Vaulta EVM public key as Memo
-
+
+To withdraw Vaulta tokens from a centralized exchange (CEX) to a Vaulta EVM address:
+1. Visit the withdrawal screen of the Exchange's app
+2. Select `A` as Coin
+3. Select Vaulta as Network
+4. Swap your Vaulta tokens to EOS
+ 1. Send Vaulta tokens to `core.vaulta` to get EOS
+5. Open your wallet and transfer your EOS tokens
+ 1. Enter `eosio.evmin` as Wallet Address
+ 2. Enter your Vaulta EVM public key as Memo
-## Bridge from EOS EVM to EOS
+## Bridge from Vaulta EVM to Vaulta
### Bridge tokens yourself
-To transfer tokens from an EVM address to an EOS account you must use the [EOS EVM Mainnet Bridge](https://bridge.evm.eosnetwork.com/)
-or the [EOS EVM Jungle Testnet Bridge](https://bridge.testnet.evm.eosnetwork.com/).
+To transfer tokens from an EVM address to a Vaulta account you must use the [Vaulta EVM Mainnet Bridge](https://bridge.evm.eosnetwork.com/)
+or the [Vaulta EVM Jungle Testnet Bridge](https://bridge.testnet.evm.eosnetwork.com/).
1. Select `Withdraw`
2. Connect your wallet
3. Enter an amount
-4. Enter an EOS account to send to
-1. Add an optional memo
-5. Click `Transfer`
+4. Enter a Vaulta account to send to
+5. Add an optional memo
+6. Click `Transfer`
+
+At this point, if you need Vaulta you can swap back:
+1. Send your EOS tokens to `core.vaulta`
+2. This will send back the same amount of Vaulta tokens to your account
### Bridge tokens to an exchange
> âš **Disclaimer:**
>
-> Some exchanges do not yet support tracking inline transfers on EOS, which prevents them from seeing EOS EVM transfers.
-> If you are in doubt whether your exchange supports this, first bridge tokens to the native EOS Network, and then send them
-> to your exchange account.
+> Some exchanges do not yet support tracking inline transfers on Vaulta, which prevents them from seeing Vaulta EVM transfers.
+> If you are in doubt whether your exchange supports this, first bridge tokens to the native Vaulta network, and then send them to your exchange account.
-You can follow the same process as above, but instead of entering an EOS account, enter your exchange account name.
+You can follow the same process as above, but instead of entering an Vaulta account, enter your exchange account name.
-Most EOS exchanges also require a `memo` field, so make sure you enter it there **or your tokens will be lost**.
+Most exchanges also require a `memo` field, so make sure you enter it there **or your tokens will be lost**.
@@ -82,7 +100,7 @@ Most EOS exchanges also require a `memo` field, so make sure you enter it there
## Important ERC-20 tokens
-There are a few ERC-20 tokens that are available on the `EOS EVM` which serve as core components of apps and defi.
+There are a few ERC-20 tokens that are available on the `Vaulta EVM` which serve as core components of apps and defi.
### Wrapped EOS
diff --git a/evm/10_quick-start/10_endpoints.md b/evm/10_quick-start/10_endpoints.md
index 568627e5..335b5dc0 100644
--- a/evm/10_quick-start/10_endpoints.md
+++ b/evm/10_quick-start/10_endpoints.md
@@ -2,18 +2,13 @@
title: Endpoints
---
-EOS EVM Endpoints
+Vaulta EVM Endpoints
| Network | RPC URL | Chain ID |
| --- |--------------------|----------|
| Mainnet | [api.evm.eosnetwork.com](https://api.evm.eosnetwork.com) | 17777 |
| Testnet | [api.testnet.evm.eosnetwork.com](https://api.testnet.evm.eosnetwork.com) | 15557 |
-> đź’° **Premium APIs:**
->
-> If you're looking for premium API services you can join the
-> [EOS Servers](https://t.me/eosservers) Telegram group where you can find premium API providers.
-
## Explorers
| Network | Explorer URL |
diff --git a/evm/15_core-concepts/02_gas.md b/evm/15_core-concepts/02_gas.md
index fd5aad7f..76a29088 100644
--- a/evm/15_core-concepts/02_gas.md
+++ b/evm/15_core-concepts/02_gas.md
@@ -14,5 +14,5 @@ on [EVM Codes](https://www.evm.codes/).
If the transaction runs out of gas before it completes, then the transaction will fail and all changes will be reverted,
but the gas spent will not be refunded.
-> **Note**: EOS EVM's gas price is fixed. It is currently set at `150000000000`.
+> **Note**: Vaulta EVM's gas price is fixed. It is currently set at `150000000000`.
>
diff --git a/evm/20_smart-contracts/01_contract-anatomy.md b/evm/20_smart-contracts/01_contract-anatomy.md
index 2ef374db..5e2d0c24 100644
--- a/evm/20_smart-contracts/01_contract-anatomy.md
+++ b/evm/20_smart-contracts/01_contract-anatomy.md
@@ -44,7 +44,7 @@ contract MyContract {
> âš **PUSH0 opcode**
>
-> Currently the EOS EVM does not support the `PUSH0` opcode. This means you must use a version less than `0.8.20` for your Solidity compiler.
+> Currently the Vaulta EVM does not support the `PUSH0` opcode. This means you must use a version less than `0.8.20` for your Solidity compiler.
### License identifier
diff --git a/evm/20_smart-contracts/02_functions.md b/evm/20_smart-contracts/02_functions.md
index b686a13b..48014abb 100644
--- a/evm/20_smart-contracts/02_functions.md
+++ b/evm/20_smart-contracts/02_functions.md
@@ -136,7 +136,7 @@ function myFunction() public myModifier1 myModifier2 {}
Functions can accept the native currency of the blockchain as payment. This is done by declaring the function as `payable`.
-In the case of the EOS EVM, this is EOS.
+In the case of the Vaulta EVM, this is EOS.
```solidity
function myFunction() public payable {
diff --git a/evm/20_smart-contracts/20_migrate-your-smart-contract.md b/evm/20_smart-contracts/20_migrate-your-smart-contract.md
index ef995ca9..5789d957 100644
--- a/evm/20_smart-contracts/20_migrate-your-smart-contract.md
+++ b/evm/20_smart-contracts/20_migrate-your-smart-contract.md
@@ -2,11 +2,11 @@
title: Migrate your Smart Contract
---
-This guide will teach you to deploy a smart contract to the EOS EVM using hardhat on both the EOS EVM mainnet and testnet.
+This guide will teach you to deploy a smart contract to the Vaulta EVM using hardhat on both the Vaulta EVM mainnet and testnet.
## Set up your MetaMask
-Click either of these buttons to instantly add EOS EVM to your MetaMask.
+Click either of these buttons to instantly add Vaulta EVM to your MetaMask.
@@ -32,9 +32,12 @@ import FaucetTokens from '@site/src/components/FaucetTokens/FaucetTokens';
If you're on the testnet, you can get some EOS tokens using the [**testnet faucet**](https://faucet.testnet.evm.eosnetwork.com/).
-If you're on the EOS Mainnet, ]you can transfer your native EOS using a standard EOS transfer:
+If you're on the Vaulta Mainnet, ]you can transfer your native EOS using a standard EOS transfer:
- Send tokens to: `eosio.evm`
-- Set the `memo` to your EOS EVM address
+- Set the `memo` to your Vaulta EVM address
+
+> ⚠️ **Important**
+> If you have only Vaulta, you will need to swap it to EOS. See the EVM tokens page below for more information.
For more ways to get EOS tokens, check out the [EVM Tokens](/evm/10_quick-start/03_evm-tokens.md) page.
@@ -52,11 +55,11 @@ const config: HardhatUserConfig = {
// ...
networks: {
- eosevm: {
+ vaulta_evm: {
url: "https://api.evm.eosnetwork.com",
accounts:[process.env.PRIVATE_KEY],
},
- eosevm_testnet: {
+ vaulta_evm_testnet: {
url: "https://api.testnet.evm.eosnetwork.com",
accounts:[process.env.PRIVATE_KEY],
}
@@ -75,13 +78,13 @@ const config: HardhatUserConfig = {
## Deploying your contract
-Now you can deploy your contract to the EOS EVM testnet:
+Now you can deploy your contract to the Vaulta EVM testnet:
```bash
-npx hardhat run scripts/deploy.js --network eosevm
+npx hardhat run scripts/deploy.js --network vaulta_evm
// or for testnet
-npx hardhat run scripts/deploy.js --network eosevm_testnet
+npx hardhat run scripts/deploy.js --network vaulta_evm_testnet
```
Once deployed, you will see the address of your new contract, and can view it an explorer by pasting it
@@ -94,10 +97,10 @@ into the search field.
## Congratulations!
-You have successfully deployed your first smart contract to the EOS EVM! 🎉
+You have successfully deployed your first smart contract to the Vaulta EVM! 🎉
If you already have a front-end application that interacts with your smart contract, you can now point it at the
-[EOS EVM Endpoints](/evm/999_miscellaneous/10_endpoints.md), and it will work as expected.
+[Vaulta EVM Endpoints](/evm/999_miscellaneous/10_endpoints.md), and it will work as expected.
Make sure you visit the [**Compatibility**](/evm/999_miscellaneous/20_evm-compatibility.md) section to learn about the differences between
-the EOS EVM and Ethereum, and how to make sure your web3 application works on the EOS EVM as expected.
+the Vaulta EVM and Ethereum, and how to make sure your web3 application works on the Vaulta EVM as expected.
diff --git a/evm/20_smart-contracts/30_develop-with-remix.md b/evm/20_smart-contracts/30_develop-with-remix.md
index 25373588..1bde4a90 100644
--- a/evm/20_smart-contracts/30_develop-with-remix.md
+++ b/evm/20_smart-contracts/30_develop-with-remix.md
@@ -2,7 +2,7 @@
title: Develop with Remix
---
-Remix is a web-based IDE that allows you to write, compile, and deploy smart contracts to the EOS EVM.
+Remix is a web-based IDE that allows you to write, compile, and deploy smart contracts to the Vaulta EVM.
## Learning the interface
@@ -127,7 +127,7 @@ In our contract, we defined two functions:
## Compiling your smart contract
-Now that we have written our smart contract, we need to compile it so that we can deploy it to the EOS EVM.
+Now that we have written our smart contract, we need to compile it so that we can deploy it to the Vaulta EVM.
Click on the `Solidity Compiler` icon in the sidebar.
@@ -145,7 +145,7 @@ If your contract has any errors, you will see a red box on the sidebar for each
## Deploying your smart contract
-Now that we have compiled our smart contract, we can deploy it to the EOS EVM.
+Now that we have compiled our smart contract, we can deploy it to the Vaulta EVM.
Click on the `Deploy & Run Transactions` icon in the sidebar.
@@ -153,7 +153,7 @@ Then click on the `ENVIROMENT` dropdown and select `Injected Provider - MetaMask
> âť• **Set up your MetaMask first!**
>
-> If you haven't already, make sure you have set up your MetaMask wallet and connected it to the EOS EVM.
+> If you haven't already, make sure you have set up your MetaMask wallet and connected it to the Vaulta EVM.
>
> **You can follow [this guide](/evm/10_quick-start/02_setup-metamask.md) to learn how to do that.**
@@ -163,7 +163,7 @@ MetaMask will pop up and ask you to connect an account.
-You can now click the `Deploy` button to deploy your smart contract to the EOS EVM.
+You can now click the `Deploy` button to deploy your smart contract to the Vaulta EVM.
This will open up a MetaMask popup asking you to confirm the transaction.
@@ -239,7 +239,7 @@ in the `Solidity Compiler` tab.
**Congratulations!**
-You have now successfully deployed and interacted with your first smart contract on the EOS EVM!
+You have now successfully deployed and interacted with your first smart contract on the Vaulta EVM!
You learned about smart contract basics, setting up MetaMask, and using Remix to develop, deploy, and interact with
your smart contract.
diff --git a/evm/23_advanced-guides/20_using-multicall3.md b/evm/23_advanced-guides/20_using-multicall3.md
index 363e9028..608f7642 100644
--- a/evm/23_advanced-guides/20_using-multicall3.md
+++ b/evm/23_advanced-guides/20_using-multicall3.md
@@ -2,7 +2,7 @@
title: Using Multicall3
---
-Multicall3 is a contract deployed to the EOS EVM that allows you to batch multiple calls into a single call. This means
+Multicall3 is a contract deployed to the Vaulta EVM that allows you to batch multiple calls into a single call. This means
that you can make multiple calls to one or more contracts in a single transaction.
This is useful for reducing the number of transactions you need to make to either read or write data. For instance, if
diff --git a/evm/23_advanced-guides/30_inscriptions.md b/evm/23_advanced-guides/30_inscriptions.md
index 849cb88b..db34466d 100644
--- a/evm/23_advanced-guides/30_inscriptions.md
+++ b/evm/23_advanced-guides/30_inscriptions.md
@@ -12,7 +12,7 @@ This means that inscriptions are only useful for indexing and other off-chain pu
## Gas fees, throughput, and inscriptions
On the majority of other EVM supporting chains, inscriptions has caused massive upward pressure on gas fees, as well as
-degradation of throughput. However, on EOS EVM the gas fee is fixed, and the chain is more than capable of handling the
+degradation of throughput. However, on Vaulta EVM the gas fee is fixed, and the chain is more than capable of handling the
load of inscriptions without any noticeable impact on throughput.
### Want to test inscriptions?
diff --git a/evm/25_configure-tooling/10_ethers.md b/evm/25_configure-tooling/10_ethers.md
index 1404bcbf..069321f6 100644
--- a/evm/25_configure-tooling/10_ethers.md
+++ b/evm/25_configure-tooling/10_ethers.md
@@ -6,7 +6,7 @@ title: Ethers
[Ethers](https://github.com/ethers-io/ethers.js) is by far the most used JavaScript SDK for EVM.
-Using Ethers with EOS EVM is the same as using it with any other EVM compatible chain.
+Using Ethers with Vaulta EVM is the same as using it with any other EVM compatible chain.
One thing to note is that as of writing this doc, our RPC endpoint does not support batch requests, so you must disable
batching when creating your provider:
diff --git a/evm/25_configure-tooling/20_hardhat.md b/evm/25_configure-tooling/20_hardhat.md
index bf896a57..fd7e497c 100644
--- a/evm/25_configure-tooling/20_hardhat.md
+++ b/evm/25_configure-tooling/20_hardhat.md
@@ -4,7 +4,7 @@ title: Hardhat
[Hardhat](https://hardhat.org/) is the most widely used development environment for Ethereum smart contracts.
-If you want to deploy your smart contracts to the EOS EVM using hardhat, update your `hardhat.config.js` file
+If you want to deploy your smart contracts to the Vaulta EVM using hardhat, update your `hardhat.config.js` file
with the following network configuration:
```javascript
@@ -13,11 +13,11 @@ const config: HardhatUserConfig = {
// ...
networks: {
- eosevm: {
+ vaulta_evm: {
url: "https://api.evm.eosnetwork.com",
accounts:[process.env.PRIVATE_KEY],
},
- eosevm_testnet: {
+ vaulta_evm_testnet: {
url: "https://api.testnet.evm.eosnetwork.com",
accounts:[process.env.PRIVATE_KEY],
}
@@ -28,8 +28,8 @@ const config: HardhatUserConfig = {
Now you can deploy your contract to either the mainnet or the testnet using:
```bash
-npx hardhat run scripts/deploy.js --network eosevm
+npx hardhat run scripts/deploy.js --network vaulta_evm
// or for testnet
-npx hardhat run scripts/deploy.js --network eosevm_testnet
+npx hardhat run scripts/deploy.js --network vaulta_evm_testnet
```
diff --git a/evm/25_configure-tooling/30_truffle.md b/evm/25_configure-tooling/30_truffle.md
index 9389e64d..0e507263 100644
--- a/evm/25_configure-tooling/30_truffle.md
+++ b/evm/25_configure-tooling/30_truffle.md
@@ -2,7 +2,7 @@
title: Truffle
---
-Modify your `truffle-config.js` to add the EOS EVM to [Truffle](https://www.trufflesuite.com/):
+Modify your `truffle-config.js` to add the Vaulta EVM to [Truffle](https://www.trufflesuite.com/):
```javascript
require('dotenv').config();
@@ -10,11 +10,11 @@ const HDWalletProvider = require('@truffle/hdwallet-provider');
module.exports = {
networks: {
- eosevm: {
+ vaulta_evm: {
provider: new HDWalletProvider([process.env.PRIVATE_KEY], "https://api.evm.eosnetwork.com"),
network_id: 17777,
},
- eosevm_testnet: {
+ vaulta_evm_testnet: {
provider: new HDWalletProvider([process.env.PRIVATE_KEY], "https://api.testnet.evm.eosnetwork.com"),
network_id: 15557,
},
diff --git a/evm/30_miners-and-nodes/10_transaction-miner.md b/evm/30_miners-and-nodes/10_transaction-miner.md
index 10fdbddd..2e3c0bf0 100644
--- a/evm/30_miners-and-nodes/10_transaction-miner.md
+++ b/evm/30_miners-and-nodes/10_transaction-miner.md
@@ -2,16 +2,16 @@
title: Transaction Miner
---
-The EOS EVM transaction miner is a simple transaction relay that allows you to take Ethereum formatted transactions and
-push them to the EOS EVM contract on an EOS Native node.
+The Vaulta EVM transaction miner is a simple transaction relay that allows you to take Ethereum formatted transactions and
+push them to the Vaulta EVM contract on an Vaulta Native node.
## Your miner account
-You will need an EOS Network account which will serve as your **miner account**.
+You will need a Vaulta account which will serve as your **miner account**.
-The EOS EVM Miner software takes the EVM transactions that it receives and converts them into EOS transactions which it then sends
-to the `eosio.evm` contract on the native EOS Network.
+The Vaulta EVM Miner software takes the EVM transactions that it receives and converts them into Vaulta transactions which it then sends
+to the `eosio.evm` contract on the native Vaulta Network.
As a relay of these transactions you have the opportunity to earn rewards for the service you provide.
@@ -26,17 +26,17 @@ without interruption.
> âť” **RAM is not required**
>
> Your miner account does not deplete RAM resources as it relays transactions. It only consumes CPU and NET resources.
-> The `eosio.evm` contract pays for the RAM that the EOS EVM uses through the fees it collects from the EVM transactions.
+> The `eosio.evm` contract pays for the RAM that the Vaulta EVM uses through the fees it collects from the EVM transactions.
### Registering your miner
Once you have your miner account, you will need to register it with the `eosio.evm` contract.
```bash
-cleos -u https://eos.greymass.com/ push action eosio.evm open '[""]' -p
+cleos -u https://vaulta.greymass.com/ push action eosio.evm open '[""]' -p
```
-If you'd like to register using a web interface you can visit [bloks.io](https://bloks.io/account/eosio.evm?loadContract=true&tab=Actions&account=eosio.evm&scope=eosio.evm&limit=100&action=open)
+If you'd like to register using a web interface you can visit [Unicove](https://unicove.com/en/eos/contract/eosio.evm/actions/open)
and sign the transaction using a wallet like [Anchor](https://www.greymass.com/anchor).
### Viewing your mining rewards
@@ -48,7 +48,7 @@ getting the table rows from the contract's `balances` table with the upper and l
cleos -u https://eos.greymass.com/ get table eosio.evm eosio.evm balances -U -L
```
-You can also view the same data on [bloks.io](https://bloks.io/account/eosio.evm?loadContract=true&tab=Tables&account=eosio.evm&scope=eosio.evm&limit=100&table=balances)
+You can also view the same data on [Unicove](https://unicove.com/en/eos/contract/eosio.evm/tables/balances)
### Withdrawing your mining rewards
@@ -60,7 +60,7 @@ time by sending a transaction to the `eosio.evm` contract with the following act
cleos -u https://eos.greymass.com/ push action eosio.evm withdraw '["", "1.0000 EOS"]' -p
```
-If you'd like to claim using a web interface you can visit [bloks.io](https://bloks.io/account/eosio.evm?loadContract=true&tab=Actions&account=eosio.evm&scope=eosio.evm&limit=100&table=balances&action=withdraw)
+If you'd like to claim using a web interface you can visit [Unicove](https://unicove.com/en/eos/contract/eosio.evm/actions/withdraw)
and sign the transaction using a wallet like [Anchor](https://www.greymass.com/anchor).
@@ -75,7 +75,7 @@ The recommended version is [`18.16.0`](https://nodejs.org/en/download), and the
#### Get the miner from GitHub and inst all dependencies
```bash
-git clone https://github.com/eosnetworkfoundation/eos-evm-miner.git
+git clone https://github.com/vaultafoundation/eos-evm-miner.git
cd eos-evm-miner
yarn
```
@@ -86,10 +86,10 @@ Copy the `.env.example` file to `.env` and fill in the environment variables.
| Name | Description | Default |
| --- |-------------------------------------------------------------------------------------------------------------------|---------|
| `PRIVATE_KEY` | The private key of the miner account | |
-| `MINER_ACCOUNT` | The name of the miner account on the EOS Network | |
-| `RPC_ENDPOINTS` | A list of EOS RPC endpoints to connect to, comma-delimited | |
+| `MINER_ACCOUNT` | The name of the miner account on the Vaulta Network | |
+| `RPC_ENDPOINTS` | A list of Vaulta RPC endpoints to connect to, comma-delimited | |
| `PORT` | The port to listen on for incoming Ethereum transactions | `50305` |
-| `LOCK_GAS_PRICE` | If set to `true`, one a gas price is set, this miner will not hit the EOS API node again to fetch a new gas price | `true` |
+| `LOCK_GAS_PRICE` | If set to `true`, one a gas price is set, this miner will not hit the Vaulta API node again to fetch a new gas price | `true` |
diff --git a/evm/30_miners-and-nodes/index.md b/evm/30_miners-and-nodes/index.md
index 5580267a..ba06c910 100644
--- a/evm/30_miners-and-nodes/index.md
+++ b/evm/30_miners-and-nodes/index.md
@@ -1,4 +1,4 @@
---
-title: Running EOS EVM Nodes
+title: Running Vaulta EVM Nodes
sidebar_class_name: sidebarhidden
---
diff --git a/evm/40_architecture/10_architecture.md b/evm/40_architecture/10_architecture.md
index 8698bdb4..838188a3 100644
--- a/evm/40_architecture/10_architecture.md
+++ b/evm/40_architecture/10_architecture.md
@@ -2,58 +2,58 @@
title: Overview
---
-The EOS EVM implements a smart contract which runs on the EOS network, we shall call it form this point forward the
-`EVM Contract`. To send transactions to the EOS EVM network one has to send transactions to the EVM Contract.
-The EOS EVM Contract is fully compatible with the Ethereum EVM except for some small differences which can be
+The Vaulta EVM implements a smart contract which runs on Vaulta, we shall call it form this point forward the
+`EVM Contract`. To send transactions to the Vaulta EVM network one has to send transactions to the EVM Contract.
+The Vaulta EVM Contract is fully compatible with the Ethereum EVM except for some small differences which can be
consulted in the [EVM Compatibility](/evm/999_miscellaneous/20_evm-compatibility.md) section.
-To achieve the complete RPC compatibility, a full functioning Ethereum node is utilized. The EOS EVM testnet and mainnet
-use an Ethereum node built on top of Silkworm node, we shall call it from this point forward the `EOS EVM Node`.
+To achieve the complete RPC compatibility, a full functioning Ethereum node is utilized. The Vaulta EVM testnet and mainnet
+use an Ethereum node built on top of Silkworm node, we shall call it from this point forward the `Vaulta EVM Node`.
-All the RPC requests, reads and writes, sent by the EOS EVM clients, are first processed by a proxy component, which
+All the RPC requests, reads and writes, sent by the Vaulta EVM clients, are first processed by a proxy component, which
redirects the requests as follows:
-- the reads to the EOS EVM RPC component, and
+- the reads to the Vaulta EVM RPC component, and
- the writes to the Transaction Wrapper service.
### The Read Requests
-The JSON-RPC read requests are supported by the EOS EVM RPC component which is a fork of
+The JSON-RPC read requests are supported by the Vaulta EVM RPC component which is a fork of
[SilkRPC](https://github.com/torquem-ch/silkrpc) and implemented as a daemon that supports nearly all of the Ethereum
-JSON-RPC for the virtual EVM blockchain managed by the EOS EVM Contract. Two of the RPC methods, `eth_sendRawTransaction`
+JSON-RPC for the virtual EVM blockchain managed by the Vaulta EVM Contract. Two of the RPC methods, `eth_sendRawTransaction`
and `eth_gasPrice` are intentionally disabled because it is not appropriate for this daemon to handle them. Instead requests
for the two methods are routed to the Transaction Wrapper service which is designed specifically to support those two RPC methods.
-The EOS EVM RPC component relies on the database managed by an execution client for (virtual) EVM blockchain. The execution
-client is the EOS EVM Node component, which is a fork of [Silkworm](https://github.com/torquem-ch/silkworm) modified to work
-with the changes to the EVM runtime that are needed to support the EOS EVM, e.g. the trustless bridge.
+The Vaulta EVM RPC component relies on the database managed by an execution client for (virtual) EVM blockchain. The execution
+client is the Vaulta EVM Node component, which is a fork of [Silkworm](https://github.com/torquem-ch/silkworm) modified to work
+with the changes to the EVM runtime that are needed to support the Vaulta EVM, e.g. the trustless bridge.
-The EOS EVM Node needs to reproduce exactly the EVM transaction execution that was first done by the EOS EVM Contract.
-It needs to reconstruct the virtual EVM blockchain that is managed by the EOS EVM Contract using data extracted from the
-EOS blockchain. To facilitate this, EOS EVM Node connects to a state history plugin (SHiP) endpoint of an EOS node which
-is part of the EOS blockchain.
+The Vaulta EVM Node needs to reproduce exactly the EVM transaction execution that was first done by the Vaulta EVM Contract.
+It needs to reconstruct the virtual EVM blockchain that is managed by the Vaulta EVM Contract using data extracted from the
+Vaulta blockchain. To facilitate this, Vaulta EVM Node connects to a state history plugin (SHiP) endpoint of an Vaulta node which
+is part of the Vaulta blockchain.
This architecture makes possible to expose the Ethereum client Web3 JSON RPC APIs and potentially other APIs if necessary.
### The Write Requests
-As mentioned earlier, the two RPC methods, `eth_sendRawTransaction` and `eth_gasPrice`, are not implemented by EOS EVM RPC.
+As mentioned earlier, the two RPC methods, `eth_sendRawTransaction` and `eth_gasPrice`, are not implemented by Vaulta EVM RPC.
Instead they are implemented by the `Transaction Wrapper` (in the below diagram `Tx Wrapper`) component. Therefore, all
-the *write requests* are forwarded to the Transaction Wrapper, which packs them into EOS actions and sends them to the EVM Contract.
+the *write requests* are forwarded to the Transaction Wrapper, which packs them into Vaulta actions and sends them to the EVM Contract.
The primary purpose of the Transaction Wrapper is to take raw EVM transactions via `eth_sendRawTransaction` and push
-them to the EOS EVM Contract.
+them to the Vaulta EVM Contract.
It accomplishes this through the following steps:
-1. Constructs an EOS transaction which contains the `pushtx` action of the EOS EVM Contract which includes the rlp-encoded EVM transaction.
-2. Sings the EOS transaction with the key of an EOS account that acts as the miner of the `pushtx` action and pays the CPU/NET costs of the EOS transaction.
-3. Sends the signed EOS transaction to the EOS blockchain via the chain API of an EOS node connected to the EOS network.
+1. Constructs an Vaulta transaction which contains the `pushtx` action of the Vaulta EVM Contract which includes the rlp-encoded EVM transaction.
+2. Sings the Vaulta transaction with the key of an Vaulta account that acts as the miner of the `pushtx` action and pays the CPU/NET costs of the Vaulta transaction.
+3. Sends the signed Vaulta transaction to the Vaulta blockchain via the chain API of a Vaulta node connected to the Vaulta network.
Transaction Wrapper also supports the `eth_gasPrice` RPC method, despite the fact that it is a read method, because its
-implementation also depends on access to the chain API of an EOS node. In particular, it simply grabs the minimum gas price
-configured in the EOS EVM Contract from the appropriate table and returns it to the caller.
+implementation also depends on access to the chain API of a Vaulta node. In particular, it simply grabs the minimum gas price
+configured in the Vaulta EVM Contract from the appropriate table and returns it to the caller.
-
+
This architecture allows the possibility for other implementations of Ethereum nodes to be used if it is deemed necessary
for some specific scenarios.
diff --git a/evm/40_architecture/20_token-economy.md b/evm/40_architecture/20_token-economy.md
index 097a18d3..198ee23b 100644
--- a/evm/40_architecture/20_token-economy.md
+++ b/evm/40_architecture/20_token-economy.md
@@ -3,32 +3,32 @@ title: Token Economy
---
All EVMs require a native token to cover the transaction fee, also known as the gas fee.
-The EOS EVM native token is the EOS token.
+The Vaulta EVM native token is the EOS token.
-## EOS EVM Bridge
+## Vaulta EVM Bridge
-Interoperability is a key part of the EOS EVM design. Therefore the EVM design allows the economic value to flow freely
+Interoperability is a key part of the Vaulta EVM design. Therefore the EVM design allows the economic value to flow freely
between the native and EVM layers. This is where the EVM’s trustless bridge comes into play.
-
+
-With the trustless bridge, users do not have to rely on third-party oracles to move tokens from EOS native to EOS EVM.
-Instead, they can simply send their tokens to the EOS EVM Contract, eosio.evm, and enter the address of their EOS EVM
+With the trustless bridge, users do not have to rely on third-party oracles to move tokens from Vaulta to Vaulta EVM.
+Instead, they can simply send their tokens to the Vaulta EVM Contract, eosio.evm, and enter the address of their Vaulta EVM
wallet in the memo field. This will move the asset from the native layer to the designated address on the EVM. When a
-user would like to move assets back to EOS native, the bridge allows an EVM transaction to trigger a transfer of EOS
-from the EOS EVM Contract to the user-specified EOS native account with an optional memo. The bridge frontend makes it
+user would like to move assets back to Vaulta native, the bridge allows an EVM transaction to trigger a transfer of EOS
+from the Vaulta EVM Contract to the user-specified Vaulta native account with an optional memo. The bridge frontend makes it
easy for users to construct these types of EVM transactions.
### Bridge Fee Break-Down
All EVM transactions, which includes outgoing bridge transfers, require the user to pay gas fees. These fees cover the
regular costs of the system, which are described in further detail in the next section that discusses
-the [EOS EVM Gas Model](#eos-evm-gas-model).
+the [Vaulta EVM Gas Model](#eos-evm-gas-model).
-However, an incoming bridge transfer starts as an EOS transaction which then causes the EOS EVM Contract to internally
-generate an EVM transaction. The internal EVM transaction incurs a cost, and because it was generated by the EOS EVM
+However, an incoming bridge transfer starts as an Vaulta transaction which then causes the Vaulta EVM Contract to internally
+generate an EVM transaction. The internal EVM transaction incurs a cost, and because it was generated by the Vaulta EVM
Contract, there is no mechanism for the user to directly pay for the gas fees of that internal transaction. Instead,
-the EOS EVM Contract covers the costs of that internal EVM transaction by deducting a small bridge fee from the incoming
+the Vaulta EVM Contract covers the costs of that internal EVM transaction by deducting a small bridge fee from the incoming
transfer amount. To avoid user confusion from a potentially volatile bridge fee, the bridge fee, while still configurable,
is not directly coupled to the actual gas fee calculated. Instead, it is configured so that the system remains profitable
on average. At launch, a bridge fee of 0.01 EOS per incoming bridge transfer is configured. But a static bridge fee and
@@ -37,48 +37,48 @@ Externally Owned Accounts as the destination.
Furthermore, while an EVM transaction, that executes an outgoing bridge transfer, requires the collection of gas fees,
the gas fee only covers the computational costs incurred with the EVM. An outgoing bridge transfer can in general trigger
-arbitrary EOS native smart contract code to execute at the destination account, and none of this additional computation
+arbitrary Vaulta native smart contract code to execute at the destination account, and none of this additional computation
cost is accounted for in the calculated gas fees. For this reason, outgoing bridge transfers can be sent to at most one
-external EOS account per EVM transaction. That account must either not have a contract deployed on it or it must be on a
+external Vaulta account per EVM transaction. That account must either not have a contract deployed on it or it must be on a
special egress allow list.
It is possible for a single EVM transaction to have multiple outgoing bridge transfers to different accounts. However,
-this requires using the more advanced functionality within the EOS EVM Contract where the destination account(s) first
-open an internal balance within the EOS EVM Contract and at later point in time withdraw funds collected within that
-balance to their external EOS accounts.
+this requires using the more advanced functionality within the Vaulta EVM Contract where the destination account(s) first
+open an internal balance within the Vaulta EVM Contract and at later point in time withdraw funds collected within that
+balance to their external Vaulta accounts.
### User Experience for EVM Users
-The trustless bridge also removes a prominent barrier for users coming to EOS EVM from other EVM based ecosystems.
-That is the need to create an EOS native account. While not difficult, the process is foreign to those who are used
+The trustless bridge also removes a prominent barrier for users coming to Vaulta EVM from other EVM based ecosystems.
+That is the need to create a Vaulta native account. While not difficult, the process is foreign to those who are used
to interact with the blockchain through an Ethereum wallet such as MetaMask. Additionally, there is an added cost
-associated with creating an EOS native account that creates added friction for the end user.
+associated with creating a Vaulta native account that creates added friction for the end user.
-To solve this, if a user only wishes to interact with EOS EVM, they can simply generate a free address in an application
-like MetaMask and connect it to the EVM. Then, they are able to purchase EOS native tokens on an exchange and send it
-in and out of the EOS EVM through utilizing the trustless bridge. This makes for a seamless user experience, where the
-end user is not required to interact with EOS native at all.
+To solve this, if a user only wishes to interact with Vaulta EVM, they can simply generate a free address in an application
+like MetaMask and connect it to the EVM. Then, they are able to purchase Vaulta tokens on an exchange and send it
+in and out of the Vaulta EVM through utilizing the trustless bridge. This makes for a seamless user experience, where the
+end user is not required to interact with Vaulta native at all.
-## EOS EVM Gas Model
+## Vaulta EVM Gas Model
-The gas model is another important part of the EOS EVM economy. All EVMs require a native token to cover the transaction
+The gas model is another important part of the Vaulta EVM economy. All EVMs require a native token to cover the transaction
fee, also known as the gas fee. On the Ethereum network this would be ETH. The EOS token serves as the gas token for the
-EVM. This ensures a simplistic design, while bringing added utility to the EOS token.
+EVM. This ensures a simplistic design, while bringing added utility to the EOS token (and through that, the Vaulta token).
### Gas Fees Calculation
-Because the EOS EVM Contract runs on the EOS blockchain, regardless of what happens within the EVM, ultimately EOS native
-resources such as RAM, CPU, and NET are being leveraged. The resource models of EVM and EOS native are quite different
+Because the Vaulta EVM Contract runs on the Vaulta blockchain, regardless of what happens within the EVM, ultimately Vaulta native
+resources such as RAM, CPU, and NET are being leveraged. The resource models of EVM and Vaulta native are quite different
which makes the mapping between them tricky, especially in regards to the cost of persistent contract storage.
-EOS native uses an ownership model for RAM in which ownership of RAM tokens represent entitlements to a corresponding
+Vaulta native uses an ownership model for RAM in which ownership of RAM tokens represent entitlements to a corresponding
amount of bytes of persistent storage space for accounts and contracts. These RAM tokens can be bought and sold from an
-on-chain market with EOS. If the account/contract no longer requires the full storage space entitled by the amount of
-RAM tokens held on an EOS account, then the free space can be efficiently reused at a later date for other storage.
-Alternatively, the excess RAM can be sold at the on-chain market for EOS.
+on-chain market with Vaulta. If the account/contract no longer requires the full storage space entitled by the amount of
+RAM tokens held on a Vaulta account, then the free space can be efficiently reused at a later date for other storage.
+Alternatively, the excess RAM can be sold at the on-chain market for Vaulta.
-The other computational resources on EOS are CPU and NET. However, these are ephemeral resources that are acquired on a
-regular basis, for example via PowerUp, or by paying for them with EOS.
+The other computational resources on Vaulta are CPU and NET. However, these are ephemeral resources that are acquired on a
+regular basis, for example via PowerUp, or by paying for them with Vaulta.
On the other hand, EVM covers storage cost using gas fees, in the same way it covers the other ephemeral computational
costs of the transaction. This simplifies how the costs are paid by the user. But it does provide limited opportunity
@@ -86,35 +86,35 @@ to recover value if the contract no longer needs to store as much data.
The mapping between gas fees and the underlying resource costs such as RAM aims for maximum compatibility and simplicity
for the end user, especially during the initial launch. The algorithm to calculate gas usage of an EVM transaction is
-exactly the same for EOS EVM as it is for other popular EVMs. The gas fee the user pays is then the gas usage multiplied
-by the gas price set in the transaction. This is enforced by the EOS EVM Contract to satisfy a configurable minimum gas
+exactly the same for Vaulta EVM as it is for other popular EVMs. The gas fee the user pays is then the gas usage multiplied
+by the gas price set in the transaction. This is enforced by the Vaulta EVM Contract to satisfy a configurable minimum gas
price. The gas fee then gets split and routed appropriately to cover the necessary expenses of the system.
-### Gas Fees Route from EOS EVM to EOS Native
+### Gas Fees Route from Vaulta EVM to Vaulta Native
There are two computational costs associated with processing EVM transactions.
-#### The EOS Native Computational Cost
+#### The Vaulta Native Computational Cost
-The first cost is the EOS native computational cost for CPU and NET which must be covered by an EOS account that is the
-first authorizer of the EOS transaction wrapping the EVM transaction. A portion of the EVM transaction’s gas fee can be
-routed to this EOS account if they claim themselves as the `miner` of the EVM transaction and have opened an internal
-balance within the EOS EVM Contract.
+The first cost is the Vaulta native computational cost for CPU and NET which must be covered by a Vaulta account that is the
+first authorizer of the Vaulta transaction wrapping the EVM transaction. A portion of the EVM transaction’s gas fee can be
+routed to this Vaulta account if they claim themselves as the `miner` of the EVM transaction and have opened an internal
+balance within the Vaulta EVM Contract.
The percentage of the gas fee routed to the internal balance of this miner is determined by a configurable parameter of
-the EOS EVM Contract called the miner cut. By setting appropriate values for miner cut and the minimum gas price within
-the EOS EVM Contract, the miners are expected to receive enough of the portion of the gas fees to cover their average
+the Vaulta EVM Contract called the miner cut. By setting appropriate values for miner cut and the minimum gas price within
+the Vaulta EVM Contract, the miners are expected to receive enough of the portion of the gas fees to cover their average
CPU and NET costs as well as the cost of running a limited RPC node focused on accepting valid EVM transactions, wrapping
-them in EOS transactions, and submitting them to the EOS blockchain. While anyone can act as a miner, at the launch of the
+them in Vaulta transactions, and submitting them to the Vaulta blockchain. While anyone can act as a miner, at the launch of the
network, the ENF will provide this service to ensure that reliable RPC endpoints expected by wallets such as MetaMask are
immediately available starting from launch.
#### The Internal EVM Operational Cost
-The second cost is the internal EVM operational cost, which primarily consist of the EOS EVM Contract’s RAM consumption.
+The second cost is the internal EVM operational cost, which primarily consist of the Vaulta EVM Contract’s RAM consumption.
This cost is covered by the remaining portion of the gas fees of EVM transactions that are not routed to the miner.
Again, tuning the miner cut and minimum gas price parameters appropriately ensures sufficient fees are collected for
the system to remain profitable. These fees accumulate in a special internal balance of the eosio.evm account which can
be withdrawn with authorization of its active permission at any point in time.
-
+
diff --git a/evm/999_miscellaneous/20_evm-compatibility.md b/evm/999_miscellaneous/20_evm-compatibility.md
index b6a1c0b8..e844cff0 100644
--- a/evm/999_miscellaneous/20_evm-compatibility.md
+++ b/evm/999_miscellaneous/20_evm-compatibility.md
@@ -2,21 +2,21 @@
title: EVM Compatibility
---
-EOS EVM is fully compatible with the Ethereum EVM specification, including all precompiles and opcodes. However, there are some key EOS EVM differences:
+Vaulta EVM is fully compatible with the Ethereum EVM specification, including all precompiles and opcodes. However, there are some key Vaulta EVM differences:
## Nested Call Limit
-Due to a limitation in the EOS EVM Contract, EOS EVM currently supports a maximum of five (5) nested calls. The EOS EVM team will keep optimizing designs to increase this number.
+Due to a limitation in the Vaulta EVM Contract, Vaulta EVM currently supports a maximum of five (5) nested calls. The Vaulta EVM team will keep optimizing designs to increase this number.
## Reserved Addresses
-EVM addresses that begin with twelve `0xbb` bytes, e.g. `0xbbbbbbbbbbbbbbbbbbbbbbbb5530ea015b900000`, are reserved for bridging EOS between native EOS and EOS within EVM. Sending messages to these addresses with a value may initiate a bridge transaction or abort the transaction depending on various bridge rules.
+EVM addresses that begin with twelve `0xbb` bytes, e.g. `0xbbbbbbbbbbbbbbbbbbbbbbbb5530ea015b900000`, are reserved for bridging EOS between native Vaulta and EOS within EVM. Sending messages to these addresses with a value may initiate a bridge transaction or abort the transaction depending on various bridge rules.
Also, while unlikely, any contract creation which results in a reserved address will also abort the transaction.
## Precompiles
-EOS EVM supports all precompiles supported by Ethereum, with the following provisions:
+Vaulta EVM supports all precompiles supported by Ethereum, with the following provisions:
### `modexp (0x05)`
@@ -43,16 +43,16 @@ The leading zero byte in the hash is a version byte which may change if a new bl
### `COINBASE (0x41)`
-This opcode returns the address of the EOS EVM contract account, `eosio.evm`. The current address is `0xbbbbbbbbbbbbbbbbbbbbbbbb5530ea015b900000`.
+This opcode returns the address of the Vaulta EVM contract account, `eosio.evm`. The current address is `0xbbbbbbbbbbbbbbbbbbbbbbbb5530ea015b900000`.
### `DIFFICULTY (0x44)`
-This opcode currently returns 1 (one) by default since there is no hash difficulty in the underlying EOS consensus protocol.
+This opcode currently returns 1 (one) by default since there is no hash difficulty in the underlying Vaulta consensus protocol.
### `GASLIMIT (0x45)`
-This opcode currently returns `0x7FFFFFFFFFF` (2^43-1) as the maximum gas limit in EOS EVM.
+This opcode currently returns `0x7FFFFFFFFFF` (2^43-1) as the maximum gas limit in Vaulta EVM.
### `PUSH0` opcode
-The EOS EVM does not currently support `PUSH0`, so you need to use solidity version `0.8.19` or below.
+The Vaulta EVM does not currently support `PUSH0`, so you need to use solidity version `0.8.19` or below.
diff --git a/evm/999_miscellaneous/30_json-rpc-compatibility.md b/evm/999_miscellaneous/30_json-rpc-compatibility.md
index 04d615aa..041d8d1c 100644
--- a/evm/999_miscellaneous/30_json-rpc-compatibility.md
+++ b/evm/999_miscellaneous/30_json-rpc-compatibility.md
@@ -2,64 +2,64 @@
title: JSON RPC Compatibility
---
-All the JSON-RPC calls are inherently supported thanks to the full functioning EOS EVM node which is built based on Silkworm node. However, some methods are blocked in the current phase for the following reasons:
+All the JSON-RPC calls are inherently supported thanks to the full functioning Vaulta EVM node which is built based on Silkworm node. However, some methods are blocked in the current phase for the following reasons:
* Some methods are deprecated or discontinued.
-* Some methods are designed for the local node scenario. They are not exposed to the public API, however you can access them when you deploy your own EOS EVM node.
+* Some methods are designed for the local node scenario. They are not exposed to the public API, however you can access them when you deploy your own Vaulta EVM node.
* Some methods involve complex logic, therefore more tests need to be performed before they will be exposed.
## RPC List
Notes:
* The JSON-RPC calls listed below do NOT include methods that are blocked in the current phase.
-* "EOS EVM Node-SlowQuery" is designated for nodes dedicated to handle slow or heavy queries. This is done so that those slow queries do not stop or degrade the performance of regular nodes serving other method requests.
+* "Vaulta EVM Node-SlowQuery" is designated for nodes dedicated to handle slow or heavy queries. This is done so that those slow queries do not stop or degrade the performance of regular nodes serving other method requests.
| RPC Method | Destination |
| ------------------------------------------- | ------------ |
-| net\_version | EOS EVM node |
-| eth\_blockNumber | EOS EVM node |
-| eth\_chainId | EOS EVM node |
-| eth\_protocolVersion | EOS EVM node |
+| net\_version | Vaulta EVM node |
+| eth\_blockNumber | Vaulta EVM node |
+| eth\_chainId | Vaulta EVM node |
+| eth\_protocolVersion | Vaulta EVM node |
| eth\_gasPrice | Tx Wrapper |
-| eth\_getBlockByHash | EOS EVM node |
-| eth\_getBlockByNumber | EOS EVM node |
-| eth\_getBlockTransactionCountByHash | EOS EVM node |
-| eth\_getBlockTransactionCountByNumber | EOS EVM node |
-| eth\_getUncleByBlockHashAndIndex | EOS EVM node |
-| eth\_getUncleByBlockNumberAndIndex | EOS EVM node |
-| eth\_getUncleCountByBlockHash | EOS EVM node |
-| eth\_getUncleCountByBlockNumber | EOS EVM node |
-| eth\_getTransactionByHash | EOS EVM node |
-| eth\_getRawTransactionByHash | EOS EVM node |
-| eth\_getTransactionByBlockHashAndIndex | EOS EVM node |
-| eth\_getRawTransactionByBlockHashAndIndex | EOS EVM node |
-| eth\_getTransactionByBlockNumberAndIndex | EOS EVM node |
-| eth\_getRawTransactionByBlockNumberAndIndex | EOS EVM node |
-| eth\_getTransactionReceipt | EOS EVM node |
-| eth\_getBlockReceipts | EOS EVM node |
-| eth\_estimateGas | EOS EVM node |
-| eth\_getBalance | EOS EVM node |
-| eth\_getCode | EOS EVM node |
-| eth\_getTransactionCount | EOS EVM node |
-| eth\_getStorageAt | EOS EVM node |
-| eth\_call | EOS EVM node |
-| eth\_callBundle | EOS EVM node |
-| eth\_createAccessList | EOS EVM node |
-| eth\_getLogs | EOS EVM Node-SlowQuery |
+| eth\_getBlockByHash | Vaulta EVM node |
+| eth\_getBlockByNumber | Vaulta EVM node |
+| eth\_getBlockTransactionCountByHash | Vaulta EVM node |
+| eth\_getBlockTransactionCountByNumber | Vaulta EVM node |
+| eth\_getUncleByBlockHashAndIndex | Vaulta EVM node |
+| eth\_getUncleByBlockNumberAndIndex | Vaulta EVM node |
+| eth\_getUncleCountByBlockHash | Vaulta EVM node |
+| eth\_getUncleCountByBlockNumber | Vaulta EVM node |
+| eth\_getTransactionByHash | Vaulta EVM node |
+| eth\_getRawTransactionByHash | Vaulta EVM node |
+| eth\_getTransactionByBlockHashAndIndex | Vaulta EVM node |
+| eth\_getRawTransactionByBlockHashAndIndex | Vaulta EVM node |
+| eth\_getTransactionByBlockNumberAndIndex | Vaulta EVM node |
+| eth\_getRawTransactionByBlockNumberAndIndex | Vaulta EVM node |
+| eth\_getTransactionReceipt | Vaulta EVM node |
+| eth\_getBlockReceipts | Vaulta EVM node |
+| eth\_estimateGas | Vaulta EVM node |
+| eth\_getBalance | Vaulta EVM node |
+| eth\_getCode | Vaulta EVM node |
+| eth\_getTransactionCount | Vaulta EVM node |
+| eth\_getStorageAt | Vaulta EVM node |
+| eth\_call | Vaulta EVM node |
+| eth\_callBundle | Vaulta EVM node |
+| eth\_createAccessList | Vaulta EVM node |
+| eth\_getLogs | Vaulta EVM Node-SlowQuery |
| eth\_sendRawTransaction | Tx Wrapper |
-| debug\_traceBlockByHash | EOS EVM Node-SlowQuery |
-| debug\_traceBlockByNumber | EOS EVM Node-SlowQuery |
-| debug\_traceTransaction | EOS EVM Node-SlowQuery |
-| debug\_traceCall | EOS EVM Node-SlowQuery |
-| trace\_call | EOS EVM Node-SlowQuery |
-| trace\_callMany | EOS EVM Node-SlowQuery |
-| trace\_rawTransaction | EOS EVM Node-SlowQuery |
-| trace\_replayBlockTransactions | EOS EVM Node-SlowQuery |
-| trace\_replayTransaction | EOS EVM Node-SlowQuery |
-| trace\_block | EOS EVM Node-SlowQuery |
-| trace\_filter | EOS EVM Node-SlowQuery |
-| trace\_get | EOS EVM Node-SlowQuery |
-| trace\_transaction | EOS EVM Node-SlowQuery |
+| debug\_traceBlockByHash | Vaulta EVM Node-SlowQuery |
+| debug\_traceBlockByNumber | Vaulta EVM Node-SlowQuery |
+| debug\_traceTransaction | Vaulta EVM Node-SlowQuery |
+| debug\_traceCall | Vaulta EVM Node-SlowQuery |
+| trace\_call | Vaulta EVM Node-SlowQuery |
+| trace\_callMany | Vaulta EVM Node-SlowQuery |
+| trace\_rawTransaction | Vaulta EVM Node-SlowQuery |
+| trace\_replayBlockTransactions | Vaulta EVM Node-SlowQuery |
+| trace\_replayTransaction | Vaulta EVM Node-SlowQuery |
+| trace\_block | Vaulta EVM Node-SlowQuery |
+| trace\_filter | Vaulta EVM Node-SlowQuery |
+| trace\_get | Vaulta EVM Node-SlowQuery |
+| trace\_transaction | Vaulta EVM Node-SlowQuery |
## Batched Requests
diff --git a/evm/index.md b/evm/index.md
index b926e1e6..70a1dc5b 100644
--- a/evm/index.md
+++ b/evm/index.md
@@ -1,4 +1,4 @@
---
-title: EOS EVM
+title: Vaulta EVM
sidebar_class_name: sidebarhidden
---
diff --git a/images/diagram_user_token_flow.png b/images/diagram_user_token_flow.png
index 01b7498f..07a4fe6b 100644
Binary files a/images/diagram_user_token_flow.png and b/images/diagram_user_token_flow.png differ
diff --git a/images/native-web-ide-basics.png b/images/native-web-ide-basics.png
index 19df7aeb..f08fa938 100644
Binary files a/images/native-web-ide-basics.png and b/images/native-web-ide-basics.png differ
diff --git a/images/native-web-ide-build.png b/images/native-web-ide-build.png
index 7da9e430..6f8fdb5e 100644
Binary files a/images/native-web-ide-build.png and b/images/native-web-ide-build.png differ
diff --git a/images/native-web-ide-built.png b/images/native-web-ide-built.png
index 18e1859b..3e72ff23 100644
Binary files a/images/native-web-ide-built.png and b/images/native-web-ide-built.png differ
diff --git a/images/native-web-ide-console.png b/images/native-web-ide-console.png
index 8cb35759..d3cd66a7 100644
Binary files a/images/native-web-ide-console.png and b/images/native-web-ide-console.png differ
diff --git a/images/native-web-ide-deploy-tab.png b/images/native-web-ide-deploy-tab.png
index 45907434..e2ba49a5 100644
Binary files a/images/native-web-ide-deploy-tab.png and b/images/native-web-ide-deploy-tab.png differ
diff --git a/images/native-web-ide-deployed.png b/images/native-web-ide-deployed.png
index a3236f66..cca28b1a 100644
Binary files a/images/native-web-ide-deployed.png and b/images/native-web-ide-deployed.png differ
diff --git a/images/native-web-ide-deploying.png b/images/native-web-ide-deploying.png
index 9d93c537..b55dbf30 100644
Binary files a/images/native-web-ide-deploying.png and b/images/native-web-ide-deploying.png differ
diff --git a/images/native-web-ide-interact.png b/images/native-web-ide-interact.png
index 7c9d91de..84efbbc6 100644
Binary files a/images/native-web-ide-interact.png and b/images/native-web-ide-interact.png differ
diff --git a/images/native-web-ide-interacted.png b/images/native-web-ide-interacted.png
index ca248b2a..bc62ce7a 100644
Binary files a/images/native-web-ide-interacted.png and b/images/native-web-ide-interacted.png differ
diff --git a/images/overview-EOS-Overview-dev.png b/images/overview-EOS-Overview-dev.png
index ae52d2bd..c977a73d 100644
Binary files a/images/overview-EOS-Overview-dev.png and b/images/overview-EOS-Overview-dev.png differ
diff --git a/native/01_quick-start/01_introduction.md b/native/01_quick-start/01_introduction.md
index 62088622..43272e39 100644
--- a/native/01_quick-start/01_introduction.md
+++ b/native/01_quick-start/01_introduction.md
@@ -2,22 +2,23 @@
title: Introduction
---
-The EOS Network is one of the most performant blockchains in the world.
-It is capable of processing 10,000+ transactions per second, with minimal fees and confirmation times.
+Vaulta is one of the most performant blockchains in the world.
+It is capable of processing 10,000+ transactions per second, with minimal fees and near-instant confirmation times.
-Before you begin, you should have a basic understanding of blockchain technology and the EOS Network.
+Before you begin, you should have a basic understanding of blockchain technology and Vaulta.
If you are new to blockchain, check out our [Core Concepts](/docs/02_core-concepts/10_blockchain-basics/10_decentralization.md) section
which dives into the knowledge you need to get off on the right foot.
## Start coding immediately
-We recommend trying things out in the [Web IDE](https://ide.eosnetwork.com/) before you start developing locally.
+**We recommend trying things out in the [Web IDE](https://ide.vaulta.com/)** before you start developing locally.
+But once you're ready to develop locally, you can use this CLI to create a new project with a frontend and contracts.
```bash
-npm create eos@latest myproject
+npm create vaulta@latest myproject
```
-Follow the prompts, and it will set up either a [Template Project](https://github.com/eosnetworkfoundation/template-projects)
+Follow the prompts, and it will set up either a [Template Project](https://github.com/vaultafoundation/template-projects)
or a barebones project with a simple contract, tests, and deployment scripts as well as a frontend of your choosing (SvelteKit, Next.js (react), or Nuxt (vue)).
Check out the next section to get started with your first smart contract.
diff --git a/native/01_quick-start/02_write-a-contract.md b/native/01_quick-start/02_write-a-contract.md
index daba03ee..b1ddc00c 100644
--- a/native/01_quick-start/02_write-a-contract.md
+++ b/native/01_quick-start/02_write-a-contract.md
@@ -1,9 +1,9 @@
---
-title: Quickstart
+title: Write a Contract
---
In this guide we're going to create a simple smart contract that will allow us to store a string in the blockchain.
-This will teach you some of the basics of smart contract development on the EOS network.
+This will teach you some of the basics of smart contract development on Vaulta.
## Create your first Smart Contract
@@ -11,7 +11,7 @@ You can think of a Smart Contract like a function that runs on the blockchain. I
that it will always produce the same output given the same input. This is required so that all nodes on the network
can agree on the output of the function.
-Open up the [EOS Web IDE](https://ide.eosnetwork.com/) in your browser. You will be presented with a
+Open up the [Vaulta Web IDE](https://ide.vaulta.com/) in your browser. You will be presented with a
dummy contract which shows you the basic structure of a smart contract.
Go ahead and clear everything out of the editor, and copy and paste the following code:
@@ -31,7 +31,7 @@ CONTRACT mycontract : public contract {
uint64_t primary_key() const { return id; }
};
- using storage_table = eosio::multi_index<"mytable"_n, StoredData>;
+ using storage_table = multi_index<"mytable"_n, StoredData>;
ACTION save( uint64_t id, std::string text ) {
storage_table _storage( get_self(), get_self().value );
@@ -56,6 +56,6 @@ section to learn more about the various parts of a smart contract and how they w
Your screen should look like this now:
-
+
Head over to the next section to see how we can deploy this to a testnet with a few clicks.
diff --git a/native/01_quick-start/03_build-and-deploy.md b/native/01_quick-start/03_build-and-deploy.md
index cb3567fa..f111b8ee 100644
--- a/native/01_quick-start/03_build-and-deploy.md
+++ b/native/01_quick-start/03_build-and-deploy.md
@@ -3,7 +3,7 @@ title: Build & Deploy
---
In the previous section we wrote a simple smart contract. In this section we will build and deploy it to the blockchain
-using the EOS Web IDE.
+using the Vaulta Web IDE.
## What does a Smart Contract build to?
@@ -26,16 +26,16 @@ compilation of high-level languages like C/C++/Rust, enabling deployment on the
## Enough talk, let's build!
-Go ahead and click the `Build` button in the lower left corner of the EOS Web IDE. You should see a message in the
+Go ahead and click the `Build` button in the lower left corner of the Vaulta Web IDE. You should see a message in the
console that says `Building project...`
-
+
If the build **succeeds**, you will see the zip, wasm, and abi files in the console to be downloaded.
If the build **fails**, you will see the error message in the console, with the line number where the error occurred.
-
+
## Deploying to the testnet
@@ -43,17 +43,17 @@ Now that we have a smart contract that builds without errors, we can deploy it t
Click the deploy tab on the left-most sidebar to open up the deploy options.
-
+
Now you can click on the `Build & Deploy` button to deploy your smart contract to the blockchain.
-This will deploy your smart contract to the EOS Jungle Testnet, and allow you to interact with it.
+This will deploy your smart contract to the Vaulta Jungle Testnet, and allow you to interact with it.
-
+
If there are any errors during the deployment process, you will see them in the console. If not,
you will see a message that says `Deployed successfully!`.
-
+
## Interacting with the contract
@@ -65,14 +65,14 @@ Once deployed, the sidebar will update to show you the:
3. The actions that the contract exposes
4. The tables that the contract exposes
-
+
You can fill out the fields for the `save` action and click the `RUN` button to execute the action.
You can also click the `GET` button next to the table that you want to query to see the data in that table,
you will get a `JSON` output in the console.
-
+
## Congratulations!
diff --git a/native/01_quick-start/06_local-development.md b/native/01_quick-start/06_local-development.md
index c1ce3e42..21bcfb0d 100644
--- a/native/01_quick-start/06_local-development.md
+++ b/native/01_quick-start/06_local-development.md
@@ -2,7 +2,7 @@
title: Local Development
---
-Developing using the [Web IDE](https://ide.eosnetwork.com) will only take you so far.
+Developing using the [Web IDE](https://ide.vaulta.com) will only take you so far.
Eventually, you will want to develop locally on your machine, so that you can easily use version control, your
favorite editor, and other tools that you are used to.
@@ -64,7 +64,7 @@ All build files will be saved to the `build/` directory.
### Testing contracts
-Testing using FuckYea uses VeRT, an emulator for EOS. You can head over to the [testing guide](../03_smart-contracts/50_testing.md) if you want to learn about writing tests.
+Testing using FuckYea uses VeRT, an emulator for Vaulta. You can head over to the [testing guide](../03_smart-contracts/50_testing.md) if you want to learn about writing tests.
```bash
npx fuckyea test [--build]
@@ -94,7 +94,6 @@ It exports a `JSON` object that includes `network` property which defines the ch
```json
networks: {
jungle: {
- // node_url: 'https://eos.greymass.com',
chain: 'Jungle4',
accounts: [
{
@@ -123,7 +122,7 @@ of available chains.
Two common ones are:
- `Jungle4`
-- `EOS`
+- `Vaulta`
#### Registering accounts
@@ -163,8 +162,7 @@ They are injected with a `deployer` object that has the following properties:
module.exports = async (deployer) => {
const contract = await deployer.deploy('someaccount', 'build/mycontract', {
- // adds the `eosio.code` permission to the contract account's active permission
- // so that you can send inline actions from the contract in its name
+ // Allows the contract to be able to send tokens from itself
addCode: true
}).catch(err => {
console.error(err)
diff --git a/native/01_quick-start/10_endpoints.md b/native/01_quick-start/10_endpoints.md
index d9731174..455e30a4 100644
--- a/native/01_quick-start/10_endpoints.md
+++ b/native/01_quick-start/10_endpoints.md
@@ -2,7 +2,7 @@
title: Endpoints
---
-EOS Native Endpoints
+Vaulta Endpoints
-To find a list of all the available endpoints for the EOS Network,
+To find a list of all the available endpoints for Vaulta,
please visit [Antelope Tools](https://eos.antelope.tools/endpoints).
diff --git a/native/02_core-concepts/10_blockchain-basics/20_consensus.md b/native/02_core-concepts/10_blockchain-basics/20_consensus.md
index 5c54e851..66c616a6 100644
--- a/native/02_core-concepts/10_blockchain-basics/20_consensus.md
+++ b/native/02_core-concepts/10_blockchain-basics/20_consensus.md
@@ -19,26 +19,26 @@ proof-of-stake (PoS), delegated proof-of-stake (DPoS), and more. Each algorithm
rules and incentives for how nodes on the network participate in reaching consensus.
-## What consensus algorithms are used in EOS?
+## What consensus algorithms are used in Vaulta?
-EOS uses a delegated proof-of-stake (DPoS) consensus algorithm.
+Vaulta uses a delegated proof-of-stake (DPoS) consensus algorithm.
Token holders elect a group of block producers who are responsible for maintaining the network and reaching consensus
on new blocks. These block producers are incentivized to act honestly, as they can be voted out if they don't perform
their duties properly. This system is designed to be more efficient than PoW, as it doesn't require as much computational
power to maintain the network.
-This allows EOS to be more efficient and greener than other blockchains that use consensus algorithms like proof-of-work.
+This allows Vaulta to be more efficient and greener than other blockchains that use consensus algorithms like proof-of-work.
### Block producers
-Block producers in EOS are the nodes on the network that are responsible for maintaining the network and reaching consensus
+Block producers in Vaulta are the nodes on the network that are responsible for maintaining the network and reaching consensus
on new blocks. There are 21 active block producers at any given time, and a long list of standby block producers who are
ready to step in if one of the active block producers goes offline or is voted out.
### Voting
-EOS token holders can vote for block producers using their EOS tokens. Every token holder can vote for up to 30 block producers,
+Vaulta token holders can vote for block producers using their Vaulta tokens. Every token holder can vote for up to 30 block producers,
and the votes are weighted based on the number of tokens staked to voting. This means that the more tokens you have staked to voting,
the more weight your vote has.
diff --git a/native/02_core-concepts/10_blockchain-basics/40_transactions-and-blocks.md b/native/02_core-concepts/10_blockchain-basics/40_transactions-and-blocks.md
index bc609c4a..06503d39 100644
--- a/native/02_core-concepts/10_blockchain-basics/40_transactions-and-blocks.md
+++ b/native/02_core-concepts/10_blockchain-basics/40_transactions-and-blocks.md
@@ -12,7 +12,7 @@ and added to the blockchain via blocks. Transactions are made up of **actions**.
## What are actions?
-Actions are the smallest unit of work in EOS. Each transaction include one or more actions within it. The ability to include
+Actions are the smallest unit of work in Vaulta. Each transaction include one or more actions within it. The ability to include
multiple actions within a transactions allows you to perform atomic operations across multiple smart contracts.
Actions are executed in the order they are included in the transaction, and if any action fails the entire transaction is rolled back.
diff --git a/native/02_core-concepts/10_blockchain-basics/50_smart-contracts.md b/native/02_core-concepts/10_blockchain-basics/50_smart-contracts.md
index 794449e5..2b5c3560 100644
--- a/native/02_core-concepts/10_blockchain-basics/50_smart-contracts.md
+++ b/native/02_core-concepts/10_blockchain-basics/50_smart-contracts.md
@@ -23,7 +23,7 @@ What a smart contract can do, is entirely up to your imagination.
## Are smart contracts immutable?
-In EOS, smart contracts have the _possibility_ of being immutable, but it is not the default.
+In Vaulta, smart contracts have the _possibility_ of being immutable, but it is not the default.
As long as you retain control of the account that the smart contract is deployed to, you may update the smart contract
at any time. This is useful for fixing bugs, or adding new features to your smart contract.
diff --git a/native/02_core-concepts/20_accounts.md b/native/02_core-concepts/20_accounts.md
index 5987d026..674f608f 100644
--- a/native/02_core-concepts/20_accounts.md
+++ b/native/02_core-concepts/20_accounts.md
@@ -2,14 +2,14 @@
title: Accounts
---
-An EOS account is a digital container for holding EOS tokens, resources, permissions, and more.
+A Vaulta account is a digital container for holding Vaulta tokens, resources, permissions, and more.
Smart Contracts are also deployed on top of accounts, and the account owner can control the smart contract unless
control is relinquished.
## Account names
-EOS accounts have human-readable names.
+Vaulta accounts have human-readable names.
However, in order to keep account names efficient on the blockchain, a few restrictions apply:
@@ -19,13 +19,13 @@ However, in order to keep account names efficient on the blockchain, a few restr
* Names cannot start with a number or a period.
* Names cannot end with a period.
-Periods have a special meaning for EOS accounts. They specify that an account has a **suffix** (similar to a top-level domain like .com), also known as a **premium name**. Accounts with a suffix can only be created by the **suffix owner**.
+Periods have a special meaning for Vaulta accounts. They specify that an account has a **suffix** (similar to a top-level domain like .com), also known as a **premium name**. Accounts with a suffix can only be created by the **suffix owner**.
For instance, if someone owns the suffix `.bar` then only that person can create `foo.bar`.
### Regex Validation
-The following regex can be used to validate an EOS account name:
+The following regex can be used to validate a Vaulta account name:
```regex
(^[a-z1-5.]{1,11}[a-z1-5]$)|(^[a-z1-5.]{12}[a-j1-5]$)
@@ -33,7 +33,7 @@ The following regex can be used to validate an EOS account name:
## Public/private keys
-Every EOS account is ultimately controlled by a key pair (public and corresponding private key).
+Every Vaulta account is ultimately controlled by a key pair (public and corresponding private key).
While the public key is used to identify the account on the blockchain and can be publicly known, the private key which is used
to sign each transaction must be kept secret at all times.
@@ -51,7 +51,7 @@ Examples of private and public keys:
## Permissions system
-EOS offers extra security mechanisms for accounts out of the box, using what we call the *permissions system*.
+Vaulta offers extra security mechanisms for accounts out of the box, using what we call the *permissions system*.
Each account has a set of hierarchical permissions that control what that account can do, and comes with two base permissions by default. These two permissions cannot be removed as they are required for your account to function properly.
@@ -107,13 +107,13 @@ Every account has the ability to have one single smart contract deployed to it,
updated and replaced at will.
-## Creating accounts costs EOS
+## Creating accounts costs Vaulta
-Because RAM is a limited resource, creating an account requires you to spend EOS to buy the RAM needed to store the
+Because RAM is a limited resource, creating an account requires you to spend Vaulta to buy the RAM needed to store the
account's data. This means that in order to create an account, someone else who already has an account must
create it for you.
-Most EOS wallets will allow you to create an account for yourself, but will require you to pay for the RAM needed to
+Most Vaulta wallets will allow you to create an account for yourself, but will require you to pay for the RAM needed to
store your account. Some wallets will pay for the RAM for you, but will require you to pay them back at a later date.
> đź’° **Current costs**
diff --git a/native/02_core-concepts/30_resources.md b/native/02_core-concepts/30_resources.md
index e95f23ac..2b67c451 100644
--- a/native/02_core-concepts/30_resources.md
+++ b/native/02_core-concepts/30_resources.md
@@ -2,29 +2,27 @@
title: Resources
---
-The EOS blockchain relies on three system resources: `CPU`, `NET` and `RAM`. Every EOS account needs system
+The Vaulta blockchain relies on three system resources: `CPU`, `NET` and `RAM`. Every Vaulta account needs system
resources to interact with smart contracts deployed on the blockchain.
## RAM
RAM, just like in a computer, is a limited resource. It is a fast memory storage space that is used by the blockchain to store data.
-Unlike your computer which has eventual persistence to a hard drive, the EOS blockchain stores all of its data in RAM.
+Unlike your computer which has eventual persistence to a hard drive, the Vaulta blockchain stores all of its data in RAM.
Because of this, RAM is a very limited and in-demand resource. Every piece of state data that is stored on the blockchain
must be stored in RAM. This includes account balances, contract code, and contract data.
-RAM can be purchased and sold by users on the EOS blockchain. The price of RAM is determined by a Bancor algorithm
+RAM can be purchased and sold by users on the Vaulta blockchain. The price of RAM is determined by a Bancor algorithm
that is implemented in the system contract. The price of RAM is determined by the amount of free RAM available. The less
free RAM available, the more expensive it is to buy RAM.
-You can also sell RAM you are no longer using back to the system contract, in order to reclaim your EOS and free up RAM for other users.
+You can also sell RAM you are no longer using back to the system contract, in order to reclaim your Vaulta and free up RAM for other users.
### Buying RAM
-The `eosio` system contracts provides the `buyram` and `buyrambytes` actions to buy RAM. The `buyram` action buys RAM in EOS, while the `buyrambytes` action buys RAM in bytes.
-
-If you want a quick way to buy RAM from any wallet, you can **send any amount of EOS to the `buyramforeos` account**, and it will send you back the equivalent amount of RAM.
+The `core.vaulta` system contracts provides the `buyram` and `buyrambytes` actions to buy RAM. The `buyram` action buys RAM in Vaulta, while the `buyrambytes` action buys RAM in bytes.
Want to know how the RAM price is calculated?
@@ -32,7 +30,7 @@ If you want a quick way to buy RAM from any wallet, you can **send any amount of
The necessary RAM needed for a smart contract to store its data is calculated from the used blockchain state.
As a developer, to understand the amount of RAM your smart contract needs, pay attention to the data structure underlying the multi-index tables your smart contract instantiates and uses. The data structure underlying one multi-index table defines a row in the table. Each data member of the data structure corresponds with a row cell of the table.
-To approximate the amount of RAM one multi-index row needs to store on the blockchain, you have to add the size of the type of each data member and the memory overheads for each of the defined indexes, if any. Find below the overheads defined by the EOS code for multi-index tables, indexes, and data types:
+To approximate the amount of RAM one multi-index row needs to store on the blockchain, you have to add the size of the type of each data member and the memory overheads for each of the defined indexes, if any. Find below the overheads defined by the Vaulta code for multi-index tables, indexes, and data types:
@@ -48,7 +46,7 @@ To approximate the amount of RAM one multi-index row needs to store on the block
## CPU & NET
-Both CPU and NET are crucial resources that every EOS account needs in order to interact with the blockchain.
+Both CPU and NET are crucial resources that every Vaulta account needs in order to interact with the blockchain.
### CPU
@@ -63,7 +61,7 @@ The amount of CPU available to an account is measured in microseconds.
Want to know how CPU is 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
+within the limits predefined by the minimum and maximum transaction CPU usage values. For Vaulta 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.
@@ -85,7 +83,7 @@ NET is a resource that is consumed based on the network bandwidth used by a tran
Want to know how NET is calculated?
-Each transaction must consume an amount of NET which can not exceed the predefined maximum transaction NET usage value. For EOS blockchain this limit is set in the blockchain's configuration. You can find out this limit by running the following command and consult the `max_transaction_net_usage` which is expressed in bytes.
+Each transaction must consume an amount of NET which can not exceed the predefined maximum transaction NET usage value. For Vaulta blockchain this limit is set in the blockchain's configuration. You can find out this limit by running the following command and consult the `max_transaction_net_usage` which is expressed in bytes.
@@ -104,29 +102,27 @@ For the accounts that execute transactions, the blockchain calculates and update
### Powering up
-CPU & NET can be powered up on an EOS account by using the system actions. This costs EOS, and will give you an amount of CPU & NET
-that is proportional to the amount of EOS you spend, for a specified period of time.
-
-There are also free services like [EOS PowerUp](https://eospowerup.io) that will allow you to power up CPU & NET for free once
-per day.
+CPU & NET can be powered up on an Vaulta account by using the system actions. This costs Vaulta, and will give you an amount of CPU & NET
+that is proportional to the amount of Vaulta you spend, for a specified period of time.
See detailed information about how to PowerUp manually
-To power up an account is a technique to rent CPU & NET resources from the PowerUp resource model. A smart contract implements this model on the blockchain and allocates these resources to the account of your choice. The action to power up an account is `powerup`. It takes as parameters:
+To power up an account is a technique to rent CPU & NET resources from the PowerUp resource model. A smart contract implements
+this model on the blockchain and allocates these resources to the account of your choice. The action to power up an account is `powerup`. It takes as parameters:
-* The `payer` of the fee, must be a valid EOS account.
-* The `receiver` of the resources, must be a valid EOS account.
-* The `days` which must always match `state.powerup_days` specified in the [PowerUp configuration settings](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/7cec470b17bd53b8c78465d4cbd889dbaf1baffb/contracts/eosio.system/include/eosio.system/eosio.system.hpp#L588).
-* The `net_frac`, and the `cpu_frac` are the percentage of the resources that you need. The easiest way to calculate the percentage is to multiple 10^15 (100%) by the desired percentage. For example: 10^15 * 0.01 = 10^13.
-* The `max_payment`, must be expressed in EOS and is the maximum amount the `payer` is willing to pay.
+* The `payer` of the fee, must be a valid Vaulta account.
+* The `receiver` of the resources, must be a valid Vaulta account.
+* The `days` which must always match `state.powerup_days` specified in the [PowerUp configuration settings](https://github.com/vaultafoundation/system-contracts/blob/7cec470b17bd53b8c78465d4cbd889dbaf1baffb/contracts/eosio.system/include/eosio.system/eosio.system.hpp#L588).
+* The `net_frac`, and the `cpu_frac` are the percentage of the resources that you need. The easiest way to calculate the percentage is to multiply 10^15 (100%) by the desired percentage. For example: 10^15 * 0.01 = 10^13.
+* The `max_payment`, must be expressed in Vaulta and is the maximum amount the `payer` is willing to pay.
```sh
-cleos push action eosio powerup '[user, user, 1, 10000000000000, 10000000000000, "1000.0000 EOS"]' -p user
+cleos push action core.vaulta powerup '[user, user, 1, 10000000000000, 10000000000000, "1000.0000 A"]' -p user
```
@@ -146,7 +142,8 @@ executed transaction: 82b7124601612b371b812e3bf65cf63bb44616802d3cd33a2c0422b583
-The PowerUp resource model on the EOS blockchain is initialized with `"powerup_days": 1,`. This setting permits the maximum period to rent CPU and NET for 24 hours. If you do not use the resources within the 24 hour interval, the rented CPU and NET expires.
+The PowerUp resource model on the Vaulta blockchain is initialized with `"powerup_days": 1,`. This setting permits the maximum
+period to rent CPU and NET for 24 hours. If you do not use the resources within the 24 hour interval, the rented CPU and NET expires.
@@ -156,7 +153,10 @@ The resources in loans that expire are not automatically reclaimed by the system
-Any calls to the `powerup` action does process also this queue (limited to two expired loans at a time). Therefore, the expired loans are automatically processed in a timely manner. Sometimes, it may be necessary to manually process expired loans in the queue to release resources back to the system, which reduces prices. Therefore, any account may process up to an arbitrary number of expired loans if it calls the `powerupexec` action.
+Any calls to the `powerup` action does process also this queue (limited to two expired loans at a time). Therefore, the expired
+loans are automatically processed in a timely manner. Sometimes, it may be necessary to manually process expired loans in the
+queue to release resources back to the system, which reduces prices. Therefore, any account may process up to an arbitrary
+number of expired loans if it calls the `powerupexec` action.
@@ -193,7 +193,7 @@ Example `powerupexec` call:
```sh
-cleos push action eosio powerupexec '[user, 2]' -p user
+cleos push action core.vaulta powerupexec '[user, 2]' -p user
```
diff --git a/native/03_smart-contracts/01_contract-anatomy.md b/native/03_smart-contracts/01_contract-anatomy.md
index 6cbbad07..5f27dee1 100644
--- a/native/03_smart-contracts/01_contract-anatomy.md
+++ b/native/03_smart-contracts/01_contract-anatomy.md
@@ -2,9 +2,9 @@
title: Anatomy
---
-The most used Smart Contract development language for EOS is C++, sometimes referred to as `EOS++`.
-The C++ knowledge required for writing smart contracts is very minimal. If you have ever written C, C++, Java, C#, or
-TypeScript, you should be able to pick up `EOS++` easily.
+The most used Smart Contract development language for Vaulta is C++.
+The C++ knowledge required for writing smart contracts is minimal. If you have ever written C, C++, Java, C#, or
+TypeScript, you should be able to pick up writing Vaulta smart contracts with ease.
There are also community efforts to support other languages such as Rust, Python, Go, and AssemblyScript.
However, these docs will focus on C++ for writing smart contracts.
@@ -115,12 +115,12 @@ There are a few key components here.
### CONTRACT definition
-The `CONTRACT` keyword is how we tell the compiler that we are writing an EOS++ Smart Contract.
+The `CONTRACT` keyword is how we tell the compiler that we are writing a Vaulta Smart Contract.
It must be followed by the name of the contract, and the base class which this contract inherits from.
```cpp
-CONTRACT mycontract : public eosio::contract {
+CONTRACT mycontract : public contract {
```
> âť• **Good to know**
@@ -155,12 +155,12 @@ private:
### Using Contract
-A required line for EOS++ Smart Contracts to compile is the `using contract::contract;` line.
+A required line for Vaulta Smart Contracts to compile is the `using contract::contract;` line.
### Primary Elements
-EOS++ Smart Contracts are made up of two primary elements:
+Vaulta Smart Contracts are made up of two primary elements:
- **Actions**: The entry points to your contract.
- **Tables**: The way you store data in your contract.
diff --git a/native/03_smart-contracts/02_actions.md b/native/03_smart-contracts/02_actions.md
index 6e70fc2e..6c670aec 100644
--- a/native/03_smart-contracts/02_actions.md
+++ b/native/03_smart-contracts/02_actions.md
@@ -38,7 +38,7 @@ return type.
> âš **Return values & Composability**
>
> Return values are only usable from outside the blockchain, and cannot currently be used
-> in EOS for smart contract composability.
+> in Vaulta for smart contract composability.
## Inline Actions
@@ -146,11 +146,36 @@ permission_level(
The `data` argument is used to specify the parameters of the action that you are calling.
A tuple is just a way to group multiple arguments together. You can create a tuple using the `std::make_tuple` function.
-
```cpp
std::make_tuple(, , , ...);
```
+> âš **Passing strings properly**
+>
+> A common issue with `make_tuple` is using literal c-strings (like `make_tuple(name, "withdrawl")`). Instead, you should use
+> `std::string` (like `make_tuple(name, std::string("withdrawl"))`).
+
+
+Instead of using `make_tuple`, you can also manually define a struct and then construct it.
+
+```cpp
+struct transfer_args {
+ name from;
+ name to;
+ asset quantity;
+ string memo;
+};
+
+// Example usage
+action(
+ permission_level{_self, name("active")},
+ name("eosio.token"),
+ name("transfer"),
+ transfer_args {.from=_self, .to=recipient, .quantity=quantity, .memo=memo}
+).send();
+
+```
+
### Code Permission
There is a special account permission called `eosio.code` that allows a contract to call inline actions.
diff --git a/native/03_smart-contracts/03_variables.md b/native/03_smart-contracts/03_variables.md
index eb5cf520..5daedf34 100644
--- a/native/03_smart-contracts/03_variables.md
+++ b/native/03_smart-contracts/03_variables.md
@@ -3,9 +3,9 @@ title: Variables
---
Defining variables is a fundamental part of any programming language. In this section, we will look at
-the different types of variables you can define in EOS Smart Contracts.
+the different types of variables you can define in Vaulta Smart Contracts.
-C++ supports a wide range of data types. EOS++ extends the set of types with EOS-specific types.
+C++ supports a wide range of data types. Vaulta extends the set of types with Vaulta-specific types.
## Defining variables
@@ -117,7 +117,7 @@ Hash types are used to represent cryptographic hashes such as SHA-256.
## Custom types
-These are the custom types that come built-in with EOS++. You will likely use some of these types often in your EOS Smart Contracts.
+These are the custom types that come built-in with Vaulta. You will likely use some of these types often in your Vaulta Smart Contracts.
### Name type
@@ -140,7 +140,7 @@ uint64_t b = a.value;
### Key and Signature types
The `public_key` and `signature` types are used to represent cryptographic keys and signatures, and are
-also an EOS++ specific type.
+also a Vaulta specific type.
#### Required Header
@@ -277,7 +277,7 @@ symbol mySymbol = symbol("ISTOOLONG", 4);
Structs are used to represent complex data. They are similar to classes, but are simpler and more lightweight. Think of a
`JSON` object.
-You can use these in EOS++, but if you are storing them in a table you should use the `TABLE` keyword which we will discuss in the
+You can use these in Vaulta, but if you are storing them in a table you should use the `TABLE` keyword which we will discuss in the
[next section](/docs/03_smart-contracts/04_state-data.md).
```cpp
diff --git a/native/03_smart-contracts/04_state-data.md b/native/03_smart-contracts/04_state-data.md
index 5d25975b..c272e991 100644
--- a/native/03_smart-contracts/04_state-data.md
+++ b/native/03_smart-contracts/04_state-data.md
@@ -12,14 +12,14 @@ one has its own use case.
## Data Models
-A model is a data structure that you will be storing in an EOS++ table. It is a serializable C++ struct, and can contain
+A model is a data structure that you will be storing in a Vaulta table. It is a serializable C++ struct, and can contain
any data type that is also serializable. All common data types are serializable, and you can also create your own
serializable data types, such as other models that start with the `TABLE` keyword.
```cpp
TABLE UserModel {
uint64_t id;
- name eos_account;
+ name account;
uint64_t primary_key() const { return id; }
};
@@ -70,7 +70,7 @@ You also cannot have an account that isn't part of the transaction's authorizati
> đź’° **Beware of RAM**
>
-> RAM is a limited resource on the EOS blockchain, and you should be careful about how much RAM you allow others to use on
+> RAM is a limited resource on the Vaulta blockchain, and you should be careful about how much RAM you allow others to use on
> your contracts. It's often better to make the user pay for the RAM, but this requires that you create incentives for them
> to spend their own RAM in return for something of perceived equal or greater value.
@@ -88,17 +88,17 @@ If we were to imagine the database as a `JSON` object, it might look like this:
1: [
{
"id": 1,
- "eos_account": "bob"
+ "account": "bob"
},
{
"id": 2,
- "eos_account": "sally"
+ "account": "sally"
}
],
2: [
{
"id": 1,
- "eos_account": "joe"
+ "account": "joe"
}
]
}
@@ -114,7 +114,7 @@ As you can see above, you can have the same primary key in different scopes with
## Multi-Index Table
-The multi-index table is the most common way to store data on the EOS blockchain. It is a persistent key-value store that
+The multi-index table is the most common way to store data on the Vaulta blockchain. It is a persistent key-value store that
can be indexed in multiple ways, but always has a primary key. Going back to the NoSQL database analogy, you can think
of the multi-index table as a collection of documents, and each index as a different way to query or fetch data from the collection.
@@ -156,7 +156,7 @@ function, which takes a lambda/anonymous function that accepts a reference to th
name ramPayer = thisContract;
users.emplace(ramPayer, [&](auto& row) {
row.id = 1;
- row.eos_account = name("eosio");
+ row.account = name("vaulta");
});
```
@@ -165,7 +165,7 @@ You can also define a model first, and insert it into the entire row.
```cpp
UserModel user = {
.id = 1,
- .eos_account = name("eosio")
+ .account = name("vaulta")
};
users.emplace(ramPayer, [&](auto& row) {
@@ -209,7 +209,7 @@ and a lambda/anonymous function that allows us to modify the data.
```cpp
users.modify(iterator, same_payer, [&](auto& row) {
- row.eos_account = name("foobar");
+ row.account = name("foobar");
});
```
@@ -232,7 +232,7 @@ users.erase(iterator);
### Using a secondary index
Using a secondary index will allow you to query your table in a different way. For example, if you wanted to query your
-table by the `eos_account` field, you will need to create a secondary index on that field.
+table by the `account` field, you will need to create a secondary index on that field.
#### Redefining our model and table
@@ -242,10 +242,10 @@ in the name of the index, and the type of the index.
```cpp
TABLE UserModel {
uint64_t id;
- name eos_account;
+ name account;
uint64_t primary_key() const { return id; }
- uint64_t account_index() const { return eos_account.value; }
+ uint64_t account_index() const { return account.value; }
};
using users_table = multi_index<"users"_n, UserModel,
@@ -285,7 +285,7 @@ then use the `find` method on the index, instead of using it directly on the tab
```cpp
auto index = users.get_index<"byaccount"_n>();
-auto iterator = index.find(name("eosio").value);
+auto iterator = index.find(name("vaulta").value);
```
To modify data in the table using the secondary index, you use the `modify` method on the index, instead of using it
@@ -293,7 +293,7 @@ directly on the table.
```cpp
index.modify(iterator, same_payer, [&](auto& row) {
- row.eos_account = name("foobar");
+ row.account = name("foobar");
});
```
diff --git a/native/03_smart-contracts/05_authorization.md b/native/03_smart-contracts/05_authorization.md
index c59a8fb8..1ce497b5 100644
--- a/native/03_smart-contracts/05_authorization.md
+++ b/native/03_smart-contracts/05_authorization.md
@@ -6,7 +6,7 @@ Authorization is the process of determining whether or not a user has permission
In blockchain applications this is a key aspect of ensuring the safety of a Smart Contract, and the digital assets that
it controls.
-Checking authorizations with EOS++ can be done in a few ways.
+Checking authorizations with Vaulta can be done in a few ways.
## Getting the sender
diff --git a/native/03_smart-contracts/06_assertions.md b/native/03_smart-contracts/06_assertions.md
index e2177762..0b8fdabc 100644
--- a/native/03_smart-contracts/06_assertions.md
+++ b/native/03_smart-contracts/06_assertions.md
@@ -2,7 +2,7 @@
title: Assertions
---
-Like every program, bugs can occur and user input must be validated. EOS++ provides a clear cut way to do this.
+Like every program, bugs can occur and user input must be validated. Vaulta provides a clear cut way to do this.
## Reverting state
@@ -12,7 +12,7 @@ persisted data / tables will be reverted as if the transaction never happened.
## Check
-The `check` function is how you validate conditions in EOS++.
+The `check` function is how you validate conditions in Vaulta.
The function will check that the specified condition is true, and if it is not, the transaction will fail.
```cpp
@@ -37,7 +37,7 @@ check(false, "This contract is: " + thisContract.to_string());
#### Logging `asset`
```cpp
-asset myAsset = asset(100, symbol("EOS", 4));
+asset myAsset = asset(100, symbol("A", 4));
check(false, "My asset is: " + myAsset.to_string());
```
diff --git a/native/03_smart-contracts/07_events.md b/native/03_smart-contracts/07_events.md
index a596aeac..7582ccfe 100644
--- a/native/03_smart-contracts/07_events.md
+++ b/native/03_smart-contracts/07_events.md
@@ -4,7 +4,7 @@ title: Events
Events are a way for smart contracts to communicate with each other as side-effects of actions.
-The most common in-use usage of events is tracking `eosio.token` (`EOS`) transfers, but they can be used for
+The most common in-use usage of events is tracking `core.vaulta` (`A`) transfers, but they can be used for
any type of communication between contracts.
We will use that exact example below, but first we will cover the basics of events.
@@ -77,7 +77,7 @@ public:
};
```
-The `transfer` action above will emit an event to both the `from` and `to` accounts (this is actually how the `eosio.token` contract works).
+The `transfer` action above will emit an event to both the `from` and `to` accounts (this is actually how the `core.vaulta` contract works).
So if your contract is either the `from` or `to` account, then you can listen for the `transfer` event. If your account is **not**
either of those accounts, you have no way of listening for the `transfer` event from within the blockchain.
diff --git a/native/03_smart-contracts/50_testing.md b/native/03_smart-contracts/50_testing.md
index 0710edf5..2ee6661a 100644
--- a/native/03_smart-contracts/50_testing.md
+++ b/native/03_smart-contracts/50_testing.md
@@ -2,9 +2,9 @@
title: Testing
---
-The easiest way to test EOS Smart Contracts is using VeRT (VM emulation RunTime for WASM-based blockchain contracts).
+The easiest way to test Vaulta Smart Contracts is using VeRT (VM emulation RunTime for WASM-based blockchain contracts).
-It is a JavaScript library that allows you to run EOS smart contracts in a Node.js environment.
+It is a JavaScript library that allows you to run Vaulta smart contracts in a Node.js environment.
You use it along-side other testing libraries like Mocha, Chai, and Sinon.
This guide will use Mocha as the testing framework, and assumes you already know how mocha works, as well as JavaScript.
@@ -20,7 +20,7 @@ We're going to install
- Chai
```shell
-npm install -D @eosnetwork/vert mocha chai
+npm install -D @vaulta/vert mocha chai
```
You should also add `"type": "module"` to your `package.json`.
@@ -44,7 +44,7 @@ Your `package.json` will look something like this now:
"test": "mocha tests/**/*.spec.js"
},
"devDependencies": {
- "@eosnetwork/vert": "^0.3.24",
+ "@vaulta/vert": "^0.3.24",
"chai": "^4.3.10",
"mocha": "^10.2.0"
}
@@ -62,7 +62,7 @@ Let's look at how to import our dependencies, setup the emulator and some accoun
```javascript
// tests/mycontract.spec.js
-import { Blockchain, nameToBigInt, expectToThrow } from "@eosnetwork/vert";
+import { Blockchain, nameToBigInt, expectToThrow } from "@vaulta/vert";
import { assert } from "chai";
// instantiate the blockchain emulator
diff --git a/native/03_smart-contracts/60_token-standard.md b/native/03_smart-contracts/60_token-standard.md
new file mode 100644
index 00000000..fdbc2ce0
--- /dev/null
+++ b/native/03_smart-contracts/60_token-standard.md
@@ -0,0 +1,236 @@
+---
+title: Token Standard
+---
+
+A token standard is a set of rules that all tokens on a blockchain must follow.
+This allows for interoperability between different tokens and applications.
+
+> **Note**
+>
+> Vaulta tokens support more than one token per contract, however in practice not
+> many contracts will do this.
+
+## Actions
+
+### create
+
+```cpp
+[[eosio::action]]
+void create(const name& issuer, const asset& maximum_supply);
+```
+
+Creates a new token with a maximum supply limit, and sets the issuer account.
+The `symbol` of the `asset` defined the precision (decimals) and the token ticker.
+For instance, a maximum supply of `1000.0000 XYZ` means that the token has a precision of 4 decimals,
+a ticker of `XYZ`, and a maximum supply of `1000`.
+
+**Parameters:**
+- `issuer` - The account that creates the token
+- `maximum_supply` - The maximum supply set for the token created
+
+**Preconditions:**
+- Token symbol must not already exist
+
+### issue
+
+```cpp
+[[eosio::action]]
+void issue(const name& to, const asset& quantity, const string& memo);
+```
+
+Issues a specific quantity of tokens to an account.
+
+**Preconditions:**
+- Must be the issuer of the token
+
+**Parameters:**
+- `to` - The account to issue tokens to (must be the same as the issuer)
+- `quantity` - The amount of tokens to be issued
+- `memo` - The memo string that accompanies the token issue transaction
+
+### retire
+
+```cpp
+[[eosio::action]]
+void retire(const asset& quantity, const string& memo);
+```
+
+Effectively burns the specified quantity of tokens, removing them from circulation.
+Only the token issuer can retire tokens. Another way to burn tokens would be to
+send them to a blackhole account (e.g. `null.vaulta`).
+
+**Parameters:**
+- `quantity` - The quantity of tokens to retire
+- `memo` - The memo string to accompany the transaction
+
+### transfer
+
+```cpp
+[[eosio::action]]
+void transfer(const name& from, const name& to, const asset& quantity, const string& memo);
+```
+
+Transfers a specified quantity of tokens from one account to another.
+
+**Parameters:**
+- `from` - The account to transfer from
+- `to` - The account to be transferred to
+- `quantity` - The quantity of tokens to be transferred
+- `memo` - The memo string to accompany the transaction
+
+### open
+
+```cpp
+[[eosio::action]]
+void open(const name& owner, const symbol& symbol, const name& ram_payer);
+```
+
+Each account's balance is a row in a table, which costs 240 bytes of RAM.
+This action creates a row in the table for the owner account and token symbol.
+If this is not done, then the first sender of a token to an account that does
+not have tokens will pay the RAM cost of creating the row.
+
+**Parameters:**
+- `owner` - The account to be created
+- `symbol` - The token to be paid with by ram_payer
+- `ram_payer` - The account that supports the cost of this action
+
+Additional information can be found in [issue #62](https://github.com/EOSIO/eosio.contracts/issues/62) and [issue #61](https://github.com/EOSIO/eosio.contracts/issues/61).
+
+### close
+
+```cpp
+[[eosio::action]]
+void close(const name& owner, const symbol& symbol);
+```
+
+This action is the opposite of open.
+It closes the row for an account for a specific token symbol and reclaims the RAM.
+
+**Parameters:**
+- `owner` - The owner account to execute the close action for
+- `symbol` - The symbol of the token to execute the close action for
+
+**Preconditions:**
+- The pair of owner plus symbol must exist, otherwise no action is executed
+- If the pair of owner plus symbol exists, the balance must be zero
+
+
+## Tables
+
+### Account data structure
+
+```cpp
+struct [[eosio::table]] account {
+ asset balance;
+ uint64_t primary_key() const { return balance.symbol.code().raw(); }
+};
+```
+
+The `account` struct represents an individual token account and stores the balance for a specific token symbol.
+
+
+```cpp
+typedef eosio::multi_index<"accounts"_n, account> accounts;
+```
+
+The `accounts` table stores token balances for all accounts.
+
+- **Table Name:** `accounts`
+- **Index Type:** Primary index on the token symbol code (ticker)
+- **Scope:** The scope is the account name, which is the owner of the token balance
+
+**Usage:**
+- Stores balance information for each account and token combination
+- Used during transfers to check balances and update them
+- Queried when retrieving an account's balance for a specific token
+
+### Fetching balances using [Wharfkit](https://wharfkit.com/)
+
+```typescript
+import {APIClient} from "@wharfkit/session"
+
+const client = new APIClient({ url: Chains.Vaulta.url });
+
+const result = await client.v1.chain.get_table_rows({
+ json: true,
+ code: 'core.vaulta',
+ scope: 'SOME_ACCOUNT_HERE',
+ table: 'accounts',
+});
+
+/*
+{
+ rows: [
+ {
+ balance: "100.0000 A",
+ }
+ ],
+ more: false,
+}
+ */
+```
+
+### currency_stats
+
+```cpp
+struct [[eosio::table]] currency_stats {
+ asset supply;
+ asset max_supply;
+ name issuer;
+ uint64_t primary_key() const { return supply.symbol.code().raw(); }
+};
+```
+
+The `currency_stats` struct stores information about a token.
+
+**Fields:**
+- `supply` - The current supply of the token in circulation
+- `max_supply` - The maximum possible supply of the token
+- `issuer` - The account name of the token issuer who has authority to issue new tokens
+
+```cpp
+typedef eosio::multi_index<"stat"_n, currency_stats> stats;
+```
+
+The `stats` table stores information about each token type.
+
+- **Table Name:** `stat`
+- **Index Type:** Primary index on the token symbol code (ticker)
+- **Scope:** The scope is the token symbol (ticker)
+
+**Usage:**
+- Stores supply, maximum supply, and issuer information for each token
+- Checked during token operations to validate permissions and limits
+- Used to enforce rules like maximum supply constraints
+- Queried to get current supply and other token information
+
+### Fetching stats using [Wharfkit](https://wharfkit.com/)
+
+```typescript
+import {APIClient} from "@wharfkit/session"
+
+const client = new APIClient({ url: Chains.Vaulta.url });
+
+const result = await client.v1.chain.get_table_rows({
+ json: true,
+ code: 'core.vaulta',
+ scope: 'A',
+ table: 'stat',
+});
+
+/*
+{
+ rows: [
+ {
+ supply: "2100000000.0000 A",
+ max_supply: "2100000000.0000 A",
+ issuer: "core.vaulta",
+ }
+ ],
+ more: false,
+}
+
+ */
+```
+
diff --git a/native/03_smart-contracts/999_language-support.md b/native/03_smart-contracts/999_language-support.md
index 4633f9f2..838db530 100644
--- a/native/03_smart-contracts/999_language-support.md
+++ b/native/03_smart-contracts/999_language-support.md
@@ -3,7 +3,7 @@ title: Language Support
---
Aside from C++, there are a number of community-led initiatives for extending language support for smart contracts
-written for EOS.
+written for Vaulta.
Here is a list of currently maintained projects:
diff --git a/native/04_web-applications/01_beginner-concepts.md b/native/04_web-applications/01_beginner-concepts.md
index a78d4444..58a4b0b6 100644
--- a/native/04_web-applications/01_beginner-concepts.md
+++ b/native/04_web-applications/01_beginner-concepts.md
@@ -3,7 +3,7 @@ title: Beginner Concepts
---
- EOS dApps - Beginner Concepts
+ Vaulta dApps - Beginner Concepts
A lot of tutorials for building decentralized web applications dive straight into the code but do not explain
diff --git a/native/04_web-applications/02_javascript-sdk.md b/native/04_web-applications/02_javascript-sdk.md
index 9e550eb2..dd07fbcb 100644
--- a/native/04_web-applications/02_javascript-sdk.md
+++ b/native/04_web-applications/02_javascript-sdk.md
@@ -2,7 +2,7 @@
title: JavaScript SDK
---
-You can use [WharfKit](https://wharfkit.com/guides) to interact with the EOS Network from a web browser or Node.js application.
+You can use [WharfKit](https://wharfkit.com/guides) to interact with Vaulta from a web browser or Node.js application.
Check out their excellent [Getting Started Guide](https://wharfkit.com/guides/session-kit/getting-started-web-app) to learn how to use the SDK to
log in with a wallet, and make a transaction.
diff --git a/native/04_web-applications/05_reading-state.md b/native/04_web-applications/05_reading-state.md
index 001f9bec..91f9e7dc 100644
--- a/native/04_web-applications/05_reading-state.md
+++ b/native/04_web-applications/05_reading-state.md
@@ -6,24 +6,26 @@ title: Reading State
To follow this guide, you will need:
-- An understanding of the EOS blockchain and how it works.
+- An understanding of the Vaulta blockchain and how it works.
- A command-line interface to run curl commands.
-- Access to an EOS node or an EOS API service.
+- Access to a Vaulta node or a Vaulta API service.
-## EOS Tables
+## Vaulta Tables
-EOS stores data in tables, which are similar to database tables. Each table has a name and a set of fields. Tables are organized into scopes, which are defined by the smart contract that created the table.
+Vaulta stores data in tables, which are similar to database tables. Each table has a name and a set of fields. Tables are
+organized into scopes, which are defined by the smart contract that created the table.
-To retrieve data from a table, you need to know its name, scope, and the name of the smart contract that created it. You can also specify a lower and upper bound to limit the amount of data returned.
+To retrieve data from a table, you need to know its name, scope, and the name of the smart contract that created it. You
+can also specify a lower and upper bound to limit the amount of data returned.
-## Methods to Retrieve Data from EOS Tables
+## Methods to Retrieve Data from Vaulta Tables
### Use get_table_rows Function
The `get_table_rows` function retrieves rows from a table. It takes the following parameters in JSON format:
-- `"code"`: the eos account name which is the owner of the smart contract that created the table.
-- `"scope"`: the scope of the table, it is an eos account name.
+- `"code"`: the Vaulta account name which is the owner of the smart contract that created the table.
+- `"scope"`: the scope of the table, it is a Vaulta account name.
- `"table"`: a string representing the name of the table.
- `"json"`: (optional) a boolean value that specifies whether to return the row results in JSON format or binary format, defaults to binary.
- `"lower_bound"`: (optional) a string representing the lower bound for the table key, defaults to first value of the index used.
@@ -39,7 +41,7 @@ Below is an example that retrieves rows from `abihash` table, owned by the `eosi
```shell
curl --request POST \
---url https://eos.greymass.com/v1/chain/get_table_rows \
+--url https://vaulta.greymass.com/v1/chain/get_table_rows \
--header 'content-type: application/json' \
--data '{
"json": true,
@@ -62,11 +64,6 @@ In the example above:
- The function will fetch a maximum of 3 rows, set by the `limit` parameter.
- The retrieved rows will be in ascending order, set by the `reverse` parameter.
-Alternatively, you can execute the same command with `cleos` utility tool, and have the same result:
-
-```shell
-dune -- cleos -u https://eos.greymass.com get table eosio eosio abihash --lower eosio --limit 3
-```
#### The get_table_rows Result
@@ -115,13 +112,13 @@ For example, the result from the previous section command contains three rows, a
Note that the previous command has the `"more"` field set to `true`. That means there's more rows in the table, which match the filter used, that were not returned with the first issued command.
-The `"next_key"`, `"lower_bound"` and `"upper_bound"` fields, can be used to implement pagination or iterative retrieval of data from any table in the EOS blockchain.
+The `"next_key"`, `"lower_bound"` and `"upper_bound"` fields, can be used to implement pagination or iterative retrieval of data from any table in the Vaulta blockchain.
To fetch the next set of rows, you can issue another `get_table_rows` request, modifying the lower bound to be the value of the `"next_key"` field:
```shell
curl --request POST \
---url https://eos.greymass.com/v1/chain/get_table_rows \
+--url https://vaulta.greymass.com/v1/chain/get_table_rows \
--header 'content-type: application/json' \
--data '{
"json": true,
@@ -134,23 +131,19 @@ curl --request POST \
}'
```
-Alternatively, you can execute the same command with `cleos` utility tool, and have the same result:
-
-```shell
-dune -- cleos -u https://eos.greymass.com get table eosio eosio abihash --lower 6138663584080503808 --limit 3
-```
-
-The above commands returns the subsequent 3 rows from the `abihash` table with the producer name value greater than `"6138663584080503808"`. By iterating this process, you can retrieve all the rows in the table.
+The above command returns the subsequent 3 rows from the `abihash` table with the producer name value greater than `"6138663584080503808"`. By iterating this process, you can retrieve all the rows in the table.
If the response from the second request includes `"more": false`, it means that you have fetched all the available rows, which match the filter, and there is no need for further requests.
### Use get_table_by_scope Function
-The purpose of `get_table_by_scope` is to scan the table names under a given `code` account, using `scope` as the primary key. If you already know the table name, e.g. `mytable`, it is not necessary to use `get_table_by_scope` unless you want to find out what are the scopes that have defined the `mytable` table.
+The purpose of `get_table_by_scope` is to scan the table names under a given `code` account, using `scope` as the primary key.
+If you already know the table name, e.g. `mytable`, it is not necessary to use `get_table_by_scope` unless you want to find out what
+are the scopes that have defined the `mytable` table.
These are the input parameters supported by `get_table_by_scope`:
-- `"code"`: the eos account name which is the owner of the smart contract that created the table.
+- `"code"`: the Vaulta account name which is the owner of the smart contract that created the table.
- `"table"`: a string representing the name of the table.
- `"lower_bound"` (optional): This field specifies the lower bound of the scope when querying for table rows. It determines the starting point for fetching rows based on the scope value. Defaults to first value of the scope.
- `"upper_bound"` (optional): This field specifies the upper bound of the scope when querying for table rows. It determines the ending point for fetching rows based on the scope value. Defaults to last value of the scope.
@@ -208,17 +201,17 @@ The above result means your request did not finish its execution due to the tran
#### Real Example
-For a real example, you can list the first three tables named `accounts` owned by the `eosio.token` account starting with the lower bound scope `eosromania`:
+For a real example, you can list the first three tables named `accounts` owned by the `core.vaulta` account starting with the lower bound scope `abc`:
```shell
curl --request POST \
---url https://eos.greymass.com/v1/chain/get_table_by_scope \
+--url https://vaulta.greymass.com/v1/chain/get_table_by_scope \
--header 'content-type: application/json' \
--data '{
"json": true,
-"code": "eosio.token",
+"code": "core.vaulta",
"table": "accounts",
-"lower_bound": "eosromania",
+"lower_bound": "abc",
"upper_bound": "",
"reverse": false,
"limit": "3"
@@ -231,28 +224,28 @@ The result looks similar to the one below:
{
"rows": [
{
- "code": "eosio.token",
- "scope": "eosromania22",
+ "code": "core.vaulta",
+ "scope": "abc",
"table": "accounts",
- "payer": "tigerchainio",
+ "payer": "abc.com",
"count": 1
},
{
- "code": "eosio.token",
- "scope": "eosromaniaro",
+ "code": "core.vaulta",
+ "scope": "abc.bank",
"table": "accounts",
- "payer": "gm3tqmrxhage",
+ "payer": "alibaba.com",
"count": 1
},
{
- "code": "eosio.token",
- "scope": "eosromansev1",
+ "code": "core.vaulta",
+ "scope": "abc.com",
"table": "accounts",
- "payer": "gateiowallet",
+ "payer": "vuniyuoxoeub",
"count": 1
}
],
- "more": "eosromario11"
+ "more": "abc.gm"
}
```
diff --git a/native/06_guides/01_create-a-token.md b/native/06_guides/01_create-a-token.md
index 1530cbec..4e68f0e1 100644
--- a/native/06_guides/01_create-a-token.md
+++ b/native/06_guides/01_create-a-token.md
@@ -86,7 +86,7 @@ It takes four parameters:
Every fungible token has a **symbol** and a **precision**.
-The **symbol** is an identifier for the token (like EOS, BTC, or in our case GOLD), and the **precision** is the number of decimal places that the token supports.
+The **symbol** is an identifier for the token (like Vaulta, BTC, or in our case GOLD), and the **precision** is the number of decimal places that the token supports.
We are going to add a constant variable to our contract to define the `symbol` and `precision` of our token.
Add this above the `issue` action:
@@ -129,7 +129,7 @@ Then, you defined the `balances_table` type which is the definition of a table t
Later you will use the `balances_table` type to instantiate a reference to the `balances` table, and use that reference to
store and retrieve data to/from the blockchain.
-The `owner` property is of type `name` (EOS account name) and will be used to identify the account that owns the tokens.
+The `owner` property is of type `name` (Vaulta account name) and will be used to identify the account that owns the tokens.
The `name` type is a way to pack a string into a 64-bit integer efficiently. It is limited to a-z, 1-5, and a period, and can
be up to 12 characters long.
@@ -608,8 +608,8 @@ CONTRACT token : public contract {
## Grab battle tested source code
-If you'd like to simply use the source code which is used in most fungible tokens on the EOS Network, you can head over to the
-[eosio.token](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/4702c8f2d95dd06f0924688560b8457962522216/contracts/eosio.token)
+If you'd like to simply use the source code which is used in most fungible tokens on Vaulta, you can head over to the
+[eosio.token](https://github.com/vaultafoundation/system-contracts/tree/4702c8f2d95dd06f0924688560b8457962522216/contracts/eosio.token)
repository to grab it. Not only is this code battle tested, but it powers the underlying EOS token.
Please note that the standard `eosio.token` contract differs considerably from this tutorial. It is a more complex
diff --git a/native/06_guides/02_create-an-nft.md b/native/06_guides/02_create-an-nft.md
index 79ffc5db..556ea871 100644
--- a/native/06_guides/02_create-an-nft.md
+++ b/native/06_guides/02_create-an-nft.md
@@ -12,10 +12,10 @@ in their uniqueness.
> đź‘€ **Want to just create an NFT?**
>
> In this tutorial we are going to discuss creating an NFT that follows Ethereum's ERC721
-> standard so that we can dig into some EOS development using a clear standard.
+> standard so that we can dig into some Vaulta development using a clear standard.
>
> **However**, if you want to create an NFT that follows the [**Atomic Assets**](https://github.com/pinknetworkx/atomicassets-contract) standard which
-> is more common on the EOS Network, you can visit the [Atomic Assets NFT Creator](https://eos.atomichub.io/creator)
+> is more common on Vaulta, you can visit the [Atomic Assets NFT Creator](https://eos.atomichub.io/creator)
> where you can easily create an NFT that will instantly be listed on the AtomicHub marketplace without deploying any code.
## What is an NFT Standard?
@@ -55,8 +55,8 @@ CONTRACT nft : public contract {
If we look at the [ERC721 standard](https://eips.ethereum.org/EIPS/eip-721), we can see that
there are a few actions that we need to implement. Overall the standard is quite simple, but
-some concepts are not necessarily EOS-native. For instance, there is no concept
-of `approvals` on EOS since you can send tokens directly to another account (via `on_notify` events), unlike Ethereum.
+some concepts are not necessarily Vaulta-native. For instance, there is no concept
+of `approvals` on Vaulta since you can send tokens directly to another account (via `on_notify` events), unlike Ethereum.
For the sake of keeping the standard as close to the original as possible, we will implement
those non-native concepts in this tutorial.
@@ -255,7 +255,7 @@ We've created singleton tables for the following:
> `singleton<""_n, >`
>
> If we look at the singleton definition, inside the double quotes we have the table name.
-> Names in EOS tables must also follow the Account Name rules, which means they must be
+> Names in Vaulta tables must also follow the Account Name rules, which means they must be
> 12 characters or less and can only contain the characters `a-z`, `1-5`, and `.`.
Now that we've created the tables and structures that will store data about the NFTs,
@@ -404,7 +404,7 @@ The `balanceof` action is used to get the balance of an account.
> âš **Return values & Composability**
>
> Return values are only usable from outside the blockchain, and cannot currently be used
-> in EOS for smart contract composability. EOS supports [**inline actions**](/docs/03_smart-contracts/02_actions.md#inline-actions) which can be used
+> in Vaulta for smart contract composability. Vaulta supports [**inline actions**](/docs/03_smart-contracts/02_actions.md#inline-actions) which can be used
> to call other smart contracts, but they cannot return values.
### OwnerOf
@@ -723,7 +723,7 @@ CONTRACT nft : public contract {
## This is for education purposes
-Keep in mind, that if you deployed this contract on the EOS Network and minted tokens, there
+Keep in mind, that if you deployed this contract on Vaulta and minted tokens, there
would be no supported marketplaces to sell them (at the time of writing this guide). This is just for education purposes.
## Challenge
diff --git a/native/06_guides/9_linked-actions-pattern.md b/native/06_guides/9_linked-actions-pattern.md
index e42407de..8c504d3c 100644
--- a/native/06_guides/9_linked-actions-pattern.md
+++ b/native/06_guides/9_linked-actions-pattern.md
@@ -12,7 +12,7 @@ isn't the only time you might want to use this pattern, hence the term "Linked-A
Taking deposit pattern as our example, let's look at what this transaction might look like:
```
- Transaction
- 1. eosio.token::transfer (Token Transfer)
+ 1. core.vaulta::transfer (Token Transfer)
-[inline] mycontract::on_transfer (Notifiable Action Receiver)
2. mycontract::record (Regular Action)
```
@@ -43,7 +43,7 @@ ACTION transfer(name from, name to, asset quantity, string memo){
```cpp
#include
-[[eosio::on_notify("eosio.token::transfer")]]
+[[eosio::on_notify("core.vaulta::transfer")]]
void on_transfer(name from, name to, asset quantity, string memo){
// ...
}
@@ -85,7 +85,7 @@ TABLE transfer_info {
using _transfers = multi_index<"transfers"_n, transfer_info>;
-[[eosio::on_notify("eosio.token::transfer")]]
+[[eosio::on_notify("core.vaulta::transfer")]]
void on_transfer(name from, name to, asset quantity, string memo){
_transfers transfers( get_self(), get_self().value );
transfers.emplace( get_self(), [&]( auto& row ) {
@@ -134,7 +134,7 @@ We can combat this by adding a `check` to the `on_transfer` event receiver to ma
is over some threshold before we store the transfer information.
```cpp
-[[eosio::on_notify("eosio.token::transfer")]]
+[[eosio::on_notify("core.vaulta::transfer")]]
void on_transfer(name from, name to, asset quantity, string memo){
check(quantity.amount > 100, "Must transfer more than 100 tokens");
diff --git a/native/07_node-operation/100_migration-guides/01_general-upgrade-guide.md b/native/07_node-operation/100_migration-guides/01_general-upgrade-guide.md
index 77e1fe3b..970ba9ea 100644
--- a/native/07_node-operation/100_migration-guides/01_general-upgrade-guide.md
+++ b/native/07_node-operation/100_migration-guides/01_general-upgrade-guide.md
@@ -84,13 +84,13 @@ Here are some tips for speeding up replays:
#### List of peer nodes with blocks.log files extending to genesis:
```bash
-EOS:
+Vaulta:
eos.seed.eosnation.io:9876
peer1.eosphere.io:9876
peer2.eosphere.io:9876
p2p.genereos.io:9876
-EOS Jungle4 Testnet:
+Jungle4 Testnet:
peer1-jungle4.eosphere.io:9876
jungle4.seed.eosnation.io:9876
jungle4.genereos.io:9876
diff --git a/native/07_node-operation/100_migration-guides/02_v1-history-alternatives.md b/native/07_node-operation/100_migration-guides/02_v1-history-alternatives.md
index ef222a93..3b70fd23 100644
--- a/native/07_node-operation/100_migration-guides/02_v1-history-alternatives.md
+++ b/native/07_node-operation/100_migration-guides/02_v1-history-alternatives.md
@@ -3,7 +3,7 @@ title: "V1 History Alternatives"
sidebar_position: 1
---
-The latest EOS v3.1 release officially ends support for the legacy V1 History plugin. Therefore, block producers and node operators who have integrations that rely on V1 History must seek alternative solutions.
+The latest Vaulta v3.1 release officially ends support for the legacy V1 History plugin. Therefore, block producers and node operators who have integrations that rely on V1 History must seek alternative solutions.
## Production Ready Alternatives
@@ -23,7 +23,7 @@ Roborovski History API is implemented and ran by [Greymass Inc.](https://greymas
## What makes the Roborovski History API safe
-Roborovski History API has a high degree of safety because it is created by [Greymass Inc.](https://greymass.com/) which has been a credible and stable block producer and wallet developer (Anchor) company for EOS, WAX, TELOS, PROTON, FIO and other EOS based chains.
+Roborovski History API has a high degree of safety because it is created by [Greymass Inc.](https://greymass.com/) which has been a credible and stable block producer and wallet developer (Anchor) company for Vaulta.
## Understanding the risks associated with hosted solutions
@@ -39,18 +39,18 @@ Existing V1 History Plugin integrators can simply replace their current API url
### How To Connect
-The Roborovski History API connection endpoint is `https://eos.greymass.com`
+The Roborovski History API connection endpoint is `https://vaulta.greymass.com`
### Functions List
- Get Actions (V1 compatible)
- - POST `https://eos.greymass.com/v1/history/get_actions`
+ - POST `https://vaulta.greymass.com/v1/history/get_actions`
- Get Transaction (V1 compatible)
- - POST `https://eos.greymass.com/v1/history/get_transaction`
+ - POST `https://vaulta.greymass.com/v1/history/get_transaction`
- Get Transaction (new method, not in V1)
- - GET `https://eos.greymass.com/v1/history/get_transaction?id=`
+ - GET `https://vaulta.greymass.com/v1/history/get_transaction?id=`
- Get Actions (new method, not in V1)
- - GET `https://eos.greymass.com/v1/history/get_actions?account_name=`
+ - GET `https://vaulta.greymass.com/v1/history/get_actions?account_name=`
### Performance Numbers
@@ -62,13 +62,13 @@ As it was observed and measured so far the Roborovski History API supports at le
## Overview
-Hyperion History is a full history solution for indexing, storing and retrieving EOS-based blockchain historical data. It can be deployed by node operators to provide data querying support for actions, transactions, and blocks stored on the blockchain.
+Hyperion History is a full history solution for indexing, storing and retrieving Vaulta-based blockchain historical data. It can be deployed by node operators to provide data querying support for actions, transactions, and blocks stored on the blockchain.
Hyperion History API provides both V2 and V1 (legacy history plugin) endpoints. Therefore, it is fully compliant with V1 history.
## What makes the Hyperion safe
-Hyperion is developed and maintained by EOS Rio: https://eosrio.io/hyperion/ and has been battle tested on every Antelope public network (EOS, WAX, TELOS, PROTON, FIO, etc).
+Hyperion is developed and maintained by EOS Rio: https://eosrio.io/hyperion/ and has been battle tested for almost a decade.
* Github: https://github.com/eosrio/Hyperion-History-API
* Documentation: https://hyperion.docs.eosrio.io/
diff --git a/native/07_node-operation/100_migration-guides/03_upgrade-guide-5-0.md b/native/07_node-operation/100_migration-guides/03_upgrade-guide-5-0.md
index 140c2a36..23996cd0 100644
--- a/native/07_node-operation/100_migration-guides/03_upgrade-guide-5-0.md
+++ b/native/07_node-operation/100_migration-guides/03_upgrade-guide-5-0.md
@@ -56,7 +56,7 @@ disable-subjective-p2p-billing=false
The following changes to configuration are recommended for nodes running Leap 5+
### Modify Transaction Time Windows
-- Comment out / Remove `max-transaction-time`, or set to a value above the on-chain limit (eg more than 150ms on EOS)
+- Comment out / Remove `max-transaction-time`, or set to a value above the on-chain limit (eg more than 150ms on Vaulta)
- Set `read-only-read-window-time-us` to 165,000 (165ms)
These updates are based on performance testing along with empirical data. In production environments, we have noticed cases of transactions exceeding the 30ms limit, and we recommend increasing the time window. `max-transaction-time` should be removed to allow enforcement of the transaction wall-clock deadline to be driven by the objective on-chain limit.
diff --git a/native/07_node-operation/100_migration-guides/04_upgrade-guide-spring-1-0.md b/native/07_node-operation/100_migration-guides/04_upgrade-guide-spring-1-0.md
index 35b563c1..493c6f4f 100644
--- a/native/07_node-operation/100_migration-guides/04_upgrade-guide-spring-1-0.md
+++ b/native/07_node-operation/100_migration-guides/04_upgrade-guide-spring-1-0.md
@@ -3,7 +3,7 @@ title: Spring 1.0 Upgrade Guide
---
## Purpose
-This upgrade guide covers the steps for upgrading a node to Spring v1 from prior Leap versions. The Node Operator's guide [Switching Over To Savanna Consensus Algorithm](https://docs.eosnetwork.com/docs/latest/node-operation/migration-guides/switch-to-savanna) covers the steps needed to upgrade the consensus algorithm. Node Producers will be interested in [Guide to Managing Finalizer Keys](https://docs.eosnetwork.com/docs/latest/advanced-topics/managing-finalizer-keys)
+This upgrade guide covers the steps for upgrading a node to Spring v1 from prior Leap versions. The Node Operator's guide [Switching Over To Savanna Consensus Algorithm](https://docs.vaulta.com/docs/latest/node-operation/migration-guides/switch-to-savanna) covers the steps needed to upgrade the consensus algorithm. Node Producers will be interested in [Guide to Managing Finalizer Keys](https://docs.vaulta.com/docs/latest/advanced-topics/managing-finalizer-keys)
### Summary of Changes
- [Exceeding number of in flight requests or Mb in flight now returns HTTP 503](#updated-error-codes)
diff --git a/native/07_node-operation/100_migration-guides/10_switch-to-savanna.md b/native/07_node-operation/100_migration-guides/10_switch-to-savanna.md
index adc10ea3..247731b0 100644
--- a/native/07_node-operation/100_migration-guides/10_switch-to-savanna.md
+++ b/native/07_node-operation/100_migration-guides/10_switch-to-savanna.md
@@ -7,7 +7,7 @@ Switching over to the Savanna Consensus Algorithm is a multi-step process.
### Overview of Upgrade Process
There are four steps
-1. Upgrade Antelope Software, Spring and EOS System Contracts
+1. Upgrade Antelope Software, Spring and Vaulta System Contracts
2. Block Producers generate and register finality keys
- First activate protocol feature `BLS_PRIMITIVES2`
- See section below on [Generate and Registering Finalizer Keys](#generate-and-registering-finalizer-keys)
@@ -16,11 +16,11 @@ There are four steps
4. `eosio` user calls `switchtosvnn` action
### Antelope Software Requirements
-Switching to Savanna will required the latest version of Spring Software and the EOS System Contracts.
+Switching to Savanna will required the latest version of Spring Software and the Vaulta System Contracts.
- [Spring v1.0.0](https://github.com/AntelopeIO/spring/releases)
-- [EOS System Contracts v3.6.0](https://github.com/eosnetworkfoundation/eos-system-contracts/releases)
+- [Vaulta System Contracts v3.6.0](https://github.com/vaultafoundation/system-contracts/releases)
-**Note:** [CDT v4.1.0](https://github.com/AntelopeIO/cdt/releases) is needed to compile the latest EOS System Contracts. This version of CDT contains both the needed host functions, and cryptography support needed to support managing finalizer keys.
+**Note:** [CDT v4.1.0](https://github.com/AntelopeIO/cdt/releases) is needed to compile the latest Vaulta System Contracts. This version of CDT contains both the needed host functions, and cryptography support needed to support managing finalizer keys.
### Protocol Features Dependencies
The reference for protocol features with their corresponding hashes may be found in [bios-boot-tutorial](https://github.com/AntelopeIO/spring/blob/main/tutorials/bios-boot-tutorial/bios-boot-tutorial.py). Switching to the `SAVANNA` consensus algorithm, requires the activation of the `SAVANNA` protocol feature. This feature depends all protocol features available in Spring v1.0.0 being in the active_schedule. This full list of protocol features in Spring v1.0.0 is listed below.
@@ -57,4 +57,4 @@ The Savanna Consensus algorithm utilized by Spring v1 separates the roles of pub
Additional information on Finalizer Keys may be found in [Guide to Managing Finalizer Keys](../../advanced-topics/managing-finalizer-keys) and [Introduction to Finalizers and Voting](../../advanced-topics/introduction-finalizers-voting).
### Confirmation of Consensus Algorithm
-The action `switchtosvnn`, initiates the change to the Savanna Consensus Algorithm, and must be called by the owner of the system contracts. On EOS Mainnet this would be the `eosio` user. This is event is called only once per chain.
+The action `switchtosvnn`, initiates the change to the Savanna Consensus Algorithm, and must be called by the owner of the system contracts. On Vaulta Mainnet this would be the `eosio` user. This is event is called only once per chain.
diff --git a/native/07_node-operation/100_migration-guides/index.md b/native/07_node-operation/100_migration-guides/index.md
index 17ce5f9c..b3e26186 100644
--- a/native/07_node-operation/100_migration-guides/index.md
+++ b/native/07_node-operation/100_migration-guides/index.md
@@ -2,7 +2,7 @@
title: Migration Guides
---
-Learn about EOS History Alternatives:
+Learn about Vaulta History Alternatives:
- [General Upgrade Guide](01_general-upgrade-guide.md)
- [V1 History Alternatives](02_v1-history-alternatives.md)
diff --git a/native/07_node-operation/10_getting-started/00_software.md b/native/07_node-operation/10_getting-started/00_software.md
index 4418a84d..adba3547 100644
--- a/native/07_node-operation/10_getting-started/00_software.md
+++ b/native/07_node-operation/10_getting-started/00_software.md
@@ -2,9 +2,9 @@
title: Software
---
-Each node on the EOS network runs the same software called `nodeos`. The software can be configured for each node to serve a different role on the EOS network. Some nodes produce blocks, others relay blocks and transactions, others respond to API requests, others provide historical chain data, etc.
+Each node on the Vaulta network runs the same software called `nodeos`. The software can be configured for each node to serve a different role on the Vaulta network. Some nodes produce blocks, others relay blocks and transactions, others respond to API requests, others provide historical chain data, etc.
-> i `nodeos` is part of the Leap software suite. It is the software that fuels every node of the EOS network. `nodeos` functions as a command line interface (CLI) application, allowing users to start it either manually through the command line or automatically using a script.
+> i `nodeos` is part of the Leap software suite. It is the software that fuels every node of the Vaulta network. `nodeos` functions as a command line interface (CLI) application, allowing users to start it either manually through the command line or automatically using a script.
The behavior of `nodeos` primarily depends on the active plugins and the options associated with those plugins. `nodeos` provides two distinct sets of options:
@@ -19,4 +19,4 @@ Nodeos-specific options exist primarily for administrative tasks, such as specif
Plugin-specific options and the applicable plugins govern the actual behavior of the node. Each plugin-specific option has a distinct name, enabling it to be specified in any order within the command line or the `config.ini` file. When providing plugin-specific options, it is necessary to enable the corresponding plugin using the `--plugin option`, or else the related options will be discarded.
-> i To install the EOS node software, visit the *Binary Installation* section or the *Build and Install from Source* section within the [Leap](https://github.com/AntelopeIO/leap/blob/release/4.0/README.md) github project.
+> i To install the Vaulta node software, visit the *Binary Installation* section or the *Build and Install from Source* section within the [Leap](https://github.com/AntelopeIO/leap/blob/release/4.0/README.md) github project.
diff --git a/native/07_node-operation/10_getting-started/10_hardware-requirements.md b/native/07_node-operation/10_getting-started/10_hardware-requirements.md
index 8693815a..1647c9ac 100644
--- a/native/07_node-operation/10_getting-started/10_hardware-requirements.md
+++ b/native/07_node-operation/10_getting-started/10_hardware-requirements.md
@@ -2,11 +2,11 @@
title: Hardware Requirements
---
-The hardware requirements for each type of EOS node can vary depending on factors such as network size, transaction volume, and the number of concurrent users. However, here are some general guidelines for the hardware requirements of different EOS node types:
+The hardware requirements for each type of Vaulta node can vary depending on factors such as network size, transaction volume, and the number of concurrent users. However, here are some general guidelines for the hardware requirements of different Vaulta node types:
## API Node without Blocks Log
-> ℹ️ The blocks log is a record of all the blocks in the blockchain and their associated transactions. The blocks log provides a comprehensive history of the transactions and changes that have occurred on the EOS network.
+> ℹ️ The blocks log is a record of all the blocks in the blockchain and their associated transactions. The blocks log provides a comprehensive history of the transactions and changes that have occurred on Vaulta.
The minimum, starting point, for an API node, without maintaining blocks log, is the following:
diff --git a/native/07_node-operation/10_getting-started/20_configuration.md b/native/07_node-operation/10_getting-started/20_configuration.md
index d4129b80..bedc43c4 100644
--- a/native/07_node-operation/10_getting-started/20_configuration.md
+++ b/native/07_node-operation/10_getting-started/20_configuration.md
@@ -34,7 +34,7 @@ To use a custom `config.ini` file, specify its filename by passing the `--config
access-control-allow-origin = *
# The name supplied to identify this node amongst the peers. (eosio::net_plugin)
-agent-name = "EOS Test Agent"
+agent-name = "Vaulta Test Agent"
# Enable block production, even if the chain is stale. (eosio::producer_plugin)
enable-stale-production = true
@@ -44,13 +44,13 @@ producer-name = eosio
# Key=Value pairs in the form =
# Where:
-# is a string form of a vaild EOSIO public key
+# is a string form of a vaild Vaulta public key
#
# is a string in the form :
#
# is KEY, KEOSD, or SE
#
-# KEY: is a string form of a valid EOSIO private key which maps to the provided public key
+# KEY: is a string form of a valid Vaulta private key which maps to the provided public key
#
# KEOSD: is the URL where keosd is available and the approptiate wallet(s) are unlocked
#
@@ -159,7 +159,7 @@ Alternatively, it can be restricted to a specific origin:
Access-Control-Allow-Origin: https://sample.io
```
-> ℹ️ In the context of blockchain applications running as web dApps, `nodeos` provides the `access-control-allow-origin` option to control access from other origins. This option can be used by an EOS API node, for instance, to grant access to selected remote hosts.
+> ℹ️ In the context of blockchain applications running as web dApps, `nodeos` provides the `access-control-allow-origin` option to control access from other origins. This option can be used by an Vaulta API node, for instance, to grant access to selected remote hosts.
## Summary
diff --git a/native/07_node-operation/10_getting-started/30_plugins/chain-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/chain-api-plugin.md
index a44af6c1..0b5426d9 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/chain-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/chain-api-plugin.md
@@ -3,7 +3,7 @@ title: chain_api_plugin
dont_translate_title: true
---
-See [Chain API Reference](https://docs.eosnetwork.com/apis/leap/latest/chain.api/).
+See [Chain API Reference](https://docs.vaulta.com/apis/leap/latest/chain.api/).
## Overview
diff --git a/native/07_node-operation/10_getting-started/30_plugins/chain-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/chain-plugin.md
index 104cdf56..c2480d93 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/chain-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/chain-plugin.md
@@ -5,7 +5,7 @@ dont_translate_title: true
## Overview
-The `chain_plugin` is an essential plugin that is necessary for the processing and consolidation of chain data on an EOS node. It implements the core functionality provided by the [Chain API plugin](./chain-api-plugin.md).
+The `chain_plugin` is an essential plugin that is necessary for the processing and consolidation of chain data on a Vaulta node. It implements the core functionality provided by the [Chain API plugin](./chain-api-plugin.md).
## Usage
diff --git a/native/07_node-operation/10_getting-started/30_plugins/db-size-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/db-size-api-plugin.md
index c90b1f91..e497133e 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/db-size-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/db-size-api-plugin.md
@@ -3,7 +3,7 @@ title: db_size_api_plugin
dont_translate_title: true
---
-See [DB Size API Reference](https://docs.eosnetwork.com/apis/leap/latest/db_size.api/).
+See [DB Size API Reference](https://docs.vaulta.com/apis/leap/latest/db_size.api/).
## Overview
diff --git a/native/07_node-operation/10_getting-started/30_plugins/index.md b/native/07_node-operation/10_getting-started/30_plugins/index.md
index 16cac8f1..26ade85c 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/index.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/index.md
@@ -6,4 +6,4 @@ title: Plugins
To learn more about a specific plugin, select it from the left navigation menu.
-> ℹ️ `nodeos` plugins provide incremental functionality to the EOS core blockchain. In contrast to runtime plugins, `nodeos` plugins are built and baked into the `nodeos` binary during the compilation process.
+> ℹ️ `nodeos` plugins provide incremental functionality to the Vaulta core blockchain. In contrast to runtime plugins, `nodeos` plugins are built and baked into the `nodeos` binary during the compilation process.
diff --git a/native/07_node-operation/10_getting-started/30_plugins/net-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/net-api-plugin.md
index 785b0a5a..29007fdc 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/net-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/net-api-plugin.md
@@ -3,7 +3,7 @@ title: net_api_plugin
dont_translate_title: true
---
-See [Net API Reference](https://docs.eosnetwork.com/apis/leap/latest/net.api/).
+See [Net API Reference](https://docs.vaulta.com/apis/leap/latest/net.api/).
## Overview
diff --git a/native/07_node-operation/10_getting-started/30_plugins/net-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/net-plugin.md
index af5f656b..aa9e1937 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/net-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/net-plugin.md
@@ -29,11 +29,11 @@ Option (=default) | Description
-|-
`--p2p-listen-endpoint arg (=0.0.0.0:9876)` | The actual host:port used to listen for incoming p2p connections.
`--p2p-server-address arg` | An externally accessible host:port for identifying this node. Defaults to p2p-listen-endpoint.
-`--p2p-peer-address arg` | The public endpoint of a peer node to connect to. Use multiple p2p-peer-address options as needed to compose a network. Syntax: host:port[:^trx^\|^blk^] The optional 'trx' and 'blk' indicates to node that only transactions 'trx' or blocks 'blk' should be sent. Examples: p2p.eos.io:9876 p2p.trx.eos.io:9876:trx p2p.blk.eos.io:9876:blk
+`--p2p-peer-address arg` | The public endpoint of a peer node to connect to. Use multiple p2p-peer-address options as needed to compose a network. Syntax: host:port[:^trx^\|^blk^] The optional 'trx' and 'blk' indicates to node that only transactions 'trx' or blocks 'blk' should be sent. Examples: p2p.vaulta.io:9876 p2p.trx.vaulta.io:9876:trx p2p.blk.vaulta.io:9876:blk
`--p2p-max-nodes-per-host arg (=1)` | Maximum number of client nodes from any single IP address
`--p2p-accept-transactions arg (=1)` | Allow transactions received over p2p network to be evaluated and relayed if valid.
-`--p2p-auto-bp-peer arg` | The account and public p2p endpoint of a block producer node to automatically connect to when the it is in producer schedule proximity . Syntax: account,host:port Example, eosproducer1,p2p.eos.io:9876 eosproducer2,p2p.trx.eos.io:9876:t rx eosproducer3,p2p.blk.eos.io:9876:b lk
-`--agent-name arg (=EOS Test Agent)` | The name supplied to identify this node amongst the peers.
+`--p2p-auto-bp-peer arg` | The account and public p2p endpoint of a block producer node to automatically connect to when the it is in producer schedule proximity . Syntax: account,host:port Example, vaultaprod1,p2p.vaulta.io:9876 vaultaprod2,p2p.trx.vaulta.io:9876:t rx vaultaprod3,p2p.blk.vaulta.io:9876:b lk
+`--agent-name arg (=Vaulta Test Agent)` | The name supplied to identify this node amongst the peers.
`--allowed-connection arg (=any)` | Can be 'any' or 'producers' or 'specified' or 'none'. If 'specified', peer-key must be specified at least once. If only 'producers', peer-key is not required. 'producers' and 'specified' may be combined.
`--peer-key arg` | Optional public key of peer allowed to connect. May be used multiple times.
`--peer-private-key arg` | Tuple of [PublicKey, WIF private key] (may specify multiple times)
diff --git a/native/07_node-operation/10_getting-started/30_plugins/producer-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/producer-api-plugin.md
index f17db932..9bad66f2 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/producer-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/producer-api-plugin.md
@@ -3,7 +3,7 @@ title: producer_api_plugin
dont_translate_title: true
---
-See [Producer API Reference](https://docs.eosnetwork.com/apis/leap/latest/producer.api/).
+See [Producer API Reference](https://docs.vaulta.com/apis/leap/latest/producer.api/).
## Overview
diff --git a/native/07_node-operation/10_getting-started/30_plugins/producer-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/producer-plugin.md
index b9face36..60ba79f0 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/producer-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/producer-plugin.md
@@ -7,7 +7,7 @@ dont_translate_title: true
The `producer_plugin` contains functionality for a node to perform the task of block production. It also implements the core functionality provided by the [Producer API plugin](./producer-api-plugin.md).
-> ℹ️ To enable block production, a particular `nodeos` configuration is necessary. Refer to the [Configuring Block Producing Node](https://docs.eosnetwork.com/manuals/leap/latest/nodeos/usage/node-setups/producing-node) guide for detailed instructions.
+> ℹ️ To enable block production, a particular `nodeos` configuration is necessary. Refer to the [Configuring Block Producing Node](https://docs.vaulta.com/manuals/leap/latest/nodeos/usage/node-setups/producing-node) guide for detailed instructions.
## Usage
@@ -33,7 +33,7 @@ Option (=default) | Description
`--max-transaction-time arg (=30)` | Limits the maximum time (in milliseconds) that is allowed a pushed transaction's code to execute before being considered invalid
`--max-irreversible-block-age arg (=-1)` | Limits the maximum age (in seconds) of the DPOS Irreversible Block for a chain this node will produce blocks on (use negative value to indicate unlimited)
`-p [ --producer-name ] arg` | ID of producer controlled by this node (e.g. inita; may specify multiple times)
-`--signature-provider arg (==KEY:)` | Key=Value pairs in the form ^public-key^=^provider-spec^ Where: ^public-key^ is a string form of a vaild EOSIO public key ^provider-spec^ is a string in the form ^provider-type^ :^data^ ^provider-type^ is KEY, KEOSD, or SE KEY:^data^ is a string form of a valid EOSIO private key which maps to the provided public key KEOSD:^data^ is the URL where keosd is available and the approptiate wallet(s) are unlocked
+`--signature-provider arg (==KEY:)` | Key=Value pairs in the form ^public-key^=^provider-spec^ Where: ^public-key^ is a string form of a vaild Vaulta public key ^provider-spec^ is a string in the form ^provider-type^ :^data^ ^provider-type^ is KEY, KEOSD, or SE KEY:^data^ is a string form of a valid Vaulta private key which maps to the provided public key KEOSD:^data^ is the URL where keosd is available and the approptiate wallet(s) are unlocked
`--greylist-account arg` | account that can not access to extended CPU/NET virtual resources
`--greylist-limit arg (=1000)` | Limit (between 1 and 1000) on the multiple that CPU/NET virtual resources can extend during low usage (only enforced subjectively; use 1000 to not enforce any limit)
`--produce-time-offset-us arg (=0)` | Offset of non last block producing time in microseconds. Valid range 0 .. -block_time_interval.
@@ -89,4 +89,4 @@ plugin = eosio::chain_plugin [operations] [options]
nodeos ... --plugin eosio::chain_plugin [operations] [options]
```
-For details about how blocks are produced please read the following [block producing explainer](https://docs.eosnetwork.com/manuals/leap/latest/nodeos/plugins/producer_plugin/block-producing-explained).
+For details about how blocks are produced please read the following [block producing explainer](https://docs.vaulta.com/manuals/leap/latest/nodeos/plugins/producer_plugin/block-producing-explained).
diff --git a/native/07_node-operation/10_getting-started/30_plugins/test-control-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/test-control-api-plugin.md
index 749a37ce..01bde438 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/test-control-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/test-control-api-plugin.md
@@ -3,7 +3,7 @@ title: test_control_api_plugin
dont_translate_title: true
---
-See [Test Control API Reference](https://docs.eosnetwork.com/apis/leap/latest/test_control.api/)
+See [Test Control API Reference](https://docs.vaulta.com/apis/leap/latest/test_control.api/)
## Overview
diff --git a/native/07_node-operation/10_getting-started/30_plugins/trace-api-plugin.md b/native/07_node-operation/10_getting-started/30_plugins/trace-api-plugin.md
index b7932e67..60487ce6 100644
--- a/native/07_node-operation/10_getting-started/30_plugins/trace-api-plugin.md
+++ b/native/07_node-operation/10_getting-started/30_plugins/trace-api-plugin.md
@@ -3,7 +3,7 @@ title: trace_api_plugin
dont_translate_title: true
---
-See [Trace API Reference](https://docs.eosnetwork.com/apis/leap/latest/trace_api.api/).
+See [Trace API Reference](https://docs.vaulta.com/apis/leap/latest/trace_api.api/).
## Overview
@@ -11,13 +11,13 @@ The `trace_api_plugin` offers a consumer-oriented API that allows for the retrie
## Purpose
-When integrating applications like block explorers and exchanges with an EOS blockchain, there is often a need for a comprehensive record of all actions processed by the blockchain. This includes actions generated from executing smart contracts and scheduled transactions. The `trace_api_plugin` was designed to address this requirement.
+When integrating applications like block explorers and exchanges with a Vaulta blockchain, there is often a need for a comprehensive record of all actions processed by the blockchain. This includes actions generated from executing smart contracts and scheduled transactions. The `trace_api_plugin` was designed to address this requirement.
The primary objective of the `trace_api_plugin` is to provide the following functionalities:
* Provision of a transcript that includes retired actions and their associated metadata.
* Availability of a consumer-focused, long-term API for retrieving blocks.
-* Enhancement of resource management within EOS nodes, ensuring sustainable usage of resources such as file system storage, disk space, and memory.
+* Enhancement of resource management within Vaulta nodes, ensuring sustainable usage of resources such as file system storage, disk space, and memory.
While the `state_history_plugin` provides a binary streaming interface to access structural chain data, action data, and state deltas, the main focus of the `trace_api_plugin` is to improve the maintenance of node resources, including the file system, disk space, and memory utilization.
@@ -125,7 +125,7 @@ Compressed trace log files have the `.clog` file extension (see [Compression of
The data is compressed into raw zlib form with full-flush *seek points* placed at regular intervals. A decompressor can start from any of these *seek points* without reading previous data and it can also traverse a seek point without issue if it appears within the data.
> ℹ️ Size reduction of trace logs
-> Data compression can reduce the space growth of trace logs twentyfold! For instance, with 512 seek points and using the test dataset on the EOS public network, data compression reduces the growth of the trace directory from ~50 GiB/day to ~2.5 GiB/day for full data. Due to the high redundancy of the trace log contents, the compression is still comparable to `gzip -9`. The decompressed data is also made immediately available via the Trace RPC API without any service degradation.
+> Data compression can reduce the space growth of trace logs twentyfold! For instance, with 512 seek points and using the test dataset on the Vaulta public network, data compression reduces the growth of the trace directory from ~50 GiB/day to ~2.5 GiB/day for full data. Due to the high redundancy of the trace log contents, the compression is still comparable to `gzip -9`. The decompressed data is also made immediately available via the Trace RPC API without any service degradation.
#### Role of seek points
@@ -156,7 +156,7 @@ The `trace_api_plugin` also supports an option to optimize disk space by applyin
If the argument `N` is 0 or greater, the plugin automatically sets a background thread to compress the irreversible sections of the trace log files. The previous N irreversible blocks past the current LIB block are left uncompressed.
> ℹ️ Trace API utility
-> The trace log files can also be compressed manually with the [trace_api_util](https://docs.eosnetwork.com/manuals/leap/latest/utilities/trace_api_util) utility.
+> The trace log files can also be compressed manually with the [trace_api_util](https://docs.vaulta.com/manuals/leap/latest/utilities/trace_api_util) utility.
If resource usage cannot be effectively managed via the `trace-minimum-irreversible-history-blocks` and `trace-minimum-uncompressed-irreversible-history-blocks` options, then there might be a need for periodic manual maintenance. In that case, the user may opt to manage resources through an external system or recurrent process.
diff --git a/native/07_node-operation/10_getting-started/40_peering.md b/native/07_node-operation/10_getting-started/40_peering.md
index 15dfe2ef..f1ca5324 100644
--- a/native/07_node-operation/10_getting-started/40_peering.md
+++ b/native/07_node-operation/10_getting-started/40_peering.md
@@ -4,18 +4,18 @@ title: Peering
# Peering
-EOS blockchains may consist of one or many nodes. Although a single node can still run a fully functional blockchain, it cannot scale or grow. To grasp the full benefits of the EOS blockchain technology, more nodes are needed. In this section, you will learn about "peering", the network feature that makes it possible. This is what allows to grow incrementally from a single node to a truly decentralized, geographically distributed, multi node EOS blockchain.
+Vaulta blockchains may consist of one or many nodes. Although a single node can still run a fully functional blockchain, it cannot scale or grow. To grasp the full benefits of the Vaulta blockchain technology, more nodes are needed. In this section, you will learn about "peering", the network feature that makes it possible. This is what allows to grow incrementally from a single node to a truly decentralized, geographically distributed, multi node Vaulta blockchain.
## What is Peering?
-Peering allows EOS nodes to propagate and synchronize the distributed blockchain state by receiving and relaying blocks and/or transactions to other nodes. Any node that is configured to send and receive data in a peer-to-peer fashion is considered a "peer". This adds redundancy and allows for faster response times to client queries and node requests. Therefore, peering is key to the decentralized operation and incremental growth of the EOS blockchain.
+Peering allows Vaulta nodes to propagate and synchronize the distributed blockchain state by receiving and relaying blocks and/or transactions to other nodes. Any node that is configured to send and receive data in a peer-to-peer fashion is considered a "peer". This adds redundancy and allows for faster response times to client queries and node requests. Therefore, peering is key to the decentralized operation and incremental growth of the Vaulta blockchain.
-> ℹ️ EOS Network Protocol
-Peering is enabled through the EOS peer-to-peer (p2p) network protocol and it is what allows the decentralized operation of the blockchain. For more information, check the [EOS Network Protocol](../../60_advanced-topics/03_network-peer-protocol.md).
+> ℹ️ Vaulta Network Protocol
+Peering is enabled through the Vaulta peer-to-peer (p2p) network protocol and it is what allows the decentralized operation of the blockchain. For more information, check the [Vaulta Network Protocol](../../60_advanced-topics/03_network-peer-protocol.md).
## Why you need nodes/peers?
-In the EOS blockchain, nodes can be configured to operate in different ways. It is this flexibility in having nodes serve distinct roles which allows for a more distributed load and a smoother blockchain experience for the end user. Some of the node types in EOS include, but are not limited to:
+In the Vaulta blockchain, nodes can be configured to operate in different ways. It is this flexibility in having nodes serve distinct roles which allows for a more distributed load and a smoother blockchain experience for the end user. Some of the node types in Vaulta include, but are not limited to:
* **Producing Nodes**: produce blocks to be added to the chain
* **Relay Nodes**: validate/relay blocks and/or transactions
@@ -23,12 +23,12 @@ In the EOS blockchain, nodes can be configured to operate in different ways. It
* **History Nodes**: stores chain data for L2 history solutions
* etc.
-Therefore, when set up as peers, EOS nodes validate the blocks and transactions they receive and relay them to other peers by default, if valid. Nodes can also be set up to respond to API requests from clients, provide historical data about blocks and transactions, etc. This separation of concerns makes the blockchain more efficient.
+Therefore, when set up as peers, Vaulta nodes validate the blocks and transactions they receive and relay them to other peers by default, if valid. Nodes can also be set up to respond to API requests from clients, provide historical data about blocks and transactions, etc. This separation of concerns makes the blockchain more efficient.
## How to set up peers
> ℹ️ Peer Setup
-The peer connection process must be performed on the local environment of each peer. Therefore, peering involves planning and agreement among some of the nodes that will act as peers in the EOS network.
+The peer connection process must be performed on the local environment of each peer. Therefore, peering involves planning and agreement among some of the nodes that will act as peers in the Vaulta network.
Peering can be set up by configuring the `net_plugin` of each `nodeos` instance whose node will act as a peer. The most important options are:
@@ -48,11 +48,11 @@ To peer your local node with other nodes, specify the following in your nodeos `
# your listening host:port
p2p-listen-endpoint = : # e.g. 0.0.0.0:9876
# your public host:port
-p2p-server-address = : # e.g. p2p.eos99.io:9876
+p2p-server-address = : # e.g. p2p.vaulta99.io:9876
# peers host:port (for each peer to connect to)
p2p-peer-address = : # e.g. peer.leap.sg:9876
-p2p-peer-address = : # e.g. p2p.eosphere.io:3571
+p2p-peer-address = : # e.g. p2p.vaultaphere.io:3571
# etc.
```
@@ -73,20 +73,19 @@ Check the previous section [Peer setup using `config.ini`](#peer-setup-using-con
## How to locate peers
-For the EOS Mainnet and various Testnets, some websites publish and maintain lists of P2P, API, and other endpoints for your nodes to connect to.
+For the Vaulta Mainnet and various Testnets, some websites publish and maintain lists of P2P, API, and other endpoints for your nodes to connect to.
> ℹ️ Endpoints and BP.json
Endpoint lists are typically generated, validated, and combined from the standard `bp.json` files provided by Block Producers, including Standby Producers.
-For a central portal that maintains the recent status of *all* active endpoints (P2P, API, History, etc.) for the EOS Mainnet and various EOS Testnets, you can visit the EOS Nation Validate Portal and select the **endpoints report** for the specific network:
+For a central portal that maintains the recent status of *all* active endpoints (P2P, API, History, etc.) for the Vaulta Mainnet and various Vaulta Testnets, you can visit the EOS Nation Validate Portal and select the **endpoints report** for the specific network:
-* EOS Mainnet endpoints: https://validate.eosnation.io/eos/reports/endpoints.html
+* Vaulta Mainnet endpoints: https://validate.eosnation.io/eos/reports/endpoints.html
* Jungle Testnet endpoints: https://validate.eosnation.io/jungle4/reports/endpoints.html
-* Kylin Testnet: https://validate.eosnation.io/kylin/reports/endpoints.html
Once you visit any of the above **endpoints report**, you can scroll down to the specific endpoints of interest: `api_http` or `api_https2` for API endpoints, `p2p` for P2P endpoints, etc.
-### For EOS Mainnet
+### For Vaulta Mainnet
Besides the **endpoints report** URLs listed in the parent section above [How to locate peers](#how-to-locate-peers), the following endpoints are available to add directly to your `config.ini`:
@@ -96,7 +95,7 @@ The above P2P endpoints list should display something similar to:
```ini
# Endpoints config.ini
-# Network: EOS
+# Network: Vaulta
# Validator last update: 2023-06-12 19:32 UTC
# For details on how this is generated see https://validate.eosnation.io/about/
# ==== p2p ====
@@ -115,7 +114,7 @@ The above API endpoints list should display something similar to:
```ini
# API Versions Report
-# Network: EOS
+# Network: Vaulta
# Validator last update: 2023-06-12 20:06 UTC
# For details on how this is generated see https://validate.eosnation.io/about/
==== 4.0.1 (leap) ====
@@ -130,37 +129,30 @@ teamgreymass api_http, v3.1.0, http://eos.greymass.com, ...
teamgreymass api_https2, v3.1.0, https://eos.greymass.com, ...
```
-### For EOS Testnets
+### For Vaulta Testnets
Besides the **endpoints report** URLs listed in the parent section [How to locate peers](#how-to-locate-peers), the following endpoints are available to add directly to your `config.ini` for the following EOS Testnets:
-#### EOS Jungle Testnet
+#### Vaulta Jungle Testnet
* P2P Endpoints: https://validate.eosnation.io/jungle4/reports/config.txt
* API Endpoints: https://validate.eosnation.io/jungle4/reports/api_versions.txt
-#### EOS Kylin Testnet
-
-* P2P Endpoints: https://validate.eosnation.io/kylin/reports/config.txt
-* API Endpoints: https://validate.eosnation.io/kylin/reports/api_versions.txt
-
## How to check peers health
Some web portals provide periodic reports and/or live monitoring to check the health of public P2P and API endpoints. Also, some real-time tools allow to estimate the proximity and/or response time of P2P or API endpoints.
-### EOS Nation Reports
+### Vaulta Nation Reports
-EOS Nation provides extensive reports on the status of various endpoints, including the health of block producing nodes, for both the EOS Mainnet and various EOS Testnets:
+EOS Nation provides extensive reports on the status of various endpoints, including the health of block producing nodes, for both the Vaulta Mainnet and various Vaulta Testnets:
-* EOS Mainnet reports: https://validate.eosnation.io/eos/reports/
+* Vaulta Mainnet reports: https://validate.eosnation.io/eos/reports/
* Jungle Testnet reports: https://validate.eosnation.io/jungle4/reports/
-* Kylin Testnet reports: https://validate.eosnation.io/kylin/reports/
Since the endpoints listed on the above reports are validated and refreshed every 30 minutes, the mere presence of an endpoint on a given report indicates a *responsive* status. For other errors detected during `bp.json` validation, check these resources:
-* EOS Mainnet error report: https://validate.eosnation.io/eos/reports/errors.html
+* Vaulta Mainnet error report: https://validate.eosnation.io/eos/reports/errors.html
* Jungle Testnet error report: https://validate.eosnation.io/jungle4/reports/errors.html
-* Kylin Testnet error report: https://validate.eosnation.io/kylin/reports/errors.html
### Third-party Tools
@@ -171,4 +163,4 @@ Some tools are available to measure the responsiveness, or lack thereof, of a li
## Summary
-Peering is crucial for the decentralized operation of any EOS blockchain network. It allows to synchronize and distribute the blockchain state among all nodes and peers for a smoother and faster blockchain experience. Peering is necessary for any EOS blockchain to grow organically, reach consensus, achieve self-governance, and exploit many of the benefits of blockchain technology.
+Peering is crucial for the decentralized operation of any Vaulta blockchain network. It allows to synchronize and distribute the blockchain state among all nodes and peers for a smoother and faster blockchain experience. Peering is necessary for any Vaulta blockchain to grow organically, reach consensus, achieve self-governance, and exploit many of the benefits of blockchain technology.
diff --git a/native/07_node-operation/10_getting-started/60_logging/10_native-logging.md b/native/07_node-operation/10_getting-started/60_logging/10_native-logging.md
index a1ad28fc..4048be30 100644
--- a/native/07_node-operation/10_getting-started/60_logging/10_native-logging.md
+++ b/native/07_node-operation/10_getting-started/60_logging/10_native-logging.md
@@ -10,7 +10,7 @@ The path where the `logging.json` is stored can be explicitly defined using the
## Appenders
-The EOS logging library supports two `appender` types:
+The Vaulta logging library supports two `appender` types:
- [GELF](#gelf) (Graylog Extended Log Format)
- [Console](#console)
@@ -78,7 +78,7 @@ Example:
## Loggers
-The EOS logging library supports the following loggers:
+The Vaulta logging library supports the following loggers:
- `default` - the default logger, always enabled.
- `producer_plugin` - detailed logging for the producer plugin.
diff --git a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/10_deep-mind-logger.md b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/10_deep-mind-logger.md
index 2081fb34..70f657c5 100644
--- a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/10_deep-mind-logger.md
+++ b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/10_deep-mind-logger.md
@@ -8,7 +8,7 @@ The `Deep-mind logger` is part of the `dfuse` [platform](https://dfuse.eosnation
## How To Enable Deep-mind Logger
-EOS integrates the `nodeos` core service daemon with `deep-mind logger`. To benefit from full `deep-mind` logging functionality you must start your `nodeos` instance with the flag `--deep-mind`. After the start you can observe in the `nodeos` console output the informative details outputs created by the `deep-mind` logger. They distinguish themselves from the default `nodeos` output lines because they start with the `DMLOG` keyword.
+Vaulta integrates the `nodeos` core service daemon with `deep-mind logger`. To benefit from full `deep-mind` logging functionality you must start your `nodeos` instance with the flag `--deep-mind`. After the start you can observe in the `nodeos` console output the informative details outputs created by the `deep-mind` logger. They distinguish themselves from the default `nodeos` output lines because they start with the `DMLOG` keyword.
Examples of `deep-mind` log lines as you would see them in the `nodeos` output console:
diff --git a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/20_prometheus-monitor.md b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/20_prometheus-monitor.md
index ad687a0b..422b8c01 100644
--- a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/20_prometheus-monitor.md
+++ b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/20_prometheus-monitor.md
@@ -4,7 +4,7 @@ title: Prometheus Integration
## Overview
-EOS supports the prometheus plugin which allows data tracing and collection by Prometheus (https://prometheus.io/) of various internal nodeos metrics.
+Vaulta supports the prometheus plugin which allows data tracing and collection by Prometheus (https://prometheus.io/) of various internal nodeos metrics.
Supported metrics are :
diff --git a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/index.md b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/index.md
index cd572e02..b866bad6 100644
--- a/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/index.md
+++ b/native/07_node-operation/10_getting-started/60_logging/20_third-party-logging/index.md
@@ -4,7 +4,7 @@ title: Third-Party Logging And Tracing Integration
## Overview
-To effectively monitor the performance of your EOS-based blockchain node(s), it is essential to utilize telemetry tools. In the EOS ecosystem, there are two recommended telemetry tools available for integration:
+To effectively monitor the performance of your Vaulta-based blockchain node(s), it is essential to utilize telemetry tools. In the Vaulta ecosystem, there are two recommended telemetry tools available for integration:
* [Deep-mind logger](10_deep-mind-logger.md)
* [Prometheus monitor and tracer](20_prometheus-monitor.md)
diff --git a/native/07_node-operation/10_getting-started/60_logging/index.md b/native/07_node-operation/10_getting-started/60_logging/index.md
index df503605..47dd5dcb 100644
--- a/native/07_node-operation/10_getting-started/60_logging/index.md
+++ b/native/07_node-operation/10_getting-started/60_logging/index.md
@@ -2,7 +2,7 @@
title: Logging And Tracing
---
-EOS has the following logging and tracing features:
+Vaulta has the following logging and tracing features:
* [Native Logging](10_native-logging.md)
* [Third-Party Logging And Tracing Integration](20_third-party-logging/index.md)
diff --git a/native/07_node-operation/10_getting-started/70_common-issues.md b/native/07_node-operation/10_getting-started/70_common-issues.md
index cbdd3095..7cebf859 100644
--- a/native/07_node-operation/10_getting-started/70_common-issues.md
+++ b/native/07_node-operation/10_getting-started/70_common-issues.md
@@ -26,4 +26,4 @@ To solve the `Could not grow database file to requested size` error, start `node
## 4. 3070000: WASM Exception Error
-If you get an error such as `Publishing contract... Error 3070000: WASM Exception Error Details: env.set_proposed_producers_ex unresolveable` when you try to deploy `eosio.bios` contract or `eosio.system` contract in an attempt to boot an EOS blockchain (locally or testnet), you must activate the `PREACTIVATE_FEATURE` protocol first.
+If you get an error such as `Publishing contract... Error 3070000: WASM Exception Error Details: env.set_proposed_producers_ex unresolveable` when you try to deploy `eosio.bios` contract or `eosio.system` contract in an attempt to boot an Vaulta blockchain (locally or testnet), you must activate the `PREACTIVATE_FEATURE` protocol first.
diff --git a/native/07_node-operation/20_api-node.md b/native/07_node-operation/20_api-node.md
index 42cb5716..4ca1c256 100644
--- a/native/07_node-operation/20_api-node.md
+++ b/native/07_node-operation/20_api-node.md
@@ -2,7 +2,7 @@
title: Run an API Node
---
-An API node is a critical component of the EOS blockchain network that serves as an interface between users, including dApps, and an EOS blockchain. API nodes serve one of the following roles when handling incoming client requests received through one of the `chain_api_plugin` endpoints:
+An API node is a critical component of the Vaulta blockchain network that serves as an interface between users, including dApps, and a Vaulta blockchain. API nodes serve one of the following roles when handling incoming client requests received through one of the `chain_api_plugin` endpoints:
- **Push API node**: Accepts transactions from HTTP clients and relays them to other peers. Typically does not accept incoming p2p transactions. Upstream traffic only.
- **Chain API node**: Provides access to blockchain data such as accounts, permissions, contract codes/ABIs, contract tables, etc. Takes API transactions too.
@@ -18,16 +18,16 @@ Push API nodes usually only listen to HTTP client requests, and do not accept in
## Why would you use an API node?
-As a developer, you can deploy your own API node to connect to an EOS blockchain and bring the following functionality to your smart contracts and dApps:
+As a developer, you can deploy your own API node to connect to Vaulta and bring the following functionality to your smart contracts and dApps:
- **Data Access**: API nodes allow users to query the blockchain's state and some of its history, accessing information such as account balances, transaction details, smart contract data, and other blockchain-related data.
-- **Transaction Broadcasting**: When users or dApps want to execute a transaction on the EOS blockchain, they submit the transaction to an API node. The node then broadcasts the transaction to the network, ensuring that it reaches all the necessary block producers for inclusion in the blockchain.
+- **Transaction Broadcasting**: When users or dApps want to execute a transaction on Vaulta, they submit the transaction to an API node. The node then broadcasts the transaction to the network, ensuring that it reaches all the necessary block producers for inclusion in the blockchain.
> ℹ️ **Public and Private Nodes**
> API nodes can be public or private. Public nodes are open to the public and can be used by anyone, while private nodes are typically operated by developers, applications, or organizations to manage their interactions with the blockchain privately.
-- **API Endpoints**: API nodes expose various endpoints that allow clients to interact with the blockchain. These endpoints are typically HTTP/HTTPS-based and follow the EOSIO API specifications, making it easier for developers to integrate EOS into their applications.
+- **API Endpoints**: API nodes expose various endpoints that allow clients to interact with the blockchain. These endpoints are typically HTTP/HTTPS-based and follow the Vaulta API specifications, making it easier for developers to integrate Vaulta into their applications.
- **Load Balancing**: Due to the potential high demand for clients accessing the blockchain, many node operators use a cluster of API nodes for load balancing. This ensures that the network can handle a large number of requests without becoming overwhelmed.
@@ -35,30 +35,30 @@ As a developer, you can deploy your own API node to connect to an EOS blockchain
The actual hardware requirements for an API node differ based on the transaction throughput, client requests, available bandwidth, etc. However, the biggest factor depends mainly on whether the API node needs to maintain a blocks log file. For more information on the actual requirements for API nodes, visit the [hardware requirements](./10_getting-started/10_hardware-requirements.md) section, in particular:
-* [API node with blocks log](./10_getting-started/10_hardware-requirements#api-node-with-blocks-log)
-* [API node without blocks log](./10_getting-started/10_hardware-requirements#api-node-without-blocks-log)
+* [API node with blocks log](./10_getting-started/10_hardware-requirements.md#api-node-with-blocks-log)
+* [API node without blocks log](./10_getting-started/10_hardware-requirements.md#api-node-without-blocks-log)
> ℹ️ **Chain API nodes maintain blocks log**
> A Chain API node needs to maintain its own blocks log file to be able to pull data from the blockchain. Maintaining a blocks log file implies that your node replayed the blockchain from a snapshot or from genesis. This allows your API node to sync the blockchain state with other peers and serve client requests quickly by reading the blockchain state locally. A common task performed by a Chain API node is to get table data requested by a dApp or a deployed smart contract.
## Software Requirements
-To setup an API node, first install the Antelope [Leap](https://github.com/AntelopeIO/leap) software. The Leap version to install depends on whether you will deploy your node on an EOS testnet or on the EOS mainnet.
+To setup an API node, first install the Antelope [Leap](https://github.com/AntelopeIO/leap) software. The Leap version to install depends on whether you will deploy your node on an Vaulta testnet or on the Vaulta mainnet.
> ℹ️ **Leap software on mainnet vs. testnets**
-> EOS testnets typically run the most recent Leap versions, usually the latest one shortly after released. The EOS mainnet will typically use a previous stable release version of the Leap software for stability and security.
+> Vaulta testnets typically run the most recent Leap versions, usually the latest one shortly after released. The Vaulta mainnet will typically use a previous stable release version of the Leap software for stability and security.
-To locate which version other API nodes are running for the EOS network you want to deploy on, select your EOS network of choice on the EOS Nation Validate site and navigate to the API report for that network:
+To locate which version other API nodes are running for the Vaulta network you want to deploy on, select your Vaulta network of choice on the EOS Nation Validate site and navigate to the API report for that network:
* https://validate.eosnation.io/
-For instance, for the most recent API nodes on EOS mainnet, EOS Jungle testnet, or EOS Kylin testnet, you can visit, respectively:
+For instance, for the most recent API nodes on Vaulta mainnet, Vaulta Jungle testnet, you can visit, respectively:
* https://validate.eosnation.io/eos/reports/api_versions.txt
* https://validate.eosnation.io/jungle4/reports/api_versions.txt
* https://validate.eosnation.io/kylin/reports/api_versions.txt
-For your API node, you would want to use the same Leap version most other API nodes are using on the EOS network you want to deploy on. You can select the Leap binaries for a specific version here:
+For your API node, you would want to use the same Leap version most other API nodes are using on Vaulta you want to deploy on. You can select the Leap binaries for a specific version here:
* https://github.com/AntelopeIO/leap/tags
@@ -81,23 +81,23 @@ API node type | Maintains blocks log | Accepts p2p transactions | Accepts API tr
Your API node will run its own `nodeos` instance. If you haven't launched `nodeos` or have `data` and `config` folders yet, follow the instructions in this section:
-* Set the main `nodeos` data folder variable according to the EOS network you plan to deploy on:
+* Set the main `nodeos` data folder variable according to the Vaulta network you plan to deploy on:
- For instance, if deploying on the EOS mainnet, you may select:
+ For instance, if deploying on the Vaulta mainnet, you may select:
```ini
- EOSDIR=~/eos/mainnet
+ VAULTADIR=~/vaulta/mainnet
```
- Or, if deploying on the EOS Jungle testnet, you may select:
+ Or, if deploying on the Vaulta Jungle testnet, you may select:
```ini
- EOSDIR=~/eos/jungle_testnet
+ VAULTADIR=~/vaulta/jungle_testnet
```
etc.
* Create the default `config.ini` file - you will edit it in the steps below:
```sh
- mkdir -p $EOSDIR
- nodeos --print-default-config >$EOSDIR/config.ini
+ mkdir -p $VAULTADIR
+ nodeos --print-default-config >$VAULTADIR/config.ini
```
Follow the instructions below to configure an API node as either a Push API, Chain API, or Pull API node. First start with the [Any API node configuration](#any-api-node-configuration), then continue with the API node configuration you selected to deploy:
@@ -109,7 +109,7 @@ The following configuration settings apply to any API node.
* Open the default `config.ini` with your text editor, for instance:
```sh
- vim $EOSDIR/config.ini
+ vim $VAULTADIR/config.ini
```
Edit the default `config.ini` and add/uncomment/modify the following fields:
@@ -276,25 +276,25 @@ Follow the instructions below to download the most recent snapshot:
#### For EOS mainnet
```sh
- wget https://snapshots.eosnation.io/eos-v6/latest -O $EOSDIR/snapshots/latest.bin.zst
+ wget https://snapshots.eosnation.io/eos-v6/latest -O $VAULTADIR/snapshots/latest.bin.zst
```
#### For Jungle testnet
```sh
- wget https://snapshots.eosnation.io/jungle4-v6/latest -O $EOSDIR/snapshots/latest.bin.zst
+ wget https://snapshots.eosnation.io/jungle4-v6/latest -O $VAULTADIR/snapshots/latest.bin.zst
```
#### For Kylin testnet
```sh
- wget https://snapshots.eosnation.io/kylin-v6/latest -O $EOSDIR/snapshots/latest.bin.zst
+ wget https://snapshots.eosnation.io/kylin-v6/latest -O $VAULTADIR/snapshots/latest.bin.zst
```
* Decompress the compressed snapshot:
```sh
- zstd -d $EOSDIR/snapshots/latest.bin.zst
+ zstd -d $VAULTADIR/snapshots/latest.bin.zst
```
The `snapshots` directory should now contain the uncompressed `latest.bin` snapshot.
@@ -304,12 +304,12 @@ The `snapshots` directory should now contain the uncompressed `latest.bin` snaps
Follow the instructions below to restore/start your node from the most recent snapshot that you downloaded.
> â„ą `blocks` directory
-> If you are repeating the instructions above, you might have a ` blocks` directory already in your `$EOSDIR` data directory. Unless you plan to use a blocks log as well, which should at least contain blocks up the snapshot, it is recommended that all existing data in the `blocks` directory is removed: `rm -rf $EOSDIR/blocks` prior to restoring from a snapshot.
+> If you are repeating the instructions above, you might have a ` blocks` directory already in your `$VAULTADIR` data directory. Unless you plan to use a blocks log as well, which should at least contain blocks up the snapshot, it is recommended that all existing data in the `blocks` directory is removed: `rm -rf $VAULTADIR/blocks` prior to restoring from a snapshot.
* Restore/start your node from the latest snapshot:
```sh
- nodeos --data-dir $EOSDIR --config-dir $EOSDIR --snapshot $EOSDIR/snapshots/latest.bin >> $EOSDIR/nodeos.log 2>&1 &
+ nodeos --data-dir $VAULTADIR --config-dir $VAULTADIR --snapshot $VAULTADIR/snapshots/latest.bin >> $VAULTADIR/nodeos.log 2>&1 &
```
The above command will launch `nodeos`, redirecting `stdout` and `stderr` to `nodeos.log`. More importantly, the `--snapshot` option will sync the chain state of your API node to the state of the EOS network you are deploying on, starting from the latest snapshot. This includes accounts, balances, contract code, tables, etc. but not past transaction history, unless you sync from a blocks log. However, after the syncing is done, your API node should continue to receive the latest irreversible blocks produced, which will now include the recent transaction history.
@@ -321,7 +321,7 @@ The above command will launch `nodeos`, redirecting `stdout` and `stderr` to `no
First, make sure your API node launched successfully and it is still syncing or receiving blocks:
```sh
-tail -f $EOSDIR/nodeos.log
+tail -f $VAULTADIR/nodeos.log
```
```
...
@@ -333,7 +333,7 @@ info 2023-08-15T23:16:05.367 nodeos producer_plugin.cpp:651 on_incomin
Second, make sure your API node initialized successfully from the snapshot. Search for `snapshot` in the `nodeos.log` file:
```sh
-grep -i snapshot $EOSDIR/nodeos.log
+grep -i snapshot $VAULTADIR/nodeos.log
```
```
info 2023-08-15T23:15:55.395 nodeos controller.cpp:603 startup ] Starting initialization from snapshot and no block log, this may take a significant amount of time
@@ -390,4 +390,4 @@ Your API node should return a similar response to the last output above. If you
## Summary
-In this guide, you configured and deployed an API node on a specific EOS network, such as EOS mainnet, EOS Jungle testnet, EOS Kylin testnet, etc. You can now get some native assets for that network, and use your API node to deploy EOS smart contracts and send transactions, get blockchain data, or both.
+In this guide, you configured and deployed an API node on a specific Vaulta network, such as Vaulta mainnet, Vaulta Jungle testnet, etc. You can now get some native assets for that network, and use your API node to deploy Vaulta smart contracts and send transactions, get blockchain data, or both.
diff --git a/native/07_node-operation/30_history/01_intro-to-hyperion-full-history.md b/native/07_node-operation/30_history/01_intro-to-hyperion-full-history.md
index ea4548d4..5d8d8bc2 100644
--- a/native/07_node-operation/30_history/01_intro-to-hyperion-full-history.md
+++ b/native/07_node-operation/30_history/01_intro-to-hyperion-full-history.md
@@ -53,11 +53,11 @@ The Hyperion indexer and API are [Node.js](https://nodejs.org/en/) application
The Topology of your Hyperion deployment depends on your history services requirement and the network you intend to index. Whether it’s Public/Private, Mainnet/Testnet or Full/Partial History.
-This guide will discuss EOS Mainnet with Full History. Testnets and Private networks generally have far lower topology and resource requirements.
+This guide will discuss Vaulta Mainnet with Full History. Testnets and Private networks generally have far lower topology and resource requirements.
-**EOS Mainnet**
+**Vaulta Mainnet**
-EOSphere originally started with a single server running all Hyperion Software Components except for the EOS State-History Node. However a challenge was discovered in relation to Elasticsearch JVM heap size when the EOS network utilisation grew and our API became well used.
+EOSphere originally started with a single server running all Hyperion Software Components except for the Vaulta State-History Node. However a challenge was discovered in relation to Elasticsearch JVM heap size when the Vaulta network utilisation grew and our API became well used.
JVM Heap size is the amount of memory allocated to the Java Virtual Machine of an Elasticsearch node, the more heap available the more cache memory available for indexing and search operations. If it’s too low Hyperion Indexing will be slow and search queries will be very latent. If the JVM heap size is more than 32GB (usually lower than this) on an Elasticsearch node, the threshold for compressed ordinary object pointers (OOP) will be exceeded and JVM will stop using compression. This will be exceptionally inefficient in regards to memory management and the node will consume vastly more memory.
@@ -67,7 +67,7 @@ Other benefits to clustering more than one ElasticSearch node are of course more
I recommend reading [Elasticsearch: The Definitive Guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/index.html) as an excellent book to help you understand Elasticsearch concepts.
-Taking the above into account our current recommended topology for the EOS Mainnet is to logically or physically run the following nodes:
+Taking the above into account our current recommended topology for the Vaulta Mainnet is to logically or physically run the following nodes:
* **Load Balancer**
* SSL Offload
@@ -93,9 +93,9 @@ Taking the above into account our current recommended topology for the EOS Mainn
Similar to Hyperion Topology, Hardware choice will vary on your history services requirement.
-The recommendations below are for EOS Mainnet with Full History, in relation to what currently works in the EOSphere Public Service Offerings.
+The recommendations below are for Vaulta Mainnet with Full History, in relation to what currently works in the EOSphere Public Service Offerings.
-**EOS Mainnet**
+**Vaulta Mainnet**
* **Load Balancer**
* Dealers choice, however HAProxy is a great option
diff --git a/native/07_node-operation/30_history/03_configure-hyperion-software-components.md b/native/07_node-operation/30_history/03_configure-hyperion-software-components.md
index 89692ada..2d294bc7 100644
--- a/native/07_node-operation/30_history/03_configure-hyperion-software-components.md
+++ b/native/07_node-operation/30_history/03_configure-hyperion-software-components.md
@@ -341,8 +341,8 @@ The below example `connections.json` is configured for an Antelope Testnet, am
"port": "6379"
},
"chains": {
- "eos": {
- "name": "EOS Testnet",
+ "vaulta": {
+ "name": "Vaulta Testnet",
"chain_id": "g17b1833c747c43682f4386fca9cbb327929334a762755ebec17f6f23c9b8a14",
"http": "http://:8888",
"ship": "ws://:8080",
@@ -357,7 +357,7 @@ The below example `connections.json` is configured for an Antelope Testnet, am
**.config.json**
-The `.config.json` file is named to reflect the chains name in this case `eos.config.json`. The configuration as before needs to be adjusted to suit your own config and deployment using the provided example as a base.
+The `.config.json` file is named to reflect the chains name in this case `vaulta.config.json`. The configuration as before needs to be adjusted to suit your own config and deployment using the provided example as a base.
There are three phases when starting a new Hyperion Indexer, the first phase is what is called the “ABI Scan” which is the default mode in the software provided `example.config.json`.
@@ -368,16 +368,16 @@ Configure as below, take note of the **#UPDATE#** parameters
```bash
> cd ~/hyperion-history-api/chains
-> cp example.config.json eos.config.json
+> cp example.config.json vaulta.config.json
-> nano eos.config.json
+> nano vaulta.config.json
{
"api": {
"enabled": true,
"pm2_scaling": 1,
"node_max_old_space_size": 1024,
- "chain_name": "EOS Testnet", #UPDATE#
+ "chain_name": "Vaulta Testnet", #UPDATE#
"server_addr": "", #UPDATE#
"server_port": 7000,
"stream_port": 1234,
@@ -437,7 +437,7 @@ Configure as below, take note of the **#UPDATE#** parameters
},
"settings": {
"preview": false,
- "chain": "eos", #SET CHAINS ID#
+ "chain": "vaulta", #SET CHAINS ID#
"eosio_alias": "eosio",
"parser": "3.2", #SET TO 1.8 for < 3.1 SHIP#
"auto_stop": 0,
diff --git a/native/07_node-operation/30_history/04_running-hyperion.md b/native/07_node-operation/30_history/04_running-hyperion.md
index c40e23ac..681c1ac1 100644
--- a/native/07_node-operation/30_history/04_running-hyperion.md
+++ b/native/07_node-operation/30_history/04_running-hyperion.md
@@ -59,21 +59,21 @@ ctrl-a+d
## Running the ABI Scan Phase
-Below is the initial configuration used for `eos.config.json` :
+Below is the initial configuration used for `vaulta.config.json` :
```bash
> cd ~/hyperion-history-api/chains
-> cp example.config.json eos.config.json
+> cp example.config.json vaulta.config.json
-> nano eos.config.json
+> nano vaulta.config.json
{
"api": {
"enabled": true,
"pm2_scaling": 1,
"node_max_old_space_size": 1024,
- "chain_name": "EOS Testnet",
+ "chain_name": "Vaulta Testnet",
"server_addr": "",
"server_port": 7000,
"stream_port": 1234,
@@ -133,7 +133,7 @@ Below is the initial configuration used for `eos.config.json` :
},
"settings": {
"preview": false,
- "chain": "eos", #SET CHAINS ID#
+ "chain": "vaulta", #SET CHAINS ID#
"eosio_alias": "eosio",
"parser": "3.2", #SET TO 1.8 for < 3.1 SHIP#
"auto_stop": 0,
@@ -232,9 +232,9 @@ This phase may take many hours depending on your hardware and network connectivi
## Running the Indexing Phase
-In this phase the `eos.config.json` needs to be amended to disable abi_scan_mode and block batches to be ingested configured. My recommendation is to start with batches of 5000000 to ensure all is being ingested smoothly.
+In this phase the `vaulta.config.json` needs to be amended to disable abi_scan_mode and block batches to be ingested configured. My recommendation is to start with batches of 5000000 to ensure all is being ingested smoothly.
-Make sure the following is configured or amended in the `eos.config.json` :
+Make sure the following is configured or amended in the `vaulta.config.json` :
```bash
"enable_caching": false, #DISABLED FOR BULK INDEXING#
@@ -274,7 +274,7 @@ http://:15672
When the first 5000000 blocks are successfully indexed the indexer will stop and a message will be displayed in the pm2 logs advising `BLOCK RANGE COMPLETED`.
-The indexer block range can now be adjusted in the `eos.config.json` for the next batch and then the indexer can be started as before. Depending on how your deployment has managed you may want to increase or decrease this range.
+The indexer block range can now be adjusted in the `vaulta.config.json` for the next batch and then the indexer can be started as before. Depending on how your deployment has managed you may want to increase or decrease this range.
```bash
"start_on": 5000001,#CONTINUE FROM FIRST BATCH#
@@ -289,7 +289,7 @@ Bulk indexing can be very heavy on hardware resources and can take days. You wil
When indexing has been completed to as close to the current chain headblock as possible, you can transition to a normal mode of index operation. This phase will enable the live reader, normal block ingestion and caching.
-Make sure the following is configured or amended in the `eos.config.json` :
+Make sure the following is configured or amended in the `vaulta.config.json` :
```bash
"enable_caching": true,
@@ -325,7 +325,7 @@ This final phase is running the Hyperion API which has already been configured i
"enabled": true,
"pm2_scaling": 1,
"node_max_old_space_size": 1024,
- "chain_name": "EOS Testnet",
+ "chain_name": "Vaulta Testnet",
"server_addr": "",
"server_port": 7000,
"stream_port": 1234,
diff --git a/native/07_node-operation/50_tutorials/10_watching-transfers.md b/native/07_node-operation/50_tutorials/10_watching-transfers.md
index 49a2f126..93352358 100644
--- a/native/07_node-operation/50_tutorials/10_watching-transfers.md
+++ b/native/07_node-operation/50_tutorials/10_watching-transfers.md
@@ -2,10 +2,10 @@
title: Watching Transfers
---
-You might want to watch for all transfers that happen within the EOS Network. This is useful for **exchanges** and
+You might want to watch for all transfers that happen within Vaulta. This is useful for **exchanges** and
**wallets** that need to keep track of incoming/outgoing funds.
-In EOS, there are multiple ways that a transfer can occur. The most common way is through a `transfer` action on a transaction
+In Vaulta, there are multiple ways that a transfer can occur. The most common way is through a `transfer` action on a transaction
directly, but a transfer can also occur as an inline action on triggered by a non-transfer action. If you are only
watching blocks, then you will miss the inline action transfers. This could impact your users' experience.
@@ -16,7 +16,7 @@ watching blocks, then you will miss the inline action transfers. This could impa
> action, as it occurred from a `exchange::withdraw` action. It was a non-root-level action.
Though this tutorial centers around watching for transfers, you can use the same method to watch for any action that
-occurs on the EOS Network, from any contract.
+occurs on Vaulta, from any contract.
## Download the token ABI
@@ -25,13 +25,13 @@ contract yourself, or you can download the ABI directly.
### Using curl
-You can use `curl` to fetch the ABI directly from the EOS Mainnet.
+You can use `curl` to fetch the ABI directly from Vaulta.
```shell
curl -X POST \
-H "Content-Type: application/json" \
-d '{ "account_name":"eosio.token" }' \
- https://eos.greymass.com/v1/chain/get_abi | jq -r '.abi' > ./eosio.token.abi
+ https://vaulta.greymass.com/v1/chain/get_abi | jq -r '.abi' > ./eosio.token.abi
```
The command above will fetch the ABI for the `eosio.token` contract's ABI and save it to a file called `eosio.token.abi`.
@@ -239,7 +239,7 @@ read this.
### Compiling the contract yourself
-You can clone the [EOS System Contracts](https://github.com/eosnetworkfoundation/eos-system-contracts/) repository,
+You can clone the [Vaulta System Contracts](https://github.com/vaultafoundation/system-contracts/) repository,
and then compile the contracts using the `build.sh` script.
You will then have a `build/contracts` directory that contains the compiled contracts.
@@ -267,11 +267,11 @@ Once you enable the Trace API, you will only get traces for blocks that are prod
If you want to get traces for blocks that were produced before you enabled the plugin, you will need to replay the chain
from that block.
-> đź•” **Want to replay from EOS EVM launch?**
+> đź•” **Want to replay from Vaulta EVM launch?**
>
-> If your aim is to get traces for transfers that happen on the EOS EVM, you can use a snapshot that was taken on or before
-> 2023-04-05T02:18:09 UTC. That way you will be able to get traces for transfers that happened on the EOS EVM, but not
-> waste time replaying blocks that were produced before the EOS EVM launch.
+> If your aim is to get traces for transfers that happen on the Vaulta EVM, you can use a snapshot that was taken on or before
+> 2023-04-05T02:18:09 UTC. That way you will be able to get traces for transfers that happened on the Vaulta EVM, but not
+> waste time replaying blocks that were produced before the Vaulta EVM launch.
## SSD considerations
@@ -329,7 +329,7 @@ There are some other important things to note about the Trace API's `get_block`
> đź“„ **API reference**
>
-> For more information about the Trace API, see the [API Reference](https://docs.eosnetwork.com/apis/leap/latest/trace_api.api).
+> For more information about the Trace API, see the [API Reference](https://docs.vaulta.com/apis/leap/latest/trace_api.api).
### Examples of both formats
@@ -563,8 +563,8 @@ When listening for actions there are three primary fields you want to look for.
- **params** - contains the parameters that were passed to the action
- **receiver** - tells you which contract is receiving the action
-If you were listening for token transfers of **EOS**, you would want to look for actions where the
-**account** field is `eosio.token` and the **action** field is `transfer`.
+If you were listening for token transfers of **Vaulta**, you would want to look for actions where the
+**account** field is `core.vaulta` and the **action** field is `transfer`.
Then, you'll want to validate the information inside the `params` object.
@@ -581,7 +581,7 @@ name, and possibly that the memo field matches some identifier that you're expec
JavaScript example of checking for transfers
```javascript
-const CONTRACT = "eosio.token";
+const CONTRACT = "core.vaulta";
const ACTION = "transfer";
const YOUR_ACCOUNT = "someexchange";
@@ -612,7 +612,7 @@ for(let transaction of result.transactions) {
const [amount, symbol] = quantity.split(' ');
// You should also check that the symbol matches
// the symbol that you're expecting as well
- if(symbol !== 'EOS') {
+ if(symbol !== 'A') {
// This is not the token that we're expecting
continue;
}
@@ -729,5 +729,5 @@ This will give you a single transaction trace in exactly the same format as the
> đź“„ **API reference**
>
-> For more information about the Trace API, see the [API Reference](https://docs.eosnetwork.com/apis/leap/latest/trace_api.api).
+> For more information about the Trace API, see the [API Reference](https://docs.vaulta.com/apis/leap/latest/trace_api.api).
diff --git a/native/60_advanced-topics/02_transactions-protocol.md b/native/60_advanced-topics/02_transactions-protocol.md
index ce813ea4..4106e7c0 100644
--- a/native/60_advanced-topics/02_transactions-protocol.md
+++ b/native/60_advanced-topics/02_transactions-protocol.md
@@ -10,9 +10,9 @@ Actions define atomic behaviors within a smart contract. At a higher level, tran
### 1.1. Actions
-An action can be authorized by one or more actors previously created on the blockchain. Actions can be created explicitly within a smart contract, or generated implicitly by application code. For any given `actor:action` pair there is at most one explicit associated minimum permission. If there are no explicit minimum permissions set, the implicit default is `actor@active`. Each actor can independently set their personal minimum permission for a given action. Also, a complex but flexible authorization structure is in place within the EOS software to allow actors to push actions on behalf of other accounts. Thus, further checks are enforced to authorize an actor to send an action (see [3.4.2. Permission Check](#342-permission-check)).
+An action can be authorized by one or more actors previously created on the blockchain. Actions can be created explicitly within a smart contract, or generated implicitly by application code. For any given `actor:action` pair there is at most one explicit associated minimum permission. If there are no explicit minimum permissions set, the implicit default is `actor@active`. Each actor can independently set their personal minimum permission for a given action. Also, a complex but flexible authorization structure is in place within the Vaulta software to allow actors to push actions on behalf of other accounts. Thus, further checks are enforced to authorize an actor to send an action (see [3.4.2. Permission Check](#342-permission-check)).
-There are two types of actions involved in a transaction. They mainly differ in the way they are executed by the EOS software:
+There are two types of actions involved in a transaction. They mainly differ in the way they are executed by the Vaulta software:
1. Explicit actions, which are present in a signed transaction (see [2. Transaction Instance](#2-transaction-instance)).
2. Implicit (inline) actions, which are created as a side effect of processing a transaction.
@@ -32,12 +32,12 @@ An implicit (inline) action is generated as a result of an explicit caller actio
### 1.2. Smart Contracts
-In EOS, smart contracts consist of a set of actions, usually grouped by functionality, and a set of type definitions which those actions depend on. Therefore, actions specify and define the actual behaviors of the contract. Several actions are implemented in the standard EOS contracts for account creation, producer voting, token operations, etc. Application developers can extend, replace, or disable this functionality altogether by creating custom actions within their own smart contracts and applications. Transactions, on the other hand, are typically created at the application level. Smart contracts are agnostic to them.
+In Vaulta, smart contracts consist of a set of actions, usually grouped by functionality, and a set of type definitions which those actions depend on. Therefore, actions specify and define the actual behaviors of the contract. Several actions are implemented in the standard Vaulta contracts for account creation, producer voting, token operations, etc. Application developers can extend, replace, or disable this functionality altogether by creating custom actions within their own smart contracts and applications. Transactions, on the other hand, are typically created at the application level. Smart contracts are agnostic to them.
#### 1.2.1. Implementation
-An EOS smart contract is implemented as a C++ class that derives from `eosio::contract`. Actions are implemented as C++ methods within the derived class. Transactions, on the other hand, are generated dynamically (as transaction instances) within an EOS application. The EOS software processes each transaction instance and keeps track of its state as it evolves from creation, signing, validation, and execution.
+An Vaulta smart contract is implemented as a C++ class that derives from `eosio::contract`. Actions are implemented as C++ methods within the derived class. Transactions, on the other hand, are generated dynamically (as transaction instances) within an Vaulta application. The Vaulta software processes each transaction instance and keeps track of its state as it evolves from creation, signing, validation, and execution.
## 2. Transaction Instance
@@ -77,7 +77,7 @@ Name | Type | Description
### 2.3. Packed Transaction Instance
-A packed transaction is an optionally compressed signed transaction with additional housekeeping fields to allow for decompression and quick validation. Packed transactions minimize space footprint and block size in the long run (see `packed_transaction` schema below). A packed transaction forms the most generic type of transaction in the EOS blockchain. Consequently, when transactions are pushed to a block, they are actually packed transactions whether compressed or not.
+A packed transaction is an optionally compressed signed transaction with additional housekeeping fields to allow for decompression and quick validation. Packed transactions minimize space footprint and block size in the long run (see `packed_transaction` schema below). A packed transaction forms the most generic type of transaction in the Vaulta blockchain. Consequently, when transactions are pushed to a block, they are actually packed transactions whether compressed or not.
#### packed_transaction schema
@@ -95,7 +95,7 @@ The `unpacked_trx` field holds the cached unpacked transaction after the transac
## 3. Transaction Lifecycle
-Transactions go through various stages during their lifespan. First, a transaction is created in an application or an EOS client such as cleos by pushing the associated actions into the transaction. Next, the transaction is sent to the locally connected node, which in turn relays it to the active producing nodes for validation and execution via the peer-to-peer network. Next, the validated transaction is pushed to a block by the active producer on schedule along with other transactions. Finally the block that contains the transaction is pushed to all other nodes for validation. When a supermajority of producers have validated the block, and the block becomes irreversible, the transaction gets permanently recorded in the blockchain and it is considered immutable.
+Transactions go through various stages during their lifespan. First, a transaction is created in an application or an Vaulta client such as cleos by pushing the associated actions into the transaction. Next, the transaction is sent to the locally connected node, which in turn relays it to the active producing nodes for validation and execution via the peer-to-peer network. Next, the validated transaction is pushed to a block by the active producer on schedule along with other transactions. Finally the block that contains the transaction is pushed to all other nodes for validation. When a supermajority of producers have validated the block, and the block becomes irreversible, the transaction gets permanently recorded in the blockchain and it is considered immutable.
### 3.1. Create Transaction
@@ -111,14 +111,14 @@ Name | Type | Description
`authorization` | array of `permission_level` | list of `actor:permission` authorizations
`data` | `bytes` | action data to send
-After the transaction instance is created at the application level, the transaction is arranged for processing. This involves two main steps: signing the transaction and pushing the signed transaction to the local node for actual propagation and execution of the transaction. These steps are typically performed within the EOS application.
+After the transaction instance is created at the application level, the transaction is arranged for processing. This involves two main steps: signing the transaction and pushing the signed transaction to the local node for actual propagation and execution of the transaction. These steps are typically performed within the Vaulta application.
### 3.2. Sign Transaction
The transaction must be signed by a set of keys sufficient to satisfy the accumulated set of explicit `actor:permission` pairs specified in all the actions enclosed within the transaction. This linkage is done through the authority table for the given permission. The actual signing key is obtained by querying the wallet associated with the signing account on the client where the application is run.
-The transaction signing process takes three parameters: the transaction instance to sign, the set of public keys from which the associated private keys within the application wallet are retrieved, and the chain ID. The chain ID identifies the actual EOS blockchain and consists of a hash of its genesis state, which depends on the blockchain’s initial configuration parameters. Before signing the transaction, the EOS software first computes a digest of the transaction. The digest value is a SHA-256 hash of the chain ID, the transaction instance, and the context free data if the transaction has any context free actions. Any instance fields get serialized before computing any cryptographic hashes to avoid including reference fields (memory addresses) in the hash computation. The transaction digest computation and the signing process are depicted below.
+The transaction signing process takes three parameters: the transaction instance to sign, the set of public keys from which the associated private keys within the application wallet are retrieved, and the chain ID. The chain ID identifies the actual Vaulta blockchain and consists of a hash of its genesis state, which depends on the blockchain’s initial configuration parameters. Before signing the transaction, the Vaulta software first computes a digest of the transaction. The digest value is a SHA-256 hash of the chain ID, the transaction instance, and the context free data if the transaction has any context free actions. Any instance fields get serialized before computing any cryptographic hashes to avoid including reference fields (memory addresses) in the hash computation. The transaction digest computation and the signing process are depicted below.
@@ -132,7 +132,7 @@ After the transaction is signed, a packed transaction instance is created from t
### 3.4. Verify Transaction
-The process to verify a transaction is twofold. First, the public keys associated with the accounts that signed the transaction are recovered from the set of signatures provided in the transaction. Such a recovery is cryptographically possible for ECDSA, the elliptic curve digital signature algorithm used in EOS. Second, the public key of each actor specified in the list of action authorizations (actor:permission) from each action included in the transaction is checked against the set of recovered keys to see if it is satisfied. Third, each satisfied `actor:permission` is checked against the associated minimum permission required for that `actor:contract::action` pair to see if it meets or exceeds that minimum. This last check is performed at the action level before any action is executed (see [3.4.2. Permission Check](#342-permission-check)).
+The process to verify a transaction is twofold. First, the public keys associated with the accounts that signed the transaction are recovered from the set of signatures provided in the transaction. Such a recovery is cryptographically possible for ECDSA, the elliptic curve digital signature algorithm used in Vaulta. Second, the public key of each actor specified in the list of action authorizations (actor:permission) from each action included in the transaction is checked against the set of recovered keys to see if it is satisfied. Third, each satisfied `actor:permission` is checked against the associated minimum permission required for that `actor:contract::action` pair to see if it meets or exceeds that minimum. This last check is performed at the action level before any action is executed (see [3.4.2. Permission Check](#342-permission-check)).
#### 3.4.1. Transaction Context
@@ -142,7 +142,7 @@ Once the public keys are recovered, a transaction context is created from the tr
#### 3.4.2. Permission Check
-Since the sequence of actions contained in the transaction must be executed atomically as a whole, the EOS software first checks that the actors specified in each action have the minimum permission required to execute it. To that end, the software checks the following for each action:
+Since the sequence of actions contained in the transaction must be executed atomically as a whole, the Vaulta software first checks that the actors specified in each action have the minimum permission required to execute it. To that end, the software checks the following for each action:
* The named permission of each actor specified in each action instance.
* The named permission of the corresponding `actor:contract::action` pair specified in the smart contract.
@@ -217,7 +217,7 @@ Deferred transactions are generated as a side effect of processing the blockchai
> âš **Warning:**
> Deprecation Notice
-> Deferred transactions are deprecated as of EOS 2.0.
+> Deferred transactions are deprecated as of Vaulta 2.0.
#### 3.6.3. Delayed User Transactions
diff --git a/native/60_advanced-topics/10_understanding-ABI-files.md b/native/60_advanced-topics/10_understanding-ABI-files.md
index b1d23656..521cdcb0 100644
--- a/native/60_advanced-topics/10_understanding-ABI-files.md
+++ b/native/60_advanced-topics/10_understanding-ABI-files.md
@@ -18,17 +18,17 @@ CONTRACT mycontract : public contract {
public:
using contract::contract;
TABLE user {
- name eos_account;
+ name account;
uint8_t is_admin;
uint64_t primary_key() const {
- return eos_account.value;
+ return account.value;
}
};
using user_table = eosio::multi_index<"users"_n, user>;
- ACTION newuser( name eos_account ){}
+ ACTION newuser( name account ){}
};
```
@@ -44,7 +44,7 @@ The code above will produce the following JSON ABI:
"base": "",
"fields": [
{
- "name": "eos_account",
+ "name": "account",
"type": "name"
}
]
@@ -54,7 +54,7 @@ The code above will produce the following JSON ABI:
"base": "",
"fields": [
{
- "name": "eos_account",
+ "name": "account",
"type": "name"
},
{
@@ -138,7 +138,7 @@ Structs are custom data structures defined in the contract. They are often used
"base": "",
"fields": [
{
- "name": "eos_account",
+ "name": "account",
"type": "name"
}
]
diff --git a/native/60_advanced-topics/20_introduction-finalizers-voting.md b/native/60_advanced-topics/20_introduction-finalizers-voting.md
index 1be27919..6b9ca5e0 100644
--- a/native/60_advanced-topics/20_introduction-finalizers-voting.md
+++ b/native/60_advanced-topics/20_introduction-finalizers-voting.md
@@ -10,10 +10,10 @@ title: Introduction to Finalizers and Voting
- Be aware of vote routing topology and activate vote threads to relay votes.
## Introduction to Finalizers and Voting
-The EOS blockchain bundles together transactions into blocks, and working across 21 producers comes to a consensus on those blocks before marking them as irreversible. EOS continues to advance its blockchain technology, has added Finalizers in Spring v1.0. Finalizers enable the blockchain to mark blocks as irreversible seconds after they are published. This improvement in time to finality does not come at the cost of safety. Marking a block as irreversible continues to require agreement from 15 out of the top 21 producers.
+The Vaulta blockchain bundles together transactions into blocks, and working across 21 producers comes to a consensus on those blocks before marking them as irreversible. Vaulta continues to advance its blockchain technology, has added Finalizers in Spring v1.0. Finalizers enable the blockchain to mark blocks as irreversible seconds after they are published. This improvement in time to finality does not come at the cost of safety. Marking a block as irreversible continues to require agreement from 15 out of the top 21 producers.
## Finalizer
-In Spring v1.0, Finalizers are tightly coupled to the role of the block producer and publisher. Only the top 21 block producers may vote to advance finality. The top block producers are determined by the votes they receive from community members who stake their EOS. This distributed proof of stake remains unchanged and continues the distributed governance model that has worked so well for EOS. Starting with Spring v1.0, block producers have the authority to run two separate functions.
+In Spring v1.0, Finalizers are tightly coupled to the role of the block producer and publisher. Only the top 21 block producers may vote to advance finality. The top block producers are determined by the votes they receive from community members who stake their Vaulta. This distributed proof of stake remains unchanged and continues the distributed governance model that has worked so well for Vaulta. Starting with Spring v1.0, block producers have the authority to run two separate functions.
- Block Publish: Bundles together transactions into a block, and links that block and transaction to previous blocks and transactions.
- Finalizer: Cryptographic verification of the on-chain transactions
@@ -23,7 +23,7 @@ To lower the time to irreversible blocks, also know as time to finality, produce
The top block producers alternate publishing blocks on a schedule determined by their accumulated votes. This publishing period is called a round. If a publisher is unavailable during its round, that publisher is skipped over and another publisher takes their place.
### Voting Overview
-Unlike the Block Publishing process, voting does not have a schedule. There are no rounds. The top 21 block producers submit votes on every block. Agreement on the state of the chain from 15 of the top 21 is required before a block may be marked as irreversible. Currently there is no penalty if a block producer's vote is not included as part of the finality calculation. If the EOS blockchain fails to get votes, or those votes disagree on the state of the chain, finality will not advance, and the last irreversible block will remain unchanged.
+Unlike the Block Publishing process, voting does not have a schedule. There are no rounds. The top 21 block producers submit votes on every block. Agreement on the state of the chain from 15 of the top 21 is required before a block may be marked as irreversible. Currently there is no penalty if a block producer's vote is not included as part of the finality calculation. If the Vaulta blockchain fails to get votes, or those votes disagree on the state of the chain, finality will not advance, and the last irreversible block will remain unchanged.
Votes include a cryptographically signed digest for the Merkle tree representing the current state of the blockchain. As the chain adds transactions and changes those digest will change. To quickly and efficiently vote each Finalizer has a `safety.dat` file which stores this history of votes, and the digest that have been voted on. The digest stored in the history file is used as a reference point for calculating future digests from incoming blocks and transactions.
@@ -40,7 +40,7 @@ Activating a new, never used, BLS Key is always safe. There is no voting history
Please take care when managing the `safety.dat` file. Please do not share BLS keys across hosts, or reuse the same BLS key when moving from host to host. Sharing and reuse of BLS Keys may result in a corrupted or partial voting history.
### Continuous Voting
-Unlike block publishing, for the top 21 block producers, voting is continuous. Taking a producer offline would prevent that producer from voting to advance finality. To support continuous voting and manage various support scenarios the EOS blockchain provides on chain actions to register, activate, and delete BLS Keys. Using these actions, a producer can quickly rotate to a new BLS Key.
+Unlike block publishing, for the top 21 block producers, voting is continuous. Taking a producer offline would prevent that producer from voting to advance finality. To support continuous voting and manage various support scenarios the Vaulta blockchain provides on chain actions to register, activate, and delete BLS Keys. Using these actions, a producer can quickly rotate to a new BLS Key.
For this reason it is recommended that each producer instance uses its own unique BLS Key, and activates the BLS Key when going online. There are many strategies for [managing BLS Keys](../managing-finalizer-keys).
diff --git a/native/60_advanced-topics/21_managing-finalizer-keys.md b/native/60_advanced-topics/21_managing-finalizer-keys.md
index 1465ad21..97d46028 100644
--- a/native/60_advanced-topics/21_managing-finalizer-keys.md
+++ b/native/60_advanced-topics/21_managing-finalizer-keys.md
@@ -30,7 +30,7 @@ Setting `vote-threads` on a nodeos instance is expensive, consuming CPU and addi
Block Producers may have an intermediate nodeos instance sitting in between their block producing nodeos and peer finalizers. In this setup each nodeos, local finalizer, intermediate node, and peer finalizer, must be able to send and forward votes. With this setup there would be a BLS finalizer key for the block producing nodes. The intermediate node would not need a BLS finalizer key. The intermediate node must set their `vote-threads` > 0 *default in Spring v1 is 4 threads*.
### Rotating Keys
-The EOS blockchain, allows producers to activate new BLS finalizer keys at anytime with an on-chain action `actfinkey`. Before called the `actfinkey` action, the key must already exist in the `signature-provider` configuration when the instance of nodeos is started, and the key must be registered using the `regfinkey` action. Activating a new BLS finalizer key is always safe, and may be performed at anytime.
+The Vaulta blockchain, allows producers to activate new BLS finalizer keys at anytime with an on-chain action `actfinkey`. Before called the `actfinkey` action, the key must already exist in the `signature-provider` configuration when the instance of nodeos is started, and the key must be registered using the `regfinkey` action. Activating a new BLS finalizer key is always safe, and may be performed at anytime.
See How To [Rotate BLS Finalizer Keys](../../node-operation/tutorials/Rotate-BLS-Finalizer-Keys) for specific instructions on moving to new finalizer keys
diff --git a/native/60_advanced-topics/22_upgrading-to-vaulta.md b/native/60_advanced-topics/22_upgrading-to-vaulta.md
new file mode 100644
index 00000000..f98bb0af
--- /dev/null
+++ b/native/60_advanced-topics/22_upgrading-to-vaulta.md
@@ -0,0 +1,311 @@
+---
+title: Upgrading to Vaulta from EOS
+sidebar_label: Upgrading to Vaulta
+---
+
+The EOS Network has rebranded to Vaulta.
+There are some basic changes to the network that you need to be aware of when upgrading your applications to Vaulta.
+
+## Basic information
+
+- Network name: **Vaulta**
+- System contract: `core.vaulta`
+- Token symbol: **A**
+- Token precision: **4**
+- Token contract: `core.vaulta`
+- Token swap contract: `core.vaulta`
+- Token swap ratio: **1:1**
+
+## The system contract
+
+The new system contract is `core.vaulta` which serves three purposes:
+- It is a token contract for the new token `A`
+- It is a token swap contract
+- It is a system contract that wraps all the functionality of the old system contract (`eosio`)
+
+The new system contract is a drop-in replacement for the old system contract.
+You can use the same user-facing actions that you would with the `eosio` contract, except that the token symbol is
+now `A` instead of `EOS` for all actions that have an `asset` that expects `EOS` as the symbol.
+
+## The token
+
+The new `A` token is a drop-in replacement for `EOS`, has the same precision (4), and max supply (2.1 billion).
+
+### Integrating the new token
+
+You will need to add new handlers for catching token transfers to your smart contracts if you want to support the
+`A` token.
+
+```cpp
+[[eosio::on_notify("core.vaulta::transfer")]]
+void on_transfer(name from, name to, asset quantity, string memo) {
+ // Fail out on self transfers and transfers not to this contract
+ if (from == get_self() || to != get_self()) return;
+
+ // ... do your logic here
+}
+```
+
+If you want to simply make sure that your `EOS` supporting contract isn't allowing `A` transfers, you can
+prevent the action from being executed by checking the symbol of the asset or contract.
+
+```cpp
+// Deny transfers from all tokens except EOS/eosio.token
+[[eosio::on_notify("*::transfer")]]
+void on_transfer(name from, name to, asset quantity, string memo) {
+ if (from == get_self() || to != get_self()) return;
+
+ // The contract that initiated the transfer
+ auto contract = get_first_receiver();
+ if (contract != name("eosio.token")) {
+ check(false, "This contract only supports EOS transfers");
+ }
+}
+
+// Or explicitly denying A transfers
+[[eosio::on_notify("core.vaulta::transfer")]]
+void on_vaulta(name from, name to, asset quantity, string memo) {
+ // Keep in mind you still want these checks, or you will not be able to
+ // transfer A from the smart contract.
+ if (from == get_self() || to != get_self()) return;
+ check(false, "This contract does not support Vaulta (A) transfers");
+}
+```
+
+### Transferring Vaulta tokens
+
+Transferring Vaulta tokens is the same as transferring EOS tokens.
+
+Here is an example using [Wharfkit](https://wharfkit.com/) to transfer `A` tokens:
+
+```javascript
+import { Session, Chains } from "@wharfkit/session"
+// See here for more wallet plugins: https://wharfkit.com/plugins?tag=wallet-plugin
+import { WalletPluginPrivateKey } from "@wharfkit/wallet-plugin-privatekey"
+
+const session = new Session({
+ chain: Chains.Vaulta,
+ actor: "youraccount",
+ permission: "active",
+
+ // Never use this plugin in the frontend!
+ walletPlugin: new WalletPluginPrivateKey(
+ process.env.YOUR_PRIVATE_KEY
+ ),
+}, {});
+
+const result = await session.transact({
+ action: {
+ account: "core.vaulta",
+ name: "transfer",
+ authorization: [session.permissionLevel],
+ data: {
+ from: session.actor, // this is your account
+ to: "change.me", // the recipient's account
+ quantity: "100.0000 A",
+ memo: "your optional extra data", // optional, can be blank
+ },
+ },
+})
+```
+
+
+
+### Getting a balance
+
+You can get a balance in the same way that you would with the `eosio.token` contract.
+
+Here is an example using [Wharfkit](https://wharfkit.com/) to get a balance:
+
+```javascript
+import { APIClient } from "@wharfkit/antelope"
+const client = new APIClient({ url: "https://vaulta.greymass.com" });
+// or session.client
+const response = await client.v1.chain.get_table_rows(
+ {
+ code: "core.vaulta",
+ scope: "some.account",
+ table: "accounts",
+ json: true
+ }
+);
+console.log(
+ JSON.stringify(response, null, 4)
+)
+```
+
+## Swapping
+
+If you have EOS in your account, you will need to swap it to `A`.
+The swap is a 1:1 swap, so you will get the same amount of `A` as you had EOS.
+
+### RAM considerations
+
+The swap contract will sponsor the RAM required for the swap, so you do not need to worry about RAM costs
+when swapping, however you will need 241 bytes of RAM available in your account on your first transfer.
+
+### Swapping from EOS to `A`
+
+Swapping from EOS to `A` is as simple as sending your EOS tokens to the new system contract (`core.vaulta`).
+You can do this using any wallet that supports the EOS network, or using javascript like below.
+
+Here is an example using [Wharfkit](https://wharfkit.com/) to swap from EOS to `A`:
+
+```javascript
+await api.transact({
+ actions: [{
+ // using the EOS token contract
+ account: "eosio.token",
+ name: "transfer",
+ authorization: [session.permissionLevel],
+ data: {
+ from: session.actor,
+ to: "core.vaulta",
+ quantity: "100.0000 EOS",
+ memo: ""
+ }
+ }]
+}, {
+ blocksBehind: 3,
+ expireSeconds: 30,
+});
+
+```
+
+In the transfer above, the sender account will get back the same amount of `A` as the amount of EOS
+they sent to the `core.vaulta` contract, in this case `100.0000 A`.
+
+Here is an example of using cleos to swap from EOS to `A`:
+
+```bash
+cleos push action core.vaulta transfer '["youraccount", "change.me", "100.0000 A", "your optional memo"]' -p
+youraccount
+```
+
+> âš **Take precautions**
+>
+> Make sure to double check the recipient address before sending your tokens. If you send to the wrong address,
+> you will not be able to get your tokens back. You should also try to use a small amount first to test the
+> transaction before sending a large amount.
+
+### Swapping to another account
+
+You can swap tokens from your account to another account using the `swapto` action.
+
+```cpp
+swapto(
+ const name& from,
+ const name& to,
+ const asset& quantity,
+ const std::string& memo
+)
+```
+
+```javascript
+await session.transact({
+ action: {
+ account: "core.vaulta",
+ name: "swapto",
+ authorization: [session.permissionLevel],
+ data: {
+ from: session.actor,
+ to: "some.account",
+ quantity: "100.0000 EOS",
+ memo: "",
+ },
+ },
+})
+```
+
+This will swap 100 EOS in your account to 100 `A` and send it to the `some.account` account.
+
+> âš **Important**
+>
+> You do **NOT** need to catch the `swapto` action in your smart contract. This is a special action that
+> wraps the `transfer` action and is only used for the swap. You will still be able to catch the underlying
+> `transfer` action in your contract.
+
+#### Blocking this to your account
+
+You might not want your account to be able to be a recipient of the `swapto` action.
+For instance if you are a centralized exchange and you want to prevent your users from
+swapping to your account and possibly sending you untracked tokens.
+
+You can prevent this by adding your own account to a blocklist.
+
+```cpp
+ACTION blockswapto(name account, bool blocked);
+```
+
+Here is and example using [Wharfkit](https://wharfkit.com/) to block the `swapto` action:
+
+```javascript
+await session.transact({
+ action: {
+ account: "core.vaulta",
+ name: "blockswapto",
+ authorization: [session.permissionLevel],
+ data: {
+ account: session.actor,
+ blocked: true
+ },
+ },
+})
+```
+
+Example using cleos:
+
+```bash
+cleos push action core.vaulta blockswapto '["youraccount", true]' -p youraccount
+```
+
+## System contract actions
+
+The new system contract has the same actions as the old system contract, except that the token symbol is now `A`.
+With actions that would normally expect EOS, you will need to use `A` instead.
+
+For example, if you wanted to buy RAM using Vaulta tokens, you would do it like this:
+
+```javascript
+await session.transact({
+ action: {
+ account: "core.vaulta",
+ name: "buyram",
+ authorization: [session.permissionLevel],
+ data: {
+ payer: session.actor,
+ receiver: session.actor,
+ quant: "1.0000 A"
+ },
+ },
+})
+```
+
+You will also get `A` tokens back if you sell RAM.
+
+```javascript
+await session.transact({
+ action: {
+ account: "core.vaulta",
+ name: "sellram",
+ authorization: [session.permissionLevel],
+ data: {
+ account: session.actor,
+ bytes: 1024
+ },
+ },
+})
+```
+
+
+## Q&A
+
+- **What happens to staked eos (in REX or staked to an account)?**
+ - All staked EOS will be automatically swapped when withdrawing from the new system contract. You do not need to do anything to swap your staked EOS.
+- **What if I don't swap in time?**
+ - You will always be able to move from EOS to `A`
+- **Can I swap back from `A` to EOS?**
+ - This is a period where a bidirectional swap is supported. You can send your Vaulta tokens to the `core.vaulta` contract and get back EOS tokens.
+ - This is aimed at making sure that contract developers and users have time to upgrade their contracts and wallets to support the new token.
+
+
diff --git a/native/60_advanced-topics/30_staking/01_overview.md b/native/60_advanced-topics/30_staking/01_overview.md
index dd2bb9b7..52ab4b5b 100644
--- a/native/60_advanced-topics/30_staking/01_overview.md
+++ b/native/60_advanced-topics/30_staking/01_overview.md
@@ -6,12 +6,12 @@ title: Overview
Staking Overview
-EOS Staking is a system-level contract that allows users to stake their EOS tokens to
+Vaulta Staking is a system-level contract that allows users to stake their Vaulta tokens to
receive rewards from the network.
## Lockup periods
-When you stake your EOS tokens you lock them up for a certain period of time.
+When you stake your Vaulta tokens you lock them up for a certain period of time.
The minimum lockup period is 21 days, but that period could be longer depending on when
you as the user decide to unstake your tokens, as the lockup period only starts when you unstake.
@@ -20,22 +20,22 @@ Otherwise, the lockup period is indefinite.
## Accounting token
-When you stake your EOS tokens you get a token called REX in return.
+When you stake your Vaulta tokens you get a token called REX in return.
REX is a non-transferable token that represents the amount of value you have staked.
-The conversion rate between EOS and REX is dynamic and goes up as more staking rewards are
+The conversion rate between Vaulta and REX is dynamic and goes up as more staking rewards are
distributed into the rewards pool.
The value of REX never decreases, only increases.
## Rewards
-The rewards from staking originate from a pre-allocated bucket of EOS tokens that are
+The rewards from staking originate from a pre-allocated bucket of Vaulta tokens that are
designated for staking rewards and aimed at incentivizing users to stake their tokens,
growing and securing the network.
## Liquid Staking
-EOS Staking is **not** a liquid staking protocol, meaning that you cannot trade your REX tokens or restake them
-in other protocols. Once you stake your EOS tokens and receive REX tokens in return, you cannot trade them or
-use them in any other way than to unstake them and receive EOS tokens back directly from the EOS Staking protocol.
+Vaulta Staking is **not** a liquid staking protocol, meaning that you cannot trade your REX tokens or restake them
+in other protocols. Once you stake your Vaulta tokens and receive REX tokens in return, you cannot trade them or
+use them in any other way than to unstake them and receive Vaulta tokens back directly from the Vaulta Staking protocol.
diff --git a/native/60_advanced-topics/30_staking/10_contracts.md b/native/60_advanced-topics/30_staking/10_contracts.md
index 78a14e86..8d164771 100644
--- a/native/60_advanced-topics/30_staking/10_contracts.md
+++ b/native/60_advanced-topics/30_staking/10_contracts.md
@@ -6,26 +6,29 @@ title: Contracts
Staking Contracts
-There are a few different contracts involved in EOS staking.
+There are a few different contracts involved in Vaulta staking.
1. `eosio.system` - The system and staking contract.
2. `eosio.reward` - An intermediate reward dispersal contract.
3. `eosio.rex` - Account that holds all funds in the staking protocol.
+> ℹ️ **Underlying tokens**
+> Though Vaulta uses the `A` token, the staking system is legacy and uses EOS tokens in the rows for its data.
+
## eosio.system
-The [system contract](https://eosauthority.com/account/eosio) is wider than just staking and controls the entire EOS network with
+The [system contract](https://unicove.com/account/eosio) is wider than just staking and controls the entire Vaulta network with
capabilities like account creation, chain governance, and resource management.
The staking portions of the system contract are responsible for managing the staking
-and unstaking of EOS tokens, as well as the distribution of rewards from the pre-allocated
+and unstaking of Vaulta tokens, as well as the distribution of rewards from the pre-allocated
staking rewards pool.
### Depositing Funds
-In order to use EOS inside the staking portion of the system contract, you need to deposit them first.
+In order to use Vaulta inside the staking portion of the system contract, you need to deposit them first.
```cpp
void deposit( const name& owner, const asset& amount )
@@ -50,7 +53,7 @@ This will stake the funds that you have deposited into the staking protocol and
### Staking Funds From Voting Rights
-On EOS you can have your EOS staked as voting rights. You may also use those funds as a source for staking.
+You can have your Vaulta staked as voting rights. You may also use those funds as a source for staking.
```cpp
void unstaketorex( const name& owner, const name& receiver, const asset& from_net, const asset& from_cpu )
@@ -82,18 +85,18 @@ You will need to do this in two steps.
void sellrex( const name& from, const asset& rex )
```
-This action will convert your REX tokens back into EOS and register them as available to withdraw.
+This action will convert your REX tokens back into Vaulta and register them as available to withdraw.
```cpp
void withdraw( const name& owner, const asset& amount )
```
-This action will withdraw your EOS tokens from the staking protocol and transfer them to your account.
+This action will withdraw your Vaulta tokens from the staking protocol and transfer them to your account.
> **Note**
> Any action you take within the staking protocol once a 21-day unstaking period has finished will trigger an
-> automatic `sellrex` on your fully matured REX tokens. This will convert them back into EOS and register them as
+> automatic `sellrex` on your fully matured REX tokens. This will convert them back into Vaulta and register them as
> available to withdraw.
### Tables
@@ -102,7 +105,7 @@ The system contract has a few tables that are relevant to staking.
#### rexbal
-[The `rexbal` table](https://eosauthority.com/account/eosio?network=eos&scope=eosio&table=rexbal&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables) holds information about staked balances for users.
+[The `rexbal` table](https://unicove.com/contract/eosio/tables/rexbal) holds information about staked balances for users.
- `version`
- `owner`
@@ -113,7 +116,7 @@ The system contract has a few tables that are relevant to staking.
#### rexfund
-[The `rexfund` table](https://eosauthority.com/account/eosio?network=eos&scope=eosio&table=rexfund&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables&lower_bound=)
+[The `rexfund` table](https://unicove.com/contract/eosio/tables/rexfund)
holds information about the deposited but unstaked EOS funds for users.
- `version`
@@ -122,7 +125,7 @@ holds information about the deposited but unstaked EOS funds for users.
#### rexmaturity
-[The `rexmaturity` table](https://eosauthority.com/account/eosio?network=eos&scope=eosio&table=rexmaturity&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables)
+[The `rexmaturity` table](https://unicove.com/contract/eosio/tables/rexmaturity)
holds information about the maturity dates of REX tokens for users.
- `num_of_maturity_buckets` - The number of days until a position fully matures
@@ -131,7 +134,7 @@ holds information about the maturity dates of REX tokens for users.
#### rexpool
-[The `rexpool` table](https://eosauthority.com/account/eosio?network=eos&scope=eosio&table=rexpool&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables)
+[The `rexpool` table](https://unicove.com/contract/eosio/tables/rexpool)
holds information about the staking pool.
- `version`
@@ -167,11 +170,11 @@ static convertRexToEos(rex:number){
}
```
-If you'd like to view full code for this example, [see here](https://github.com/eosnetworkfoundation/rex-staking-portal/blob/6f1297bbb5cc5e4d1e39ac5e52e815ea69a29803/src/lib/wharf.ts#L142-L143).
+If you'd like to view full code for this example, [see here](https://github.com/vaultafoundation/rex-staking-portal/blob/6f1297bbb5cc5e4d1e39ac5e52e815ea69a29803/src/lib/wharf.ts#L142-L143).
#### rexretpool
-[The `rexretpool` table](https://eosauthority.com/account/eosio?network=eos&scope=eosio&table=rexretpool&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables)
+[The `rexretpool` table](https://unicove.com/contract/eosio/tables/rexretpool)
holds information about the return pool for REX tokens.
- `version`
@@ -184,11 +187,11 @@ holds information about the return pool for REX tokens.
## eosio.reward
-The [reward contract](https://eosauthority.com/account/eosio.reward) ([see contract code](https://github.com/eosnetworkfoundation/eosio.reward)) is an intermediate contract
+The [reward contract](https://unicove.com/contract/eosio.reward) ([see contract code](https://github.com/vaultafoundation/eosio.reward)) is an intermediate contract
that is responsible for dispersing the rewards from the staking rewards tokenomics bucket to the various strategies
-aimed at rewarding the EOS community.
+aimed at rewarding the Vaulta community.
-It allows the EOS Network to define a [set of receivers](https://eosauthority.com/account/eosio.reward?mode=contract&sub=tables&network=eos&scope=eosio.reward&table=strategies&limit=10&index_position=1&key_type=i64&reverse=0)
+It allows the Vaulta blockchain to define a [set of receivers](https://unicove.com/contract/eosio.reward/tables/strategies)
that will receive rewards, and a weight for each receiver.
See the [inflows](./inflows) document for more information on how the reward contract is funded.
@@ -233,7 +236,7 @@ rounding errors.
## eosio.rex
-The [contract on the eosio.rex account](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/contracts/eosio.system/src/rex.results.cpp#L1) is merely a record-keeping contract. Each of the actions
+The [contract on the eosio.rex account](https://github.com/vaultafoundation/system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/contracts/eosio.system/src/rex.results.cpp#L1) is merely a record-keeping contract. Each of the actions
does nothing (no implmentation) and is only there to provide an identifiable record within the transactions stack that
can be tracked and filtered by external tooling such as history solutions or frontend SDKs that want more
information that normally would not be available (like the REX received for an amount of EOS in a `buyrex` action).
diff --git a/native/60_advanced-topics/30_staking/20_token-flows.md b/native/60_advanced-topics/30_staking/20_token-flows.md
index ce40a2ee..40e96ac1 100644
--- a/native/60_advanced-topics/30_staking/20_token-flows.md
+++ b/native/60_advanced-topics/30_staking/20_token-flows.md
@@ -6,19 +6,19 @@ title: Token Flows
Staking Token Flows
-The inflows to the EOS staking protocol travel through a few different contracts, each with their own responsibilities.
+The inflows to the Vaulta staking protocol travel through a few different contracts, each with their own responsibilities.
We will cover the contracts that are involved in the inflows to the staking protocol, as well as the origins of the funds.
## Tokenomics Change
-[In May of 2024 the EOS network underwent a tokenomics change](https://eosnetwork.com/blog/eos-network-approves-tokenomics-proposal-ushering-in-a-new-era-for-eos/) that introduced a new bucket
-of EOS tokens designated for staking rewards.
+In May of 2024 the Vaulta network underwent a tokenomics change that introduced a new bucket of Vaulta tokens
+designated for staking rewards.
-**250 million** EOS was set aside in this bucket to be emitted with a halving schedule every 4 years. Meaning that in
-the first 4 years 125,000,000 EOS will be distributed as staking rewards (31,250,000 EOS per year), and in the next 4 years
-62,500,000 EOS will be distributed as staking rewards (15,625,000 EOS per year), and so on.
+**250 million** Vaulta was set aside in this bucket to be emitted with a halving schedule every 4 years. Meaning that in
+the first 4 years 125,000,000 Vaulta will be distributed as staking rewards (31,250,000 Vaulta per year), and in the next 4 years
+62,500,000 Vaulta will be distributed as staking rewards (15,625,000 Vaulta per year), and so on.
-Inflation for the chain was also shut off during that change, and the various buckets replaced that inflated EOS.
+Inflation for the chain was also shut off during that change, and the various buckets replaced that inflated Vaulta.
This means that instead of inflating the chain at a set rate of X% per year, the chain now distributes a percentage of the
pre-allocated reserved supply to various parts of the network, like staking rewards.
@@ -29,13 +29,13 @@ various token allocations to target accounts.
-The block producers claim rewards from the **System Contract**, which then flows EOS into their accounts, and
-into the `eosio.saving` account that holds a contract which distributes EOS to **EOS Labs**, the **EOS Network
-Foundation**, and the **Staking Rewards** buckets (these are configured in [the `eosio.saving` contract](https://eosauthority.com/account/eosio.saving?network=eos&scope=eosio.saving&table=config&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables&action=claim#transactions)).
+The block producers claim rewards from the **System Contract**, which then flows Vaulta into their accounts, and
+into the `eosio.saving` account that holds a contract which distributes Vaulta to **Vaulta Labs**, the **Vaulta
+Foundation**, and the **Staking Rewards** buckets (these are configured in [the `eosio.saving` contract](https://unicove.com/contract/eosio.saving/tables/config)).
As the rewards flow into the `eosio.saving` account, they are immediately split up according to the distribution
configurations on that contract, which are set by a 15/21 multisig of the block producers and tallied into
-[the `claimers` table](https://eosauthority.com/account/eosio.saving?network=eos&scope=eosio.saving&table=claimers&limit=10&index_position=1&key_type=i64&reverse=0&mode=contract&sub=tables&action=claim#transactions).
+[the `claimers` table](https://unicove.com/contract/eosio.saving/tables/claimers).
Once funds are available, each entity can claim their rewards by calling the `claim` action, which then sends
the funds to the account specified in the configuration.
@@ -44,11 +44,12 @@ In the case of the **Staking Rewards** bucket, the funds are sent to the `eosio.
account until they are distributed to the various strategies that are configured there by an account calling the
`distribute` action.
-When the `distribute` action is called, the funds aimed at EOS Staking are used in the [`donatetorex` action](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/contracts/eosio.system/src/rex.cpp#L389)
+When the `distribute` action is called, the funds aimed at Vaulta Staking are used in the [`donatetorex` action]
+(https://github.com/vaultafoundation/system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/contracts/eosio.system/src/rex.cpp#L389)
back on the System Contract which adds those funds to the REX pools, and then sends the funds to `eosio.rex` for
accounting purposes.
-These pathways and mechanisms allow all participants to clearly see the flow of EOS as it makes its way through the
+These pathways and mechanisms allow all participants to clearly see the flow of Vaulta as it makes its way through the
chain's various contracts and accounts, and ensures that the funds are distributed according to the network's
governance decisions instead of being hardcoded into smart contract logic with low visibility and flexibility.
@@ -56,9 +57,9 @@ governance decisions instead of being hardcoded into smart contract logic with l
-When a user stakes their EOS to the protocol staking system they are transferring their EOS tokens to the system
-contract which then issues them REX tokens in return and forwards their EOS to the `eosio.rex` account for accounting
+When a user stakes their Vaulta to the protocol staking system they are transferring their Vaulta tokens to the system
+contract which then issues them REX tokens in return and forwards their Vaulta to the `eosio.rex` account for accounting
purposes.
-Since the value of REX can never go down, the user is guaranteed to receive _at least_ the same amount of EOS back when
+Since the value of REX can never go down, the user is guaranteed to receive _at least_ the same amount of Vaulta back when
they unstake, sell, and withdraw their REX tokens.
\ No newline at end of file
diff --git a/native/60_advanced-topics/30_staking/30_security.md b/native/60_advanced-topics/30_staking/30_security.md
index e2c2e001..4bfa4805 100644
--- a/native/60_advanced-topics/30_staking/30_security.md
+++ b/native/60_advanced-topics/30_staking/30_security.md
@@ -6,18 +6,18 @@ title: Security
Staking Security
-To understand the security that underpins the EOS network's staking protocol, we need to look at the
+To understand the security that underpins the Vaulta network's staking protocol, we need to look at the
various layers of security that are in place to protect the network and its users and how they impact staking, as well
as the additional security measures that apply only to staking.
## System Level Security
-The staking actions and logic exist within the core system contract on EOS, `eosio.system`.
-This contract is responsible for managing the entire EOS network, including account creation, chain governance, and resource management.
+The staking actions and logic exist within the core system contracts on Vaulta, `eosio.system` and `core.vaulta`.
+These contracts are responsible for managing the entire Vaulta network, including account creation, chain governance, and resource management.
The system contract is designed to be secure and robust, with extensive testing and auditing to ensure that it is free
from vulnerabilities and exploits as it controls the most critical functions of the network. There isn't a single
-contract on the EOS network that undergoes more scrutiny or has more eyes on it than the system contract, both
+contract on Vaulta that undergoes more scrutiny or has more eyes on it than the system contract, both
internally and externally.
The contract account is a "privileged" account, meaning that it has special permissions and access to system-level
@@ -28,7 +28,7 @@ flow of actions that the contract needs to perform, reducing the complexity and
## Multisig Contract Control
The system contract is controlled by 15 of the 21 block producers on the network, who must sign off on any changes to
-the contract. This is the highest level of security that can be achieved on the EOS network, as it requires a supermajority
+the contract. This is the highest level of security that can be achieved on Vaulta, as it requires a supermajority
of the most trusted and reputable entities on the network.
This multisig control ensures that no single entity or group can make changes to the system contract without the
@@ -39,7 +39,7 @@ have a vested interest in maintaining the security and integrity of the network.
## Token Ownership
-All funds that are staked into the staking protocol are deposited into the [`eosio.rex` account](https://eosauthority.com/account/eosio.rex)
+All funds that are staked into the staking protocol are deposited into the [`eosio.rex` account](https://unicove.com/account/eosio.rex)
which is also controlled by the same quorum of BPs. When a user first deposits their funds into the staking protocol,
they are effectively transferring ownership of those funds to the system contract in return for the REX token that
represents their staked value.
@@ -50,7 +50,7 @@ balance and other relevant information.
## Lockup Periods
-When a user stakes EOS into the staking protocol, they are subject to a lockup period that prevents them from
+When a user stakes Vaulta into the staking protocol, they are subject to a lockup period that prevents them from
unstaking their tokens for a certain amount of time. This lockup period is infinite as long as a user is not
unstaking their tokens, and once they decide to begin the unstaking period the lockup period is 21 days.
@@ -67,10 +67,10 @@ robust.
Tests relevant to the staking protocol can be found at the following locations:
-- [Core staking tests](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.system_tests.cpp#L3948)
-- [Maturity tests](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.system_rex_matured_tests.cpp#L1)
-- [Fees tests](https://github.com/eosnetworkfoundation/eos-system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.fees_tests.cpp#L1)
-- [Reward contract tests](https://github.com/eosnetworkfoundation/eosio.reward/blob/4a2f3cb9ffcbabb5f1682540636aae02d5d8480c/eosio.reward.spec.ts#L1)
+- [Core staking tests](https://github.com/vaultafoundation/system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.system_tests.cpp#L3948)
+- [Maturity tests](https://github.com/vaultafoundation/system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.system_rex_matured_tests.cpp#L1)
+- [Fees tests](https://github.com/vaultafoundation/system-contracts/blob/8ecd1ac6d312085279cafc9c1a5ade6affc886da/tests/eosio.fees_tests.cpp#L1)
+- [Reward contract tests](https://github.com/vaultafoundation/eosio.reward/blob/4a2f3cb9ffcbabb5f1682540636aae02d5d8480c/eosio.reward.spec.ts#L1)
## Audits
diff --git a/native/60_advanced-topics/30_staking/index.md b/native/60_advanced-topics/30_staking/index.md
index 4fb9d669..e83384af 100644
--- a/native/60_advanced-topics/30_staking/index.md
+++ b/native/60_advanced-topics/30_staking/index.md
@@ -6,7 +6,7 @@ title: Staking
Staking
-Learn about how EOS Staking works on EOS on a technical level.
+Learn about how Vaulta Staking works on a technical level.
- [Overview](./01_overview.md)
- [Contracts](./10_contracts.md)
diff --git a/native/60_advanced-topics/index.md b/native/60_advanced-topics/index.md
index 2984b8f4..f717f16a 100644
--- a/native/60_advanced-topics/index.md
+++ b/native/60_advanced-topics/index.md
@@ -6,7 +6,7 @@ sidebar_class_name: sidebarhidden
## Core
-The `EOS Core` provides the basic building blocks for the `system` layer. However, since they are not implemented as smart contracts, they do not provide the same level of flexibility. Nevertheless, the `core` implementation is also open source, and thus it can be modified to suit custom business requirements.
+The `Vaulta Core` provides the basic building blocks for the `system` layer. However, since they are not implemented as smart contracts, they do not provide the same level of flexibility. Nevertheless, the `core` implementation is also open source, and thus it can be modified to suit custom business requirements.
The core protocols are:
@@ -16,12 +16,12 @@ The core protocols are:
## System
-The EOS blockchain is unique in that the features and characteristics of the blockchain built on it are flexible, that is, they can be changed or be modified completely to suit each business case requirement. Core blockchain features such as consensus, fee schedules, account creation and modification, token economics, block producer registration, voting, multi-sig, etc., are implemented inside smart contracts which are deployed on the blockchain built on the EOS blockchain. These smart contracts are referred to as `system contracts` and the layer as the `EOS system` layer, or simply the `system` layer.
+The Vaulta blockchain is unique in that the features and characteristics of the blockchain built on it are flexible, that is, they can be changed or be modified completely to suit each business case requirement. Core blockchain features such as consensus, fee schedules, account creation and modification, token economics, block producer registration, voting, multi-sig, etc., are implemented inside smart contracts which are deployed on the blockchain built on the Vaulta blockchain. These smart contracts are referred to as `system contracts` and the layer as the `Vaulta system` layer, or simply the `system` layer.
-The EOS Network Foundation implements and maintains these `system contracts` as reference implementations only, encapsulating the base functionality for an EOS-based blockchain. The `system contracts` are listed below:
+The Vaulta Network Foundation implements and maintains these `system contracts` as reference implementations only, encapsulating the base functionality for an Vaulta-based blockchain. The `system contracts` are listed below:
-* [eosio.bios](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main/contracts/eosio.bios) - The `eosio.bios` contract is a special contract that is used to initialize the blockchain
-* [eosio.system](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main/contracts/eosio.system) - The `eosio.system` contract is the core contract that implements the foundational EOS blockchain features
-* [eosio.msig](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main/contracts/eosio.msig) - The `eosio.msig` contract implements the multi-signature functionality
-* [eosio.token](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main/contracts/eosio.token) - The `eosio.token` contract implements the system token functionality
-* [eosio.wrap](https://github.com/eosnetworkfoundation/eos-system-contracts/tree/main/contracts/eosio.wrap) - The `eosio.wrap` contract implements a governance feature
+* [eosio.bios](https://github.com/vaultafoundation/system-contracts/tree/main/contracts/eosio.bios) - The `eosio.bios` contract is a special contract that is used to initialize the blockchain
+* [eosio.system](https://github.com/vaultafoundation/system-contracts/tree/main/contracts/eosio.system) - The `eosio.system` contract is the core contract that implements the foundational Vaulta blockchain features
+* [eosio.msig](https://github.com/vaultafoundation/system-contracts/tree/main/contracts/eosio.msig) - The `eosio.msig` contract implements the multi-signature functionality
+* [eosio.token](https://github.com/vaultafoundation/system-contracts/tree/main/contracts/eosio.token) - The `eosio.token` contract implements the system token functionality
+* [eosio.wrap](https://github.com/vaultafoundation/system-contracts/tree/main/contracts/eosio.wrap) - The `eosio.wrap` contract implements a governance feature
diff --git a/native/999_miscellaneous/1000_glossary.md b/native/999_miscellaneous/1000_glossary.md
index 072da0e6..66c4b50e 100644
--- a/native/999_miscellaneous/1000_glossary.md
+++ b/native/999_miscellaneous/1000_glossary.md
@@ -30,7 +30,7 @@ A marketing implementation that involves sending free coins or tokens to wallet
A method to deploy tokens for dApp developers. Use your personal RAM to receive airgrab tokens.
## Antelope
-The technology that powers EOS, WAX, Telos, UX, Ultra
+The technology that powers Vaulta
## API
Application Programming Interface. A computer interface that enables two computer applications to interact with each other.
@@ -73,7 +73,7 @@ The list of block producers who currently have the possibility of being selected
Blockchain Producer
## Byzantine Fault Tolerance
-In the context of distributed systems, Byzantine Fault Tolerance (BFT) is the ability of a distributed computer network to function as desired and correctly reach a sufficient consensus despite malicious components (nodes) of the system failing or propagating incorrect information to other peers. In an EOSIO based blockchain BFT is achieved using a combination of Delegated Proof of Stake, the last irreversible block, and the fact that a producer cannot sign two blocks with the same block number.
+In the context of distributed systems, Byzantine Fault Tolerance (BFT) is the ability of a distributed computer network to function as desired and correctly reach a sufficient consensus despite malicious components (nodes) of the system failing or propagating incorrect information to other peers. In a Vaulta based blockchain BFT is achieved using a combination of Delegated Proof of Stake, the last irreversible block, and the fact that a producer cannot sign two blocks with the same block number.
**Related**: [Account](#Account)
## CDT
@@ -86,10 +86,7 @@ A version controlled, fast, transactional database.
The chain state (or "database" as it is often called) is a memory mapped file, which stores the blockchain state of each block (account details, deferred transactions, transactions, data stored using multi index tables in smart contracts, etc.). Once a block becomes irreversible the chain state is no longer cached.
## Cleos
-cleos is a command line tool that interfaces with the REST api exposed by nodeos. In other words cleos is the command line tool through which you can interface with an Antelope-based blockchain. cleos is used to deploy and test Antelope smart contracts. cleos contains documentation for all of its commands. For a list of all commands known to cleos, simply run it with no arguments. cleos = command line + eos
-
-## Coalition
-EOS, WAX, Telos, UX (Origin)
+cleos is a command line tool that interfaces with the REST api exposed by nodeos. In other words cleos is the command line tool through which you can interface with an Antelope-based blockchain. cleos is used to deploy and test Antelope smart contracts. cleos contains documentation for all of its commands. For a list of all commands known to cleos, simply run it with no arguments.
## Consensus / DPoS
A large number of participants or stakeholders elect a smaller number of delegates, which in turn make decisions for them.
@@ -142,20 +139,20 @@ A consensus of replicated, shared, and synchronized digital data geographically
## Digital Signature
A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A valid digital signature, where the prerequisites are satisfied, gives a recipient very strong reason to believe that the message was created by a known sender (authentication), and that the message was not altered in transit (integrity). Digital signatures are a standard element of most cryptographic protocol suites, and are commonly used for software distribution, financial transactions, contract management software, and in other cases where it is important to detect forgery or tampering.
-## Dune
-Docker Utilities for Node Execution. A personal container for Antelope blockchain management, smart contract development, and testing purposes.
-
## EA
Employment Agreement
## ENF
EOS Network Foundation
-## EOS Blockchain
-EOS is a smart contract blockchain project that is built with Antelope framework.
+## VF
+Vaulta Foundation
+
+## Vaulta Blockchain
+Vaulta is a smart contract blockchain project that is built with Antelope framework.
## EOSIO Types
-The EOS source code defines a list of types which ease the developer's work when writing smart contracts, plugins, or when extending the EOS source code. Example types include `account_name`, `permission_name`, `table_name`, `action_name`, `scope_name`, `weight_type`, `public_key`, etc.
+The Vaulta source code defines a list of types which ease the developer's work when writing smart contracts, plugins, or when extending the Vaulta source code. Example types include `account_name`, `permission_name`, `table_name`, `action_name`, `scope_name`, `weight_type`, `public_key`, etc.
## EOSJS
A frontend library for javascript development for native mobile applications development, in addition to Swift and Java SDKs. A Javascript API SDK for integration with Antelope-based blockchains using the Antelope RPC API.
@@ -194,7 +191,7 @@ A block is considered irreversible (i.e. immutable) on an Antelope-based blockch
**Related**: [Account](#Account)
## Keosd
-keosd is the component that securely stores Antelope keys in wallets. keosd = key + eos
+keosd is the component that securely stores Antelope keys in wallets.
## KYC
Know Your Customer
@@ -220,7 +217,7 @@ Multisig is a short term for multiple signatures. It’s used to describe the ca
NET is required to store transactions on an Antelope-based blockchain. The amount of NET an account has is measured in bytes, representing the amount of transaction storage an account has at its disposal when creating a new transaction. NET is recalculated after each block is produced, based on the system tokens staked for NET bandwidth by the account. The amount allocated to an account is proportional with the total system tokens staked for NET by all accounts. Do not confuse NET with RAM, although it is also storage space, NET measures the size of the transactions and not contract state.
## Nodeos
-nodeos is the core Antelope node daemon that can be configured with plugins to run a node. Example uses are block production, dedicated API endpoints, and local development. nodeos = node + eos
+nodeos is the core Antelope node daemon that can be configured with plugins to run a node. Example uses are block production, dedicated API endpoints, and local development.
## Non-Producing Node
A full node running nodeos that is only watching and verifying for itself each block, and maintaining its own local full copy of the blockchain. A non-producing node that is in the "standby pool" can, through the process of being voted in, become a Producing Node. A producing node, if voted out, will become a non-producing node. For large Antelope changes, non-producing nodes are outside the realm of the "standby pool".
diff --git a/native/999_miscellaneous/10_helpful-links.md b/native/999_miscellaneous/10_helpful-links.md
index 9795263d..cadbd50b 100644
--- a/native/999_miscellaneous/10_helpful-links.md
+++ b/native/999_miscellaneous/10_helpful-links.md
@@ -2,9 +2,7 @@
title: Helpful Links
---
-- [Developers Telegram](https://t.me/antelopedevs)
-- [Blog](https://eosnetwork.com/blog/)
-- [Github: EOS Foundation](https://github.com/eosnetworkfoundation)
+- [Developers Telegram](https://t.me/vaultadevelopers)
+- [Github: Vaulta Foundation](https://github.com/vaultafoundation)
- [Github: Antelope Framework](https://github.com/antelopeio)
-- [Twitter](https://twitter.com/EOSnFoundation)
-- [IBC Documentation](https://ibc-docs.uxnetwork.io/overview/)
+- [Twitter](https://twitter.com/Vaulta_)
diff --git a/native/999_miscellaneous/20_audits.md b/native/999_miscellaneous/20_audits.md
index 8510c713..1b07df91 100644
--- a/native/999_miscellaneous/20_audits.md
+++ b/native/999_miscellaneous/20_audits.md
@@ -2,7 +2,7 @@
title: Audits
---
-Here you can find a list of the audits that have been completed on various EOS software.
+Here you can find a list of the audits that have been completed on various Vaulta software.
| Date | Audit | Auditor |
|------------|-----------------------------------------------------------------------------|------------------------------------|
diff --git a/package.json b/package.json
index 07ff6cd6..71505828 100644
--- a/package.json
+++ b/package.json
@@ -1,17 +1,17 @@
{
- "name": "@eosnetwork/docs",
+ "name": "@vaulta/docs",
"version": "1.0.0",
- "description": "This repository contains the source of truth for the EOS Network documentation.",
+ "description": "This repository contains the source of truth for the Vaulta documentation.",
"repository": {
"type": "git",
- "url": "git+https://github.com/eosnetworkfoundation/docs.git"
+ "url": "git+https://github.com/vaultafoundation/docs.git"
},
- "author": "EOS Network Foundation",
+ "author": "Vaulta Foundation",
"license": "MIT",
"bugs": {
- "url": "https://github.com/eosnetworkfoundation/docs/issues"
+ "url": "https://github.com/vaultafoundation/docs/issues"
},
- "homepage": "https://docs.eosnetwork.com",
+ "homepage": "https://docs.vaulta.com",
"devDependencies": {
"js-yaml": "^4.1.0"
}