Move chain abstraction to a single folder (#2482)

* move content

* fix anchors

* fix links

blog/2024-04-24.md

@@ -15,7 +15,7 @@ hide_table_of_contents: true
 ## Organic growth
 Our documentation is the result of multiple people collaborating across the span of four very active years, and it has seen a lot of changes: [2942 commits and counting](https://github.com/near/docs/commits/master/).
 
-In the beginning, our docs only needed to explain how to create [smart contracts](/build/smart-contracts/what-is), and how to [interact with them through a frontend](/build/web3-apps/quickstart). Fast forward to today, and we have more than 200 pages of documentation, covering topics such as [chain abstraction](/build/chain-abstraction/what-is), [data infrastructure](/build/data-infrastructure/what-is), and [primitives such as NFT, FT](/build/primitives/what-is).
+In the beginning, our docs only needed to explain how to create [smart contracts](/build/smart-contracts/what-is), and how to [interact with them through a frontend](/build/web3-apps/quickstart). Fast forward to today, and we have more than 200 pages of documentation, covering topics such as [chain abstraction](/chain-abstraction/what-is), [data infrastructure](/build/data-infrastructure/what-is), and [primitives such as NFT, FT](/build/primitives/what-is).
 
 The best thing is that new features are released every single month. However, all progress comes at a cost, and as our ecosystem grew, so did the disorganization of our documentation.
 

blog/2024-05-15.md

@@ -24,7 +24,7 @@ As an added bonus, trades are atomic across chains, settlement takes just 2 seco
 :::tip Keep in mind
 
  There are transactions happening on different blockchains.
- The difference is that a [Multi-Party Computation service](/concepts/abstraction/chain-signatures#multi-party-computation-service) (MPC) signs a transaction for you, and that transaction is then broadcast to another blockchain RPC node or API.
+ The difference is that a [Multi-Party Computation service](/chain-abstraction/chain-signatures#multi-party-computation-service) (MPC) signs a transaction for you, and that transaction is then broadcast to another blockchain RPC node or API.
 
 :::
 

blog/2024-05-30.md

@@ -23,7 +23,7 @@ There is also a new documentation page on [Yield and Resume](/build/smart-contra
 ## The problem of waiting
 Currently, smart contracts have no way to wait for an external event to happen. This can be a problem when the contract relies on an external service to provide a result.
 
-We encountered this issue while implementing [Chain Signatures](/concepts/abstraction/chain-signatures), which work by requiring an external service to provide a signature.
+We encountered this issue while implementing [Chain Signatures](/chain-abstraction/chain-signatures), which work by requiring an external service to provide a signature.
 
 Until now, the only workaround has been to make the contract call itself in a loop, checking on each iteration if the result is ready. Each call delays the result by one block (~1 second), allowing the contract to wait almost a minute before running out of gas.
 

blog/2024-08-13.md

@@ -33,7 +33,7 @@ The Infrastructure Committee feels that Pagoda's fully-subsidized near.org RPC s
 
 ### Chain Abstraction Services
 
-[Chain Signatures](https://docs.near.org/concepts/abstraction/chain-signatures), Multichain Gas Relayer, and [FastAuth](https://docs.near.org/build/chain-abstraction/fastauth-sdk) will continue to be developed by Pagoda, then will be taken over by the new Chain Abstraction / Multichain spinout from Pagoda and Proximity. More information will be shared in September or October 2024.
+[Chain Signatures](https://docs.near.org/chain-abstraction/chain-signatures), Multichain Gas Relayer, and [FastAuth](https://docs.near.org/chain-abstraction/fastauth-sdk) will continue to be developed by Pagoda, then will be taken over by the new Chain Abstraction / Multichain spinout from Pagoda and Proximity. More information will be shared in September or October 2024.
 
 ### Pagoda Operations & Ecosystem Services
 

blog/2025-01-01.md

@@ -39,7 +39,7 @@ To keep the sidebar clean, we added a `What is...` page for each major topic, wh
 For example, we now have the following pages:
 
 - [What is NEAR Protocol?](/concepts/basics/protocol)
-- [What is Chain Abstraction?](/build/chain-abstraction/what-is)
+- [What is Chain Abstraction?](/chain-abstraction/what-is)
 - [What is a Smart Contract?](/build/smart-contracts/what-is)
 
 ## Code Explainer
@@ -68,7 +68,7 @@ Every page is full of snippets that explain how to leverage each primitive from
 
 ### Chain Abstraction
 
-We also added a section about [Chain Abstraction](/build/chain-abstraction/what-is), which explains how NEAR accounts can be used to control accounts on other chains.
+We also added a section about [Chain Abstraction](/chain-abstraction/what-is), which explains how NEAR accounts can be used to control accounts on other chains.
 
 ![alt text](/docs/blog/2024-review/2024-blog-4.jpg)
 _Did you know you can control Ethereum and Bitcoin accounts from NEAR?_

docs/1.concepts/basics/protocol.md

@@ -38,7 +38,7 @@ NEAR is a technical marvel, offering built-in features such as named accounts an
 3. Transactions are **fast** _(~1.3s transactions)_ and **cheap** _(< 1¢ in fees)_
 4. You don't need to buy crypto thanks to **built-in account abstraction**
 5. [Access Keys](../protocol/access-keys.md) make it safe and easy to use
-6. Control accounts on **other chains** thanks to [chain signatures](../abstraction/chain-signatures.md)
+6. Control accounts on **other chains** thanks to [chain signatures](../../chain-abstraction/chain-signatures.md)
 
 ### 🛡️ Battle-Tested
 

docs/2.build/2.smart-contracts/release/deploy.md

@@ -118,7 +118,7 @@ Considering this, we advise to name methods using `snake_case` in all SDKs as th
 ---
 
 ## Initializing the Contract
-If your contract has an [initialization method](/build/smart-contracts/anatomy/storage#initializing-the-state) you can call it to
+If your contract has an [initialization method](../anatomy/storage.md) you can call it to
 initialize the state. This is not necessary if your contract implements `default` values for the state.
 
 <Tabs groupId="cli-tabs">

docs/2.build/2.smart-contracts/release/upgrade.md

@@ -11,7 +11,7 @@ allowing the code to be changed.
 
 Contract's can be updated in two ways:
 
-1. **Through tools** such as [NEAR CLI](../../../4.tools/cli.md) or the 
+1. **Through tools** such as [NEAR CLI](../../../4.tools/cli.md) or the
    [NEAR API](../../../4.tools/near-api.md) (if you hold
    the account's
    [full access key](../../../1.concepts/protocol/access-keys.md)).
@@ -244,7 +244,7 @@ state, removes the `payments` vector and adds the information to the
 </CodeTabs>
 
 Notice that `migrate` is actually an
-[initialization method](/build/smart-contracts/anatomy/storage#initializing-the-state)
+[initialization method](../anatomy/storage.md)
 that **ignores** the existing state (`[#init(ignore_state)]`), thus being able
 to execute and rewrite the state.
 

docs/2.build/4.web3-apps/integrate-contracts.md

@@ -253,7 +253,7 @@ If the method invoked returned a result, you can use the transaction hash to ret
 const txHash = new URLSearchParams(window.location.search).get('transactionHashes');
 ```
 
-Assuming you created the `near` object as in the [example above](#connecting-to-a-contract), then you query the result by utilizing:
+Assuming you created the `near` object as in the [example above](#calling-change-methods), then you query the result by utilizing:
 
 <CodeTabs>
   <Language value="js" language="js">

docs/3.tutorials/examples/update.md

@@ -34,7 +34,7 @@ The migration method deserializes the current state (`OldState`) and iterates th
 to the new `PostedMessage` that includes the `payment` field.
 
 :::tip
-Notice that migrate is actually an [initialization method](/build/smart-contracts/anatomy/storage#initializing-the-state) that ignores the existing state (`[#init(ignore_state)]`), thus being able to execute and rewrite the state.
+Notice that migrate is actually an [initialization method](../../2.build/2.smart-contracts/anatomy/storage.md) that ignores the existing state (`[#init(ignore_state)]`), thus being able to execute and rewrite the state.
 :::
 
 ---

docs/6.integrations/create-transactions.md

@@ -18,7 +18,7 @@ At the core, all transactions require the following:
 - `actions` _( [[click here]](/concepts/protocol/transaction-anatomy#actions) for supported arguments)_
 - `blockHash` _(a current block hash (within 24hrs) to prove the transaction was recently created)_
 
-See [Transaction Class](https://near.github.io/near-api-js/classes/near_api_js.transaction.Transaction.html) for a more in depth outline.
+See [Transaction Class](https://near.github.io/near-api-js/classes/near-api-js.transaction.Transaction.html) for a more in depth outline.
 
 ---
 
@@ -289,7 +289,7 @@ const publicKey = keyPair.getPublicKey();
 
 - A unique number or `nonce` is required for each transaction signed with an access key.
 - To ensure a unique number is created for each transaction, the current `nonce` should be queried and then incremented by 1.
-- Current nonce can be retrieved using the `provider` we [created earlier](#setting-up-a-connection-to-near-1).
+- Current nonce can be retrieved using the `provider` we [created earlier](#setting-up-a-connection-to-near).
 
 ```js
 const accessKey = await provider.query(
@@ -394,7 +394,7 @@ const signedTransaction = new nearAPI.transactions.SignedTransaction({
 Final step is to encode and send the transaction.
 
 - First we serialize transaction into [Borsh](https://borsh.io/), and store the result as `signedSerializedTx`. _(required for all transactions)_
-- Then we send the transaction via [RPC call](/api/rpc/introduction) using the `sendJsonRpc()` method nested inside [`near`](#setting-up-connection-to-near-1).
+- Then we send the transaction via [RPC call](/api/rpc/introduction) using the `sendJsonRpc()` method nested inside [`near`](#setting-up-a-connection-to-near).
 
 ```js
 // encodes transaction to serialized Borsh (required for all transactions)

docs/2.build/1.chain-abstraction/chain-signatures/getting-started.md → docs/chain-abstraction/chain-signatures/getting-started.md

@@ -22,7 +22,7 @@ _Chain signatures flow_
 
 #### 1. Deriving Foreign Addresses
 
-Chain Signatures uses [derivation paths](../../../1.concepts/abstraction/chain-signatures.md#derivation-paths-one-account-multiple-chains) to represent accounts on foreign blockchains
+Chain Signatures uses [derivation paths](../chain-signatures.md#derivation-paths-one-account-multiple-chains) to represent accounts on foreign blockchains
 
 The NEAR account’s name and the derivation path are used to mathematically derive a unique address for the user on the foreign blockchain
 

docs/2.build/1.chain-abstraction/chain-signatures/chain-signatures.md → docs/chain-abstraction/chain-signatures/implementation.md

@@ -1,5 +1,5 @@
 ---
-id: chain-signatures
+id: implementation
 title: Implementing Chain Signatures
 ---
 
@@ -55,7 +55,7 @@ If you want to try things out, these are the smart contracts available on `testn
 
 ## 1. Deriving the Foreign Address
 
-Chain Signatures use [`derivation paths`](/concepts/abstraction/chain-signatures#derivation-paths-one-account-multiple-chains) to represent accounts on the target blockchain. The external address to be controlled can be deterministically derived from:
+Chain Signatures use [`derivation paths`](../chain-signatures.md#derivation-paths-one-account-multiple-chains) to represent accounts on the target blockchain. The external address to be controlled can be deterministically derived from:
 
 - The NEAR address (e.g., `example.near`, `example.testnet`, etc.)
 - A derivation path (a string such as `ethereum-1`, `ethereum-2`, etc.)
@@ -112,7 +112,7 @@ Constructing the transaction to be signed (transaction, message, data, etc.) var
   <!-- In Ethereum, constructing the transaction is simple since you only need to specify the address of the receiver, and any necessary data for the transaction. -->
       <Github language="js"
       url="https://github.com/near-examples/near-multichain/blob/main/src/components/EVM/FunctionCall.jsx"
-      start="30" end="39" 
+      start="30" end="39"
       fname="FunctionCall.jsx"/>
        <Github language="js"
       url="https://github.com/near-examples/near-multichain/blob/main/src/components/EVM/Transfer.jsx"
@@ -236,7 +236,7 @@ Once we have reconstructed the signature, we can relay it to the corresponding n
 </Tabs>
 
 :::info
-⭐️ For a deep dive into the concepts of Chain Signatures see [What are Chain Signatures?](/concepts/abstraction/chain-signatures)
+⭐️ For a deep dive into the concepts of Chain Signatures see [What are Chain Signatures?](../chain-signatures.md)
 
 ⭐️ For complete examples of a NEAR account performing Eth transactions:
 

docs/2.build/1.chain-abstraction/meta-transactions.md → docs/chain-abstraction/meta-transactions.md

@@ -1,7 +1,7 @@
 ---
-id: meta-transactions
+id: meta-transactions-relayer
 title: Building a Meta Transaction Relayer
-sidebar_label: Meta Transaction Relayers
+sidebar_label: Building a Relayer
 ---
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
@@ -195,13 +195,13 @@ Check the [Use cases section](#use-cases) for example configuration files corres
 
 You can follow these steps to set up your local Relayer server development environment:
 
-1. [Install Rust for NEAR Development](../2.smart-contracts/quickstart.md#prerequisites)
-2. If you don't have a NEAR account, [create one](../../1.concepts/protocol/account-model.md)
+1. [Install Rust for NEAR Development](../2.build/2.smart-contracts/quickstart.md#prerequisites)
+2. If you don't have a NEAR account, [create one](../1.concepts/protocol/account-model.md)
 3. With the account from step 2, create a JSON file in this directory in the format
    ```js
    [{"account_id":"example.testnet","public_key":"ed25519:98GtfFzez3opomVpwa7i4m3nptHtc7Ha514XHMWszLtQ","private_key":"ed25519:YWuyKVQHE3rJQYRC3pRGV56o1qEtA1PnMYPDEtroc5kX4A4mWrJwF7XkzGe7JWNMABbtY4XFDBJEzgLyfPkwpzC"}]
    ```
-   using a [Full Access Key](../../1.concepts/protocol/access-keys.md#full-access-keys) from an account that has enough NEAR to cover the gas costs of transactions your server will be relaying. Usually, this will be a copy of the json file found in the `.near-credentials` directory.
+   using a [Full Access Key](../1.concepts/protocol/access-keys.md#full-access-keys) from an account that has enough NEAR to cover the gas costs of transactions your server will be relaying. Usually, this will be a copy of the json file found in the `.near-credentials` directory.
 4. Update values in `config.toml`
 5. Open up the `port` from `config.toml` in your machine's network settings
 6. Run the server using `cargo run`.

docs/1.concepts/abstraction/meta-tx.md → docs/chain-abstraction/meta-tx.md

@@ -58,7 +58,7 @@ In the example visualized above, the payment is done using $FT. Together with
 the transfer to John, Alice also adds an action to pay 0.1 $FT to the relayer.
 The relayer checks the content of the `SignedDelegateAction` and only processes
 it if this payment is included as the first action. In this way, the relayer
-will be paid in the same transaction as John. 
+will be paid in the same transaction as John.
 
 :::warning Keep in mind
 The payment to the relayer is still not guaranteed. It could be that
@@ -84,12 +84,12 @@ atomicity guarantee and no roll-back mechanism.
 
 <hr class="subsection" />
 
-### Accounts must be initialized 
+### Accounts must be initialized
 
 Any transaction, including meta transactions, must use NONCEs to avoid replay
 attacks. The NONCE must be chosen by Alice and compared to a NONCE stored on
 chain. This NONCE is stored on the access key information that gets initialized
-when creating an account. 
+when creating an account.
 
 ---
 
@@ -161,7 +161,7 @@ but will fail on Bob's shard.
 
 ## Function Call Access Keys in Meta Transactions
 
-[Function Call Access Keys](../protocol/access-keys.md#function-call-keys)
+[Function Call Access Keys](../1.concepts/protocol/access-keys.md#function-call-keys)
 are limited to signing transactions for specific methods on a specific contract.
 
 

docs/1.concepts/abstraction/relayers.md → docs/chain-abstraction/relayers.md

@@ -3,7 +3,7 @@ id: relayers
 title: Relayers
 ---
 
-A relayer is a simple web service that receives signed transactions from NEAR users, and relays them to the network while attaching tokens to sponsor their GAS expenses. This can be useful to create applications in which the users are not required to purchase NEAR in order to be able to transact. In this document we present a high-level overview on how relayers work. Please check the [build a relayer](../../2.build/1.chain-abstraction/meta-transactions.md) page if you want to learn how to build your own relayer.
+A relayer is a simple web service that receives signed transactions from NEAR users, and relays them to the network while attaching tokens to sponsor their GAS expenses. This can be useful to create applications in which the users are not required to purchase NEAR in order to be able to transact. In this document we present a high-level overview on how relayers work. Please check the [build a relayer](meta-transactions.md) page if you want to learn how to build your own relayer.
 
 ---
 

docs/2.build/1.chain-abstraction/wallet.md → docs/chain-abstraction/wallet.md

@@ -10,7 +10,7 @@ You'll also learn how to ensure that a signature on one chain is not used to tak
 
 ### Key derivation
 
-When signing using [chain signatures](./chain-signatures/chain-signatures.md) each account has an unlimited number of keys. Each key's public key is derived from the account name and the key extension which is an arbitrary string.
+When signing using [chain signatures](./chain-signatures/implementation.md) each account has an unlimited number of keys. Each key's public key is derived from the account name and the key extension which is an arbitrary string.
 
 User's keys can be described as follow: