Merge pull request #946 from multiversx/rm/fix-broken-anchors

Fix Broken Links and Anchors

docs/bridge/whitelist-requirements.md

@@ -5,15 +5,15 @@ title: Whitelist requirements
 
 [comment]: # (mx-abstract)
 
-Before enabling a token to be sent via the Ad-Astra bridge, the token must be whitelisted. 
+Before enabling a token to be sent via the Ad-Astra bridge, the token must be whitelisted.
 The whitelisting process is performed with the help of the MultiversX team.
 
 [comment]: # (mx-context-auto)
 
 ## Whitelist requirements
 
 1. The MultiversX team must whitelist the token on both the Safe(1) and Safe(3) contracts. Only whitelisted tokens can be bridged.
-2. The token issuer must issue the token on the MultiversX network and submit a branding request manually or using https://assets.multiversx.com/.
-3. The token issuer must assign the MINT&BURN role to the BridgedTokensWrapper (6) contract as per the instructions provided at https://docs.multiversx.com/tokens/esdt-tokens/#setting-and-unsetting-special-roles
+2. The token issuer must issue the token on the MultiversX network and submit a branding request manually or using [https://assets.multiversx.com](https://assets.multiversx.com).
+3. The token issuer must assign the MINT&BURN role to the BridgedTokensWrapper (6) contract as per the instructions provided at [https://docs.multiversx.com/tokens/fungible-tokens/#setting-and-unsetting-special-roles](/tokens/fungible-tokens/#setting-and-unsetting-special-roles)
 
 **Note**: As an alternative approach, MultiversX team can issue an ESDT token on the MultiversX chain with the same properties as on Ethereum, and give the needed roles to the Smart Contracts, as indicated above. The MultiversX team can then give the token issuer the ownership of token management for that specific ESDT token.

docs/developers/best-practices/the-dynamic-allocation-problem.md

@@ -54,7 +54,7 @@ Below is a table of unmanaged types (basic Rust types) and their managed counter
 [^1]: `ArrayVec` allocates on the stack, and so it has a fixed capacity - it cannot grow indefinitely. You can make it as large as you please, but be warned that adding beyond this capacity results in a panic. Use `try_push` instead of `push` for more graceful error handling.
 [^2]: Be careful when passing arrays around, since they get copied when returned from functions. This can add a lot of expensive memory copies in your contract.
 
-In most cases, the managed types can be used as drop-in replacements for the basic Rust types. For a simple example, see [BigUint Operations](#biguint-operations).
+In most cases, the managed types can be used as drop-in replacements for the basic Rust types. For a simple example, see [BigUint Operations](/developers/best-practices/biguint-operations).
 
 We also recommend _allocating Rust arrays directly on the stack_ (as local variables) whenever a contiguous area of useful memory is needed. Moreover, avoid allocating mutable global buffers for this purpose, which require `unsafe` code to work with.
 

docs/developers/built-in-functions.md

@@ -116,8 +116,8 @@ already covered [here](/developers/account-storage).
 
 ## **ESDT and NFT built-in functions**
 
-Most of the ESDT and NFT related built-in function are already described in the [ESDT](/developers/esdt-tokens/) and
-[NFT](/developers/nft-tokens) sections.
+Most of the ESDT and NFT related built-in function are already described in the [ESDT](/tokens/fungible-tokens) and
+[NFT](/tokens/nft-tokens) sections.
 
 [comment]: # (mx-context-auto)
 

docs/developers/data/abi.md

@@ -118,6 +118,7 @@ Please note that the type names are not necessarily the ones from Rust, we are t
 ### Basic types
 
 First off, there are a number of [basic types](/developers/data/simple-values) that are known, and which have a universal representation:
+
 - Numerical types: `BigUint`, `BigInt`, `u64`, `i32`, etc.
 - Booleans: `bool`.
 - Raw byte arrays are all specified as `bytes`, irrespective of the underlying implementation in the contract. Someone who just interacts with the contract does not care whether the contracts works with `ManagedBuffer`, `Vec<u8>`, or something else, it's all the same to the exterior.
@@ -130,6 +131,7 @@ First off, there are a number of [basic types](/developers/data/simple-values) t
 ### Composite types
 
 Then, there are several standard [composite types](/developers/data/composite-values). They also have type arguments that describe the type of their content:
+
 - Variable-length lists: `List<T>`, where `T` can be any type; e.g. `List<u32>`.
 - Fixed-length arrays: `arrayN<T>`, where `N` is a number and `T` can be any type; e.g. `array5<u8>` represents 5 bytes.
 - Heterogenous fixed-length tuples, `tuple<T1,T2,...,TN>`, no spaces, where `T1`, `T2` , ... , `TN` can be any types; e.g. `tuple<i16,bytes>`.
@@ -308,6 +310,7 @@ You can read more about Rust enums [here](https://doc.rust-lang.org/book/ch06-01
 [comment]: # (mx-context-auto)
 
 ### Overview
+
 The framework will export all data types found in arguments, results, and events, but it doesn't intrinsically know abut the data that we use in SFT and NFT attributes. This is why there is a special annotation to specify this explicitly.
 
 Starting with the framework version `0.44`, developers can use the new trait annotation `#[esdt_attribute("name", Type)]` in order to export ESDT attributes types in the ABI file. 
@@ -321,6 +324,7 @@ The annotation can only be used at trait level along with `#[multiversx_sc::cont
 :::
 
 The exported data will end up in 2 places:
+
 1. In the contract ABI, in a special `"esdt_attributes"` section;
 2. In a special ESDT ABI file (`name.esdt-abi.json`), one for each such declared ESDT.
 
@@ -360,6 +364,7 @@ Adding the `#[esdt_attribute("testBasic", BigUint)]` at trait level along with `
 The abi can be generated calling `sc-meta all abi` in the contract folder, or by building the contract using `sc-meta all build` (this command also adds the `wasm` file to the `output` folder).
 
 Building the contract using `sc-meta all build` will generate the following folder structure:
+
 ```
 some_contract
 ├── output

docs/developers/data/simple-values.md

@@ -5,6 +5,7 @@ title: Simple Values
 [comment]: # (mx-abstract)
 
 We will start by going through the basic types used in smart contracts:
+
 - Fixed-width numbers
 - Arbitrary width (big) numbers
 - Boolean values
@@ -156,7 +157,7 @@ Booleans are serialized the same as a byte (`u8`) that can take values `1` or `0
 
 ### Byte slices and ASCII strings
 
-Byte slices are technically a special case of the [list types](developers/data/composite-values#lists-of-items), but they are usually thought of as basic types. Their encoding is, in any case, consistent with the rules for lists of "byte items".
+Byte slices are technically a special case of the [list types](/developers/data/composite-values#lists-of-items), but they are usually thought of as basic types. Their encoding is, in any case, consistent with the rules for lists of "byte items".
 
 :::important
 Strings are treated from the point of view of serialization as series of bytes. Using Unicode strings, while often a good practice in programming, tends to add unnecessary overhead to smart contracts. The difference is that Unicode strings get validated on input and concatenation.
@@ -182,7 +183,7 @@ We consider best practice to use Unicode on the frontend, but keep all messages
 | `String`        | `"abc".to_string()`         | `0x616263`         | `0x00000003616263` | Unicode string (owned).                                           |
 
 :::info Note
-Inside contracts, `ManagedBuffer` is [the only recommended type for generic bytes](developers/best-practices/the-dynamic-allocation-problem).
+Inside contracts, `ManagedBuffer` is [the only recommended type for generic bytes](/developers/best-practices/the-dynamic-allocation-problem).
 :::
 
 ---
@@ -205,9 +206,8 @@ They are top-encoded as is, the exact bytes and nothing else.
 
 Because of their variable length, they need to be serialized like variable length byte slices when nested, so the length is explicitly encoded at the start.
 
- Type            | Value                       | Top-level encoding | Nested encoding    |
+| Type            | Value                       | Top-level encoding | Nested encoding    |
 | --------------- | --------------------------- | ------------------ | ------------------ |
 | `TokenIdentifier` | `ABC-123456`                    | `0x4142432d313233343536`         | `0x0000000A4142432d313233343536` |
 
 ---
-

docs/developers/esdt-tokens.md

@@ -3,4 +3,4 @@ id: esdt-tokens
 title: ESDT tokens
 ---
 
-The Fungible Tokens documentation has been moved [here](/tokens/esdt-tokens).
+The Fungible Tokens documentation has been moved [here](/tokens/fungible-tokens).

docs/developers/gas-and-fees/system-smart-contracts.md

@@ -9,5 +9,5 @@ For more details, please follow:
 
  - [The Staking Smart Contract](/validators/staking/staking-smart-contract)
  - [The Delegation Manager](/validators/delegation-manager)
- - [ESDT tokens](/developers/esdt-tokens)
- - [NFT tokens](/developers/nft-tokens)
+ - [ESDT tokens](/tokens/fungible-tokens)
+ - [NFT tokens](/tokens/nft-tokens)

docs/developers/guard-accounts.md

@@ -63,18 +63,18 @@ In order to register a guardian a user has to set a **guardian** address by send
 
 ### Guard account
 
-In order to activate guardian signing (co-signing) a ```GuardAccount``` builtin function transaction needs to be sent to MultiversX network. A guard account transaction can be issued by the account and processed by the protocol only if the account has an ```activeGuardian``` (see [guardian-data fields](/sdk-and-tools/rest-api/addresses#get-address-guardian-data)) already set (which implies that the **20 epochs** since sending the ```SetGuardian``` already passed). When the account is guarded, any transaction issued by the owner of the account would be ignored unless it also carries the signature of its set guardian. This transaction could be sent either directly from the user or also through a relayer, if the user does not have the egld required for the transaction fee. 
+In order to activate guardian signing (co-signing) a ```GuardAccount``` builtin function transaction needs to be sent to MultiversX network. A guard account transaction can be issued by the account and processed by the protocol only if the account has an ```activeGuardian``` (see [guardian-data fields](/sdk-and-tools/rest-api/addresses#get-address-guardian-data)) already set (which implies that the **20 epochs** since sending the ```SetGuardian``` already passed). When the account is guarded, any transaction issued by the owner of the account would be ignored unless it also carries the signature of its set guardian. This transaction could be sent either directly from the user or also through a relayer, if the user does not have the egld required for the transaction fee.
 
-The field ```"guarded":true``` in [guardian-data fields](/sdk-and-tools/rest-api/addresses#get-address-guardian-data) specifies that the ```GuardAccount``` transaction was executed and was successful for the account. In this case all transactions from the user account, to be executed by the protocol, will require to be guarded transactions, and the guardian to be the activeGuardian of the account. The only exception is the SetGuardian transaction which can as well be sent through a regular transaction, in which case, the new guardian will become pending for 20 epochs, and at the end of these 20 epochs replace the current active guardian. 
+The field ```"guarded":true``` in [guardian-data fields](/sdk-and-tools/rest-api/addresses#get-address-guardian-data) specifies that the ```GuardAccount``` transaction was executed and was successful for the account. In this case all transactions from the user account, to be executed by the protocol, will require to be guarded transactions, and the guardian to be the activeGuardian of the account. The only exception is the SetGuardian transaction which can as well be sent through a regular transaction, in which case, the new guardian will become pending for 20 epochs, and at the end of these 20 epochs replace the current active guardian.
 
-In case ```"guarded":false``` even if there is a non-empty ```activeGuardian```, the protocol will still only execute regular (non-guarded) transactions. 
+In case ```"guarded":false``` even if there is a non-empty ```activeGuardian```, the protocol will still only execute regular (non-guarded) transactions.
 
 :::note
 The exception is the ```setGuardian``` transaction which can either:
 
 - be executed immediately if it is co-signed by the active guardian and **cleans up any pending guardian activation**;
-
 - not be confirmed by the guardian but in this case the guardian can only be set with an activation time in future (e.g the same 20 epochs from the initial setting of a guardian).
+
 :::
 
 :::note
@@ -180,12 +180,14 @@ There is no official solution released for the **Ledger**. As soon as there is o
 In the meantime you can use the **MultiversX Guardians Test - BETA** version:
 
 **How to activate it?**
+
 1. In Ledger Live
 2. Go to My Ledger
 3. Go to Settings (⚙️)
 4. Go to Experimental features
 5. Enable Developer Mode - ✅
 6. Search and install MultiversX Guardians Test
+
 :::
 
 :::important
@@ -205,4 +207,3 @@ There should be no impact on integrators who utilize the [sdk-dapp](https://gith
 ### Trusted Co-Signer Service for Guardians
 
 In the future we want to publish the codebase to MultiversX TCS so that third party TCS service providers will be allowed to be listed in the MultiversX wallet, this process of launching a TCS guardian service needs to be defined.
-

docs/developers/interactor/interactors-example.md

@@ -285,5 +285,5 @@ async fn test_full_farm_scenario() {
 }
 ```
 
-As illustrated, these tests resemble typical Rust tests but apply scenarios directly on the actual blockchain, facilitated by the [interactor tx environment](/docs//developers/transactions/tx-env.md#interactor). These tests can be executed with `cargo test` or `sc-meta test`, seamlessly integrating into your standard testing workflow.
+As illustrated, these tests resemble typical Rust tests but apply scenarios directly on the actual blockchain, facilitated by the [interactor tx environment](//developers/transactions/tx-env.md#interactor). These tests can be executed with `cargo test` or `sc-meta test`, seamlessly integrating into your standard testing workflow.
 

docs/developers/meta/sc-config.md

@@ -8,6 +8,7 @@ title: Configuration
 We like to say that developers don't write smart contracts directly, rather they write _specifications_ for smart contracts, from which an automated process creates the smart contracts themselves.
 
 This philosophy has two practical implications:
+
 1. The smart contract code itself has no direct knowledge of the underlying technology or of the blockchain, and can therefore be used to build other products too, such as tests, interactors, services, etc.
 2. The build process is its own separate thing, which needs to be configured.
 
@@ -140,7 +141,7 @@ The settings are as follows:
     - _values_: `true` | `false`
     - _default_: `false`
 - `proxy`
-  - Sets custom configuration for a generated proxy. More details about proxies are available [here](../../transactions/tx-proxies#how-to-set-up-project-to-re-generate-easily)
+  - Sets custom configuration for a generated proxy. More details about proxies are available [here](/developers/transactions/tx-proxies#how-to-set-up-project-to-re-generate-easily)
   - `path`
     - Set the output path where the generated proxy will be saved.
     - _values_: `String`
@@ -576,4 +577,3 @@ fn world() -> ScenarioWorld {
     blockchain
 }
 ```
-

docs/developers/overview.md

@@ -130,11 +130,11 @@ Learn about transaction's gas and how a fee is calculated:
 
 | Name                                                                 | Description                                              |
 |----------------------------------------------------------------------|----------------------------------------------------------|
-| [Scenario Overview](/developers/scenario-reference/overview)             | Test your Smart Contracts by using Scenario JSON tests. |
-| [Scenario Structure](/developers/scenario-reference/structure)           | How to structure a scenario.                          |
-| [Scenario Simple Values](/developers/scenario-reference/values-simple)   | Handle simple values in scenario tests.                    |
-| [Scenario Complex Values](/developers/scenario-reference/values-complex) | Handle complex values in scenario tests.                   |
-| [Embedding Scenario code in GO](/developers/scenario-reference/embed)    | How to embed scenario code in Go.                          |
+| [Scenario Overview](/developers/testing/scenario/concept)             | Test your Smart Contracts by using Scenario JSON tests. |
+| [Scenario Structure](/developers/testing/scenario/structure-json)           | How to structure a scenario.                          |
+| [Scenario Simple Values](/developers/testing/scenario/values-simple)   | Handle simple values in scenario tests.                    |
+| [Scenario Complex Values](/developers/testing/scenario/values-complex) | Handle complex values in scenario tests.                   |
+| [Embedding Scenario code in GO](/developers/testing/testing-in-go)    | How to embed scenario code in Go.                          |
 
 [comment]: # (mx-context-auto)
 
@@ -180,4 +180,4 @@ the execution of smart contract, information about ESDT transfers or built-in fu
 | [Setup local testnet advanced](/developers/setup-local-testnet-advanced) | How to set up a localnet (local testnet) - advanced solution                           |
 | [Creating wallets](/developers/creating-wallets)                         | Examples on creating wallets.                                                          |
 | [Reproducible builds](/developers/reproducible-contract-builds)          | How to perform reproducible contract builds.                                           |
-| [Contract API limits](/developers/contract-api-limits)                   | Limits that a smart contract must abide when calling external (node-related) functions | 
+| [Contract API limits](/developers/contract-api-limits)                   | Limits that a smart contract must abide when calling external (node-related) functions |

docs/developers/relayed-transactions.md

@@ -14,13 +14,13 @@ Relayed transactions (or meta-transactions) are transactions with the fee paid b
 In other words, if a relayer is willing to pay for an interaction, it is not mandatory that the address
 interacting with a Smart Contract has any EGLD for fees.
 
-More details and specifications can be found on [MultiversX Specs](https://github.com/multiversx/mx-specs/blob/main/sc-meta-transactions.md).
+More details and specifications can be found on [MultiversX Specs](https://github.com/multiversx/mx-specs/blob/main/sc-meta-transactions).
 
 [comment]: # (mx-context-auto)
 
 ## Types of relayed transactions
 
-Currently, there are 3 versions of relayed transactions: v1, v2 and v3. In the end, they all have the same effect. 
+Currently, there are 3 versions of relayed transactions: v1, v2 and v3. In the end, they all have the same effect.
 
 Relayed v2 was meant to bring optimisations in terms of gas usage. But v3 reduces the costs even further, making it our recommendation.