Fix more broken anchors

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

@@ -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-keys)
+[Function Call Access Keys](../protocol/access-keys.md#function-call-keys)
 are limited to signing transactions for specific methods on a specific contract.
 
 
@@ -175,4 +175,4 @@ make the call, the action is executed.
 
 The allowance however is not checked, as all costs have been covered by the
 relayer. Hence, the action will be executed even if the allowance is insufficient
-to cover the costs.
+to cover the costs.

docs/2.build/5.primitives/ft/bos/check-balance.md

@@ -1,5 +1,5 @@
 :::info
-Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [above](#querying-metadata).
+Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [here](/build/primitives/ft/bos/get-metadata).
 :::
 
 ```js

docs/2.build/5.primitives/ft/web-app/check-balance.md

@@ -1,7 +1,7 @@
 
 
 :::info
-Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [above](#querying-metadata).
+Remember about fungible token precision. You may need this value to show a response of balance requests in an understandable-to-user way in your app. How to get precision value (decimals) you may find [here](/build/primitives/ft/web-app/get-metadata).
 :::
 
 ```js

docs/3.tutorials/fts/1-skeleton.md

@@ -35,7 +35,7 @@ The repository comes with many different folders. Each folder represents a diffe
 
 | File                             | Description                                                                      |
 | -------------------------------- | -------------------------------------------------------------------------------- |
-| [ft_core.rs](#corers)       | Contains the logic for transferring and controlling FTs. This file represents the implementation of the [core](https://nomicon.io/Standards/Tokens/FungibleToken/Core) standard. |              |
+| [ft_core.rs](#ft_corers)       | Contains the logic for transferring and controlling FTs. This file represents the implementation of the [core](https://nomicon.io/Standards/Tokens/FungibleToken/Core) standard. |              |
 | [lib.rs](#librs)                 | Holds the smart contract initialization functions and dictates what information is kept on-chain.                               |
 | [metadata.rs](#metadatars)       | Defines the metadata structure. This file represents the implementation of the [metadata](https://nomicon.io/Standards/Tokens/FungibleToken/Metadata) extension of the standard.                                      |
 | [storage.rs](#storagers)               | Contains the logic for registration and storage.  This file represents the implementation of the [storage management](https://nomicon.io/Standards/StorageManagement) standard.                                                   |

docs/3.tutorials/fts/5.transfers.md

@@ -369,7 +369,7 @@ Hurray! At this point, your FT contract is fully complete and all the functional
 
 ## Conclusion
 
-In this tutorial, you learned how to expand a FT contract by adding ways for users to transfer FTs. You [broke down](#introduction) the problem into smaller, more digestible subtasks and took that information and implemented both the [FT transfer](#transfer-function) and [FT transfer call](#transfer-call-function) functions. In addition, you deployed another [contract](#redeploying-contract) and [tested](#testing-changes) the transfer functionality.
+In this tutorial, you learned how to expand a FT contract by adding ways for users to transfer FTs. You [broke down](#introduction) the problem into smaller, more digestible subtasks and took that information and implemented both the [FT transfer](#transfer-function) and [FT transfer call](#transfer-call-function) functions. In addition, you deployed another [contract](#redeploying-contract) and [tested](#testing-the-transfer-function) the transfer functionality.
 
 In the [next tutorial](/tutorials/fts/marketplace), you'll learn about how an NFT marketplace can operate to purchase NFTs by using Fungible Tokens.
 

docs/3.tutorials/nfts/5-approval.md

@@ -585,13 +585,13 @@ Today you went through a lot of logic to implement the [approvals extension](htt
 
 First, you explored the [basic approach](#allow-an-account-to-transfer-your-nft) of how to solve the problem. You then went through and discovered some of the [problems](#the-problem) with that solution and learned how to [fix it](#the-solution).
 
-After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-the-token-and-jsontoken-structs) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts) and saw how [marketplaces](#marketplace-integrations) are integrated.
+After understanding what you should do to implement the approvals extension, you started to [modify](#expanding-the-token-and-jsontoken-structs) the JsonToken and Token structs in the contract. You then implemented the logic for [approving accounts](#approving-accounts).
 
 After implementing the logic behind approving accounts, you went and [changed the restrictions](#changing-the-restrictions-for-transferring-nfts) needed to transfer NFTs. The last step you did to finalize the approving logic was to go back and edit the [nft_core](#changes-to-nft_corers) files to be compatible with the new changes.
 
 At this point, everything was implemented in order to allow accounts to be approved and you extended the functionality of the [core standard](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core) to allow for approved accounts to transfer tokens.
 
-You implemented a view method to [check](#check-if-an-account-is-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-a-ann-account) as well as [revoke all accounts](#revoke-all-accounts).
+You implemented a view method to [check](#check-if-an-account-is-approved) if an account is approved and to finish the coding portion of the tutorial, you implemented the logic necessary to [revoke an account](#revoke-an-account) as well as [revoke all accounts](#revoke-all-accounts).
 
 After this, the contract code was finished and it was time to move onto testing where you created an [account](#deployment-and-initialization) and tested the [approving](#approving-an-account) and [transferring](#transferring-the-nft) for your NFTs.
 

docs/6.integrations/create-transactions.md

@@ -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).
+- Current nonce can be retrieved using the `provider` we [created earlier](#setting-up-a-connection-to-near-1).
 
 ```js
 const accessKey = await provider.query(