Merge pull request #1152 from multiversx/rebranding-leftovers

Rebranding (leftovers)

README.md

@@ -26,7 +26,7 @@ The crowdfunding tutorial is a great place to start: https://docs.multiversx.com
 
 # IDE
 
-The framework is designed to be easiest to use with the Elrond IDE VSCode extension: https://marketplace.visualstudio.com/items?itemName=Elrond.vscode-elrond-ide
+The framework is designed to be easiest to use with the IDE VSCode extension: https://marketplace.visualstudio.com/items?itemName=Elrond.vscode-elrond-ide
 
 # Building contracts
 

contracts/core/price-aggregator/Cargo.toml

@@ -10,7 +10,7 @@ readme = "README.md"
 repository = "https://github.com/multiversx/mx-sdk-rs"
 homepage = "https://multiversx.com/"
 documentation = "https://docs.multiversx.com/"
-description = "Elrond Price aggregator Smart Contract"
+description = "MultiversX Price aggregator Smart Contract"
 keywords = ["multiversx", "wasm", "webassembly", "blockchain", "contract"]
 categories = ["no-std", "wasm", "cryptography::cryptocurrencies"]
 edition = "2021"

contracts/core/wegld-swap/Cargo.toml

@@ -11,7 +11,7 @@ readme = "README.md"
 repository = "https://github.com/multiversx/mx-sdk-rs"
 homepage = "https://multiversx.com/"
 documentation = "https://docs.multiversx.com/"
-description = "Elrond Price aggregator Smart Contract"
+description = "MultiversX Wrapped EGLD Smart Contract"
 keywords = ["multiversx", "wasm", "webassembly", "blockchain", "contract"]
 categories = ["no-std", "wasm", "cryptography::cryptocurrencies"]
 edition = "2021"

contracts/examples/lottery-esdt/documentation.md

@@ -1,6 +1,6 @@
 # Abstract
 
-The lottery smart contract is designed to allow anyone to create their very own lottery, directly on the blockchain. Having said that, the purpose of this contract is just to have a bit of fun and show what’s possible on the current version of the Elrond blockchain. We do not endorse gambling. 
+The lottery smart contract is designed to allow anyone to create their very own lottery, directly on the blockchain. Having said that, the purpose of this contract is just to have a bit of fun and show what’s possible on the current version of the MultiversX blockchain. We do not endorse gambling. 
 
 This is the esdt version, which allows any arbitrary token to be used as currency.
 

contracts/examples/multisig/README.md

@@ -27,14 +27,14 @@ The required guidelines are:
 
 * **No libraries.** Extending the last guideline, our contract has no upstream dependencies other than itself. This minimizes the chance of us misunderstanding or misusing some piece of library code. It also forces us to stay simple and eases auditing and eventually formal verification.
 
-* **Minimal internal state.** Complex applications can be built inside of Elrond smart contracts. Storing minimal internal state allows our contract’s code to be simpler, and to be written in a more functional style, which is easier to test and reason about.
+* **Minimal internal state.** Complex applications can be built inside of MultiversX smart contracts. Storing minimal internal state allows our contract’s code to be simpler, and to be written in a more functional style, which is easier to test and reason about.
 
 * **Uses cold-storage.** The proposer which creates an action or spends from the contract has no special rights or access to the MSC. Authorization is handled by directly signing messages by the board members’ wallets that can be hardware wallets (Trezor; Ledger, etc.) or software wallets.
 
 * **Complete end-to-end testing.** The contract itself is exhaustively unit tested, audited and formally verified.
 
 ## Roles
-* **Deployer** - This is the address that deploys the MSC. By default this address is also the owner of the SC, but the owner can be changed later if required, as this is by default supported by the Elrond protocol itself. This is the address that initially set up the configuration of the SC: board members, quorum, etc. It is important to mention that at deployment a very important configuration parameter is the option to allow the SC to be upgradeable or not. It is recommended for most use cases the SC to be non-upgradeable. Leaving the SC upgradable will give the owner of the SC the possibility to upgrade the SC and bypass the board, defeating the purpose of a MSC. If keeping the SC upgradeable is desired, a possible approach would be to make the owner another MSC, and both SCs could maintain the same board, so an upgrade action would need the approval of the board.
+* **Deployer** - This is the address that deploys the MSC. By default this address is also the owner of the SC, but the owner can be changed later if required, as this is by default supported by the MultiversX protocol itself. This is the address that initially set up the configuration of the SC: board members, quorum, etc. It is important to mention that at deployment a very important configuration parameter is the option to allow the SC to be upgradeable or not. It is recommended for most use cases the SC to be non-upgradeable. Leaving the SC upgradable will give the owner of the SC the possibility to upgrade the SC and bypass the board, defeating the purpose of a MSC. If keeping the SC upgradeable is desired, a possible approach would be to make the owner another MSC, and both SCs could maintain the same board, so an upgrade action would need the approval of the board.
 
 * **Owner** - The deployer is initially the owner of the MSC, but if desired can be changed later by the current owner to a different owner. If the SC is upgradeable, the owner can also upgrade the SC.
 
@@ -79,4 +79,4 @@ MSC is a deployable SC written in Rust and compiled in WASM.
 
 ## Conclusion
 
-Multisig accounts are a critical safety feature for all users of the Elrond ecosystem. Decentralised applications will rely heavily upon multisig security.
+Multisig accounts are a critical safety feature for all users of the MultiversX ecosystem. Decentralised applications will rely heavily upon multisig security.

contracts/examples/order-book/.gitignore

