fix links

bucanero · bucanero · commit a25e44cfe2e1 · 2022-07-19T15:17:09.000-03:00
diff --git a/docs/1.concepts/1.basics/epoch.md b/docs/1.concepts/1.basics/epoch.md
@@ -10,7 +10,7 @@ import TabItem from '@theme/TabItem';
 An **epoch** is a unit of time when validators of the network remain constant. It is measured in blocks:
 
 - Both `testnet` and `mainnet` have an epoch duration of 43,200 blocks. Ideally epochs last about 12 hours, since blocks are created every second (in reality, they take slightly longer to be created).
-- You can view this setting by querying the **[`protocol_config`](/docs/api/rpc#protocol-config)** RPC endpoint and searching for `epoch_length`.
+- You can view this setting by querying the **[`protocol_config`](/api/rpc/setup#protocol-config)** RPC endpoint and searching for `epoch_length`.
 
 **Note:** Nodes garbage collect blocks after 5 epochs (~2.5 days) unless they are [archival nodes](https://near-nodes.io/intro/node-types#archival-node).
 
diff --git a/docs/1.concepts/web3/near.md b/docs/1.concepts/web3/near.md
@@ -139,7 +139,7 @@ To support more complex data retrieval scenarios, smart contract data should be
     
 
 
-In order to simplify creation of indexers, [NEAR Indexer Framework](../2.tools/near-indexer-framework.md) has been created. However, even with a framework available, extracting data from a transaction may not be an easy task, since each smart contract has its unique structure and data storage model. To simplify this process, smart contracts can write structured information about outcome into the logs  (e.g. in the JSON format). Each smart contract can use its own format for such logs, but the general format has been standardized as [Events](https://nomicon.io/Standards/EventsFormat).
+In order to simplify creation of indexers, [NEAR Indexer Framework](https://near-indexers.io/docs/projects/near-indexer-framework) has been created. However, even with a framework available, extracting data from a transaction may not be an easy task, since each smart contract has its unique structure and data storage model. To simplify this process, smart contracts can write structured information about outcome into the logs  (e.g. in the JSON format). Each smart contract can use its own format for such logs, but the general format has been standardized as [Events](https://nomicon.io/Standards/EventsFormat).
 
 Such architecture is very similar to Event Sourcing, where blockchain stores events (transactions), and they are materialized to a relational database using an indexer. This means the same drawbacks also apply. For instance, a client should be designed to accommodate indexing delay, which may take a few seconds.
 
@@ -151,12 +151,12 @@ By now, we should be familiar with necessary concepts to start developing WEB 3.
 
 First of all, we need a development and testing environment. Of course, we could theoraticaly perform development and testing on the main blockchain network, but this would not be cheap. For this reason, NEAR provides [several networks](https://docs.near.org/concepts/basics/networks) that can be used during development:
 - testnet - public NEAR network which is identical to mainnet and can be used for free.
-- localnet - you can deploy your personal NEAR network on your own environment. Because it’s owned by you, data and code can be kept private during development. More info on how you can run your own node can be [found here](https://docs.near.org/docs/develop/node/validator/running-a-node). Alternatively, you can bootstrap an entire testing infrastructure in Docker on your local machine using Kurtosis - [guide is here](../2.tools/kurtosis-localnet.md).
+- localnet - you can deploy your personal NEAR network on your own environment. Because it’s owned by you, data and code can be kept private during development. More info on how you can run your own node can be [found here](https://docs.near.org/docs/develop/node/validator/running-a-node). Alternatively, you can bootstrap an entire testing infrastructure in Docker on your local machine using Kurtosis - [guide is here](/develop/testing/kurtosis-localnet).
 - workspaces - you can start your own local network to perform e2e testing. More info [here](../../2.develop/testing/integration.md).
 
 Once we’ve chosen a network to use, we need a way to interact with it. Of course, transactions can be constructed manually and posted into [node’s API](https://docs.near.org/api/rpc/setup). But [this is tedious](https://github.com/near-examples/transaction-examples) and isn’t fun at all. That’s why, NEAR [provides a CLI](../../4.tools/cli.md) which automates all of the necessary actions. It can be used locally for development purposes or on build machines for CI/CD scenarios.
 
-In order to manage accounts on the NEAR network, [Wallet](../2.tools/2.near-wallet.md) can be used. It can show an effective account balance and active keys.
+In order to manage accounts on the NEAR network, [Wallet](https://wiki.near.org/getting-started/creating-a-near-wallet) can be used. It can show an effective account balance and active keys.
 
 ![image](/docs/assets/web3/web3-16.png)
 
diff --git a/docs/1.concepts/web3/nfts.md b/docs/1.concepts/web3/nfts.md
@@ -625,5 +625,5 @@ When building a Web 3 application, it’s important to remember that cost calcul
 1. Smart Contracts deployment costs. While deploying on NEAR testnet or local environment, it’s essentially free of charge. However, when deploying into the mainnet, developers will be charged for storage and gas cost. Gas cost for a contract deployment transaction is relatively small (around 0.04$ at the time of writing). On the other hand, storage costs can be quite substantial, e.g. a 150KB contract (compiled) will cost around 20$.
 2. Smart Contracts usage cost. In Web 3, users pay for smart contract calls, so in order to make sure users aren’t discouraged to interact with a contract due to a high cost, it should be optimized to incur the lowest cost possible. This is especially important for storage costs, since gas is relatively cheap.
 3. If we want to use a privately hosted RPC node for better availability, its operational costs should be taken into account as well. Cost breakdown can be found [here](https://near-nodes.io/rpc/hardware-rpc), a rough estimation is about 290$ per node per month (and remember that we need at least 2 nodes for redundancy).
-4. Cost of a privately hosted indexer (if it’s used). More information can be found [here](../2.tools/near-indexer-framework.md), a rough estimation for the costs is about 100$ per month.
+4. Cost of a privately hosted indexer (if it’s used). More information can be found [here](https://near-indexers.io/docs/projects/near-indexer-framework), a rough estimation for the costs is about 100$ per month.
 5. Third party services costs. 
diff --git a/docs/2.develop/deploy.md b/docs/2.develop/deploy.md
@@ -15,7 +15,7 @@ cannot change anymore.
 Thanks to the `NEAR CLI` deploying a contract is as simple as:
 
 1. Compiling the contract to wasm (done automatically through `yarn build` in our templates).
-2. Deploy it into the desired account using the [NEAR Command Line Interface (CLI)](/concepts/tools/near-cli):
+2. Deploy it into the desired account using the [NEAR Command Line Interface (CLI)](/develop/integrate/cli):
 
 ```bash
 # Login to NEAR
diff --git a/docs/4.tools/near-api-js/cookbook.md b/docs/4.tools/near-api-js/cookbook.md
@@ -19,7 +19,7 @@ solve common case scenarios.
 | [Access Key Rotation](#access-key-rotation)               | Create and delete [access keys](/concepts/basics/account#access-keys) for added security.                   |
 | **TRANSACTIONS**                                          |                                                                                                             |
 | [Get Transaction Status](#get-transaction-status)         | Gets transaction status using a tx hash and associated account/contract ID.                                 |
-| [Recent Transaction Details](#recent-transaction-details) | Get recent transaction details without using an [indexing](/concepts/tools/near-indexer-framework) service. |
+| [Recent Transaction Details](#recent-transaction-details) | Get recent transaction details without using an [indexing](https://near-indexers.io/docs/projects/near-indexer-framework) service. |
 | [Batch Transactions](#batch-transactions)                 | Sign and send multiple [transactions](/concepts/basics/transactions/overview).                              |
 | **UTILS**                                                 |                                                                                                             |
 | [Deploy Contract](#deploy-contract)                       | Deploys a smart contract using a pre-compiled WASM file.                                                    |
@@ -290,7 +290,7 @@ async function getState(txHash, accountId) {
 
 ### Recent Transaction Details {#recent-transaction-details}
 
-> Allows you to inspect chunks and transaction details for recent blocks without having to use an [indexer](/concepts/tools/near-indexer-framework).
+> Allows you to inspect chunks and transaction details for recent blocks without having to use an [indexer](https://near-indexers.io/docs/projects/near-indexer-framework).
 
 ```js
 const { connect, keyStores } = require("near-api-js");
diff --git a/docs/6.integrator/accounts.md b/docs/6.integrator/accounts.md
@@ -9,7 +9,7 @@ sidebar_label: Accounts
 Please see the [documentation for accounts](/concepts/basics/account) for basic information.
 
 - For exchanges, NEAR supports [implicit account](https://nomicon.io/DataStructures/Account.html#implicit-account-ids) creation which allows the creation of accounts without paying for transactions.
-- You can create an implicit account by following the steps in [this guide](/docs/roles/integrator/implicit-accounts).
+- You can create an implicit account by following the steps in [this guide](/integrator/implicit-accounts).
 - Accounts must have enough tokens to cover its storage which currently costs 0.0001 NEAR per byte. This equates to a minimum balance of 0.0182 NEAR for an account with one access key. You can query the live storage price using the [`protocol-config`](https://docs.near.org/api/rpc/setup#protocol-config) RPC endpoint. For more details on storage fees see [this section of the economics paper](https://near.org/papers/economics-in-sharded-blockchain/#transaction-and-storage-fees).
 
 ## Transfer from Function Call {#transfer-from-function-call}
diff --git a/docs/6.integrator/errors/introduction.md b/docs/6.integrator/errors/introduction.md
@@ -7,7 +7,7 @@ sidebar_label: Introduction
 <blockquote class="info">
 <strong>did you know?</strong><br /><br />
 
-The [NEAR Platform overview](/docs/concepts/overview) clarifies much of the language in this section.
+The [NEAR Platform overview](/concepts/welcome) clarifies much of the language in this section.
 
 </blockquote>
 
@@ -17,7 +17,7 @@ The [NEAR Platform overview](/docs/concepts/overview) clarifies much of the lang
 - The RPC interface receives the transaction and routes it to the correct physical node using `signer_id`.  Since the `signer_id` must be a NEAR Account ID which lives on a single shard, the account is mapped to a shard which is followed by at least one validator running at least one machine with an IP address.
 - When a node receives a new signed transaction, it validates the transaction for signer, receiver, account balance, cost overflow, signature, etc. ([see here](https://nomicon.io/RuntimeSpec/Scenarios/FinancialTransaction.html#transaction-to-receipt)) and gossips it to all peers following the same shard. If a transaction has an invalid signature or would be invalid on the latest state, it is rejected quickly and returns an error to the original RPC call. 
 - Valid transactions are added to the transaction pool (every validating node has its own independent copy of a transaction pool). The transaction pool maintains transactions that are not yet discarded and not yet included into the chain.
-- A pool iterator is used to pick transactions from the pool one at a time, ordered from the smallest nonce to largest, until the pool is drained or some chunk limit is reached (max number of transactions per chunk or max gas burnt per chunk to process transactions).  Please refer to articles on the [pool iterator](https://nomicon.io/ChainSpec/Transactions.html?highlight=pool#pool-iterator) and [gas](/docs/concepts/gas) for more details.
+- A pool iterator is used to pick transactions from the pool one at a time, ordered from the smallest nonce to largest, until the pool is drained or some chunk limit is reached (max number of transactions per chunk or max gas burnt per chunk to process transactions).  Please refer to articles on the [pool iterator](https://nomicon.io/ChainSpec/Transactions.html?highlight=pool#pool-iterator) and [gas](/concepts/basics/transactions/gas) for more details.
 - To accommodate the distributed nature of a sharded blockchain, all transactions are subsequently returned to a segmented transaction pool having 3 distinct layers: accepted transactions (which will be processed on the next chunk), pending transactions (which exceeded the limits of the current chunk and will be included in a later round of processing) and invalid transactions (which will be rejected at the next available opportunity).
 - Before producing a chunk, transactions are ordered and validated again. This is done to produce chunks with only valid transactions across a distributed system.
 - While a transaction is being processed on to a chunk, any errors raised by the application of its actions are also returned via RPC.
diff --git a/docs/6.integrator/exchange-integration.md b/docs/6.integrator/exchange-integration.md
@@ -6,15 +6,15 @@ sidebar_label: Exchange Integration
 
 ## Integration Reference {#integration-reference}
 
-- [Balance Changes](/docs/roles/integrator/balance-changes)
-- [Accounts](/docs/roles/integrator/accounts)
-- [Fungible Tokens](/docs/roles/integrator/fungible-tokens)
-- [Implicit Accounts](/docs/roles/integrator/implicit-accounts)
+- [Balance Changes](/integrator/balance-changes)
+- [Accounts](/integrator/accounts)
+- [Fungible Tokens](/integrator/fungible-tokens)
+- [Implicit Accounts](/integrator/implicit-accounts)
 
 ### Transaction Reference Links {#transaction-reference-links}
 
- - [Basics](/docs/concepts/transaction)
- - [Specifications](https://nomicon.io/RuntimeSpec/Transactions.html)
+ - [Basics](/concepts/basics/transactions/overview)
+ - [Specifications](https://nomicon.io/RuntimeSpec/Transactions)
  - [Constructing Transactions](/docs/tutorials/create-transactions)
 
 ## Blocks and Finality {#blocks-and-finality}
diff --git a/docs/6.integrator/faq.md b/docs/6.integrator/faq.md
@@ -260,7 +260,7 @@ Transactions are a collection of related data that is composed and cryptographic
 
 Transactions can be constructed and signed offline. Nodes are not required for signing. We are planning to add optional recent block hash to help prevent various replay attacks.
 
-See [transactions](/docs/concepts/transaction) in the concepts section of our documentation.
+See [transactions](/concepts/basics/transactions/overview) in the concepts section of our documentation.
 
 ### How is the hash preimage generated? Which fields does the raw transaction consist of? {#how-is-the-hash-preimage-generated-which-fields-does-the-raw-transaction-consist-of}
 
@@ -275,11 +275,11 @@ Transactions are received via our JSON-RPC endpoint and routed to the shared whe
 
 Once received by the network, signed transactions are verified (using the embedded public key of the signer) and transformed into a collection of `Receipt`s, one per action. Receipts are of two types: `Action Receipt` is the most common and represents almost all actions on the network while `Data Receipt` handles the very special case of "a `FunctionCallAction` which includes a Promise". These receipts are then propagated and applied across the network according to the "home shard" rule for all affected receiver accounts.
 
-These receipts are then propagated around the network using the receiver account's "home shard" since each account lives on one and only one shard. Once located on the correct shard, receipts are pulled from a nonce-based [queue](https://nomicon.io/ChainSpec/Transactions.html#pool-iterator).
+These receipts are then propagated around the network using the receiver account's "home shard" since each account lives on one and only one shard. Once located on the correct shard, receipts are pulled from a nonce-based [queue](https://nomicon.io/ChainSpec/Transactions#pool-iterator).
 
 Receipts may generate other, new receipts which in turn are propagated around the network until all receipts have been applied. If any action within a transaction fails, the entire transaction is rolled back and any unburnt fees are refunded to the proper accounts.
 
-For more detail, see specs on [`Transactions`](https://nomicon.io/RuntimeSpec/Transactions.html), [`Actions`](https://nomicon.io/RuntimeSpec/Actions.html), [`Receipts`](https://nomicon.io/RuntimeSpec/Receipts.html)
+For more detail, see specs on [`Transactions`](https://nomicon.io/RuntimeSpec/Transactions), [`Actions`](https://nomicon.io/RuntimeSpec/Actions.html), [`Receipts`](https://nomicon.io/RuntimeSpec/Receipts)
 
 ### How does NEAR serialize transactions? {#how-does-near-serialize-transactions}
 
diff --git a/docs/6.integrator/tokens.md b/docs/6.integrator/tokens.md
@@ -143,7 +143,7 @@ You can get `name`, `decimals`, `icon` and other parameters by calling the next
 
 To follow this guide, please check the [step by step instructions](/docs/tutorials/create-transactions#low-level----create-a-transaction) on how to create a transaction first.
 
-In order to send a fungible token to an account, the receiver must have a storage deposit. This is because each smart contract on NEAR must account for storage used, and each account on a fungible token contract is a key-value pair, taking up a small amount of storage. For more information, please see [how storage works in NEAR](/docs/concepts/storage-staking). To check if account has deposited the storage for this FT do the following:
+In order to send a fungible token to an account, the receiver must have a storage deposit. This is because each smart contract on NEAR must account for storage used, and each account on a fungible token contract is a key-value pair, taking up a small amount of storage. For more information, please see [how storage works in NEAR](/concepts/storage/storage-staking). To check if account has deposited the storage for this FT do the following:
 
 Get storage balance of the account. `storage_balance_of` function returns the amount of deposited storage or `null` if there is no deposit.
   - using NEAR CLI:
