Small StakingV4 fix and xBot Markers update

docs/developers/developer-reference/storage-mappers.md

@@ -1164,4 +1164,4 @@ fn my_endpoint(&self) -> u32 {
 
 Calling `my_endpoint` will return the sum of the values stored in `contract_to_be_called`'s SetMapper.
 
-By specifying the expected type, storage key and address, the value can be read and used inside our logic.
+By specifying the expected type, storage key and address, the value can be read and used inside our logic.

docs/developers/developer-reference/upgrading-smart-contracts.md

@@ -33,6 +33,8 @@ fn upgrade(&self, new_value: u64) {
 
 Let's assume we deploy the contract with the argument **1u64**, and then we upgrade it using the argument **2u64**. If before the new release, after upgrading the SC, we would have the value **1u64** in storage (as the `init` function would have been called, which saves the value in the storage only when it is empty), with the new release, the new value in the storage would be **2u64**.
 
+[comment]: # (mx-context-auto)
+
 ## Deep diving into the Smart Contract Upgrade Process
 
 Upgrading a smart contract is a relatively easy process, but its implications are not exactly obvious. To upgrade a smart contract, simply run the following command:

docs/developers/guidelines/react-development.md

@@ -13,12 +13,16 @@ However, in a big team and in a big project, small quirks and personal preferenc
 
 Given this, we have established some basic principles and a code style we would like to follow. These are, of course, not set in stone, and can be changed, given a valid reason.
 
+[comment]: # (mx-context-auto)
+
 ## Using Git
 
 :::important
 * We use **yarn** as a package manager.
 :::
 
+[comment]: # (mx-context-auto)
+
 ### Branch naming
 We use a system for **branch naming**: \[your initials\]/-[feature || fix || redesign\]/-\[2-3 words describing the branch\]  
 > e.g. John Doe creates `jd/feature/fix-thing-called-twice`
@@ -27,9 +31,12 @@ We use a system for **branch naming**: \[your initials\]/-[feature || fix || red
 All branch names are lowercase
 :::
 
+[comment]: # (mx-context-auto)
 
 ## Basic principles
 
+[comment]: # (mx-context-auto)
+
 ### Imports and exports
 We import **lodash-specific functions** instead of the whole library for the tree shaking to take effect.
 
@@ -46,6 +53,7 @@ import get from 'lodash/get';`
 
 Do not use `default` exports. **Use named exports** instead.
 
+[comment]: # (mx-context-auto)
 
 ### Using conditionals
 Avoid using nested conditionals. **Use early returns** instead.
@@ -67,6 +75,8 @@ if (!anotherCondition) {
 // do stuff
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Defining function arguments
 If a function has more than 2 arguments and the second argument is not optional, **use an object** instead.
 
@@ -87,6 +97,8 @@ const myFunction = ({arg1, arg2, arg3}) => {
 }
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Validity checks
 We use **`!=` or `== null` verifications** for all variables, and `!myBool` for booleans only.
 
@@ -123,6 +135,8 @@ if (array?.length > 0){
 }
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Folder structure
 For folder and file naming we're using the following convention:  
 **camelCase for all folders and files, except when it's a React Component or a Module Root Folder**, in which case we're using PascalCase.  
@@ -131,16 +145,19 @@ Also, for components' and containers' subcomponents, we create separate folders,
 Each folder that has an exportable component will have an **`index.tsx`** file for ease of import. <br/>
 Each folder that has an exportable file will have an **`index.ts`** file for ease of import.
 
+[comment]: # (mx-context-auto)
+
 ### File length convetions
 - < 100 lines of code - ✅ OK
 - 100 - 200 lines of code - try to split the file into smaller files
 - 200 - 300 lines of code - should be split the file into smaller files
 - \> 300 lines of code 🚫 DON'T
 
+[comment]: # (mx-context-auto)
+
 ### Naming conventions
 * When naming types, use the suffix **`Type`**. This helps us differentiate between types and components. When naming component props types, use MyComponentPropsType. When naming a type that is not a component, use MyFunctionType. When naming return values, use MyFunctionReturnType.
 
-
 **Try to extract at the top of the function all constants** such as strings, numbers, objects, instead of declaring this ad hoc inside the code.
 
 ```jsx
@@ -159,18 +176,24 @@ if (x === PermissionsEnum.rejected && y === ACCESS_LEVEL)
 }
 ```
 
-
+[comment]: # (mx-context-auto)
 
 ## React guidelines
 
+[comment]: # (mx-context-auto)
+
 ### Using functional components
 We're using **functional components** for almost all new components, no classes, except when strictly necessary (e.g. error boundaries);
 
+[comment]: # (mx-context-auto)
+
 ### Using selectors
 We use `useSelector` and `useDispatch` hooks to connect to redux store via react-redux. 🚫 **No** `mapStateToProps` in functional components.
 
 We use **reselect** for memoizing complex state variables and composing those into optimized selectors that don't rerender the whole tree when the values don't change. This package needs to be added only when there is a performance bottleneck, either existing or expected.
 
+[comment]: # (mx-context-auto)
+
 ### Defining handlers
 
 We're using **"handle" prefix** for handlers defined in the function and **"on"** prefix for handlers passed via props. `handleTouchStart` vs `props.onTouchStart`, to distinguish between own handlers and parent handlers.
@@ -186,6 +209,8 @@ function handleClick(e) {
 <div onClick={onClick}/>`
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Number of props per component
 
 If a component has more than 7 props, it should draw a red flag and be refactored. If it has >= 10 props, it should be refactored immediately. Strategies for refactoring:
@@ -227,6 +252,8 @@ If a component has more than 7 props, it should draw a red flag and be refactore
 <MyComplicatedComponent/> 
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Inline functions
 No **inline functions** in TSX.
 
@@ -240,6 +267,8 @@ const handlePress = () => {
 <TouchableOpacity onPress={handlePress}/>
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Implicit values
 Use implicit `true` for **boolean** props
 
@@ -250,6 +279,8 @@ Use implicit `true` for **boolean** props
 <Card isFullscreen /> 
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Destructuring arguments
 Always destructure arguments, with minor exceptions.
 
@@ -276,7 +307,6 @@ function verifyUser(user) {
 ```
 2. Same props are passed below to a component, or are used for further processing
 
-
 ```jsx
 // 🚫 DON'T 
 const DisplayUser = ({name, age}: UserType) {
@@ -297,6 +327,7 @@ const UserList = (users: UserType[]) {
 }
 ```
 
+[comment]: # (mx-context-auto)
 
 ### Over-optimization 
 No **`useCallback` or `useMemo` or `React.memo` unless really necessary**. Since the release of hooks, over-optimization has become a big problem.
@@ -315,6 +346,8 @@ const handlePress = useCallback(() => setPressed(true), []);
 </Context.Provider>
 ```
 
+[comment]: # (mx-context-auto)
+
 ### Conditionally rendered TSX
 
 In React, conditionally rendered TSX is very common. Given the ability to render it inline, it's very easy to include it inside normal TSX:
@@ -348,6 +381,8 @@ const mysteryBoxesContainer = mysteryBoxEnabled && <ProfileMysteryBoxesCard isCu
 </Container>
 ```
 
+[comment]: # (mx-context-auto)
+
 ## Rules for hooks
 
 1. **Fake modularization**:
@@ -374,6 +409,8 @@ const mysteryBoxesContainer = mysteryBoxEnabled && <ProfileMysteryBoxesCard isCu
     ```
 5. If a hook exports > 4 values, it should draw a red flag and be refactored. If it exports >= 7 values, it should be refactored immediately.
 
+[comment]: # (mx-context-auto)
+
 ## Modularisation
 
 Given the size of the project, we have agreed on a couple of modularisation techniques that will help us to:
@@ -386,6 +423,8 @@ There are a couple of rules that we agreed upon and will be enforced in all PRs,
 
 Therefore, we agreed on the certain principles: 
 
+[comment]: # (mx-context-auto)
+
 ### Abstracting the logic away into hooks and functions
 
 If there is a piece of code in a component or container that holds a certain amount of logic and can be converted to a testable hook or utils function, we should move it to a separate function/hook and add props interface, return type interface and a test file.
@@ -491,6 +530,8 @@ if (myClaimableAuctions != null && myClaimableAuctions.length > 0) {
 
 👆 Here, it's not worth moving the if logic inside a local variable, it would be redundant, as it's very easy to read through it.
 
+[comment]: # (mx-context-auto)
+
 ### New functions/hooks
 
 When creating new functions and hooks, the new entity must have:

docs/developers/meta/rust-nightly.md

@@ -13,7 +13,6 @@ While it would be ideal to have our infrastructure running on stable Rust, there
 
 This page is intended to provide a list of all these features that we use, and explain what it would take to renounce them and move to stable.
 
-
 [comment]: # (mx-context-auto)
 
 ## Nightly features

docs/developers/testing/scenario/concept.md

@@ -3,7 +3,6 @@ id: concept
 title: Concept
 ---
 
-
 [comment]: # (mx-context-auto)
 
 ## What is a scenario?
@@ -24,7 +23,6 @@ So it doesn't really matter if these steps are real or imagined. All that matter
 
 Because of their generality, it is natural to think of all blockchain interactions and black-box tests as such scenarios.
 
-
 [comment]: # (mx-context-auto)
 
 ## Scenario formats
@@ -41,7 +39,6 @@ There are several ways to generate a scenario JSON file automatically, and we en
 
 The greatest benefit of the JSON format is that it is language-agnostic, and so it can be used with any of our backends.
 
-
 [comment]: # (mx-context-auto)
 
 ## Scenarios as tests
@@ -52,7 +49,6 @@ Scenarios also have syntax for checking transaction outputs and the blockchain s
 They are always **black-box** tests. They model real blockchain interactions, so there is no way for them to peek inside contracts and access their private functions.
 :::
 
-
 [comment]: # (mx-context-auto)
 
 ## Typed vs. untyped scenarios

docs/developers/testing/scenario/running-scenarios.md

@@ -32,7 +32,6 @@ Most of the code lies [here](https://github.com/multiversx/mx-chain-vm-go/tree/m
 
 To call, simply run `run-scenarios <path>`, where the path can be either a speciific scenario file, or a folder containing scenarios. In the case of a folder, the tool will run all files ending in `*.scen.json`. Results are printed to console.
 
-
 [comment]: # (mx-context-auto)
 
 ## Integration in Rust
@@ -114,8 +113,6 @@ It also helps that ignored tests will also show up in console, unlike the ones t
 
 It is customary to add a `_go` suffix to the test functions, to distinguish them from the ones with the Rust backend. The test-gen tool does the same.
 
-
-
 [comment]: # (mx-context-auto)
 
 ### Rust backend
@@ -149,8 +146,6 @@ Note that we can have different tests ignored on the different backends.
 
 Here it is also customary to add a `_rs` suffix to the test functions, to distinguish them from the ones on the Go backend. The test-gen tool does the same.
 
-
-
 [comment]: # (mx-context-auto)
 
 ### Rust backend environment minimal setup
@@ -170,7 +165,6 @@ The example above is a great example of a minimal setup. Other than creating the
     - The path to binary is given as a scenario value expression. [The file syntax](/developers/testing/scenario/values-simple#file-contents) in the example is simply the most common way of loading a large value from file. It is also possible to provide the compiled contract as bytes, (e.g. `"0x0061736d0100000001661160000060017..."`), but hard-coding that is weird.
     - The `ContractBuilder` object is generated automatically for every contract, by the `#[multiversx_sc::contract]` procedural macro. That is why you won't see it in code, but it's always there.
 
-
 [comment]: # (mx-context-auto)
 
 ### Auto-generating the boilerplate

docs/developers/testing/scenario/structure-json.md

@@ -14,7 +14,6 @@ Scenario files should end in `.scen.json`, where "scen" comes from "scenario". T
 
 On a side note, there is also an older format that is now deprecated, where test file names end in `.test.json`, but you shouldn't worry about it.
 
-
 [comment]: # (mx-context-auto)
 
 ## **Top level**

docs/developers/testing/testing-overview.md

@@ -9,7 +9,6 @@ What does it mean to test a smart contract?
 
 Well, smart contracts are little programs that run on the blockchain, so the first step is to find an environment for them to run.
 
-
 [comment]: # (mx-context-auto)
 
 ## Types of tests
@@ -39,7 +38,6 @@ So, to recap, the ways to test a smart contract are as follows:
     - White-box tests;
 - Unit tests.
 
-
 [comment]: # (mx-context-auto)
 
 ## What language should I use for my tests?
@@ -61,7 +59,6 @@ Let's, however, quickly go through all options avialable on MultiversX:
 - Unit tests:
     - Rust only (since direct access to the contract code is needed).
 
-
 [comment]: # (mx-context-auto)
 
 ## Testing backends

docs/governance/governance-interaction.md

@@ -9,6 +9,8 @@ title: Governance interaction
 
 The interaction with the governance system smartcontract is done through correctly formatted transactions to submit actions and through the usage of the vm-query REST API calls for reading the proposal(s) status.
 
+[comment]: # (mx-context-auto)
+
 ### Creating a proposal
 
 The proposal creation transaction has the following parameters:
@@ -37,6 +39,8 @@ After issuing the proposal, there is a log event generated having the `proposal`
 - `start epoch` as encoded integer for the starting epoch
 - `end epoch` as encoded integer for the ending epoch
 
+[comment]: # (mx-context-auto)
+
 ### Voting a proposal using the direct staked or delegation-system amount
 
 Any wallet that has staked EGLD (either direct staked or through the delegation sub-system) can cast a vote for a proposal.
@@ -60,6 +64,8 @@ The `nonce` is the hex encoded value of the proposal's unique nonce and the `vot
 
 The vote value for the account that will vote a proposal is the sum of all staked values along with the sum of all delegated values in the delegation sub-system. 
 
+[comment]: # (mx-context-auto)
+
 ### Voting a proposal through smart contracts (delegation voting)
 
 Whenever we deal with a smart contract that delegated through the delegation sub-system or owns staked nodes it is the out of scope of the metachain's governance contract to track each address that sent EGLD how much is really staked (if any EGLD is staked).
@@ -93,6 +99,8 @@ The `nonce` is the hex encoded value of the proposal's unique nonce and the `vot
 The `account address handled by the smart contract` is the address handled by the smart contract that will delegate the vote towards the governance smart contract. This address will be recorded for casting the vote.
 The `vote_balance` is the amount of stake the address has in the smart contract. The governance contract will "believe" that this is the right amount as it impossible to verify the information. The balance will diminish the total voting power the smart contract has. 
 
+[comment]: # (mx-context-auto)
+
 ### Closing a proposal
 
 A proposal can be closed only in an epoch that is strictly higher than the end epoch value provided when the proposal was open.
@@ -110,6 +118,8 @@ CloseProposalTransaction {
 
 Only the address that created the proposal can call the `closeProposal` function that will also trigger the funds unlocking. As stated in the overview page, if the proposal does not pass, the amount returned will be less with 10 EGLD.
 
+[comment]: # (mx-context-auto)
+
 ### Querying the status of a proposal
 
 The status of a certain proposal can be queried at any time by using the `vm-values/query` REST API endpoints provided by the gateway/API.
@@ -169,6 +179,7 @@ Example:
 }
 ```
 
+[comment]: # (mx-context-auto)
 
 ### Querying an address voting status (direct staking or system delegation)
 
@@ -228,4 +239,4 @@ Example for an address that did not cast votes on any proposals:
     "AA==", (number of direct nonces: 0)
   ]
 }
-```
+```