@@ -1,4 +1,4 @@
-# Elrond IDE
+# IDE
 **/node_modules
 **/output/**
 **/testnet/**

contracts/feature-tests/erc-style-contracts/erc721/documentation.md

@@ -1,6 +1,6 @@
 # Abstract
 
-Non Fungible Token (NFT) implementation, using the Elrond Rust Framework. This is a very simplistic implementation where each token simply has an ID, an assigned owner, and optionally a "co-owner", also known as "approved account".
+Non Fungible Token (NFT) implementation, using the MultiversX SC Framework. This is a very simplistic implementation where each token simply has an ID, an assigned owner, and optionally a "co-owner", also known as "approved account".
 
 # Deployment
 

contracts/feature-tests/erc-style-contracts/lottery-erc20/documentation.md

@@ -2,7 +2,7 @@
 
 This is a lottery smart contract designed to be used with the erc20 token.
 
-The lottery smart contract is designed to allow anyone to create their very own lottery, directly on the blockchain. Having said that, the purpose of this contract is just to have a bit of fun and show what’s possible on the current version of the Elrond blockchain. We do not endorse gambling and this should never really be used with high sums of erc20 tokens.
+The lottery smart contract is designed to allow anyone to create their very own lottery, directly on the blockchain. Having said that, the purpose of this contract is just to have a bit of fun and show what’s possible on the current version of the MultiversX blockchain. We do not endorse gambling and this should never really be used with high sums of erc20 tokens.
 
 Now that that’s out of the way, there’s not much else to say in this section. It’s just a lottery! You buy tickets and hope to win. The difference between this and the traditional lottery is that you don’t pick some numbers, you just buy a ticket and at the end, one (or more) of the tickets are declared the “winning tickets”.  
 

contracts/modules/Cargo.toml

@@ -9,7 +9,7 @@ readme = "README.md"
 repository = "https://github.com/multiversx/mx-sdk-rs"
 homepage = "https://multiversx.com/"
 documentation = "https://docs.multiversx.com/"
-description = "Elrond WebAssembly standard smart contract modules"
+description = "MultiversX WebAssembly standard smart contract modules"
 keywords = ["multiversx", "wasm", "webassembly", "blockchain", "contract"]
 categories = ["no-std", "wasm", "cryptography::cryptocurrencies"]
 

contracts/modules/README.md

@@ -1,7 +1,7 @@
-# Standard modules for Elrond smart contracts
+# Standard modules for MultiversX smart contracts
 
 [![Crates.io](https://img.shields.io/crates/v/multiversx-sc-modules)](https://crates.io/crates/multiversx-sc-modules)
 
-This crate contains several smart contract modules developed by the Elrond team, which can be used to add standard functionality to any smart contract.
+This crate contains several smart contract modules developed by the MultiversX team, which can be used to add standard functionality to any smart contract.
 
 It is enough to add the module traits as supertraits of the contract traits to receive all endpoints and all functionality from the modules in contracts.

contracts/modules/src/dns.rs

@@ -13,7 +13,7 @@ multiversx_sc::imports!();
 
 /// Standard smart contract module that deals with registering usernames in a DNS contract.
 ///
-/// Elrond usernames/herotags need to be requested by the beneficiary.
+/// MultiversX usernames/herotags need to be requested by the beneficiary.
 /// For a contract, this means that they need an endpoint via which to request a username from the DNS.
 ///
 #[multiversx_sc::module]

contracts/modules/src/governance/README.md

@@ -1,4 +1,4 @@
-# Elrond smart contract module - Governance
+# MultiversX smart contract module - Governance
 
 This is a standard smart contract module, that when added to a smart contract offers governance features:
 - proposing actions

contracts/modules/src/governance/governance_configurable.rs

@@ -1,6 +1,6 @@
 multiversx_sc::imports!();
 
-/// # Elrond smart contract module - Governance
+/// # MultiversX smart contract module - Governance
 ///
 /// This is a standard smart contract module, that when added to a smart contract offers governance features:
 /// - proposing actions

framework/base/src/hex_call_data/cd_de.rs

@@ -6,7 +6,7 @@ use crate::{
 };
 use alloc::{boxed::Box, vec::Vec};
 
-/// Deserializes from Elrond's smart contract call format.
+/// Deserializes from the MultiversX smart contract call format.
 ///
 /// This format consists of the function name, followed by '@', follwed by hex-encoded argument bytes separated by '@' characters.
 /// Example: "funcName@00000@aaaa@1234@@".

framework/base/src/hex_call_data/cd_ser.rs

@@ -7,7 +7,7 @@ use alloc::vec::Vec;
 
 use super::SEPARATOR;
 
-/// Serializes to Elrond's smart contract call format.
+/// Serializes to the MultiversX smart contract call format.
 ///
 /// This format consists of the function name, followed by '@', follwed by hex-encoded argument bytes separated by '@' characters.
 /// Example: "funcName@00000@aaaa@1234@@".

tools/rust-debugger/format-tests/src/format_tests.rs

@@ -152,7 +152,7 @@ fn main() {
     > = ManagedOption::some(managed_vec_of_addresses.clone());
     push!(to_check, managed_option_of_vec_of_addresses, "ManagedOption::some((1) { [0] = (32) 0x000000000000000000010000000000000000000000000000000000000002ffff })");
 
-    // 5. Elrond wasm - heap
+    // 5. SC wasm - heap
     let heap_address: Address = managed_address.to_address();
     push!(
         to_check,
@@ -174,7 +174,7 @@ fn main() {
         "(3) { [0] = (2) 0x6162, [1] = (4) 0x61626364, [2] = (12) 0x6162636465666768696a6b6c }"
     );
 
-    // 6. Elrond codec - Multi-types
+    // 6. MultiversX codec - Multi-types
     let optional_value_some: OptionalValue<BigUint<DebugApi>> =
         OptionalValue::Some(BigUint::from(42u64));
     push!(to_check, optional_value_some, "OptionalValue::Some(42)");

tools/rust-debugger/pretty-printers/multiversx_sc_lldb_pretty_printers.py

@@ -15,15 +15,15 @@
 NUM_BIG_INT_TYPE = "num_bigint::bigint::BigInt"
 NUM_BIG_UINT_TYPE = "num_bigint::biguint::BigUint"
 
-# 2. Elrond wasm - Managed basic types
+# 2. SC wasm - Managed basic types
 MOD_PATH = "multiversx_sc::types::managed::basic"
 
 BIG_INT_TYPE = f"{MOD_PATH}::big_int::BigInt<{DEBUG_API_TYPE}>"
 BIG_UINT_TYPE = f"{MOD_PATH}::big_uint::BigUint<{DEBUG_API_TYPE}>"
 BIG_FLOAT_TYPE = f"{MOD_PATH}::big_float::BigFloat<{DEBUG_API_TYPE}>"
 MANAGED_BUFFER_TYPE = f"{MOD_PATH}::managed_buffer::ManagedBuffer<{DEBUG_API_TYPE}>"
 
-# 3. Elrond wasm - Managed wrapped types
+# 3. SC wasm - Managed wrapped types
 MOD_PATH = "multiversx_sc::types::managed::wrapped"
 
 TOKEN_IDENTIFIER_TYPE = f"{MOD_PATH}::token_identifier::TokenIdentifier<{DEBUG_API_TYPE}>"
@@ -42,15 +42,15 @@
 MANAGED_VEC_INNER_TYPE_INDEX = 1
 MANAGED_VEC_TYPE = f"{MOD_PATH}::managed_vec::ManagedVec<{DEBUG_API_TYPE}, {ANY_TYPE}>"
 
-# 4. Elrond wasm - Managed multi value types
+# 4. SC wasm - Managed multi value types
 
-# 5. Elrond wasm - heap
+# 5. SC wasm - heap
 MOD_PATH = "multiversx_sc::types::heap"
 
 HEAP_ADDRESS_TYPE = f"{MOD_PATH}::h256_address::Address"
 BOXED_BYTES_TYPE = f"{MOD_PATH}::boxed_bytes::BoxedBytes"
 
-# 6. Elrond codec - Multi-types
+# 6. MultiversX codec - Multi-types
 MOD_PATH = "multiversx_sc_codec::multi_types"
 
 OPTIONAL_VALUE_TYPE = f"{MOD_PATH}::multi_value_optional::OptionalValue<{ANY_TYPE}>::{SOME_OR_NONE}"
@@ -460,24 +460,24 @@ def summary(self, optional_value: lldb.value) -> str:
     # 1. num_bigint library
     (NUM_BIG_INT_TYPE, NumBigInt),
     (NUM_BIG_UINT_TYPE, NumBigUint),
-    # 2. Elrond wasm - Managed basic types
+    # 2. SC wasm - Managed basic types
     (BIG_INT_TYPE, BigInt),
     (BIG_UINT_TYPE, BigInt),
     (BIG_FLOAT_TYPE, BigFloat),
     (MANAGED_BUFFER_TYPE, ManagedBuffer),
-    # 3. Elrond wasm - Managed wrapped types
+    # 3. SC wasm - Managed wrapped types
     (TOKEN_IDENTIFIER_TYPE, TokenIdentifier),
     (MANAGED_ADDRESS_TYPE, ManagedAddress),
     (MANAGED_BYTE_ARRAY_TYPE, ManagedByteArray),
     (MANAGED_OPTION_TYPE, ManagedOption),
     (ESDT_TOKEN_PAYMENT_TYPE, EsdtTokenPayment),
     (EGLD_OR_ESDT_TOKEN_IDENTIFIER_TYPE, EgldOrEsdtTokenIdentifier),
     (MANAGED_VEC_TYPE, ManagedVec),
-    # 4. Elrond wasm - Managed multi value types
-    # 5. Elrond wasm - heap
+    # 4. SC wasm - Managed multi value types
+    # 5. SC wasm - heap
     (HEAP_ADDRESS_TYPE, HeapAddress),
     (BOXED_BYTES_TYPE, BoxedBytes),
-    # 6. Elrond codec - Multi-types
+    # 6. MultiversX codec - Multi-types
     (OPTIONAL_VALUE_TYPE, OptionalValue),
 ]
 

vm/src/world_mock/esdt_instance.rs

@@ -3,7 +3,7 @@ use num_traits::Zero;
 
 use super::EsdtInstanceMetadata;
 
-/// Holds the data for a Elrond standard digital token transaction
+/// Holds the data for a MultiversX standard digital token transaction
 #[derive(Clone, Default, Debug)]
 pub struct EsdtInstance {
     pub nonce: u64,

vm/src/world_mock/esdt_instance_metadata.rs

@@ -1,6 +1,6 @@
 use multiversx_sc::types::heap::Address;
 
-/// Holds the data for a Elrond standard digital token transaction
+/// Holds the data for a MultiversX standard digital token transaction
 #[derive(Clone, Default, Debug)]
 pub struct EsdtInstanceMetadata {
     pub name: Vec<u8>,