Development

docs/developers/relayed-transactions.md

@@ -30,6 +30,10 @@ Once all applications will completely transition to relayed v3 model, v1 and v2
 
 ## Relayed transactions version 1
 
+:::note
+Legacy version. Please use [version 3](#relayed-transactions-version-3), instead.
+:::
+
 A relayed transaction version 1 relies on having the inner transaction JSON serialized and given as an argument to the `relayedTx` protocol function.
 
 It would look like:
@@ -165,6 +169,10 @@ gasLimit = 61040000  // just like the gas limit set in the relayed transaction
 
 ## Relayed transactions version 2
 
+:::note
+Legacy version. Please use [version 3](#relayed-transactions-version-3), instead.
+:::
+
 In contrast with version 1, relayed transactions version 2 have only certain fields of the inner transaction included
 in the data field, making the payload smaller, therefore the tx fee smaller. It also eliminates the need of calculating
 the matching gas limit values between the relayed and inner transactions.
@@ -249,10 +257,6 @@ Decoding the arguments ([useful resources here](/developers/sc-calls-format/)) w
 
 ## Relayed transactions version 3
 
-:::note
-This feature is not yet available on **Mainnet**. See [Spica Protocol Upgrade](https://governance.multiversx.com/proposal/erd1qqqqqqqqqqqqqpgq4qvrwlr2e6ld50f3qfc94am38p8298kthg4s3f0vfn/1).
-:::
-
 Relayed transactions v3 feature comes with a change on the entire transaction structure, adding two new optional fields: 
 - `relayer`, which is the relayer address that will pay the fees.
 - `relayerSignature`, the signature of the relayer that proves the agreement of the relayer.
@@ -316,3 +320,11 @@ Here's an example of a relayed v3 transaction. Its intent is to call the `add` m
   "relayerSignature": "..."
 }
 ```
+
+### Preparing relayed transactions using the SDKs
+
+The SDKs have built-in support for relayed transactions. Please follow:
+ - [mxpy support](/sdk-and-tools/sdk-py/mxpy-cli/#relayed-transactions-v3)
+ - [sdk-py support](/sdk-and-tools/sdk-py/sdk-py-cookbook/#relayed-transactions)
+ - [sdk-js v14 support](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14#relayed-transactions)
+ - [sdk-js v13 support (legacy)](/sdk-and-tools/sdk-js/sdk-js-cookbook-v13#preparing-a-relayed-transaction)

docs/developers/sc-calls-format.md

@@ -76,7 +76,7 @@ There are multiple ways of formatting the data field:
 
 - manually convert each argument, and then join the function name, alongside the argument via the `@` character.
 - use a pre-defined arguments serializer, such as [the one found in sdk-js](https://github.com/multiversx/mx-sdk-js-core/blob/main/src/smartcontracts/argSerializer.ts).
-- use sdk-js's [contract calls](/sdk-and-tools/sdk-js/sdk-js-cookbook-v13/#contract-interactions).
+- use sdk-js's [contract calls](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14/#smart-contracts).
 - use sdk-cpp's [contract calls](https://github.com/multiversx/mx-sdk-cpp/blob/main/src/smartcontracts/contract_call.cpp).
 - and so on
 

docs/developers/signing-transactions/signing-programmatically.md

@@ -5,5 +5,5 @@ title: Signing programmatically
 
 In order to sign a transaction (or a message) using one of the SDKs, follow:
 
-- [Signing objects using **sdk-js**](/sdk-and-tools/sdk-js/sdk-js-cookbook-v13#signing-objects)
+- [Signing objects using **sdk-js**](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14#signing-objects)
 - [Signing objects using **sdk-py**](/sdk-and-tools/sdk-py/sdk-py-cookbook#signing-objects)

docs/developers/tutorials/your-first-dapp.md

@@ -199,6 +199,8 @@ The interactor crate is located at `ping-pong/contract/ping-pong/interactor` and
 To access `wallet-owner.pem` you must navigate up three folders: `../../../`, then into the **wallet** directory.
 :::
 
+Make sure to add the absolute path at `Wallet::from_pem_file("/ping-pong/wallet/wallet-owner.pem")`, completing the missing directories above "ping-pong".
+
 This next command deploys the Ping-Pong contract with the following settings:
 
 - Ping Amount: **1 EGLD**.

docs/learn/entities.md

@@ -9,6 +9,8 @@ A **user** is anyone holding one or more pairs of keys (one secret, one public).
 
 An account is uniquely identified by its _address_. The MultiversX network defines the address of an account to be equal to the public key of its corresponding pair of keys (the secret key remains known only by the user that owns the key pair). The public key is 32 bytes in length, which means that the address of an account is 32 bytes as well. As a standard, the MultiversX network uses the Bech32 human-readable representation for account addresses.
 
-Users normally manage the keys of their accounts using _wallets_, which are applications dedicated to securely contain these keys. While it's completely possible to manage one's keys and accounts without a wallet application, it is an uncommon practice and employed mostly by advanced users or by automated processes. The **nodes** are the devices connected to the MultiversX network, which perform the operations requested by its users. Nodes can be either passive or actively engaged in processing tasks. _Eligible validators_ are active participants in the network. Specifically, they are responsible for performing consensus, adding blocks, maintaining the state, and they are also rewarded for their contribution. Each eligible validator can be uniquely identified by its 96-byte-long BLS public key (not to be confused with account keys, which are generated with the Schnorr algorithm).
+Users normally manage the keys of their accounts using _wallets_, which are applications dedicated to securely contain these keys. While it's completely possible to manage one's keys and accounts without a wallet application, it is an uncommon practice and employed mostly by advanced users or by automated processes.
+
+The **nodes** are the devices connected to the MultiversX network, which perform the operations requested by its users. Nodes can be either passive or actively engaged in processing tasks. _Eligible validators_ are active participants in the network. Specifically, they are responsible for performing consensus, adding blocks, maintaining the state, and they are also rewarded for their contribution. Each eligible validator can be uniquely identified by its 96-byte-long BLS public key (not to be confused with account keys, which are generated with the Schnorr algorithm).
 
 A user that manages one or multiple nodes is called a **node operator**. These users must stake a substantial amount of EGLD tokens for each of their node as a collateral, effectively vouching for the correctness and performance of the nodes. The network locks the staked amount, which cannot be accessed by the node operator unless they withdraw both the stake _and the nodes_. Nodes that have been staked for by a user are promoted to **validator** status, and they may participate in consensus and earn rewards for their contribution. Without staking, nodes remain **observers** of the network. While passive, observers are still important in the network.

docs/sdk-and-tools/overview.md

@@ -30,7 +30,7 @@ Note that Rust is also the recommended programming language for writing Smart Co
 | Name                                                                                                     | Description                                         |
 | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
 | [sdk-js](/sdk-and-tools/sdk-js)                                                                          | High level overview about sdk-js.                   |
-| [sdk-js cookbook](/sdk-and-tools/sdk-js/sdk-js-cookbook-v13)                                             | Learn how to handle common tasks by using sdk-js.   |
+| [sdk-js cookbook](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14)                                             | Learn how to handle common tasks by using sdk-js.   |
 | [Extending sdk-js](/sdk-and-tools/sdk-js/extending-sdk-js)                                               | How to extend and tailor certain modules of sdk-js. |
 | [Writing and testing sdk-js interactions](/sdk-and-tools/sdk-js/writing-and-testing-sdk-js-interactions) | Write sdk-js interactions for Visual Studio Code    |
 | [sdk-js migration guides](/sdk-and-tools/sdk-js/sdk-js-migration-guides)                                 | Migrate from sdk-js v9.x to v10+                    |

docs/sdk-and-tools/sdk-js/migration-guides.md

@@ -8,7 +8,7 @@ title: Migration guides
 This page links to resources which are helpful in upgrading to newer versions of a **sdk-js** package.
 
 :::important
-Make sure you have a look over the [cookbook](/sdk-and-tools/sdk-js/sdk-js-cookbook-v13), in advance.
+Make sure you have a look over the [cookbook](/sdk-and-tools/sdk-js/sdk-js-cookbook-v14), in advance.
 :::
 
 ## Migrate to a newer sdk-core