diff --git a/cdt/02_installation/index.md b/cdt/02_installation/index.md
deleted file mode 100644
index 181808906..000000000
--- a/cdt/02_installation/index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-content_title: Installation
----
-
-See README of https://github.com/AntelopeIO/cdt for instructions on how to build and install CDT.
diff --git a/cdt/03_command-reference/cdt-abidiff.md b/cdt/03_command-reference/cdt-abidiff.md
deleted file mode 100644
index 3fff56ba7..000000000
--- a/cdt/03_command-reference/cdt-abidiff.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-content_title: cdt-abidiff tool
----
-
-The cdt-abidiff tool is used to diff two ABI files to flag and output differences.
-To report differences with ```cdt-abidiff```, you only need to pass the two ABI file names as command line arguments.
-
-Example:
-```bash
-$ cdt-abidiff hello.abi old_hello.abi
-```
-
-This will generate dump the report output to the console.
-```
-OVERVIEW: cdt-abidiff
-USAGE: cdt-abidiff [options] ... ...
-
-OPTIONS:
-
-Generic Options:
-
- -help - Display available options (-help-hidden for more)
- -help-list - Display list of available options (-help-list-hidden for more)
- -version - Display the version of this program
-```
diff --git a/cdt/03_command-reference/cdt-cc.md b/cdt/03_command-reference/cdt-cc.md
deleted file mode 100644
index 913e94006..000000000
--- a/cdt/03_command-reference/cdt-cc.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-content_title: cdt-cc tool
----
-
-To manually compile the source code, use `cdt-cc` and `cdt-ld` as if it were __clang__ and __lld__. All the includes and options specific to Antelope and CDT are baked in.
-
-```
-USAGE: cdt-cc [options] ...
-
-OPTIONS:
-
-Generic Options:
-
- -help - Display available options (-help-hidden for more)
- -help-list - Display list of available options (-help-list-hidden for more)
- -version - Display the version of this program
-
-compiler options:
-
- -C - Include comments in preprocessed output
- -CC - Include comments from within macros in preprocessed output
- -D= - Define to (or 1 if omitted)
- -E - Only run the preprocessor
- -I= - Add directory to include search path
- -L= - Add directory to library search path
- -MD - Write depfile containing user and system headers
- -MF= - Write depfile output
- -MMD - Write depfile containing user
- -MT= - Specify name of main file output in depfile
- -O= - Optimization level s, 0-3
- -R= - Add a resource path for inclusion
- -S - Only run preprocess and compilation steps
- -U= - Undefine macro
- -W= - Enable the specified warning
- -abigen - Generate ABI
- -abigen_output= - ABIGEN output
- -c - Only run preprocess, compile, and assemble steps
- -contract= - Contract name
- -dD - Print macro definitions in -E mode in addition to normal output
- -dI - Print include directives in -E mode in addition to normal output
- -dM - Print macro definitions in -E mode instead to normal output
- -emit-ast - Emit Clang AST files for source inputs
- -emit-llvm - Use the LLVM representation for assembler and object files
- -fasm - Assemble file for x86-64
- -fcolor-diagnostics - Use colors in diagnostics
- -finline-functions - Inline suitable functions
- -finline-hint-functions - Inline functions which are (explicitly or implicitly) marked inline
- -fmerge-all-constants - Allow merging of constants
- -fnative - Compile and link for x86-64
- -fno-cfl-aa - Disable CFL Alias Analysis
- -fno-elide-constructors - Disable C++ copy constructor elision
- -fno-lto - Disable LTO
- -fno-post-pass - Don't run post processing pass
- -fno-stack-first - Don't set the stack first in memory
- -fquery - Produce binaries for wasmql
- -fquery-client - Produce binaries for wasmql
- -fquery-server - Produce binaries for wasmql
- -fstack-protector - Enable stack protectors for functions potentially vulnerable to stack smashing
- -fstack-protector-all - Force the usage of stack protectors for all functions
- -fstack-protector-strong - Use a strong heuristic to apply stack protectors to functions
- -fstrict-enums - Enable optimizations based on the strict definition of an enum's value range
- -fstrict-return - Always treat control flow paths that fall off the end of a non-void function as unreachable
- -fstrict-vtable-pointers - Enable optimizations based on the strict rules for overwriting polymorphic C++ objects
- -fuse-main - Use main as entry
- -include= - Include file before parsing
- -isystem= - Add directory to SYSTEM include search path
- -l= - Root name of library to link
- -lto-opt= - LTO Optimization level (O0-O3)
- -o= - Write output to
- -stack-size= - Specifies the maximum stack size for the contract. Defaults to 8192 bytes.
- -sysroot= - Set the system root directory
- -v - Show commands to run and use verbose output
- -w - Suppress all warnings
- --warn-action-read-only - Issue a warning if a read-only action uses a write API and continue compilation
-```
diff --git a/cdt/03_command-reference/cdt-cpp.md b/cdt/03_command-reference/cdt-cpp.md
deleted file mode 100644
index 382f4f485..000000000
--- a/cdt/03_command-reference/cdt-cpp.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-content_title: cdt-cpp tool
----
-
-To manually compile the source code, use `cdt-cpp` and `cdt-ld` as if it were __clang__ and __lld__. All the includes and options specific to Antelope and CDT are baked in.
-
-```
-USAGE: cdt-cpp [options] ...
-
-OPTIONS:
-
-Generic Options:
-
- -help - Display available options (-help-hidden for more)
- -help-list - Display list of available options (-help-list-hidden for more)
- -version - Display the version of this program
-
-compiler options:
-
- -C - Include comments in preprocessed output
- -CC - Include comments from within macros in preprocessed output
- -D= - Define to (or 1 if omitted)
- -E - Only run the preprocessor
- -I= - Add directory to include search path
- -L= - Add directory to library search path
- -MD - Write depfile containing user and system headers
- -MF= - Write depfile output
- -MMD - Write depfile containing user
- -MT= - Specify name of main file output in depfile
- -O= - Optimization level s, 0-3
- -R= - Add a resource path for inclusion
- -S - Only run preprocess and compilation steps
- -U= - Undefine macro
- -W= - Enable the specified warning
- -abigen - Generate ABI
- -abigen_output= - ABIGEN output
- -c - Only run preprocess, compile, and assemble steps
- -contract= - Contract name
- -dD - Print macro definitions in -E mode in addition to normal output
- -dI - Print include directives in -E mode in addition to normal output
- -dM - Print macro definitions in -E mode instead to normal output
- -emit-ast - Emit Clang AST files for source inputs
- -emit-llvm - Use the LLVM representation for assembler and object files
- -faligned-allocation - Enable C++17 aligned allocation functions
- -fasm - Assemble file for x86-64
- -fcolor-diagnostics - Use colors in diagnostics
- -fcoroutine-ts - Enable support for the C++ Coroutines TS
- -finline-functions - Inline suitable functions
- -finline-hint-functions - Inline functions which are (explicitly or implicitly) marked inline
- -fmerge-all-constants - Allow merging of constants
- -fnative - Compile and link for x86-64
- -fno-cfl-aa - Disable CFL Alias Analysis
- -fno-elide-constructors - Disable C++ copy constructor elision
- -fno-lto - Disable LTO
- -fno-post-pass - Don't run post processing pass
- -fno-stack-first - Don't set the stack first in memory
- -stack-size - Specifies the maximum stack size for the contract
- -fstack-protector - Enable stack protectors for functions potentially vulnerable to stack smashing
- -fstack-protector-all - Force the usage of stack protectors for all functions
- -fstack-protector-strong - Use a strong heuristic to apply stack protectors to functions
- -fstrict-enums - Enable optimizations based on the strict definition of an enum's value range
- -fstrict-return - Always treat control flow paths that fall off the end of a non-void function as unreachable
- -fstrict-vtable-pointers - Enable optimizations based on the strict rules for overwriting polymorphic C++ objects
- -fuse-main - Use main as entry
- -include= - Include file before parsing
- -isystem= - Add directory to SYSTEM include search path
- -l= - Root name of library to link
- -lto-opt= - LTO Optimization level (O0-O3)
- -o= - Write output to
- -std= - Language standard to compile for
- -sysroot= - Set the system root directory
- -v - Show commands to run and use verbose output
- -w - Suppress all warnings
- -no-missing-ricardian-clause - Defaults to false, disables warnings for missing Ricardian clauses
- --warn-action-read-only - Issue a warning if a read-only action uses a write API and continue compilation
-```
-
-## Notes
-
-* `-no-missing-ricardian-clause`: Defaults to false, if enabled, it suppresses warnings for missing Ricardian clauses on contracts and contract actions. That includes the warnings generated when there is no independent Ricardian clause file.
diff --git a/cdt/03_command-reference/cdt-init.md b/cdt/03_command-reference/cdt-init.md
deleted file mode 100644
index 24d274030..000000000
--- a/cdt/03_command-reference/cdt-init.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-content_title: cdt-init tool
----
-
-This tool is used to generate a skeleton smart contract and directory structure.
-To generate a new smart contract project you can either generate a "bare" project (no CMake) or the default is to generate a CMake project.
-
-Example:
-```bash
-$ cdt-init --path=\destination\path\where\to\generate\project\ --project=hello_contract_folder
-```
-
-This will generate a project folder `hello_contract_folder` in the path `\destination\path\where\to\generate\project\` containing the skeleton smart contract and directory structure.
-
-```
-USAGE: cdt-init [options]
-
-OPTIONS:
-
-Generic Options:
-
- -help - Display available options (-help-hidden for more)
- -help-list - Display list of available options (-help-list-hidden for more)
- -version - Display the version of this program
-
-cdt-init:
-generates a smart contract project
-
- -bare - produces only a skeleton smart contract without CMake support
- -path= - directory to place the project
- -project= - output project name
-```
diff --git a/cdt/03_command-reference/cdt-ld.md b/cdt/03_command-reference/cdt-ld.md
deleted file mode 100644
index f4339e91d..000000000
--- a/cdt/03_command-reference/cdt-ld.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-content_title: cdt-ld tool
----
-
-The cdt-ld tool is a the custom web assembly linker for Antelope framework smart contracts.
-
-
-```
-USAGE: cdt-ld [options] ...
-
-OPTIONS:
-
-Generic Options:
-
- -help - Display available options (-help-hidden for more)
- -help-list - Display list of available options (-help-list-hidden for more)
- -version - Display the version of this program
-
-ld options:
-
- -L= - Add directory to library search path
- -fasm - Assemble file for x86-64
- -fnative - Compile and link for x86-64
- -fno-cfl-aa - Disable CFL Alias Analysis
- -fno-lto - Disable LTO
- -fno-post-pass - Don't run post processing pass
- -fno-stack-first - Don't set the stack first in memory
- -stack-size - Specifies the maximum stack size for the contract
- -fuse-main - Use main as entry
- -l= - Root name of library to link
- -lto-opt= - LTO Optimization level (O0-O3)
- -o= - Write output to
-```
diff --git a/cdt/04_upgrading/eosio.cdt-to-cdt.md b/cdt/04_upgrading/eosio.cdt-to-cdt.md
deleted file mode 100644
index d2e1de573..000000000
--- a/cdt/04_upgrading/eosio.cdt-to-cdt.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-content_title: EOSIO.CDT To CDT
----
-
-For this release all of the naming of namespaces and file paths will remain as `eosio`, so there is no need to migrate away from that with this release.
-
-But there are a few differences.
-
-1. The tool names have change prefix. I.e. tools like `eosio-cpp` are now `cdt-cpp`.
-2. The CMake toolchain file has changed its name from `EosioWasmToolchain.cmake` to `CDTWasmToolchain.cmake`.
-3. The library path for the CMake package has changed from `/usr/local/lib/cmake/eosio.cdt` to `/usr/local/lib/cmake/cdt` (or alternatively from `/usr/lib/cmake/eosio.cdt` to `/usr/lib/cmake/cdt` if installing from the Debian package). Additionally, the name to use with CMake `find_package` has similarly changed: use `find_package(cdt)` now instead of `find_package(eosio.cdt)`.
diff --git a/cdt/05_features/10_return_values_from_actions.md b/cdt/05_features/10_return_values_from_actions.md
deleted file mode 100644
index 2d3e0faf8..000000000
--- a/cdt/05_features/10_return_values_from_actions.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-content_title: Return Values From Actions
----
-
-## Overview
-
-An Antelope blockchain with the `ACTION_RETURN_VALUE` protocol feature activated enables you to return any value from any action. This new feature facilitates easier smart contract implementation debugging, and better messaging between a smart contract and its clients. From now on the clients of a smart contract are able to use the value returned by an action, no more string parsing on the client side and no more print statements in the smart contract implementation.
-
-## Concept
-
-When you implement an action within a smart contract use the `return` statement and pass any value to the action sender. The returned value can be of any C++ primitive type, any C++ standard library type, or any user defined type. The `Antelope` framework does all the work necessary to serialize the value returned and send it back to the client. On the client side you deserialize the received value and access it the same way you access any other function’s return value.
-
-## Details
-
-The following list provides important details for when you return a value from an action:
-
-* As mentioned above, the `Antelope` framework does all the heavy lifting for the return value to convey it to the client. The `Antelope` framework defines and uses a new intrinsic, namely `set_action_return_value`. To learn more about `Antelope` returned values functionality, refer to its documentation and [implementation](https://github.com/AntelopeIO/cdt/blob/develop/libraries/native/intrinsics.cpp#L295).
-* The CPU time and memory limit of your contract (maximum size of wasm), not RAM or NET, defines the limits of the returned value..
-* The action receipt includes a hash of the serialized returned value.
-* The action trace includes the serialized returned value.
-* If the trace log is enabled, the state history trace logs also store the serialized returned value.
-* If the trace api plugin is enabled, the trace api trace logs also store the serialized returned value.
-* The returned value is available in the action trace. If the sender is another action, the action trace is not available to the sender action `code`. Therefore the returned value from an inline action can not be read by the action that sent the inline action.
-* Also inline actions do not execute synchronously. Inline actions execute at a later time. No return value is available to the sender at the time the inline action is sent.
-
-## Examples
-
-For a full working example of a smart contract action which returns a value, refer to the following resources:
-
-* The [`hello`](https://github.com/AntelopeIO/cdt/blob/develop/examples/hello/src/hello.cpp#L14) smart contract example, see action `hello::checkwithrv`.
-* The [How-to return values from actions](../06_how-to-guides/60_how-to-return-values-from-actions.md).
diff --git a/cdt/05_features/30_binary-extension.md b/cdt/05_features/30_binary-extension.md
deleted file mode 100644
index 612a22a10..000000000
--- a/cdt/05_features/30_binary-extension.md
+++ /dev/null
@@ -1,720 +0,0 @@
----
-content_title: The eosio::binary_extension Type
----
-
-Let's fully explain what the `eosio::binary_extension` type is, what it does, and why we need it for contract upgrades in certain situations.
-
-You can find the implementation of `eosio::binary_extension` within the CDT repository in the file: `libraries/eosiolib/core/eosio/binary_extension.hpp`.
-
-Our primary concern when using this type is when we are adding a new field to a smart contract's data structure that is currently utilized in an `eosio::multi_index` type (AKA a _table_), or when adding a new parameter to an action declaration.
-
-By wrapping the new field in an `eosio::binary_extension`, you are enabling your contract to be backwards compatible for future use. Note that this new field/parameter **MUST** be appended at the end of a data structure (this is due to implementation details in `eosio::multi_index`, which relies on the `boost::multi_index` type), or at the end of the parameter list in an action declaration.
-
-If you don't wrap the new field in an `eosio::binary_extension`, the `eosio::multi_index` table will be reformatted in such a way that disallows reads to the former datum; or in an action's case, the function will be uncallable.
-
-
-
-But let's see how the `eosio::binary_extension` type works with a good example.
-
-Take a moment to study this smart contract and its corresponding `.abi`.
-
-This contract not only serves as a good example to the `eosio::binary_extension` type, but can also be used as a gateway for developing smart contracts on the eosio protocol.
-
-**binary_extension_contract.hpp**
-
-```c++
-#include // eosio::contract
-#include // eosio::binary_extension
-#include // eosio::datastream
-#include // eosio::name
-#include // eosio::indexed_by, eosio::multi_index
-#include // eosio::print_f
-
-class [[eosio::contract]] binary_extension_contract : public eosio::contract {
-public:
- using contract::contract;
- binary_extension_contract(eosio::name receiver, eosio::name code, eosio::datastream ds)
- : contract{receiver, code, ds}, _table{receiver, receiver.value}
- { }
-
- [[eosio::action]] void regpkey (eosio::name primary_key); ///< Register primary key.
- [[eosio::action]] void printbyp(eosio::name primary_key); ///< Print by primary key.
- [[eosio::action]] void printbys(eosio::name secondary_key); ///< Print by secondary key.
- [[eosio::action]] void modifyp (eosio::name primary_key, eosio::name n); ///< Modify primary key by primary key.
- [[eosio::action]] void modifys (eosio::name primary_key, eosio::name n); ///< Modify secondary key by primary key.
-
- struct [[eosio::table]] structure {
- eosio::name _primary_key;
- eosio::name _secondary_key;
-
- uint64_t primary_key() const { return _primary_key.value; }
- uint64_t secondary_key() const { return _secondary_key.value; }
- };
-
- using index1 = eosio::indexed_by<"index1"_n, eosio::const_mem_fun>;
- using index2 = eosio::indexed_by<"index2"_n, eosio::const_mem_fun>;
- using table = eosio::multi_index<"table"_n, structure, index1, index2>;
-
-private:
- table _table;
-};
-
-```
-
-**binary_extension_contract.cpp**
-
-```c++
-#include "binary_extension_contract.hpp"
-
-using eosio::name;
-
-[[eosio::action]] void binary_extension_contract::regpkey(name primary_key) {
- eosio::print_f("`regpkey` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()}; ///< `index` represents `_table` organized by `index1`.
- auto iter {index.find(primary_key.value) }; ///< Note: the type returned by `index.find` is different than the type returned by `_table.find`.
-
- if (iter == _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % not found; registering.\n", primary_key.to_string());
- _table.emplace(_self, [&](auto& row) {
- row._primary_key = primary_key;
- row._secondary_key = "nothin"_n;
- });
- }
- else {
- eosio::print_f("`_primary_key`: % found; not registering.\n", primary_key.to_string());
- }
-
- eosio::print_f("`regpkey` finished executing.\n");
-}
-
-[[eosio::action]] void binary_extension_contract::printbyp(eosio::name primary_key) {
- eosio::print_f("`printbyp` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()};
- auto iter {index.find(primary_key.value) };
-
- if (iter != _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % found; printing.\n", primary_key.to_string());
- eosio::print_f("{%, %}\n", iter->_primary_key, iter->_secondary_key);
- }
- else {
- eosio::print_f("`_primary_key`: % not found; not printing.\n", primary_key.to_string());
- }
-
- eosio::print_f("`printbyp` finished executing.\n");
-}
-
-[[eosio::action]] void binary_extension_contract::printbys(eosio::name secondary_key) {
- eosio::print_f("`printbys` executing.\n");
-
- auto index{_table.get_index<"index2"_n>()};
- auto iter {index.find(secondary_key.value)};
-
- if (iter != _table.get_index<"index2"_n>().end()) {
- eosio::print_f("`_secondary_key`: % found; printing.\n", secondary_key.to_string());
- printbyp(iter->_primary_key);
- }
- else {
- eosio::print_f("`_secondary_key`: % not found; not printing.\n", secondary_key.to_string());
- }
-
- eosio::print_f("`printbys` finished executing.\n");
-}
-
-[[eosio::action]] void binary_extension_contract::modifyp(eosio::name primary_key, name n) {
- eosio::print_f("`modifyp` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()};
- auto iter {index.find(primary_key.value)};
-
- if (iter != _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % found; modifying `_primary_key`.\n", primary_key.to_string());
- index.modify(iter, _self, [&](auto& row) {
- row._primary_key = n;
- });
- }
- else {
- eosio::print_f("`_primary_key`: % not found; not modifying `_primary_key`.\n", primary_key.to_string());
- }
-
- eosio::print_f("`modifyp` finished executing.\n");
-}
-
-[[eosio::action]] void binary_extension_contract::modifys(eosio::name primary_key, name n) {
- eosio::print_f("`modifys` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()};
- auto iter {index.find(primary_key.value)};
-
- if (iter != _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % found; modifying `_secondary_key`.\n", primary_key.to_string());
- index.modify(iter, _self, [&](auto& row) {
- row._secondary_key = n;
- });
- }
- else {
- eosio::print_f("`_primary_key`: % not found; not modifying `_secondary_key`.\n", primary_key.to_string());
- }
-
- eosio::print_f("`modifys` finished executing.\n");
-}
-```
-
-**binary_extension_contract.abi**
-
-```javascript
-{
- "____comment": "This file was generated with eosio-abigen. DO NOT EDIT ",
- "version": "eosio::abi/1.1",
- "types": [],
- "structs": [
- {
- "name": "modifyp",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- },
- {
- "name": "n",
- "type": "name"
- }
- ]
- },
- {
- "name": "modifys",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- },
- {
- "name": "n",
- "type": "name"
- }
- ]
- },
- {
- "name": "printbyp",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- }
- ]
- },
- {
- "name": "printbys",
- "base": "",
- "fields": [
- {
- "name": "secondary_key",
- "type": "name"
- }
- ]
- },
- {
- "name": "regpkey",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- }
- ]
- },
- {
- "name": "structure",
- "base": "",
- "fields": [
- {
- "name": "_primary_key",
- "type": "name"
- },
- {
- "name": "_secondary_key",
- "type": "name"
- }
- ]
- }
- ],
- "actions": [
- {
- "name": "modifyp",
- "type": "modifyp",
- "ricardian_contract": ""
- },
- {
- "name": "modifys",
- "type": "modifys",
- "ricardian_contract": ""
- },
- {
- "name": "printbyp",
- "type": "printbyp",
- "ricardian_contract": ""
- },
- {
- "name": "printbys",
- "type": "printbys",
- "ricardian_contract": ""
- },
- {
- "name": "regpkey",
- "type": "regpkey",
- "ricardian_contract": ""
- }
- ],
- "tables": [
- {
- "name": "table",
- "type": "structure",
- "index_type": "i64",
- "key_names": [],
- "key_types": []
- }
- ],
- "ricardian_clauses": [],
- "variants": []
-}
-```
-
-
-
-Take note of the action `regpkey`, and the struct `structure` in `con.hpp` and `con.cpp`; the parts of the contract we will be upgrading.
-
-**binary_extension_contract.hpp**
-
-```c++
-[[eosio::action]] void regpkey (eosio::name primary_key);
-```
-
-```c++
-struct [[eosio::table]] structure {
- eosio::name _primary_key;
- eosio::name _secondary_key;
-
- uint64_t primary_key() const { return _primary_key.value; }
- uint64_t secondary_key() const { return _secondary_key.value; }
-};
-```
-
-**binary_extension_contract.cpp**
-
-```c++
-[[eosio::action]] void binary_extension_contract::regpkey(name primary_key) {
- eosio::print_f("`regpkey` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()}; ///< `index` represents `_table` organized by `index1`.
- auto iter {index.find(primary_key.value) }; ///< Note: the type returned by `index.find` is different than the type returned by `_table.find`.
-
- if (iter == _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % not found; registering.\n", primary_key.to_string());
- _table.emplace(_self, [&](auto& row) {
- row._primary_key = primary_key;
- row._secondary_key = "nothin"_n;
- });
- }
- else {
- eosio::print_f("`_primary_key`: % found; not registering.\n", primary_key.to_string());
- }
-
- eosio::print_f("`regpkey` finished executing.\n");
-}
-```
-
-Find below their corresponding sections in the `.abi` files:
-
-**binary_extension_contract.abi**
-
-```javascript
-{
- "name": "regpkey",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- }
- ]
-}
-```
-
-```javascript
-{
- "name": "structure",
- "base": "",
- "fields": [
- {
- "name": "_primary_key",
- "type": "name"
- },
- {
- "name": "_secondary_key",
- "type": "name"
- }
- ]
-}
-```
-
-
-
-Now, let's start up a blockchain instance, compile this smart contract, and test it out.
-
-```
-~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
-```
-
-```
-~/binary_extension_contract $ cleos set contract eosio ./
-```
-
-```
-Reading WASM from /Users/john.debord/binary_extension_contract/binary_extension_contract.wasm...
-Publishing contract...
-executed transaction: 6c5c7d869a5be67611869b5f300bc452bc57d258d11755f12ced99c7d7fe154c 4160 bytes 729 us
-# eosio <= eosio::setcode "0000000000ea30550000d7600061736d01000000018f011760000060017f0060027f7f0060037f7f7f017f6000017e60067...
-# eosio <= eosio::setabi "0000000000ea3055d1020e656f73696f3a3a6162692f312e310006076d6f646966797000020b7072696d6172795f6b65790...
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-Next, let's push some data to our contract.
-
-```
-~/binary_extension_contract $ cleos push action eosio regpkey '{"primary_key":"eosio.name"}' -p eosio
-```
-
-```
-executed transaction: 3c708f10dcbf4412801d901eb82687e82287c2249a29a2f4e746d0116d6795f0 104 bytes 248 us
-# eosio <= eosio::regpkey {"primary_key":"eosio.name"}
-[(eosio,regpkey)->eosio]: CONSOLE OUTPUT BEGIN =====================
-`regpkey` executing.
-`_primary_key`: eosio.name not found; registering.
-`regpkey` finished executing.
-[(eosio,regpkey)->eosio]: CONSOLE OUTPUT END =====================
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-Finally, let's read back the data we have just written.
-
-```
-~/binary_extension_contract $ cleos push action eosio printbyp '{"primary_key":"eosio.name"}' -p eosio
-```
-
-```
-executed transaction: e9b77d3cfba322a7a3a93970c0c883cb8b67e2072a26d714d46eef9d79b2f55e 104 bytes 227 us
-# eosio <= eosio::printbyp {"primary_key":"eosio.name"}
-[(eosio,printbyp)->eosio]: CONSOLE OUTPUT BEGIN =====================
-`printbyp` executing.
-`_primary_key`: eosio.name found; printing.
-{eosio.name, nothin}
-`printbyp` finished executing.
-[(eosio,printbyp)->eosio]: CONSOLE OUTPUT END =====================
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-
-
-Now, let's upgrade the smart contract by adding a new field to the table and a new parameter to an action while **NOT** wrapping the new field/parameter in an `eosio::binary_extension` type and see what happens:
-
-**binary_extension_contract.hpp**
-
-```diff
-+[[eosio::action]] void regpkey (eosio::name primary_key, eosio::name secondary_key);
--[[eosio::action]] void regpkey (eosio::name primary_key);
-```
-
-```diff
-struct [[eosio::table]] structure {
- eosio::name _primary_key;
- eosio::name _secondary_key;
-+ eosio::name _non_binary_extension_key;
-
- uint64_t primary_key() const { return _primary_key.value; }
- uint64_t secondary_key() const { return _secondary_key.value; }
-};
-```
-
-**binary_extension_contract.cpp**
-
-```diff
-+[[eosio::action]] void binary_extension_contract::regpkey(name primary_key, name secondary_key) {
--[[eosio::action]] void binary_extension_contract::regpkey(name primary_key) {
- eosio::print_f("`regpkey` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()}; ///< `index` represents `_table` organized by `index1`.
- auto iter {index.find(primary_key.value) }; ///< Note: the type returned by `index.find` is different than the type returned by `_table.find`.
-
- if (iter == _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % not found; registering.\n", primary_key.to_string());
- _table.emplace(_self, [&](auto& row) {
- row._primary_key = primary_key;
-+ if (secondary_key) {
-+ row._secondary_key = secondary_key;
-+ }
-+ else {
- row._secondary_key = "nothin"_n;
-+ }
- });
- }
- else {
- eosio::print_f("`_primary_key`: % found; not registering.\n", primary_key.to_string());
- }
-
- eosio::print_f("`regpkey` finished executing.\n");
-}
-```
-
-**binary_extension_contract.abi**
-```diff
-{
- "name": "regpkey",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
-+ },
-+ {
-+ "name": "secondary_key",
-+ "type": "name"
- }
- ]
-}
-```
-
-```diff
-{
- "name": "structure",
- "base": "",
- "fields": [
- {
- "name": "_primary_key",
- "type": "name"
- },
- {
- "name": "_secondary_key",
- "type": "name"
-+ },
-+ {
-+ "name": "_non_binary_extension_key",
-+ "type": "name"
- }
- ]
-}
-```
-
-Next, let's upgrade the contract and try to read from our table and write to our table the original way:
-
-```
-~/binary_extension_contract $ cdt-cpp binary_extension_contract.cpp -o binary_extension_contract.wasm
-```
-
-```
-~/binary_extension_contract $ cleos set contract eosio ./
-```
-
-```
-Reading WASM from /Users/john.debord/binary_extension_contract/binary_extension_contract.wasm...
-Publishing contract...
-executed transaction: b8ea485842fa5645e61d35edd97e78858e062409efcd0a4099d69385d9bc6b3e 4408 bytes 664 us
-# eosio <= eosio::setcode "0000000000ea30550000a2660061736d01000000018f011760000060017f0060027f7f0060037f7f7f017f6000017e60067...
-# eosio <= eosio::setabi "0000000000ea305583030e656f73696f3a3a6162692f312e310006076d6f646966797000020b7072696d6172795f6b65790...
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-```
-~/binary_extension_contract $ cleos push action eosio printbyp '{"primary_key":"eosio.name"}' -p eosio
-```
-
-```
-Error 3050003: eosio_assert_message assertion failure
-Error Details:
-assertion failure with message: read
-```
-
-Whoops! We aren't able to read the data we've previously written to our table!
-
-```
-~/binary_extension_contract $ cleos push action eosio regpkey '{"primary_key":"eosio.name2"}' -p eosio
-```
-
-```
-Error 3015014: Pack data exception
-Error Details:
-Missing field 'secondary_key' in input object while processing struct 'regpkey'
-```
-
-Whoops! We aren't able to write to our table the original way with the upgraded action either!
-
-
-
-Ok, let's back up and wrap the new field and the new action parameter in an `eosio::binary_extension` type:
-
-**binary_extension_contract.hpp**
-
-```diff
-+[[eosio::action]] void regpkey (eosio::name primary_key. eosio::binary_extension secondary_key);
--[[eosio::action]] void regpkey (eosio::name primary_key, eosio::name secondary_key);
-```
-
-```diff
-struct [[eosio::table]] structure {
- eosio::name _primary_key;
- eosio::name _secondary_key;
-+ eosio::binary_extension _binary_extension_key;
-- eosio::name _non_binary_extension_key;
-
- uint64_t primary_key() const { return _primary_key.value; }
- uint64_t secondary_key() const { return _secondary_key.value; }
-};
-```
-
-**binary_extension_contract.cpp**
-
-```diff
-+[[eosio::action]] void binary_extension_contract::regpkey(name primary_key, binary_extension secondary_key) {
--[[eosio::action]] void binary_extension_contract::regpkey(name primary_key, name secondary_key) {
- eosio::print_f("`regpkey` executing.\n");
-
- auto index{_table.get_index<"index1"_n>()}; ///< `index` represents `_table` organized by `index1`.
- auto iter {index.find(primary_key.value) }; ///< Note: the type returned by `index.find` is different than the type returned by `_table.find`.
-
- if (iter == _table.get_index<"index1"_n>().end()) {
- eosio::print_f("`_primary_key`: % not found; registering.\n", primary_key.to_string());
- _table.emplace(_self, [&](auto& row) {
- row._primary_key = primary_key;
- if (secondary_key) {
-+ row._secondary_key = secondary_key.value();
-- row._secondary_key = secondary_key;
- }
- else {
- row._secondary_key = "nothin"_n;
- }
- });
- }
- else {
- eosio::print_f("`_primary_key`: % found; not registering.\n", primary_key.to_string());
- }
-
- eosio::print_f("`regpkey` finished executing.\n");
-}
-```
-
-**binary_extension_contract.abi**
-```diff
-{
- "name": "regpkey",
- "base": "",
- "fields": [
- {
- "name": "primary_key",
- "type": "name"
- },
- {
- "name": "secondary_key",
-+ "type": "name$"
-- "type": "name"
- }
- ]
-}
-```
-
-```diff
-{
- "name": "structure",
- "base": "",
- "fields": [
- {
- "name": "_primary_key",
- "type": "name"
- },
- {
- "name": "_secondary_key",
- "type": "name"
- },
- {
-+ "name": "_binary_extension_key",
-+ "type": "name$"
-- "name": "_non_binary_extension_key",
-- "type": "name"
- }
- ]
-}
-```
-
-Note the `$` after the types now; this indicates that this type is an `eosio::binary_extension` type field.
-```diff
-{
- "name": "secondary_key",
-+ "type": "name$"
-- "type": "name"
-}
-```
-
-```diff
-{
- "name": "_binary_extension_key",
-+ "type": "name$"
-- "type": "name"
-}
-```
-
-Now, let's upgrade the contract again and try to read/write from/to our table:
-
-```
-~/binary_extension_contract $ cleos set contract eosio ./
-```
-
-```
-Reading WASM from /Users/john.debord/binary_extension_contract/binary_extension_contract.wasm...
-Publishing contract...
-executed transaction: 497584d4e43ec114dbef83c134570492893f49eacb555d0cd47d08ea4a3a72f7 4696 bytes 648 us
-# eosio <= eosio::setcode "0000000000ea30550000cb6a0061736d01000000018f011760000060017f0060027f7f0060037f7f7f017f6000017e60017...
-# eosio <= eosio::setabi "0000000000ea305581030e656f73696f3a3a6162692f312e310006076d6f646966797000020b7072696d6172795f6b65790...
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-```
-~/binary_extension_contract $ cleos push action eosio printbyp '{"primary_key":"eosio.name"}' -p eosio
-```
-
-```
-executed transaction: 6108f3206e1824fe3a1fdcbc2fe733f38dc07ae3d411a1ccf777ecef56ddec97 104 bytes 224 us
-# eosio <= eosio::printbyp {"primary_key":"eosio.name"}
-[(eosio,printbyp)->eosio]: CONSOLE OUTPUT BEGIN =====================
-`printbyp` executing.
-`_primary_key`: eosio.name found; printing.
-{eosio.name, nothin}
-`printbyp` finished executing.
-[(eosio,printbyp)->eosio]: CONSOLE OUTPUT END =====================
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-```
-~/binary_extension_contract $ cleos push action eosio regpkey '{"primary_key":"eosio.name2"}' -p eosio
-```
-
-```
-executed transaction: 75a135d1279a9c967078b0ebe337dc0cd58e1ccd07e370a899d9769391509afc 104 bytes 227 us
-# eosio <= eosio::regpkey {"primary_key":"eosio.name2"}
-[(eosio,regpkey)->eosio]: CONSOLE OUTPUT BEGIN =====================
-`regpkey` executing.
-`_primary_key`: eosio.name2 not found; registering.
-`regpkey` finished executing.
-[(eosio,regpkey)->eosio]: CONSOLE OUTPUT END =====================
-warning: transaction executed locally, but may not be confirmed by the network yet
-```
-
-Nice! The smart contract is now backwards compatible for the future use of its tables and/or actions.
-
-
-
-Just keep these simple rules in mind when upgrading a smart contract.
-If you are adding a new field to a struct currently in use by a `eosio::multi_index` be **SURE** to:
-- add the field at the end of the struct.
-- wrap the type using an `eosio::binary_extension` type.
diff --git a/cdt/05_features/40_native-tester-compilation.md b/cdt/05_features/40_native-tester-compilation.md
deleted file mode 100644
index 216b8e2e5..000000000
--- a/cdt/05_features/40_native-tester-compilation.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-content_title: Native Tester And Compilation
----
-
-As of v1.5.0 native compilation can be performed and a new set of libraries to facilitate native testing and native "scratch pad" compilation. [`cdt-cc`](../03_command-reference/cdt-cc.md), [`cdt-cpp`](../03_command-reference/cdt-cpp.md) and [`cdt-ld`](../03_command-reference/cdt-ld.md) now support building "smart contracts" and unit tests natively for quick tests to help facilitate faster development (note the default implementations of a lot of the Antelope intrinsics (aka host functions) are currently asserts that state they are unavailable, these are user definable.)
-
-## Getting Started
-Once you have your smart contract written then a test source file can be written.
-
-`hello.hpp`
-```c++
-#include
-
-using namespace eosio;
-
-class [[eosio::contract]] hello : public eosio::contract {
- public:
- using contract::contract;
-
- [[eosio::action]] void hi( name user );
-
- // accessor for external contracts to easily send inline actions to your contract
- using hi_action = action_wrapper<"hi"_n, &hello::hi>;
-};
-```
-
-and then a quick test
-`hello_test.cpp`
-```c++
-#include
-#include
-
-#include
-
-using namespace eosio;
-using namespace eosio::native;
-
-EOSIO_TEST_BEGIN(hello_test)
- // These can be redefined by the user to suit there needs per unit test
- // the idea is that in a future release there will be a base library that
- // initializes these to "useable" default implementations and probably
- // helpers to more easily define read_action_data and action_data_size intrinsics
- // like these"
- intrinsics::set_intrinsic(
- [](void* m, uint32_t len) {
- check(len <= sizeof(eosio::name), "failed from read_action_data");
- *((eosio::name*)m) = "hello"_n;
- return len;
- });
-
- intrinsics::set_intrinsic(
- []() {
- return (uint32_t)sizeof(eosio::name);
- });
-
- intrinsics::set_intrinsic(
- [](capi_name nm) {
- });
-
-
- // "Name : hello" should be in the print buffer
- CHECK_PRINT("Name : hello",
- []() {
- apply("test"_n.value, "test"_n.value, "hi"_n.value);
- });
-
- // should not assert
- apply("test"_n.value, "test"_n.value, "check"_n.value);
-
- name nm = "null"_n;
- intrinsics::set_intrinsic(
- [&](void* m, uint32_t len) {
- check(len <= sizeof(eosio::name), "failed from read_action_data");
- *((eosio::name*)m) = nm;
- return len;
- });
-
- REQUIRE_ASSERT( "check name not equal to `hello`",
- []() {
- // should assert
- apply("test"_n.value, "test"_n.value, "check"_n.value);
- });
-
-EOSIO_TEST_END
-
-// boilerplate main, this will be generated in a future release
-int main(int argc, char** argv) {
- silence_output(true);
- EOSIO_TEST(hello_test);
- return has_failed();
-}
-```
-
-Every `intrinsic` that is defined for eosio (prints, require_auth, etc.) is re-definable given the `intrinsics::set_intrinsics()` functions. These take a lambda whose arguments and return type should match that of the intrinsic you are trying to define. This gives the contract writer the flexibility to modify behavior to suit the unit test being written. A sister function `intrinsics::get_intrinsics()` will return the function object that currently defines the behavior for said intrinsic. This pattern can be used to mock functionality and allow for easier testing of smart contracts. For more information see, either the [tests](https://github.com/AntelopeIO/cdt/tree/main/examples/hello/tests/) directory or [hello_test.cpp](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/tests/hello_test.cpp) for working examples.
-
-## Compiling Native Code
-- Raw `cdt-cpp` to compile the test or program the only addition needed to the command line is to add the flag `-fnative` this will then generate native code instead of `wasm` code.
-- Via CMake
- - `add_native_library` and `add_native_executable` CMake macros have been added (these are a drop in replacement for add_library and add_executable).
-
-## CDT Native Tester API
-- CHECK_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed but allow the rest of the tests to run.
- - This is called either by
- - `CHECK_ASSERT("", [](){ whatever_function(); })`
- - `CHECK_ASSERT([](std::string msg){ user defined comparison function }, [](){ whatever_function(); })`
-- CHECK_PRINT(...) : This macro will check whether the print buffer holds the string that is expected and flag the tests as failed but allow the rest of the test to run.
- - This is called either by
- - `CHECK_PRINT("", [](){ whatever_function(); })`
- - `CHECK_PRINT([](std::string print_buffer){ user defined comparison function }, [](){ whatever_function(); })`
-- CHECK_EQUAL(X, Y) : This macro will check whether two inputs equal eachother and fail the test but allow the rest of the test to continue.
-- REQUIRE_ASSERT(...) : This macro will check whether a particular assert has occured and flag the tests as failed and halt the test on failure.
- - This is called either by
- - `REQUIRE_ASSERT("", [](){ whatever_function(); })`
- - `REQUIRE_ASSERT([](std::string msg){ user defined comparison function }, [](){ whatever_function(); })`
-- REQUIRE_PRINT(...) : This macro will check whether the print buffer holds the string that is expected and flag the tests as failed and halt the test on failure.
- - This is called either by
- - `REQUIRE_PRINT("", [](){ whatever_function(); })`
- - `REQUIRE_PRINT([](std::string print_buffer){ user defined comparison function }, [](){ whatever_function(); })`
-- REQUIRE_EQUAL(X, Y) : This macro will check whether two inputs `X` and `Y` equal eachother and fail the test and halt the test on failure.
-- EOSIO_TEST_BEGIN(X) : This macro defines the beginning of a unit test and assigns `X` as the symbolic name of that test.
-- EOSIO_TEST_END : This macro defines the end of a unit test.
-- EOSIO_TEST(X) : This is used to run a particular named unit test `X` in the main function.
diff --git a/cdt/05_features/50_crypto-extensions.md b/cdt/05_features/50_crypto-extensions.md
deleted file mode 100644
index 414517be8..000000000
--- a/cdt/05_features/50_crypto-extensions.md
+++ /dev/null
@@ -1,241 +0,0 @@
----
-content_title: Crypto Extensions
----
-
-As of `v3.0` crypto host functions were extended to include
-- `mod_exp`: Big integer modular exponentiation
-- `alt_bn128_add`, `alt_bn128_mul`, `alt_bn128_pair`: Add, multiply, and pairing check functions for the `alt_bn128` elliptic curve
-- `blake2_f`: `BLAKE2b F` compression function
-- `sha3`: sha3` hash function using `SHA3 NIST`
-- `Keccak256`: `sha3` hash function using `SHA3 Keccak`
-- `k1_recover`: Safe `ECDSA` uncompressed pubkey recover for the `secp256k1` curve
-
-In `v3.0`, `C` format was supported; in `v3.1`, `C++` format was added for better data abstraction.
-
-## Prerequisites
-
-- In `nodeos`, activate protocol feature `CRYPTO_PRIMITIVES` (`68d6405cb8df3de95bd834ebb408196578500a9f818ff62ccc68f60b932f7d82`)
-- In smart contract code, include `crypto_ext.hpp`
-
-## C Format
-
-- `int32_t alt_bn128_add( const char* op1, uint32_t op1_len, const char* op2, uint32_t op2_len, char* result, uint32_t result_len )`
-Perform addition operation on the elliptic curve `alt_bn128`, store the result in `result`, and return `0` if success otherwise `-1`
-- `int32_t alt_bn128_mul( const char* g1, uint32_t g1_len, const char* scalar, uint32_t scalar_len, char* result, uint32_t result_len )`
-Perform scalar multiplication operation on the elliptic curve `alt_bn128`
-- `int32_t alt_bn128_pair( const char* pairs, uint32_t pairs_len )`
-Perform Optimal-Ate pairing check elliptic curve `alt_bn128`, and return `0` if `true` and successful, `1` if `false`, otherwise `-1`
-- `int32_t mod_exp( const char* base, uint32_t base_len, const char* exp, uint32_t exp_len, const char* mod, uint32_t mod_len, char* result, uint32_t result_len )`
-Calculate `( BASE^EXP ) % MOD`, store in `result`, and return `0` if successful, otherwise `-1`
-- `int32_t blake2_f( uint32_t rounds, const char* state, uint32_t state_len, const char* msg, uint32_t msg_len, const char* t0_offset, uint32_t t0_len, const char* t1_offset, uint32_t t1_len, int32_t final, char* result, uint32_t result_len)`
-Implement BLAKE2 compression function `F`. Return `0` if success otherwise `-1`
-- `eosio::checksum256 sha3(const char* data, uint32_t length)`
-Return hash of `data` using `SHA3 NIST`
-- `void assert_sha3(const char* data, uint32_t length, const eosio::checksum256& hash)`
-Test if the SHA3 hash generated from data matches the provided digest
-- `eosio::checksum256 keccak(const char* data, uint32_t length)`
-Return hash of `data` using `SHA3 Keccak`
-- `void assert_keccak(const char* data, uint32_t length, const eosio::checksum256& hash)
-Test if the SHA3 keccak hash generated from data matches the provided digest
-- `int32_t k1_recover( const char* sig, uint32_t sig_len, const char* dig, uint32_t dig_len, char* pub, uint32_t pub_len )`
-Calculates the uncompressed public key used for a given signature on a given digest. Return `0` if success otherwise `-1`
-
-## C++ Format
-
-C++ types were added to represent `G1` and `G2` points (read and write) and views (read-only), and represent big integers. Their definitions are
-
-### Types
-
-```c++
- /**
- * Abstracts mutable G1 and G2 points
- *
- */
- template
- struct ec_point {
- /**
- * Bytes of the x coordinate
- */
- std::vector x;
-
- /**
- * Bytes of the y coordinate
- */
- std::vector y;
-
- /**
- * Construct a point given x and y
- *
- * @param x_ - The x coordinate, a vector of chars
- * @param y_ - The y coordinate, a vector of chars
- */
- ec_point(std::vector& x_, std::vector& y_);
-
- /**
- * Construct a point given a serialized point
- *
- * @param p - The serialized point
- */
- ec_point(std::vector& p);
-
- /**
- * Return serialzed point containing only x and y
- */
- std::vector serialized() const;
- };
-
- /**
- * Abstracts read-only G1 and G2 points
- */
- template
- struct ec_point_view {
- /**
- * Pointer to the x coordinate
- */
- const char* x;
-
- /**
- * Pointer to the y coordinate
- */
- const char* y;
-
- /**
- * Number of bytes in each of x and y
- */
- uint32_t size;
-
- /**
- * Construct a point view from x and y
- *
- * @param x_ - The x coordinate, poiter to chars
- * @param x_size - x's size
- * @param y_ - The y coordinate, poiter to chars
- * @param y_size - y's size
- */
- ec_point_view(const char* x_, uint32_t x_size, const char* y_, uint32_t y_size);
-
- /**
- * Construct a point view from a serialized point
- *
- * @param p - The serialized point
- */
- ec_point_view(const std::vector& p);
-
- /**
- * Construct a point view from a point
- *
- * @param p - The point
- */
- ec_point_view(const ec_point& p);
-
- /**
- * Return serialzed point containing only x and y
- */
- std::vector serialized() const;
- };
-
- static constexpr size_t g1_coordinate_size = 32;
- static constexpr size_t g2_coordinate_size = 64;
-
- using g1_point = ec_point;
- using g2_point = ec_point;
- using g1_point_view = ec_point_view;
- using g2_point_view = ec_point_view;
-
- /**
- * Big integer.
- *
- * @ingroup crypto
- */
- using bigint = std::vector;
-```
-
-### Methods
-
-- `alt_bn128_add`
-```c++
- template
- g1_point alt_bn128_add( const T& op1, const T& op2 )
-```
-Take two G1 points or G1 views as input and return a G1 point.
-- `alt_bn128_mul`
-```c++
- template
- g1_point alt_bn128_mul( const T& g1, const bigint& scalar)
-```
-Take a G1 point or view and a bigint as input and return a G1 point
-- `alt_bn128_pair`
-```c++
- template
- int32_t alt_bn128_pair( const std::vector>& pairs )
-```
-Take a pair of G1 and G2 as input.
-- `mod_exp`
-```c++
- int32_t mod_exp( const bigint& base, const bigint& exp, const bigint& mod, bigint& result )
-```
-Take bigints as input
-
-### Examples
-
-- `alt_bn128_add`
-```c++
- std::vector x1, y1, x2, y2;
-
- // point
- eosio::g1_point point1 {x1, y1};
- eosio::g1_point point2 {x2, y2};
- auto result = eosio::alt_bn128_add(point1, point2);
-
- // view
- eosio::g1_point_view point_view1 {x1.data(), x1.size(), y1.data(), y1.size()};
- eosio::g1_point_view point_view2 {x2.data(), x2.size(), y2.data(), y2.size()};
- result = eosio::alt_bn128_add(point_view1, point_view2);
-```
-
-- `alt_bn128_mul`
-```c++
- std::vector x, y, scaler;
- eosio::bigint s {scalar};
-
- // point
- eosio::g1_point g1_point {x, y};
- auto result = eosio::alt_bn128_mul(g1_point, s);
-
- // view
- eosio::g1_point_view g1_view {x.data(), x.size(), y.data(), y.size()};
- result = eosio::alt_bn128_mul(g1_view, s);
-```
-
-- `alt_bn128_pair`
-```c++
- std::vector g1_a_x, g1_a_y, g2_a_x, g2_a_y, g1_b_x, g1_b_y, g2_b_x, g2_b_y;
-
-
- // point
- eosio::g1_point g1_a {g1_a_x, g1_a_y};
- eosio::g2_point g2_a {g2_a_x, g2_a_y};
- eosio::g1_point g1_b {g1_b_x, g1_b_y};
- eosio::g2_point g2_b {g2_b_x, g2_b_y};
- std::vector> pairs { {g1_a, g2_a}, {g1_b, g2_b} };
- auto result = eosio::alt_bn128_pair(pairs);
-
- // view
- eosio::g1_point_view g1_view_a {g1_a_x.data(), g1_a_x.size(), g1_a_y.data(), g1_a_y.size()};
- eosio::g2_point_view g2_view_a {g2_a_x.data(), g2_a_x.size(), g2_a_y.data(), g2_a_y.size()};
- eosio::g1_point_view g1_view_b {g1_b_x.data(), g1_b_x.size(), g1_b_y.data(), g1_b_y.size()};
- eosio::g2_point_view g2_view_b {g2_b_x.data(), g2_b_x.size(), g2_b_y.data(), g2_b_y.size()};
- std::vector> view_pairs { {g1_a, g2_a}, {g1_b, g2_b} };
- result = eosio::alt_bn128_pair(view_pairs);
-```
-
-- `mod_exp`
-```c++
- std::vector base, exp, modulo;
- eosio::bigint base_val {base};
- eosio::bigint exp_val {exp};
- eosio::bigint modulo_val {modulo};
- eosio::bigint result( modulo.size(), '\0' );
-
- auto rc = eosio::mod_exp(base_val, exp_val, modulo_val, result);
-```
diff --git a/cdt/05_features/99_deferred_transactions.md b/cdt/05_features/99_deferred_transactions.md
deleted file mode 100644
index 12e5d82c5..000000000
--- a/cdt/05_features/99_deferred_transactions.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-content_title: Deferred Transactions
----
-
-Deferred communication conceptually takes the form of action notifications sent to a peer transaction. Deferred actions get scheduled to run, at best, at a later time, at the producer's discretion. There is no guarantee that a deferred action will be executed.
-
-As already mentioned, deferred communication will get scheduled later at the producer's discretion. From the perspective of the originating transaction, i.e., the transaction that creates the deferred transaction, it can only determine whether the create request was submitted successfully or whether it failed (if it fails, it will fail immediately). Deferred transactions carry the authority of the contract that sends them. A transaction can cancel a deferred transaction.
-
-[[warning | Deferred Transactions Are Deprecated]]
-| As of [EOSIO 2.0 RC1](https://github.com/EOSIO/eos/releases/tag/v2.0.0-rc1) deferred transactions are deprecated.
-
-Due to the above described behaviors it is not recommended to use `deferred transactions`.
-
-[[warning | Duplicate deferred transaction IDs]]
-| In earlier versions, prior to `v1.8.0`, it is possible to observe rare deferred transaction ID collisions because technically the protocol's validation rules allow any number of duplicate deferred transaction IDs. However, the block producing code prior to `v1.8.0` limited this to exactly one duplicate ID in the same block followed by at-most one duplicate ID in the following block. This behavior was mitigated starting with version `v1.8.0` making it functionally impossible to be achieved at the block producing code level. On top of that, the same version `v1.8.0` introduced the optional `NO_DUPLICATE_DEFERRED_ID` protocol feature which, if deployed, it makes this behavior impossible at the protocol layer as well.
diff --git a/cdt/06_how-to-guides/10_compile/01_compile-a-contract-via-cli.md b/cdt/06_how-to-guides/10_compile/01_compile-a-contract-via-cli.md
deleted file mode 100644
index 7cc8c1c80..000000000
--- a/cdt/06_how-to-guides/10_compile/01_compile-a-contract-via-cli.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-content_title: How to compile a smart contract via CLI
----
-
-## Overview
-
-This guide provides instructions how to compile a smart contract using the command line interface (CLI).
-
-## Before you begin
-
-* You have the source of the contract saved in a local folder, e.g. `./examples/hello/`
-## Procedure
-
-Follow the following steps to compile your contract.
-
-1. Navigate to the hello folder in examples `./examples/hello`. You should see the `./src/hello.cpp` file.
-
-2. Run the following commands:
-
- ```sh
- mkdir build
- cd build
- cdt-cpp ../src/hello.cpp -o hello.wasm -I ../include/
- ```
-
- Where:
- - `../src/hello.cpp` = Is the input cpp source file to be compiled.
- - `-o hello.wasm` = It instructs the `cdt--cpp` tool who to name the output wasm file.
- - `-I ../include/` = It tells `cdt-cpp` tool what the include folder path is, in this particular case it is a relative path.
-
-3. Verify the following two files were generated:
-
-* the compiled binary wasm: `hello.wasm`,
-* and the generated ABI file: `hello.abi`.
-
-## Summary
-
-In conclusion, the above instructions show how to compile a smart contract using the command line interface (CLI).
diff --git a/cdt/06_how-to-guides/10_compile/02_how-to-configure-cmake.md b/cdt/06_how-to-guides/10_compile/02_how-to-configure-cmake.md
deleted file mode 100644
index c62cd2a05..000000000
--- a/cdt/06_how-to-guides/10_compile/02_how-to-configure-cmake.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-content_title: How to configure CMake
----
-
-## Overview
-
-This guide provides instructions how to configure CMake.
-
-## Before you begin
-
-* You have installed CMake, for detailed instructions consult the official [CMake installation page](https://CMake.org/install/).
-
-## Procedure
-
-The following steps show:
-
-* [Automatic generation of CMake configuration](#automatic-generation-of-CMake-configuration)
-* [Manual generation of CMake configuration](#manual-generation-of-CMake-configuration)
-
-### Automatic generation of CMake configuration
-
-To compile a smart contract project with CMake, you'll need a CMake file. To use the new `cdt-init` tool to generate the directory structure stub `.hpp/.cpp` files and the CMake configuration files follow these steps:
-
- ```sh
- cd ~
- cdt-init --path=. --project=test_contract
- cd test_contract
- cd build
- cmake ..
- make
- ls -al test_contract
- ```
-
-At this point, you'll have the `test_contract.abi` and `test_contract.wasm` files in `~/test_contract/test_contract`. These files are ready to be deployed.
-
-### Manual generation of CMake configuration
-
-To create manually the CMake configuration, the template `CMakeLists.txt` in the examples folder is a good boilerplate for manual usage.
-
-1. In `CMakeLists.txt`:
-
- ```sh
- cmake_minimum_required(VERSION 3.5)
- project(test_example VERSION 1.0.0)
-
- find_package(cdt)
-
- add_contract( test test test.cpp )
- ```
-
-2. In `test.cpp`:
-
- ```c++
- #include
- using namespace eosio;
-
- class [[eosio::contract]] test : public eosio::contract {
- public:
- using contract::contract;
-
- [[eosio::action]] void testact( name test ) {
- }
- };
- ```
-
-3. The following CMake macros are provided:
-
-* `add_contract` is used to build your smart contract and generate an ABI. The first parameter is the contract name, the second is the CMake target name, and the rest are the CPP files needed to build the contract.
-
-* `target_ricardian_directory` can be used to add the directory where your ricardian contracts live to a specific CMake target.
-
-* `add_native_library` and `add_native_executable` are CMake macros for the native tester. They are drop in replacements for `add_library` and `add_executable`.
-
-## Summary
-
-In conclusion, the above instructions show how to configure CMake .
diff --git a/cdt/06_how-to-guides/10_compile/03_compiling-contracts-with-cmake.md b/cdt/06_how-to-guides/10_compile/03_compiling-contracts-with-cmake.md
deleted file mode 100644
index 9cb6ffe95..000000000
--- a/cdt/06_how-to-guides/10_compile/03_compiling-contracts-with-cmake.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-content_title: How to compile a smart contract with CMake
----
-
-## Overview
-
-This guide provides instructions to compile a smart contract with CMake.
-
-## Before you begin
-
-* You have the source of the contract saved in a local folder, e.g. `./examples/hello/`
-
-## Procedure
-
-Follow the following steps to compile your contract.
-
-1. Navigate to the hello folder in examples (./examples/hello), you should then see the ./src/hello.cpp file
-2. Run following commands:
-
- ```sh
- mkdir build
- cd build
- cmake ..
- make
- ```
-
-3. Verify the following two files were generated:
-
-* the compiled binary wasm: `hello.wasm`,
-* and the generated ABI file: `hello.abi`.
-
-## Summary
-
-In conclusion, the above instructions show how to compile a smart contract with CMake.
diff --git a/cdt/06_how-to-guides/20_authorization/how_to_restrict_access_to_an_action_by_user.md b/cdt/06_how-to-guides/20_authorization/how_to_restrict_access_to_an_action_by_user.md
deleted file mode 100644
index 04269f4b4..000000000
--- a/cdt/06_how-to-guides/20_authorization/how_to_restrict_access_to_an_action_by_user.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-content_title: How To Perform Authorization Checks
-link_text: How To Perform Authorization Checks
----
-
-## Overview
-
-This guide provides instructions how to perform authorization checks in a smart contract.
-
-## Before you begin
-
-1. You have the sources of a contract with a `hi` action defined and implemented.
-2. The `hi` action has defined one input parameter `user` of type `name`.
-
-## Code Reference
-
-See the following code reference guides for functions which can be used to implement authorization checks in a smart contract:
-
-* function [has_auth(name n)](../../reference/Namespaces/namespaceeosio#function-has_auth)
-* function [require_auth(name n)](../../reference/Namespaces/namespaceeosio#function-require_auth)
-* function [require_auth2(capi_name name, capi_name permission)](../../reference/Files/action_8h)
-* function [check(bool pred, ...)](../../reference/Namespaces/namespaceeosio#function-check)
-
-## Procedure
-
-The following steps show how to check authorization for `user` account for the `hi` action. There are three ways to accomplish an authorization check in a smart contract action implementation. You can use any of the methods provided below depending on your needs:
-
-* [Use check(...) in combination with has_auth(...)](#1-use-checkhas_auth)
-* [Use require_auth(...)](#2-use-require_auth)
-* [Use require_auth2(...)](#3-use-require_auth2)
-
-### 1. Use check(has_auth(...)...)
-
-The following code example enforces the action `hi` to be executed only by the account that is sent as parameter to the action, no matter what permission the account uses to sign the transaction (e.g. owner, active, code).
-
-[[info | Error message is custom]]
-| Observe that in this case the yielded error message is a custom one and thus it can be used to provide a better experience for the user.
-
-```cpp
-#include
-
-void hi( name user ) {
- check(has_auth(user), "User is not authorized to perform this action.");
- print( "Hello, ", name{user} );
-}
-```
-
-Another example can be found in the [Tic Tac Toe Tutorial](https://docs.eosnetwork.com/docs/latest/smart-contracts/tutorials/tic-tac-toe-game-contract#create-tictactoecpp-file).
-
-### 2. Use require_auth
-
-The below code enforces the action `hi` to be executed only by the account that is sent as parameter to the action, no matter what permission the account uses to sign the transaction (e.g. owner, active, code).
-
-```cpp
-void hi( name user ) {
- require_auth( user );
- print( "Hello, ", name{user} );
-}
-```
-
-[[info | Error message is not custom]]
-| Note that this time you can not customize the yielded error message, it will be a generic authorization error message.
-
-### 3. Use require_auth2
-
-The below code is enforces the action `hi` to be executed only by the account that is sent as parameter to the action and only if the permission used to sign the transaction is the 'active' one. In other words, if the same user uses the transaction with a different permission (e.g. code, owner) the execution of the action is halted.
-
-```cpp
-#include
-
-void hi( name user ) {
- require_auth2(user.value, "active"_n.value);
- print( "Hello, ", name{user} );
-}
-```
-
-[[info | Error message is not custom]]
-| Note that this time, as well as previous method, you can not customize the yielded error message, it will be a generic authorization error message.
-
-## Summary
-
-In conclusion, the above instructions show how to perform authorization checks in a smart contract.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md b/cdt/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md
deleted file mode 100644
index a8497d052..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-primary-index.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-content_title: How to define a primary index
----
-
-## Overview
-
-This guide provides instructions to define a primary index for a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-
-## Procedure
-
-Complete the following steps to define a primary index for the multi-index table `testtab`.
-
-### 1. Preparation And Initialization
-
-Include the `eosio.hpp` header and use the `using` directive to access the `eosio` namespace.
-
- ```cpp
- #include
- using namespace eosio;
- ```
-
-### 2. Define The Table Data Structure
-
-Define the data structure for the multi-index table.
-
- ```cpp
- struct [[eosio::table]] test_table {
- };
- ```
-
-Add the data structure data members. Each data member corresponds to a field of the multi-index table. A primary key is required when defining a multi-index table structure, therefore you need to know which is the multi-index table field that is the primary key for your multi-index table. The corresponding data member for the primary key field must store unique values. In this case it is the `test_primary` data member of type `eosio::name`.
-
- ```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- + // this data member stores a name for each row of the multi-index table
- + name test_primary;
- + // additional data stored in table row, e.g. an uint64_t type data
- + uint64_t datum;
- };
- ```
-
-### 3. Define The Primary Index
-
-Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key:
-
- ```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- + // mandatory definition for primary key getter
- + uint64_t primary_key( ) const { return test_primary.value; }
- };
- ```
-
-[[info | Secondary indexes information]]
-| Secondary indexes may be defined which are not unique. There can be up to 16 secondary indexes. Secondary indices support the following types:
-* uint64_t
-* uint128_t
-* uint256_t
-* double
-* long double
-
-### 4. Define A Multi-Index Type Alias
-
-For ease of use, define a type alias `test_table_t` based on the `eosio::multi_index` template type, parametarized with a random name `"testtaba"` and the `test_table` data structure. The names must adhere to `Antelope` account name restrictions.
-
- ```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
- + typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
- ```
-
-### 5. Instantiate The Multi-Index Table
-
-Declare the `testtab` multi-index table as a data member of type `test_table_t`.
-
- ```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
- typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
- + test_table_t testtab;
- ```
-
-Now you have instantiated a multi-index table, and assigned to `testtab` variable, which has a primary index defined for its `test_primary` data member.
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to define a primary index for a multi-index table.
-
-## Next Steps
-
-* You can [insert data in the multi-index table](./how-to-insert-data-into-a-multi-index-table).
-* You can [iterate and retrieve data](./how-to-iterate-and-retrieve-a-multi_index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md b/cdt/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md
deleted file mode 100644
index b689f52a2..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-secondary-index.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-content_title: How to define a secondary index
----
-
-## Overview
-
-This guide provides instructions to define a secondary index for a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index table `testtab` along with its `test_table` data structure, its mandatory primary index, and the type alias definition `test_table_t`. Please see [How To Define A Primary Index](./how-to-define-a-primary-index) to set up these prerequisites.
-
-## Procedure
-
-Complete the following steps to define a secondary index for the multi-index table `testtab`.
-
-### 1. Extend The Multi-Index Data Structure
-
-Add a second data member `secondary`, of type `eosio::name`, to the `test_table` data structure that defines the `testtab` data.
-
- ```diff
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- + name secondary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
- ```
-
-### 2. Add The Secondary Index Accessor Method
-
-Add `by_secondary()` method, which is the index accessor method to the new data member added. The secondary index, that will be added in the next step, will index this new data structure data member.
-
- ```diff
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- name secondary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- + uint64_t by_secondary( ) const { return secondary.value; }
- };
- ```
-
-### 3. Define The Secondary Index
-
-In the `test_table_t` type definition, add the definition of the secondary index with the use of the `eosio::indexed_by` template. `eosio::index_by` needs two parameters: the name of the index, `"secid"_n`, and a function call operator which extracts the value from the secondary data member as an index key. The function call operator is defined with the use of `eosio::const_mem_fun` template which receives two parameters: the data structure `test_table` and the reference to the getter function member `by_secondary`.
-
- ```diff
- - typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
- + typedef eosio::multi_index<"testtaba"_n, test_table, eosio::indexed_by<"secid"_n, eosio::const_mem_fun>> test_table_t;
- ```
-
-For reference see below the full contract definition code with all the changes described above.
-
-__multi_index_example.hpp__
-
- ```cpp
- #include
- using namespace eosio;
-
- // multi-index example contract class
- class [[eosio::contract]] multi_index_example : public contract {
- public:
- using contract::contract;
-
- // contract class constructor
- multi_index_example( name receiver, name code, datastream ds ) :
- // contract base class contructor
- contract(receiver, code, ds),
- // instantiate multi-index instance as data member (find it defined below)
- testtab(receiver, receiver.value)
- { }
-
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- name secondary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- uint64_t by_secondary( ) const { return secondary.value; }
- };
-
- // the multi-index type definition, for ease of use a type alias `test_table_t` is defined,
- // based on the multi_index template type, parametarized with a random name, the
- // test_table data structure, and the secondary index
- typedef eosio::multi_index<"testtaba"_n, test_table, eosio::indexed_by<"secid"_n, eosio::const_mem_fun>> test_table_t;
-
- // the multi-index table instance declared as a data member of type test_table_t
- test_table_t testtab;
-
- [[eosio::action]] void set( name user );
- [[eosio::action]] void print( name user );
-
- using set_action = action_wrapper<"set"_n, &multi_index_example::set>;
- using print_action = action_wrapper<"print"_n, &multi_index_example::print>;
- };
- ```
-
-Now you have instantiated the `testtab` as a multi-index table which has a primary index defined for its `test_primary` data member and a secondary index for its `secondary` data member.
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-[[warning | Do not add a secondary index to an existing table]]
-| Adding a secondary index to an existing multi-index table it will have unpredictable outcome. Consult the [Data design and migration](../best-practices/data-design-and-migration) documentation for more details.
-
-
-## Summary
-
-In conclusion, the above instructions show how to define a secondary index for a multi-index table.
-
-## Next Steps
-
-* You can [iterate and retrieve data using the secondary index](./how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md b/cdt/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md
deleted file mode 100644
index b46d08cfd..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-define-a-singleton.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-content_title: How to define a singleton
----
-
-## Overview
-
-This guide provides instructions to define a singleton.
-
-## Reference
-
-See the following code reference:
-
-* The [`singleton`](../../reference/Classes/classeosio_1_1singleton) class.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-
-## Procedure
-
-A singleton uses a single multi-index table to store named objects of various types. To define a simple singleton, which is storing an account `name` as primary value and a `uint64_t` as secondary value in structure `testtable`, follow the steps below:
-
-### 1. Preparation And Initialization
-
-Include the `eosio.hpp` and `singleton.hpp` headers and declare the `eosio` namespace usage
-
- ```cpp
- #include
- #include
- using namespace eosio;
- ```
-
-### 2. Define The Table Data Structure
-
-Define the data structure for the multi-index table:
-
- ```cpp
- struct [[eosio::table]] testtable {
- name primary_value;
- uint64_t secondary_value;
- };
- ```
-
-### 3. Define A Singleton Type Alias
-
-For ease of use, define a type alias `singleton_type` based on the `eosio::singleton` template type, parametarized with a random name `"testtable"` and the `testtable` data structure. The names must adhere to `Antelope` account name restrictions.
-
- ```diff
- struct [[eosio::table]] testtable {
- name primary_value;
- uint64_t secondary_value;
- };
- +using singleton_type = eosio::singleton<"testtable"_n, testtable>;
- ```
-
-### 4. Define The Singleton Instance
-
-Define the singleton table instance as a data member of type `singleton_type`.
-
- ```diff
- struct [[eosio::table]] testtable {
- name primary_value;
- uint64_t secondary_value;
- };
-
- using singleton_type = eosio::singleton<"testtable"_n, testtable>;
- +singleton_type singleton_instance;
- ```
-
-### 5. Initialize And Use The Singleton Instance
-
-Initialize the `singleton_instance` using the constructor with the parameters `receiver` and `code` (the last one in in this case is `receiver.value`). These parameters, combined with `testtable`, provide access to the partition of the RAM cache used by this singleton. In our example you initialize the `singleton_instance` data member in the smart contract constructor, see below:
-
- ```diff
- // singleton contract constructor
- singleton_example( name receiver, name code, datastream ds ) :
- contract(receiver, code, ds),
- + singleton_instance(receiver, receiver.value)
- { }
- }
- ```
-
-Now you have defined and initialized a singleton as a data member for the smart contract class. You can access it from any of the smart contract methods via `singleton_instance` data member. Below you can find a possible implementation for the full class singleton example contract.
-
-__singleton_example.hpp__
-
-```cpp
-#include
-#include
-using namespace eosio;
-
-class [[eosio::contract]] singleton_example : public contract {
- public:
- using contract::contract;
- singleton_example( name receiver, name code, datastream ds ) :
- contract(receiver, code, ds),
- singleton_instance(receiver, receiver.value)
- {}
-
- [[eosio::action]]
- void set( name user, uint64_t value );
- [[eosio::action]]
- void get( );
-
- struct [[eosio::table]] testtable {
- name primary_value;
- uint64_t secondary_value;
- uint64_t primary_key() const { return primary_value.value; }
- } testtablerow;
-
- using singleton_type = eosio::singleton<"testtable"_n, testtable>;
- singleton_type singleton_instance;
-
- using set_action = action_wrapper<"set"_n, &singleton_example::set>;
- using get_action = action_wrapper<"get"_n, &singleton_example::get>;
-};
-```
-
-Below is an example for the `get` and `set` actions. It also demonstrates the usage of the `get` and `set` singleton methods. Note that the `set` action makes use of the singleton's `set` method, for which the second parameter is the payer account for the RAM needed to store the new value.
-
-__singleton_example.cpp__
-
-```cpp
-#include
-
-[[eosio::action]] void singleton_example::set( name user, uint64_t value ) {
- auto entry_stored = singleton_instance.get_or_create(user, testtablerow);
- entry_stored.primary_value = user;
- entry_stored.secondary_value = value;
- singleton_instance.set(entry_stored, user);
-}
-
-[[eosio::action]] void singleton_example::get( ) {
- if (singleton_instance.exists())
- eosio::print(
- "Value stored for: ",
- name{singleton_instance.get().primary_value.value},
- " is ",
- singleton_instance.get().secondary_value,
- "\n");
- else
- eosio::print("Singleton is empty\n");
-}
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of singleton can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to define a singleton.
-
-## Next Steps
-
-* Singleton uses as underlying structure a multi-index table therefore you can [iterate and retrieve data](./how-to-iterate-and-retrieve-a-multi_index-table) from the singleton the same way you would with a multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md b/cdt/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md
deleted file mode 100644
index 5e8d0ab64..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-delete-data-from-a-multi-index-table.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-content_title: How to delete data from a multi-index table
----
-
-## Overview
-
-This guide provides instructions to to delete data from a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-* The [`multi-index::find(...)`](../../reference/Modules/group__multiindex#function-find) method.
-* The [`multi-index::erase(...)`](../../reference/Modules/group__multiindex#function-erase) method.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index `testab` table instance which stores `user` objects indexed by the primary key which is of type `eosio::name`. Consult the section [How to instantiate a multi-index table](./how-to-instantiate-a-multi-index-table.md) to learn how to set it up.
-
-## Procedure
-
-Complete the following steps to implement a `del` action which deletes an user object, identified by its account name, from the multi-index table.
-
-### 1. Find The User You Want To Delete
-
-Use the multi-index [`find(...)`](../../reference/Modules/group__multiindex#function-find) method to locate the user object you want to delete. The targeted user is searched based on its account name.
-
-```cpp
-[[eosio::action]] void multi_index_example::del( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-}
-```
-
-### 2. Delete The User If Found
-
-Check to see if the user exists and use [`erase`(...)](../../reference/Modules/group__multiindex#function-erase) method to delete the row from table. Otherwise print an informational message and return.
-
-```diff
-[[eosio::action]] void multi_index_example::del( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-+ if ( itr == testtab.end() ) {
-+ printf("User does not exist in table, nothing to delete");
-+ return;
-+ }
-
-+ testtab.erase( itr );
-}
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to delete data from a multi-index table.
-
-## Next Steps
-
-* You can verify if the user object was deleted from the multi-index table.
-
-```cpp
- // check if the user was deleted
- auto itr = testtab.find(user.value);
- if ( itr == testtab.end() ) {
- printf("User was deleted successfully.");
- }
- else {
- printf("User was NOT deleted!");
- }
-```
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md b/cdt/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md
deleted file mode 100644
index 75427f56c..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-insert-data-into-a-multi-index-table.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-content_title: How to insert data into a multi-index table
----
-
-## Overview
-
-This guide provides instructions to insert data into a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-* The [`multi-index::find(...)`](../../reference/Modules/group__multiindex#function-find) method.
-* The [`multi-index::emplace(...)`](../../reference/Modules/group__multiindex#function-emplace) method.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index `testab` table instance which stores `user` objects indexed by the primary key which is of type `eosio::name`. Consult the section [How to instantiate a multi-index table](./how-to-instantiate-a-multi-index-table.md) to learn how to set it up.
-
-## Procedure
-
-Complete the following steps to insert an user object in the `testtab` multi-index table:
-
-### 1. Verify If The User Already Exists
-
-Use of the multi-index table iterator to find out if the user object already exists. The targeted user is searched based on its account name.
-
-```cpp
-[[eosio::action]] void multi_index_example::set( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-}
-```
-
-### 2. Insert The User If Not Found In Table
-
-Use the [`emplace`](../../reference/Modules/group__multiindex#function-emplace) method to make the insertion if the user object is not already in the multi-index table. Otherwise print an informational message.
-
-```diff
-[[eosio::action]] void multi_index_example::set( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-
-+ if ( itr == testtab.end() ) {
-+ testtab.emplace( _self, [&]( auto& u ) {
-+ u.test_primary = user;
-+ u.secondary = "second"_n;
-+ u.datum = 0;
-+ });
-+ }
-+ else {
-+ printf("User already exists.");
-+ }
-}
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to insert data in a multi-index table.
-
-## Next Steps
-
-* You can [iterate and retrieve newly inserted data](./how-to-iterate-and-retrieve-a-multi_index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md b/cdt/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md
deleted file mode 100644
index 0a15ad44e..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-instantiate-a-multi-index-table.md
+++ /dev/null
@@ -1,185 +0,0 @@
----
-content_title: How to instantiate a multi-index table
----
-
-## Overview
-
-This guide provides instructions to instantiate a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-
-## Procedure
-
-Complete the following steps to instantiate a multi-index table `testtab`.
-
-### 1. Preparation And Initialization
-
-Include the `eosio.hpp` header and use the `using` directive to access the `eosio` namespace.
-
-```cpp
-#include
-using namespace eosio;
-```
-
-### 2. Define The Table Data Structure
-
-Define the data structure for the multi-index table.
-
-```cpp
- struct [[eosio::table]] test_table {
- };
-```
-
-Add the data structure data members. Each data member corresponds to a field of the multi-index table. A primary key is required when defining a multi-index table structure, therefore you need to know which is the multi-index table field that is the primary key for your multi-index table. The corresponding data member for the primary key field must store unique values. In this case it is the `test_primary` data member of type `eosio::name`.
-
- ```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- + // this data member stores a name for each row of the multi-index table
- + name test_primary;
- + // additional data stored in table row, e.g. an uint64_t type data
- + uint64_t datum;
- };
- ```
-
-### 3. Define The Primary Index
-
-Add the definition of the primary index for the multi-index table. The primary index type must be uint64_t, it must be unique and must be named `primary_key()`, otherwise the compiler (cdt-cpp) will generate an error saying it can not find the field to use as the primary key:
-
-```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
-+ // mandatory definition for primary key getter
-+ uint64_t primary_key( ) const { return test_primary.value; }
- };
-```
-
-[[info | Additional indexes information]]
-| Other, secondary, indexes if they will be defined can have duplicates. You can have up to 16 additional indexes and the field types can be uint64_t, uint128_t, uint256_t, double or long double.
-
-### 4. Define A Multi-Index Type Alias
-
-For ease of use, define a type alias `test_table_t` based on the `eosio::multi_index` template type, parametarized with a random name `"testtaba"` and the `test_table` data structure. The names must adhere to `Antelope` account name restrictions.
-
-```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
-+ typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
-```
-
-### 5. Instantiate The Multi-Index Table
-
-Declare the `testtab` multi-index table as a data member of type `test_table_t`.
-
-```diff
- // the data structure which defines each row of the table
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
- typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
-+ test_table_t testtab;
-```
-
-# 6. Initialize The Multi-Index Table Instance
-
-Initialize the data member `testtab` by passing to its constructor these two values: `receiver` for the `code` parameter and `receiver.value` for the `scope` parameter. These two parameters combined with table name `"testtaba"` provide access to the partition of the RAM cache used by this multi-index table, in this example you will initialize the `testtab` data member in the smart contract constructor
-
-```diff
-// contract class constructor
-multi_index_example( name receiver, name code, datastream ds ) :
- // contract base class contructor
- contract(receiver, code, ds),
- // instantiate multi-index instance as data member (find it defined below)
-+ testtab(receiver, receiver.value)
- { }
-```
-
-Now you have instantiated a multi-index table, and assigned to `testtab` variable, which has a primary index defined for its `test_primary` data member.
-
-Here is how the definition of a `multi_index_example` contract containing a multi-index table could look like after following all the steps above.
-
-__multi_index_example.hpp__
-
-```cpp
-#include
-using namespace eosio;
-
-// multi-index example contract class
-class [[eosio::contract]] multi_index_example : public contract {
- public:
- using contract::contract;
-
- // contract class constructor
- multi_index_example( name receiver, name code, datastream ds ) :
- // contract base class contructor
- contract(receiver, code, ds),
- // instantiate multi-index instance as data member (find it defined below)
- testtab(receiver, receiver.value)
- { }
-
- // the row structure of the multi-index table, that is, each row of the table
- // will contain an instance of this type of structure
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
- // the multi-index type definition, for ease of use define a type alias `test_table_t`,
- // based on the multi_index template type, parametarized with a random name and
- // the test_table data structure
- typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
-
- // the multi-index table instance declared as a data member of type test_table_t
- test_table_t testtab;
-
- [[eosio::action]] void set( name user );
- [[eosio::action]] void print( name user );
-
- using set_action = action_wrapper<"set"_n, &multi_index_example::set>;
- using print_action = action_wrapper<"print"_n, &multi_index_example::print>;
-};
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to define and instantiate a multi-index table instance.
-
-## Next Steps
-
-* You can [insert data in the multi-index table](./how-to-insert-data-into-a-multi-index-table).
-* You can [iterate and retrieve data](./how-to-iterate-and-retrieve-a-multi_index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md b/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md
deleted file mode 100644
index 9d0025896..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table-based-on-secondary-index.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-content_title: How to iterate and retrieve from multi-index table based on secondary index
----
-
-## Overview
-
-This guide provides instructions on how iterate and retrieve data from a multi-index table based on a secondary index defined in the multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-* The [`multi-index::find(...)`](../../reference/Modules/group__multiindex#function-find) method.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index `testab` table instance which stores `user` objects indexed by the primary key which is of type `eosio::name` and a secondary index for data member `secondary` of type `eosio::name` accessible through `by_secondary()` method. Consult the section [How to define a secondary index](./how-to-define-a-secondary-index) to learn how to set it up.
-
-## Procedure
-
-Complete the following steps to iterate, retrieve and print data from the `testtab` multi-index table using the secondary index.
-
-### 1. Define The bysec(...) Action
-
-Add an action to the definition of the multi-index table which takes as parameter an account name. This action will retrieve the user object stored in the multi-index based on the passed in account name parameter. The action will use the secondary index.
-
-```cpp
- [[eosio::action]] void bysec( name secid );
-```
-
-Optionally, for ease of use add the action wrapper definition as well.
-
-```diff
- [[eosio::action]] void bysec( name secid );
-
- +using bysec_action = action_wrapper<"bysec"_n, &multi_index_example::bysec>;
-```
-
-### 2. Implement The `bysec(...)` Action
-
-Search for the `user` name in the multi-index table using the secondary index. If found, print out the value of field `datum`. Otherwise raise and error with a custom message. In the contract definition add the following implementation for `print` action:
-
-```cpp
-// iterates the multi-index table rows using the secondary index and prints the row's values
-[[eosio::action]] void multi_index_example::bysec( name secid ) {
- // access the secondary index
- auto idx = testtab.get_index<"secid"_n>();
- // iterate through secondary index
- for ( auto itr = idx.begin(); itr != idx.end(); itr++ ) {
- // print each row's values
- eosio::print_f("Test Table : {%, %, %}\n", itr->test_primary, itr->secondary, itr->datum);
- }
-}
-```
-
-### 3. Put It All Together
-
-The full definition and implementation files for the contract should look like this:
-
-__multi_index_example.hpp__
-
-```cpp
-#include
-using namespace eosio;
-
-// multi-index example contract class
-class [[eosio::contract]] multi_index_example : public contract {
- public:
- using contract::contract;
-
- // contract class constructor
- multi_index_example( name receiver, name code, datastream ds ) :
- // contract base class contructor
- contract(receiver, code, ds),
- // instantiate multi-index instance as data member (find it defined below)
- testtab(receiver, receiver.value)
- { }
-
- // the row structure of the multi-index table, that is, each row of the table
- // will contain an instance of this type of structure
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- name secondary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- uint64_t by_secondary( ) const { return secondary.value; }
- };
-
- // the multi-index type definition, for ease of use define a type alias `test_table_t`,
- // based on the multi_index template type, parametarized with a random name, the
- // test_table data structure, and the secondary index
- typedef eosio::multi_index<"testtaba"_n, test_table, eosio::indexed_by<"secid"_n, eosio::const_mem_fun>> test_table_t;
-
- // the multi-index table instance declared as a data member of type test_table_t
- test_table_t testtab;
-
- [[eosio::action]] void set( name user );
- [[eosio::action]] void print( name user );
- [[eosio::action]] void bysec( name secid );
-
- using set_action = action_wrapper<"set"_n, &multi_index_example::set>;
- using print_action = action_wrapper<"print"_n, &multi_index_example::print>;
- using bysec_action = action_wrapper<"bysec"_n, &multi_index_example::bysec>;
-};
-```
-
-__multi_index_example.cpp__
-
-```cpp
-#include
-
-[[eosio::action]] void multi_index_example::set( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-
- if ( itr == testtab.end() ) {
- // user is not found in table, use emplace to insert a new row data structure in table
- testtab.emplace( _self, [&]( auto& u ) {
- u.test_primary = user;
- u.secondary = "second"_n;
- u.datum = 0;
- });
- }
-}
-
-[[eosio::action]] void multi_index_example::print( name user ) {
- // searches for the row that corresponds to the user parameter
- auto itr = testtab.find(user.value);
-
- // asserts if the row was found for user parameter, if fails use the given message
- check( itr != testtab.end(), "user does not exist in table" );
-
- // prints the test_primary and datum fields stored for user parameter
- eosio::print_f("Test Table : {%, %}\n", itr->test_primary, itr->datum);
-}
-
-// iterates the multi-index table rows using the secondary index and prints the row's values
-[[eosio::action]] void multi_index_example::bysec( name secid ) {
- // access the secondary index
- auto idx = testtab.get_index<"secid"_n>();
-
- // iterate through secondary index
- for ( auto itr = idx.begin(); itr != idx.end(); itr++ ) {
- // print each row's values
- eosio::print_f("Test Table : {%, %, %}\n", itr->test_primary, itr->secondary, itr->datum);
- }
-}
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to iterate and retrieve a multi-index table based on secondary index.
-
-## Next Steps
-
-* You can [insert data](./how-to-insert-data-into-a-multi-index-table) into the multi-index table.
-* You can [delete data](./how-to-delete-data-from-a-multi-index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md b/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md
deleted file mode 100644
index 7451c0f64..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-iterate-and-retrieve-a-multi_index-table.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-content_title: How to iterate and retrieve from multi-index table
----
-
-## Overview
-
-This guide provides instructions to iterate and retrieve data from a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-* The [`multi-index::find(...)`](../../reference/Modules/group__multiindex#function-find) method.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index `testab` table instance which stores `user` objects indexed by the primary key which is of type `eosio::name`. Consult the section [How to instantiate a multi-index table](./how-to-instantiate-a-multi-index-table) to learn how to set it up.
-
-## Procedure
-
-Complete the following steps to iterate, retrieve and print data from the `testtab` multi-index table.
-
-### 1. Define The print(...) Action
-
-Add a `print` action to the `testtab` multi-index table. The `print` action takes an account name as a parameter.
-
-```cpp
-[[eosio::action]] void print( name user );
-```
-
-Optionally, for ease of use add the action wrapper definition as well.
-
-```diff
-[[eosio::action]] void print( name user );
-
-+using print_action = action_wrapper<"print"_n, &multi_index_example::print>;
-```
-
-### 2. Implement The `print(...)` Action
-
-Search for the `user` name in the multi-index table using the primary index. If found, print out the value of field `datum`. Otherwise raise an error with a custom message. In the contract definition add the following implementation for `print` action:
-
-```cpp
- [[eosio::action]] void multi_index_example::print( name user ) {
- // searches for the row that corresponds to the user parameter
- auto itr = testtab.find(user.value);
-
- // asserts if the row was found for user parameter, if fails use the given message
- check( itr != testtab.end(), "user does not exist in table" );
-
- // prints the test_primary and datum fields stored for user parameter
- eosio::print_f("Test Table : {%, %}\n", itr->test_primary, itr->datum);
-}
-```
-
-### 3. Put It All Together
-
-The full definition and implementation files for the contract should look like this:
-
-__multi_index_example.hpp__
-
-```cpp
-#include
-using namespace eosio;
-
-// multi-index example contract class
-class [[eosio::contract]] multi_index_example : public contract {
- public:
- using contract::contract;
-
- // contract class constructor
- multi_index_example( name receiver, name code, datastream ds ) :
- // contract base class contructor
- contract(receiver, code, ds),
- // instantiate multi-index instance as data member (find it defined below)
- testtab(receiver, receiver.value)
- { }
-
- // the row structure of the multi-index table, that is, each row of the table
- // will contain an instance of this type of structure
- struct [[eosio::table]] test_table {
- // this data member stores a name for each row of the multi-index table
- name test_primary;
- // additional data stored in table row
- uint64_t datum;
- // mandatory definition for primary key getter
- uint64_t primary_key( ) const { return test_primary.value; }
- };
-
- // the multi-index type definition, for ease of use define a type alias `test_table_t`,
- // based on the multi_index template type, parametarized with a random name and
- // the test_table data structure
- typedef eosio::multi_index<"testtaba"_n, test_table> test_table_t;
-
- // the multi-index table instance declared as a data member of type test_table_t
- test_table_t testtab;
-
- [[eosio::action]] void set( name user );
- [[eosio::action]] void print( name user );
-
- using set_action = action_wrapper<"set"_n, &multi_index_example::set>;
- using print_action = action_wrapper<"print"_n, &multi_index_example::print>;
-};
-```
-
-__multi_index_example.cpp__
-
-```cpp
-#include
-
-[[eosio::action]] void multi_index_example::set( name user ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
-
- if ( itr == testtab.end() ) {
- // user is not found in table, use emplace to insert a new row data structure in table
- testtab.emplace( _self, [&]( auto& u ) {
- u.test_primary = user;
- u.secondary = "second"_n;
- u.datum = 0;
- });
- }
-}
-
-[[eosio::action]] void multi_index_example::print( name user ) {
- // searches for the row that corresponds to the user parameter
- auto itr = testtab.find(user.value);
-
- // asserts if the row was found for user parameter, if fails use the given message
- check( itr != testtab.end(), "user does not exist in table" );
-
- // prints the test_primary and datum fields stored for user parameter
- eosio::print_f("Test Table : {%, %}\n", itr->test_primary, itr->datum);
-}
-```
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to iterate and retrieve a multi-index table.
-
-## Next Steps
-
-* You can [insert data](./how-to-insert-data-into-a-multi-index-table) into the multi-index table.
-* You can [delete data](./how-to-delete-data-from-a-multi-index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md b/cdt/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md
deleted file mode 100644
index eee7e8604..000000000
--- a/cdt/06_how-to-guides/40_multi-index/how-to-modify-data-in-a-multi-index-table.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-content_title: How to modify data in a multi-index table
----
-
-## Overview
-
-This guide provides instructions to modify data in a multi-index table.
-
-## Reference
-
-See the following code reference:
-
-* The [`multi-index`](../../reference/Classes/classeosio_1_1multi__index) class.
-* The [`multi-index::modify(...)`](../../reference/Modules/group__multiindex#function-modify) method.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A multi-index `testab` table instance which stores `user` objects indexed by the primary key which is of type `eosio::name`. Consult the section [How to instantiate a multi-index table](./how-to-instantiate-a-multi-index-table) to learn how to set it up.
-
-## Procedure
-
-Complete the following steps to modify data in the `testtab` multi-index table.
-
-### 1. Define The mod(...) Action
-
-Add a `mod` action to the `testtab` multi-index table. The `mod` action takes as input parameters a `user` of type `eosio::name` and a `value` of type `uint32_t`. The `mod` action updates the `user` object `datum` data member with the `uint32_t` value.
-
-```cpp
-[[eosio::action]] void mod( name user, uint32_t value );
-```
-
-Optionally, for ease of use add the action wrapper definition as well.
-
-```diff
-[[eosio::action]] void mod( name user, uint32_t value );
-
-+using mod_action = action_wrapper<"mod"_n, &multi_index_example::mod>;
-```
-
-### 2. Find The User You Want To Modify
-
-Use the multi-index [`find(...)`](../../reference/Modules/group__multiindex#function-find) method to locate the user object you want to modify. The targeted user is searched based on its account name.
-
-```cpp
-[[eosio::action]] void multi_index_example::mod( name user, uint32_t value ) {
- auto itr = testtab.find(user.value);
-}
-```
-
-### 3. Yield Error If User Not Found
-
-If the `user` object you want to update is not found then raise an error message by using the [`eosio::check`](../../reference/Namespaces/namespaceeosio#function-check) method.
-
-```diff
-[[eosio::action]] void multi_index_example::mod( name user, uint32_t value ) {
- auto itr = testtab.find(user.value);
-+ check( itr != testtab.end(), "user does not exist in table" );
-}
-```
-
-### 4. Update The User If Found
-
-If the `user` object you want to update is found, the [`eosio::check`](../../reference/Namespaces/namespaceeosio#function-check) method will do nothing and the iterator `itr` will be pointing at the object which you want to update. Use the [`multi-index::modify(...)`](../../reference/Modules/group__multiindex#function-modify) method to update the user object `datum` data member with the `value` parameter.
-
-```diff
-[[eosio::action]] void multi_index_example::mod( name user, uint32_t value ) {
- // check if the user already exists
- auto itr = testtab.find(user.value);
- check( itr != testtab.end(), "user does not exist in table" );
-
-+ testtab.modify( itr, _self, [&]( auto& row ) {
-+ row.datum = value;
-+ });
-}
-```
-
-Now you have implemented a new action `mod`. Call `mod` to update the `datum` data member for the user object identified by the `user` name parameter.
-
-[[info | Full example location]]
-| A full example project demonstrating the instantiation and usage of multi-index table can be found [here](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to modify data in a multi-index table.
-
-## Next Steps
-
-* You can [insert data](./how-to-insert-data-into-a-multi-index-table) into the multi-index table.
-* You can [delete data](./how-to-delete-data-from-a-multi-index-table) from the multi-index table.
diff --git a/cdt/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md b/cdt/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md
deleted file mode 100644
index 9ecac19b0..000000000
--- a/cdt/06_how-to-guides/50_how-to-create-and-use-action-wrappers.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-content_title: How to create and use action wrappers
-link_text: "How to create and use action wrappers"
----
-
-## Overview
-
-This guide provides instructions to create and use an action wrapper in a smart contract.
-
-## Code Reference
-
-See the following code reference guide for action wrapper:
-
-* [eosio::action_wrapper](../reference/Classes/structeosio_1_1action__wrapper).
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A smart contract named `multi_index_example`, defined in file `multi_index_example.hpp`.
-* An action `mod` which modifies the integer value `n` stored for row with key `user`.
-
-Refer to the following reference implementation for your starting point:
-
-```cpp
-class [[eosio::contract]] multi_index_example : public contract {
- // ...
- [[eosio::action]] void mod( name user, uint32_t n );
- // ...
-}
-```
-
-## Procedure
-
-Complete the following steps to create and use `mod_action` action wrapper for the existing `mod` action in the smart contract:
-
-1. [Define the action wrapper](#1-define-the-action-wrapper)
-2. [Use the action wrapper](#2-use-the-action-wrapper)
- * [2.1. Include Header File](#21-include-header-file)
- * [2.2. Instantiate The Action Wrapper](#22-instantiate-the-action-wrapper)
- * [2.3. Send The Action Using The Action Wrapper](#23-send-the-action-using-the-action-wrapper)
-
-### 1. Define The Action Wrapper
-
-To define an action wrapper for the `mod` action, use the `eosio::action_wrapper` template, with the first parameter the action name as a `eosio::name` and second parameter as the reference to the action method:
-
-```diff
-class [[eosio::contract]] multi_index_example : public contract {
- // ...
- [[eosio::action]] void mod(name user);
- // ...
-+ using mod_action = action_wrapper<"mod"_n, &multi_index_example::mod>;
- // ...
-}
-```
-
-### 2. Use The Action Wrapper
-
-#### 2.1. Include Header File
-
-To use the action wrapper, you have to include the header file where the action wrapper is defined:
-
-```cpp
-#include
-```
-
-#### 2.2. Instantiate The Action Wrapper
-
-Instantiate the `mod_action`. Specify the contract to send the action to as the first argument. In this case, it is assumed the contract is deployed to `multiindexex` account. Specify a structure with two parameters: the self account, obtained by `get_self()` call, and the `active` permission (you can modify these two parameters based on your requirements).
-
-```diff
-#include
-
-+multi_index_example::mod_action modaction("multiindexex"_n, {get_self(), "active"_n});
-```
-
-#### 2.3. Send The Action Using The Action Wrapper
-
-Call the `send` method of the action wrapper and pass in the `mod` action's parameters as positional arguments:
-
-```diff
-#include
-
-multi_index_example::mod_action modaction("multiindexex"_n, {get_self(), 1});
-
-+modaction.send("eostutorial"_n, 1);
-```
-
-For a full example see the [multi_index example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/multi_index_example).
-
-## Summary
-
-In conclusion, the above instructions show how to create and use action wrapper in a smart contract.
diff --git a/cdt/06_how-to-guides/60_how-to-return-values-from-actions.md b/cdt/06_how-to-guides/60_how-to-return-values-from-actions.md
deleted file mode 100644
index 3f1266a88..000000000
--- a/cdt/06_how-to-guides/60_how-to-return-values-from-actions.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-content_title: How-To Return Values From Action
----
-
-## Overview
-
-This how-to demonstrates how a smart contract developer implements return values from an action.
-
-In order to accomplish this, use the `return` statement and pass the desired returned value, which can be of any C++ primitive type, a standard library type, or a user defined type.
-
-## Before you begin
-
-Make sure you have the following prerequisites in place:
-
-* An Antelope development environment, for details consult the [Documentation Portal](https://docs.eosnetwork.com/docs/latest/).
-* A smart contract, let’s call it `smrtcontract`, which builds without error.
-* An action, let’s call it `checkwithrv`, from which you want to return a value of a user defined type `action_response`.
-
-Refer to the following reference implementation for your starting point:
-
-```cpp
-struct action_response
-{
- uint16_t id;
- std::pair status;
-};
-
-class [[eosio::contract]] smrtcontract : public contract {
- public:
- using contract::contract;
-
- [[eosio::action]]
- action_response checkwithrv( name nm );
-};
-```
-
-## Procedure
-
-Complete the following steps to return an instance of `action_response` from the `checkwithrv` action:
-
-1. Create an instance of the `action_response` C++ user defined structure.
-2. Initialize its data members based on the action’s business logic.
-3. Use `return` statement and pass as a parameter the instance created and initialized in previous steps.
-
-```cpp
-[[eosio::action]]
-action_response smrtcontract::checkwithrv( name nm ) {
- print_f("Name : %\n", nm);
-
- // create instance of the action response structure
- action_response results;
-
- // initialize its data members
- results.id = 1;
- if (nm == "hello"_n) {
- results.status = {0, "Validation has passed."};
- }
- else {
- results.status = {1, "Input param `name` not equal to `hello`."};
- }
-
- // use return statement
- return results; // the `set_action_return_value` intrinsic is invoked automatically here
-}
-```
-
-For a complete example of a smart contract that implements an action which returns a value see the [hello example contract](https://github.com/AntelopeIO/cdt/blob/main/examples/hello).
-
-## Next Steps
-
-* Compile the smart contract and deploy it to the Antelope testnet or any Antelope based blockchain.
-* Use the `cleos` command to send the `checkwithrv` action to the smart contract and observe the returned value in the `cleos` output.
-* Use other means (e.g. programmatically) to send the `checkwithrv` action to the smart contract and observe the returned value in the action trace.
-
-[[info | Returned values from actions availability]]
-The action return values are only available to clients sending the action via the RPC API. Currently, there is no support for an inline action to be able to use the return value, because inline actions don't execute synchronously.
-
-## Summary
-
-In conclusion, the above instructions show how to return values from actions.
diff --git a/cdt/07_best-practices/02_naming-conventions.md b/cdt/07_best-practices/02_naming-conventions.md
deleted file mode 100644
index 3cc91fc08..000000000
--- a/cdt/07_best-practices/02_naming-conventions.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-content_title: Naming conventions
----
-
-When implementing Antelope smart contracts and when storing data in an Antelope blockchain, it is important to follow the established Antelope conventions for naming accounts, actions, tables, etc.
-
-## Antelope names
-
-* Applies to all Antelope encoded names (accounts, actions, tables, etc.)
-* Encoded as a 64-bit unsigned integer (`uint64_t`) on the blockchain.
-* First 12 characters, if any, encoded in `base32` using characters: `.`, `1-5`, `a-z`
-* 13th character, if applicable, encoded in `base16` using characters: `.`, `1-5`, `a-j`
-
-### Standard account names
-
-* Must contain exactly 12 characters from the `base32` set: `.`, `1-5`, `a-z`
-* 13th character not allowed or lesser than 12 characters
-* Must start with a lowercase letter `a-z`
-* Must not end in a dot `.` character
-
-### Non-standard account names
-
-* May contain between 1 and 12 characters from the `base32` set: `.`, `1-5`, `a-z`
-* 13th character not allowed in account name
-* Must not end in a dot `.` character
-
-### Table, struct, class, function (action) names
-
-* May contain between 1 and 13 characters.
-* First 12 characters, if any, from the `base32` set: `.`, `1-5`, `a-z`
-* 13th character, if any, from the `base16` set: `.`, `1-5`, `a-j`
-
-### Format
-
-The figure below showcases a 12 character string formatted into a 64-bit unsigned integer. Note: the 13th char, if any, contains 24 = 16 cases per 1 digit (char): 1 (`.`) + 5 (`1-5`) + 10 (`a-j`).
-
-
-
-## Encoding and decoding
-
-Antelope name objects can be created, encoded, and decoded via the `eosio::name` class.
-
-1. To encode an `std::string` into an Antelope name object, use the appropriate `eosio::name()` constructor.
-2. To encode a `char *` string literal into an Antelope name object, you can also use the `""_n` operator.
-3. To decode an Antelope name object into an `std::string`, use the `eosio::to_string()` function.
-
-### Examples
-
-```cpp
-auto eosio_user = eosio::name{user}; //encodes user string to eosio::name object
-auto user_str = user_name_obj.to_string(); //decodes eosio::name obj to string
-auto standard_account = "standardname"_n; //encodes literal string to eosio::name
-auto non_standard_account = ".standard"_n; //encodes literal string to eosio::name
-```
diff --git a/cdt/07_best-practices/03_resource-planning.md b/cdt/07_best-practices/03_resource-planning.md
deleted file mode 100644
index 4be5c4278..000000000
--- a/cdt/07_best-practices/03_resource-planning.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-content_title: Resource planning
----
-
-How much RAM do I need? This is not an easy question to answer, and there's really no perfect answer for it. You need to find out by measuring your contracts' actions and by planning accordingly based on your predictions on how fast and how much your blockchain application will grow. If your blockchain application growth is requiring more storage capacity you'll need to buy more RAM. If it requires more actions to be executed in the 3 day window (the staking time) you need to stake more tokens for CPU bandwidth. If your blockchain application growth means more actions will be stored on the blockchain then you also will need to expand your NET bandwidth maximum limit by staking more tokens for NET bandwidth.
-
-*Ok, you say, but how much?*
-
-You need to test and simulate various business scenarios that apply to your blockchain application and measure their resource usage. Hence, the existence of the public test networks. These allow you to measure how much RAM, CPU, and NET each action consumes, and to measure worst and best case business scenarios. You can then extrapolate and build a fairly good view of your blockchain application's resource needs.
-
-Once you have a fair idea of how your contract, blockchain application, and user base are consuming blockchain resources on a public test-net you can estimate what you'll need to start with on any Antelope-based networks, public or private. From that point onward, as with any other application, it is advisable to have monitors that tell you statistics and metrics about your application performance.
-
-Of course some aspects might differ from network to network, because each network might have altered its system contracts. The Antelope code base is open sourced and it can be tailored to each network's requirements. You need to be aware of these differences and take them into account if this is the case with a network you're testing on.
-
-The Antelope community is also providing tools that can help you in this endeavor. One example is https://www.eosrp.io
-Because the RAM price varies and because the CPU and NET bandwidth allocations vary too, as it is explained in the previous section, this tool can help you estimate how much of each resource you can allocate based on a specific amount of tokens and vice-versa.
-
-Another aspect of resource planning involves making sure your contract is efficient, that is, not consuming resources unnecessarily. Therefore, it is beneficial for you to find answers to the following questions when writing your own smart contracts and blockchain applications:
-
- * Is your smart contract storing only the information that is necessary to be stored on a blockchain and for the rest is using alternative ways for storing data (e.g. IPFS)?
- * If you have multiple smart contracts, are they communicating between them too much via inline actions? Could some of the smart contracts be merged into one and thus eliminate the need to spawn inline actions between them, reducing the overall inline actions count and thus resource consumption?
- * Could you change your smart contracts so that your clients pay for some parts of the RAM used? Recall how originally the addressbook contract was making each new account added to the book pay for the RAM needed to store its individual data?
- * Or conversely, are you making your clients pay too much RAM or CPU in order to access your contracts' actions, to the point where you are prohibiting their use of your smart contract? Would it be better for your blockchain application's growth and success to take on some of those costs?
diff --git a/cdt/07_best-practices/04_data-design-and-migration.md b/cdt/07_best-practices/04_data-design-and-migration.md
deleted file mode 100644
index 87c040d9f..000000000
--- a/cdt/07_best-practices/04_data-design-and-migration.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-content_title: Data design and migration
----
-
-Antelope based blockchains allow developers to easily update their smart contract code. However, a few things need to be considered when it comes to data updates and/or migration. The multi-index table API is one of the mechanisms (Key-Value API being the other) for storing and updating blockchain state. The multi-index table API creates and uses data structures in RAM. Once created and deployed on the blockchain there are limitations if you want to update these structures. Below you will find a few approaches to your smart contract data design, updates to this design, and for data migration.
-
-# How to modify a data structure defined using multi-index table API
-
-Modifying a deployed multi-index table structure may be done by selecting one of the different strategies outlined below:
-
-## 1. If you don't mind losing the existing data
-
-If you don't mind losing the data from the initial table you can follow these two steps:
-
-1. Erase all records from first table
-2. Deploy a new contract with modified table structure
-
-## 2. If you want to keep the existing data
-
-If you want to keep the existing data there are two ways to do it:
-
-### 2.1. Using binary extensions
-
-To learn how to modify the structure using binary extensions read this [tutorial](../09_tutorials/01_binary-extension.md).
-
-### 2.2. Using ABI variants
-
-To learn how to modify the structure using ABI variants read this [tutorial](../09_tutorials/02_abi-variants.md).
-
-### 2.3. Migrate the existing data to a second table
-
-#### 2.3.1. Migration without downtime, but slower
-
-1. Create the new version of your multi-index table alongside the old one.
-2. Transfer data from the old table to the new one. You may do so as part of your normal access pattern, first checking the new table to see if the entry you seek is present and if not, check the original table, and if it's present, migrate it while adding the data for the new field, then remove it from the original table to save RAM costs.
-3. You must retain both versions of your multi-index table until you have completed this migration, at which point you may update your contract to remove the original version of your multi-index table.
-
-#### 2.3.2. Migration with downtime, but faster
-
-If you prefer less code complexity and can accept downtime for your application:
-
-1. Deploy a version of your contract solely for migration purposes, and run migration transactions on every row of your table until complete. If the first table is big, e.g. has a large number of rows, the transaction time limit could be reached while running the migration transactions. To mitigate this implement the migrate function to move a limited number of rows each time it runs.
-2. Deploy a new contract using only the new version of the table, at which point, your migration and downtime is complete.
-
-[[caution]]
-| Both of the above migration methods require some pre-planning (like the ability to put your contract into a maintenance mode for user feedback)
diff --git a/cdt/07_best-practices/05_securing_your_contract.md b/cdt/07_best-practices/05_securing_your_contract.md
deleted file mode 100644
index fca6c9769..000000000
--- a/cdt/07_best-practices/05_securing_your_contract.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-content_title: Securing your contract
----
-
-## Basic Recommendations
-
-The following are basic recommendations which can be the foundation for securing your smart contract.
-
-### 1. Authorization Checks
-
-The following methods are available in the `Antelope` library and they can be used to implemented authorization checks in your smart contracts:
-
-- [`has_auth`](../group__action/#function-has_auth)
-- [`require_auth`](../group__action/#function-require_auth)
-- [`require_auth2`](../how-to-guides/authorization/how_to_restrict_access_to_an_action_by_user/#3-using-require_auth2)
-- [`require_recipient`](../group__action/#function-require_recipient)
-
-### 2. Resource Management
-
-Understand how each of your contracts' actions is impacting the RAM, CPU, and NET consumption, and which account ends up paying for these resources.
-
-### 3. Secure by Default
-
-Have a solid and comprehensive development process that includes security considerations from day one of the product planning and development.
-
-### 4. Continuous Integration And Continuous Delivery
-
-Test your smart contracts with every update announced for the blockchain you have deployed to. To ease your work, automate the testing as much as possible so you can run them often, and improve them periodically.
-
-### 5. Security Audits
-
-Conduct independent smart contract audits, at least two from different organizations.
-
-### 6. Bug Bounties
-
-Host periodic bug bounties on your smart contracts and keep a continuous commitment to reward real security problems reported at any time.
diff --git a/cdt/07_best-practices/07_error_handling.md b/cdt/07_best-practices/07_error_handling.md
deleted file mode 100644
index 645b7b5a3..000000000
--- a/cdt/07_best-practices/07_error_handling.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-content_title: Error handling
----
-
-Contracts can use `uint64_t` error codes as an alternative (and shorter) means of signaling error conditions, as opposed to string error messages. However, Antelope and CDT reserve certain ranges of the `uint64_t` value space for their own purposes. Contract developers must be aware of the following ranges and restrictions:
-
-1. $0 - 4,999,999,999,999,999,999$:
-Available for contract developers to assign error codes specific to their contracts.
-
-2. $5,000,000,000,000,000,000 - 7,999,999,999,999,999,999$:
-Reserved for the CDT compiler to allocate as appropriate. Although the WASM code generated by the CDT compiler may use error code values that were automatically generated from within this range, the error codes in this range are meant to have meaning specific to the particular compiled contract (the meaning would typically be conveyed through the mapping between the error code value and strings in the associated generated ABI file).
-
-3. $8,000,000,000,000,000,000 - 9,999,999,999,999,999,999$:
-Reserved for the CDT compiler to allocate as appropriate. The error codes in this range are not specific to any contract but rather are used to convey general runtime error conditions associated with the generated code by CDT.
-
-4. $10,000,000,000,000,000,000 - 18,446,744,073,709,551,615$:
-Reserved by the Antelope protocol to represent protocol-level error conditions. Antelope will actually enforce this by restricting the ability for `eosio_assert_code` to be used to fail with error code values used within this range.
-
-Therefore, contract developers should only reserve error codes from the first range above to use in their contracts.
diff --git a/cdt/07_best-practices/08_abi/00_understanding-abi-files.md b/cdt/07_best-practices/08_abi/00_understanding-abi-files.md
deleted file mode 100644
index a5b33165a..000000000
--- a/cdt/07_best-practices/08_abi/00_understanding-abi-files.md
+++ /dev/null
@@ -1,546 +0,0 @@
----
-content_title: "Understanding ABI Files"
-link_text: "Understanding ABI Files"
----
-## Introduction
-
-ABI files can be generated using the `cdt-cpp` utility provided by CDT. However, there are several situations that may cause ABI's generation to malfunction or fail altogether. Advanced C++ patterns can trip it up and custom types can sometimes cause issues for ABI generation. For this reason, it's **imperative** you understand how ABI files work, so you can debug and fix if and when necessary.
-
-## What is an ABI
-
-The Application Binary Interface (ABI) is a JSON-based description on how to convert user actions between their JSON and Binary representations. The ABI also describes how to convert the database state to/from JSON. Once you have described your contract via an ABI then developers and users will be able to interact with your contract seamlessly via JSON.
-
-[[warning | Security Note]]
-| ABI can be bypassed when executing transactions. Messages and actions passed to a contract do not have to conform to the ABI. The ABI is a guide, not a gatekeeper.
-
-## Create an ABI File
-
-Start with an empty ABI, for exemplification we will work based on the `eosio.token` therefore name it `eosio.token.abi`:
-
-```text
-{
- "version": "eosio::abi/1.0",
- "types": [],
- "structs": [],
- "actions": [],
- "tables": [],
- "ricardian_clauses": [],
- "abi_extensions": [],
- "___comment" : ""
-}
-```
-
-## Types
-
-An ABI enables any client or interface to interpret and even generate a GUI for your contract. For this to work consistently, describe the custom types that are used as a parameter in any public action or struct that needs to be described in the ABI.
-
-[[info | Built-in Types]]
-| Antelope implements a number of custom built-ins. Built-in types don't need to be described in an ABI file. If you would like to familiarize yourself with Antelope's built-ins, they are defined [here](https://github.com/AntelopeIO/leap/blob/6817911900a088c60f91563995cf482d6b380b2d/libraries/chain/abi_serializer.cpp#L88-L129)
-
-
-```json
-{
- "new_type_name": "name",
- "type": "name"
-}
-```
-The ABI now looks like this:
-
-```json
-{
- "version": "eosio::abi/1.1",
- "types": [{
- "new_type_name": "name",
- "type": "name"
- }],
- "structs": [],
- "actions": [],
- "tables": [],
- "ricardian_clauses": [],
- "abi_extensions": []
-}
-```
-
-## Structs
-
-Structs that are exposed to the ABI also need to be described. By looking at eosio.token.hpp, it can be quickly determined which structs are utilized by public actions. This is particularly important for the next step.
-
-A struct's object definition in JSON looks like the following:
-
-```json
-{
- "name": "issue", //The name
- "base": "", //Inheritance, parent struct
- "fields": [] //Array of field objects describing the struct's fields.
-}
-```
-## Fields
-
-```json
-{
- "name":"", // The field's name
- "type":"" // The field's type
-}
-```
-In the `eosio.token` contract, there's a number of structs that require definition. Please note, not all of the structs are explicitly defined, some correspond to an actions' parameters. Here's a list of structs that require an ABI description for the `eosio.token` contract:
-
-## Implicit Structs
-
-The following structs are implicit in that a struct was never explicitly defined in the contract. Looking at the [create](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-create) action, you'll find two parameters, `issuer` of type `name ` and `maximum_supply` of type `asset`. For brevity this tutorial won't break down every struct, but applying the same logic, you will end up with the following:
-
-### [create](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-create)
-
-```json
-{
- "name": "create",
- "base": "",
- "fields": [
- {
- "name":"issuer",
- "type":"name"
- },
- {
- "name":"maximum_supply",
- "type":"asset"
- }
- ]
-}
-```
-### [issue](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-issue)
-
-```json
-{
- "name": "issue",
- "base": "",
- "fields": [
- {
- "name":"to",
- "type":"name"
- },
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
-}
-```
-### [retire](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-retire)
-
-```json
-{
- "name": "retire",
- "base": "",
- "fields": [
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
-}
-```
-
-### [transfer](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-transfer)
-
-```json
-{
- "name": "transfer",
- "base": "",
- "fields": [
- {
- "name":"from",
- "type":"name"
- },
- {
- "name":"to",
- "type":"name"
- },
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
-}
-```
-
-### [close](http://docs.eosnetwork.com/system-contracts/latest/reference/Classes/classeosio_1_1token#function-close)
-
-```json
-{
- "name": "close",
- "base": "",
- "fields": [
- {
- "name":"owner",
- "type":"name"
- },
- {
- "name":"symbol",
- "type":"symbol"
- }
- ]
- }
-```
-
-## Explicit Structs
-
-These structs are explicitly defined, as they are a requirement to instantiate a multi-index table. Describing them is no different than defining the implicit structs as demonstrated above.
-
-### [account](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L120)
-
-```json
-{
- "name": "account",
- "base": "",
- "fields": [
- {
- "name":"balance",
- "type":"asset"
- }
- ]
-}
-```
-
-## Actions
-
-An action's JSON object definition looks like the following:
-
-```json
-{
- "name": "transfer", //The name of the action as defined in the contract
- "type": "transfer", //The name of the implicit struct as described in the ABI
- "ricardian_contract": "" //An optional ricardian clause to associate to this action describing its intended functionality.
-}
-```
-Describe the actions of the `eosio.token` contract by aggregating all the public functions described in the `eosio.token` contract's [header file](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp).
-
-Then describe each action's *type* according to its previously described struct. In most situations, the function name and the struct name will be equal, but are not required to be equal.
-
-Below is a list of actions that link to their source code with example JSON provided for how each action would be described.
-
-## [create](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L35-L37)
-
-```json
-{
- "name": "create",
- "type": "create",
- "ricardian_contract": ""
-}
-```
-
-## [issue](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L45-L46)
-
-```json
-{
- "name": "issue",
- "type": "issue",
- "ricardian_contract": ""
-}
-```
-
-## [retire](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L55-L56)
-
-```json
-{
- "name": "retire",
- "type": "retire",
- "ricardian_contract": ""
-}
-```
-
-## [transfer](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L67-L71)
-
-```json
-{
- "name": "transfer",
- "type": "transfer",
- "ricardian_contract": ""
-}
-```
-
-## [close](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L96-L97)
-
-```json
-{
- "name": "close",
- "type": "close",
- "ricardian_contract": ""
-}
-```
-
-## Tables
-
-Describe the tables. Here's a table's JSON object definition:
-
-```json
-{
- "name": "", //The name of the table, determined during instantiation.
- "type": "", //The table's corresponding struct
- "index_type": "", //The type of primary index of this table
- "key_names" : [], //An array of key names, length must equal length of key_types member
- "key_types" : [] //An array of key types that correspond to key names array member, length of array must equal length of key names array.
-}
-```
-
-The eosio.token contract instantiates two tables, [accounts](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L134) and [stat](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L135).
-
-The `accounts` table is an i64 index, based on the [`account` struct](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L120-L124), has a [`uint64` as it's primary key](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L123)
-
-Here's how the accounts table would be described in the ABI
-
-```json
-{
- "name": "accounts",
- "type": "account", // Corresponds to previously defined struct
- "index_type": "i64",
- "key_names" : ["primary_key"],
- "key_types" : ["uint64"]
-}
-```
-
-The `stat` table is an i64 index, based on the [`currency_stats` struct](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L126-L132), has a [`uint64` as it's primary key](https://github.com/AntelopeIO/reference-contracts/blob/main/contracts/eosio.token/include/eosio.token/eosio.token.hpp#L131)
-
-Here's how the stat table would be described in the ABI
-
-```json
-{
- "name": "stat",
- "type": "currency_stats",
- "index_type": "i64",
- "key_names" : ["primary_key"],
- "key_types" : ["uint64"]
-}
-```
-You'll notice the above tables have the same "key name." Naming your keys similar names is symbolic in that it can potentially suggest a subjective relationship. As with this implementation, implying that any given value can be used to query different tables.
-
-## Putting it all Together
-
-Finally, an ABI file that accurately describes the `eosio.token` contract.
-
-```json
-{
- "version": "eosio::abi/1.1",
- "types": [
- {
- "new_type_name": "name",
- "type": "name"
- }
- ],
- "structs": [
- {
- "name": "create",
- "base": "",
- "fields": [
- {
- "name":"issuer",
- "type":"name"
- },
- {
- "name":"maximum_supply",
- "type":"asset"
- }
- ]
- },
- {
- "name": "issue",
- "base": "",
- "fields": [
- {
- "name":"to",
- "type":"name"
- },
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
- },
- {
- "name": "retire",
- "base": "",
- "fields": [
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
- },
- {
- "name": "close",
- "base": "",
- "fields": [
- {
- "name":"owner",
- "type":"name"
- },
- {
- "name":"symbol",
- "type":"symbol"
- }
- ]
- },
- {
- "name": "transfer",
- "base": "",
- "fields": [
- {
- "name":"from",
- "type":"name"
- },
- {
- "name":"to",
- "type":"name"
- },
- {
- "name":"quantity",
- "type":"asset"
- },
- {
- "name":"memo",
- "type":"string"
- }
- ]
- },
- {
- "name": "account",
- "base": "",
- "fields": [
- {
- "name":"balance",
- "type":"asset"
- }
- ]
- },
- {
- "name": "currency_stats",
- "base": "",
- "fields": [
- {
- "name":"supply",
- "type":"asset"
- },
- {
- "name":"max_supply",
- "type":"asset"
- },
- {
- "name":"issuer",
- "type":"name"
- }
- ]
- }
- ],
- "actions": [
- {
- "name": "transfer",
- "type": "transfer",
- "ricardian_contract": ""
- },
- {
- "name": "issue",
- "type": "issue",
- "ricardian_contract": ""
- },
- {
- "name": "retire",
- "type": "retire",
- "ricardian_contract": ""
- },
- {
- "name": "create",
- "type": "create",
- "ricardian_contract": ""
- },
- {
- "name": "close",
- "type": "close",
- "ricardian_contract": ""
- }
- ],
- "tables": [
- {
- "name": "accounts",
- "type": "account",
- "index_type": "i64",
- "key_names" : ["currency"],
- "key_types" : ["uint64"]
- },
- {
- "name": "stat",
- "type": "currency_stats",
- "index_type": "i64",
- "key_names" : ["currency"],
- "key_types" : ["uint64"]
- }
- ],
- "ricardian_clauses": [],
- "abi_extensions": []
-}
-```
-
-## Cases not Covered by Token Contract
-
-## Vectors
-
-When describing a vector in your ABI file, simply append the type with `[]`, so if you need to describe a vector of permission levels, you would describe it like so: `permission_level[]`
-
-## Struct Base
-
-It's a rarely used property worth mentioning. You can use **base** ABI struct property to reference another struct for inheritance, as long as that struct is also described in the same ABI file. Base will do nothing or potentially throw an error if your smart contract logic does not support inheritance.
-
-You can see an example of base in use in the system contract [source code](https://github.com/AntelopeIO/reference-contracts/blob/9d9401e1bd937406b4e2c4f2fd234f22a2d6e3bc/contracts/eosio.system/include/eosio.system/eosio.system.hpp#L141).
-
-The corresponsing ABI definition would look like this:
-
-```json
-{
- "name": "eosio_global_state",
- "base": "blockchain_parameters",
- "fields": [
- {"name":"max_ram_size", "type":"uint64"},
- {"name":"total_ram_bytes_reserved", "type":"uint64"},
- {"name":"total_ram_stake", "type":"int64"},
- ]
-}
-```
-
-## Extra ABI Properties Not Covered Here
-
-A few properties of the ABI specification were skipped here for brevity, however, there is a pending ABI specification that will outline every property of the ABI in its entirety.
-
-## Ricardian Clauses
-
-Ricardian clauses describe the intended outcome of a particular actions. It may also be utilized to establish terms between the sender and the contract.
-
-## ABI Extensions
-
-A generic "future proofing" layer that allows old clients to skip the parsing of "chunks" of extension data. For now, this property is unused. In the future each extension would have its own "chunk" in that vector so that older clients skip it and newer clients that understand how to interpret it.
-
-## Maintenance
-
-Every time you change a struct, add a table, add an action or add parameters to an action, use a new type, you will need to remember to update your ABI file. In many cases failure to update your ABI file will not produce any error.
-
-## Troubleshooting
-
-### Table returns no rows
-
-Check that your table is accurately described in the ABI file. For example, If you use `cleos` to add a table on a contract with a malformed ABI definition and then get rows from that table, you will receive an empty result. `cleos` will not produce an error when adding a row nor reading a row when a contract has failed to properly describe its tables in its ABI.
diff --git a/cdt/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md b/cdt/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md
deleted file mode 100644
index a07729736..000000000
--- a/cdt/07_best-practices/08_abi/01_abi-code-generator-attributes-explained.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-content_title: ABI/Code generator attributes
-link_text: ABI/Code generator attributes
----
-
-The new ABI generator tool uses C++11 or GNU style attributes to mark `actions` and `tables`.
-
-## [[eosio::action]]
-This attribute marks a method as an action.
-Example (four ways to declare an action for ABI generation):
-```cpp
-// this is the C++11 and greater style attribute
-[[eosio::action]]
-void testa( name n ) {
- // do something
-}
-
-// this is the GNU style attribute, this can be used in C code and prior to C++ 11
-__attribute__((eosio_action))
-void testa( name n ){
- // do something
-}
-
-struct [[eosio::action]] testa {
- name n;
- EOSLIB_SERIALIZE( testa, (n) )
-};
-
-struct __attribute__((eosio_action)) testa {
- name n;
- EOSLIB_SERIALIZE( testa, (n) )
-};
-```
-
-If your action name is not a valid [Antelope name](../02_naming-conventions.md) you can explicitly specify the name in the attribute ```c++ [[eosio::action("")]]```
-
-## [[eosio::table]]
-Example (two ways to declare a table for ABI generation):
-```cpp
-struct [[eosio::table]] testtable {
- uint64_t owner;
- /* all other fields */
-};
-
-struct __attribute__((eosio_table)) testtable {
- uint64_t owner;
- /* all other fields */
-};
-
-typedef eosio::multi_index<"tablename"_n, testtable> testtable_t;
-```
-
-If you don't want to use the multi-index you can explicitly specify the name in the attribute ```c++ [[eosio::table("")]]```.
-
-## [[eosio::contract("ANY_NAME_YOU_LIKE")]]
-```cpp
-class [[eosio::contract("ANY_NAME_YOU_LIKE")]] test_contract : public eosio::contract {
-};
-```
-
-The code above will mark this `class` as being an `Antelope` contract, this allows for namespacing of contracts, i.e. you can include headers like `eosio::token` and not have `eosio::token`'s actions/tables wind up in you ABI or generated dispatcher.
-
-## [[eosio::on_notify("VALID_EOSIO_ACCOUNT_NAME::VALID_EOSIO_ACTION_NAME")]]
-```cpp
-[[eosio::on_notify("eosio.token::transfer")]]
-void on_token_transfer(name from, name to, assert quantity, std::string memo) {
- // do something on eosio.token contract's transfer action from any account to the account where the contract is deployed.
-}
-
-[[eosio::on_notify("*::transfer")]]
-void on_any_transfer(name from, name to, assert quantity, std::string memo) {
- // do something on any contract's transfer action from any account to the account where the contract is deployed.
-}
-```
-
-## [[eosio::wasm_entry]]
-```cpp
-[[eosio::wasm_entry]]
-void some_function(...) {
- // do something
-}
-```
-
-The code above will mark an arbitrary function as an entry point, which will then wrap the function with global constructors (ctors) and global destructors (dtors). This will allow for the CDT toolchain to produce WASM binaries for other ecosystems.
-
-## [[eosio::wasm_import]]
-```cpp
-extern "C" {
- __attribute__((eosio_wasm_import))
- void some_intrinsic(...);
-}
-```
-
-The code above will mark a function declaration as being a WebAssembly import. This allows for other compilation modes to specify which functions are import only (i.e. do not link) without having to maintain a secondary file with duplicate declarations.
-
-## [[eosio::action, eosio::read-only]]
-The `read-only` attribute marks a method which has been defined as an action as a read-only action.
-
-Example:
-
-```cpp
-[[eosio::action, eosio::read-only]]
-std::vector get() {
- std::vector ret;
- // retrieve blockchain state and populate the ret vector
- return ret;
-}
-```
-
-Contract actions tagged read-only:
-* Cannot call insert/update (write) functions on the `Multi-Index API`, nor the `Key Value API`.
-* Cannot call `deferred transactions`.
-* Cannot call `inline actions`.
-* The amount of data returned by read-only queries is limited by the action return value size. By default these are set to 256 bytes by `default_max_action_return_value_size`.
-
-The `cdt-cpp` and `cdt-cc` tools will generate an error and terminate compilation if an action tagged read-only attempts to call insert/update (write) functions, `deferred transactions` or `inline actions`. However, if the command-line override option `--warn-action-read-only` is used, the `cdt-cpp` and `cdt-cc` tools will issue a warning and continue compilation.
diff --git a/cdt/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md b/cdt/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md
deleted file mode 100644
index b67bee83c..000000000
--- a/cdt/07_best-practices/08_abi/02_manually_write_an_ABI_file_explained.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-content_title: Manually write/edit an ABI file
-link_text: Manually write/edit an ABI file
----
-
-- Advanced features of the newest version of the ABI will require manual construction of the ABI, and odd and advanced C++ patterns could capsize the generator's type deductions. So having a good knowledge of how to write an ABI should be an essential piece of knowledge of a smart contract writer.
-- Please refer to [Create an ABI File](00_understanding-abi-files.md#create-an-abi-file) to learn about the different sections of an ABI.
-
-## Adding Ricardian Contracts and Clauses to ABI
-- The ABI generator will try to automatically import contracts and clauses into the generated ABI. There are a few caveats to this, one is a strict naming policy of the files and an HTML tag used to mark each Ricardian contract and each clause.
-- The Ricardian contracts should be housed in a file with the name `.contracts.md` and the clauses should be in a file named `.clauses.md`.
- - For each Ricardian contract the header `
ActionName
` should be used, as this directs the ABI generator to attach this Ricardian contract to the specified action.
- - For each Ricardian clause, the header `
ClauseID
` should be used, as this directs the ABI generator to the clause id and the subsequent body.
- - The option `-R` has been added to [`cdt-cpp`](../../03_command-reference/cdt-cpp.md) to add "resource" paths to search from, so you can place these files in any directory structure you like and use `-R` in the same vein as `-I` for include paths.
- - For exemplification see [hello.contracts.md](https://github.com/AntelopeIO/cdt/blob/main/examples/hello/ricardian/hello.contracts.md).
diff --git a/cdt/07_best-practices/08_abi/index.md b/cdt/07_best-practices/08_abi/index.md
deleted file mode 100644
index 1b8648053..000000000
--- a/cdt/07_best-practices/08_abi/index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-content_title: ABI
-link_text: ABI
----
-
-- [Understanding ABI Files](00_understanding-abi-files.md)
-- [ABI/Code generator attributes](01_abi-code-generator-attributes-explained.md)
-- [Manually write/edit an ABI file](02_manually_write_an_ABI_file_explained.md)
diff --git a/cdt/07_best-practices/11_debugging_a_smart_contract.md b/cdt/07_best-practices/11_debugging_a_smart_contract.md
deleted file mode 100644
index d32c505ea..000000000
--- a/cdt/07_best-practices/11_debugging_a_smart_contract.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-content_title: Debugging a smart contract
----
-
-In order to be able to debug your smart contract, you will need to setup a local nodeos node. This local nodeos node can be run as separate private testnet or as an extension of a public testnet. This local node also needs to be run with the contracts-console option on, either `--contracts-console` via the command line or `contracts-console = true` via the config.ini and/or by setting up logging on your running nodeos node and checking the output logs. See below for details on logging.
-
-When you are creating your smart contract for the first time, it is recommended to test and debug your smart contract on a private testnet first, since you have full control of the whole blockchain and can easily add suitable logging. This enables you to have unlimited amount of eos needed and you can just reset the state of the blockchain whenever you want. When it is ready for production, debugging on the public testnet (or official testnet) can be done by connecting your local nodeos to the public testnet (or official testnet) so you can see the log of the testnet in your local nodeos.
-
-The concept is the same, so for the following guide, debugging on the private testnet will be covered.
-
-If you haven't set up your own local nodeos, follow the [DUNE setup guide](https://github.com/AntelopeIO/DUNE#readme). By default, your local nodeos will just run in a private testnet unless you modify the config.ini file to connect with public testnet (or official testnet) nodes.
-
-# Method
-
-The main method used to debug smart contract is **Caveman Debugging**. Printing is utilized to inspect the value of a variable and check the flow of the contract. Printing in smart contracts can be done through the Print API. The C++ API is a wrapper for C API and is the recommended API.
-
-# Print
-
-Print C API supports the following data type that you can print:
-- prints - a null terminated char array (string)
-- prints_l - any char array (string) with given size
-- printi - 64-bit signed integer
-- printui - 64-bit unsigned integer
-- printi128 - 128-bit signed integer
-- printui128 - 128-bit unsigned integer
-- printsf - single-precision floating point number
-- printdf - double encoded as 64-bit unsigned integer
-- printqf - quadruple encoded as 64-bit unsigned integer
-- printn - 64 bit names as base32 encoded string
-- printhex - hex given binary of data and its size
-
-The Print C++ API wraps some of the above C API by overriding the print() function, so the user doesn't need to determine which specific print function to use. Print C++ API supports:
-- a null terminated char array (string)
-- integer (128-bit unsigned, 64-bit unsigned, 32-bit unsigned, signed, unsigned)
-- base32 string encoded as 64-bit unsigned integer
-- struct that has print() method
-
-# Example
-Here's an example contract for debugging
-
-## debug.hpp
-
-```cpp
-namespace debug {
- struct foo {
- account_name from;
- account_name to;
- uint64_t amount;
- void print() const {
- eosio::print("Foo from ", eosio::name(from), " to ", eosio::name(to), " with amount ", amount, "\n");
- }
- };
-}
-```
-## debug.cpp
-
-```cpp
-#include
-
-extern "C" {
-
- void apply( uint64_t code, uint64_t action ) {
- if (code == N(debug)) {
- eosio::print("Code is debug\n");
- if (action == N(foo)) {
- eosio::print("Action is foo\n");
- debug::foo f = eosio::unpack_action_data();
- if (f.amount >= 100) {
- eosio::print("Amount is larger or equal than 100\n");
- } else {
- eosio::print("Amount is smaller than 100\n");
- eosio::print("Increase amount by 10\n");
- f.amount += 10;
- eosio::print(f);
- }
- }
- }
- }
-} // extern "C"
-```
-## debug.abi
-
-```json
-{
- "structs": [{
- "name": "foo",
- "base": "",
- "fields": {
- "from": "account_name",
- "to": "account_name",
- "amount": "uint64"
- }
- }
- ],
- "actions": [{
- "action_name": "foo",
- "type": "foo"
- }
- ]
-}
-```
-Deploy it and push an action to it. It is assumed you have a `debug` account created and have its key in your wallet.
-
-```bash
-$ cdt-cpp -abigen debug.cpp -o debug.wasm
-$ cleos set contract debug CONTRACT_DIR/debug -p youraccount@active
-$ cleos push action debug foo '{"from":"inita", "to":"initb", "amount":10}' --scope debug
-```
-
-When you check your local `nodeos` node log, you will see the following lines after the above message is sent.
-
-```
-Code is debug
-Action is foo
-Amount is smaller than 100
-Increase amount by 10
-Foo from inita to initb with amount 20
-```
-
-There, you can confirm that your message is going to the right control flow and the amount is updated correctly. You might see the above message at least 2 times and that's normal because each transaction is being applied during verification, block generation, and block application.
\ No newline at end of file
diff --git a/cdt/07_best-practices/naming-conventions-format.png b/cdt/07_best-practices/naming-conventions-format.png
deleted file mode 100644
index 3db1f378f..000000000
Binary files a/cdt/07_best-practices/naming-conventions-format.png and /dev/null differ
diff --git a/cdt/08_troubleshooting/index.md b/cdt/08_troubleshooting/index.md
deleted file mode 100644
index ffda655a7..000000000
--- a/cdt/08_troubleshooting/index.md
+++ /dev/null
@@ -1,203 +0,0 @@
----
-content_title: Troubleshooting
----
-
-## When sending an action to the blockchain you get the error below
-
-```console
-{
- "code":500,
- "message":"Internal Service Error",
- "error":{
- "code":3090003,
- "name":"unsatisfied_authorization",
- "what":"Provided keys, permissions, and delays do not satisfy declared authorizations",
- "details":[
- {
- "message":"transaction declares authority '{"actor":"account_name","permission":"permission_name"}', but does not have signatures for it under a provided delay of 0 ms, provided permissions [], provided keys ["EOS5ZcMvpgtDMdVtvCFewAQYTyfN6Vqhg4kdgauffx3jiaKaeWfY1"], and a delay max limit of 3888000000 ms",
- "file":"authorization_manager.cpp",
- "line_number":524,
- "method":"check_authorization"
- }
- ]
- }
-}
-```
-
-__Possible solution__: Verify if you did not forget to set code for contract, is it possible that you only set the `abi` for the contract but not the code as well?
-
-## When sending an action to the blockchain an error similar to the one below is encountered
-
-```console
-Error 3015014: Pack data exception
-Error Details:
-Unexpected input encountered while processing struct 'action_name_here'
-```
-
-__Possible solution__: You did not specify correctly the parameter when sending the action to the blockchain. When no parameter is needed the command should look like the one below
-
-```sh
-cleos push action eostutorial1 get '[]' -p eostutorial1@active
-```
-
-The command above is one way of sending correctly `get` action with no parameters to the blockchain.
-
-## When sending an action to the blockchain an error similar to the one below is encountered
-
-```console
-error 2019-09-25T07:38:14.859 thread-0 main.cpp:3449 main ] Failed with error: Assert Exception (10)
-!action_type.empty(): Unknown action action_name in contract eostutorial1
-```
-
-__Possible solution__: Verify if the action attribute `[[eosio::action]]` is used when defining and/or declaring the action `action_name` for the contract.
-
-## When deploying a contract code to the blockchain a similar error with the ones below is encountered
-
-```console
-Error 3160010: No abi file found
-or
-Error 3160009: No wasm file found
-```
-
-__Possible solution__: Verify that `abi` and `wasm` files exist in the directory specified in the `cleos set contract` command, and that their names match the directory name.
-
-## Action triggers a ram charge which cannot be initiated from a notification
-
-__Possible solution__: This error happens because the notification action has no authorization to buy the needed RAM. In the context of multi-index tables, there is a table payer and a row payer. Only the contract can modify rows. The contract can create rows with a payer that did not authorize the action if the total amount of ram charged does not increase (e.g. delete a row and add another with the same payer). The table payer can not change until the last row is deleted. For the purposes of billing, a table is identified by the tuple `contract, scope, table`. When you create a row for a `contract, scope, table` tuple that doesn’t exist, you create a table with the same payer. This can outlive the original row which created it, if other rows were created with that combination and this prevents the original payer from getting their ram back. Secondary indexes throw in more complexity since they use the lower 4 bits of the table name, producing additional `contract, scope, table` tuples combinations. Key takeaway: payer is about billing, not access control
-
-## You successfully re-deployed the contract code, but when you query the table you get the custom message that you coded when the table is not initialized (doesn't exist), or the system error message below in case you do not have code that checks first if table exist
-
-```console
-Error 3050003: eosio_assert_message assertion failure
-Error Details:
-assertion failure with message: singleton does not exist
-pending console output:
-```
-
-__Possible solution__: It is possible that you changed the table name? That is the first, of `eosio::name` type, parameter which you passed to the `eosio::template` type alias definition. Or did you change the table structure definition at all? If you need to change the table structure definition there are some limitations and a couple of ways to do it which are explained in the [Data Design and Migration](./07_best-practices/04_data-design-and-migration.md) section.
-
-## You successfully re-deployed the contract code, but when you query the table you get the fields of the row values swapped, that is, it appears the values stored in table rows are the same only that they are swapped between fields/columns
-
-__Possible solution__: It is possible that you changed the order of the fields the table struct definition? If you change the order of the table struct definition, if the swapped fields have the same type you will see the data in the fields correctly, however if the types of the fields are different the results could be of something undefined. If you need to change the table structure definition there are some limitations and a couple of ways to do it which are explained in the [Data Design and Migration](./07_best-practices/04_data-design-and-migration.md) section.
-
-## You successfully re-deployed the contract code, but when you query the table you get a parse error, like the one below, or the returned data seems to be garbage
-
-```console
-error 2019-09-26T07:05:54.825 thread-0 main.cpp:3449 main ] Failed with error: Parse Error (4)
-Couldn't parse type_name
-```
-
-__Possible solution__: It is possible that you changed the type of the fields for the table struct definition? If you need to change the table structure definition there are some limitations and a couple of ways to do it which are explained in the [Data Design and Migration](./07_best-practices/04_data-design-and-migration.md) section.
-
-## cdt-cpp process never completes
-
-__Possible solution__: make sure you have at least 2 cores on the host that executes the cdt-cpp (e.g. docker container, VM, local sub-system)
-
-## You can not find the `now()` time function, or the result of the `current_time_point` functions are not what you expected them to be
-
-__Possible solution__: The `now()` function has been replaced by `current_time_point().sec_since_epoch()`, it returns the time in microseconds from 1970 of the `current block` as a time_point. There's also available `current_block_time()` which returns the time in microseconds from 1970 of the `current block` as a `block_timestamp`. Be aware that for time base functions, the assumption is when you call something like `now()` or `current_time()` you will get the exact now/current time, however that is not the case with Antelope, you get __the block time__, and only ever get __the block time__ from the available `sec_since_epoch()` or `current_block_time()` no matter how many times you call it.
-
-## You successfully re-deployed the contract code, but when you broadcast one of the contracts methods to the blockchain you get below error message
-
-```console
-Error 3050004: eosio_assert_code assertion failure
-Error Details:
-assertion failure with error code: 8000000000000000000
-```
-
-__Possible solution__: If you are referencing a smart contract from another smart contract and each of them have at least one action with the same name you will experience the above error when sending to the blockchain one of those actions, so what you have to do is to make sure the action names between those two contracts are not common.
-
-## Print statements from smart contract code are not seen in the output
-
-__Possible solution__: There are a few reasons print statements do not show up in the output. One reason could be because an error occurs, in which case the whole transaction is rolled back and the print statements output is replaced by the error that occurs instead; Another reason is if you are in a loop, iterating through a table's rows for example and for each row you have a print statement that prints also the new line char at the `'\n'` only the chars before the new line char from the first iteration will be printed, nothing else after that, nothing from the second iteration onwards either.
-
-The below code will print just the first line of the iteration.
-
-```cpp
- auto index=0;
- for (auto& item : testtab)
- {
- eosio::print_f("{item %}={%, %, %} \n", ++index, item.test_primary, item.secondary, item.datum);
- }
-```
-
-The below code will print all lines of the iteration separated by `'|'` char.
-
-```cpp
- auto index=0;
- for (auto& item : testtab)
- {
- eosio::print_f("{item %}={%, %, %} |", ++index, item.test_primary, item.secondary, item.datum);
- }
-```
-
-## Print statements from smart contract code are not shown in the `expected order`
-
-__Possible solution__: The key point here is the `expected order` and what you think it should be. Although the Antelope is single threaded, when looking at your smart contract action code implementation, which let's say it has a series of `print` (either `print_f` or `printf`) statements, they might not necessarily be outputted in the order the `apparent` code workflow is. One example is when inline transactions are sent from your smart contract action code, and you expect to see the `print` statements from within the inline action code outputted before the `print` statements made after the inline action `send` statement. For better exemplification let's look at the code below:
-
-```cpp
-[[eosio::action]] void multi_index_example::mod( name user, uint64_t n ) {
-
- // `mod` action implementation code goes here...
-
- print_f("Output line before the inline send action.")
-
- singleton_set_action singleton_set("eostutorial1"_n, {get_self(), "active"_n});
- singleton_set.send(get_self(), n, get_self());
-
- print_f("Output line after the inline send action.")
-}
-```
-
-The code above has one `print` statement before the `singleton_set.send` and another one after the `singleton_set.send`. If you wrote some more `print` statements in the code that implements the `singleton_set.send` action and expect to see them before the second `print` statement then it is a wrong assumption. The inline actions are broadcasted to the network and they are executed at a different time, asynchronous of the current execution thread of the current `multi_index_example::mod` action, therefor it is impossible to predict when the `print` statements from inline action code will be outputted.
-
-## Assertion failure while creating an account after eosio.system was installed
-
-```sh
-cleos create account eosio bob EOS5HUanbay86UUnr1d4fuBsQ3ksjfgZYoLUVvrYVLy6pj4i8xqVY
-```
-
-```console
-Error 3050003: eosio_assert_message assertion failure
-Error Details:
-assertion failure with message: system contract must first be initialized
-```
-
-The failure is stating that `eosio.system` `init` action was not called yet. The `init` action is implemented by the `void init(uint64_t, symbol)` function. The first parameter is the version, this should always be `0` for now, until a new version of `init` will be created that handles more information.
-The second parameter is the system's symbol (i.e. for main net this is `EOS`). If you followed the [BIOS Boot Sequence](https://docs.eosnetwork.com/docs/latest/tutorials/bios-boot-sequence) tutorial and created a system with the default symbol `SYS` then `SYS` shall be used as the system's symbol in the `init` action. It is whatever symbol you as the chain creator want to use in your `Antelope` based blockchain.
-
-## Backward incompatible change in generating abi for maps
-
-In CDT version 3.0.1, there has been breaking ABI change in std::map. The change is as follows:
-
-Old Version (CDT 3.0.0 or earlier):
-```
- "fields": [
- {
- "name": "key",
- "type": "