Nialexsan/fix anchors

.github/workflows/deploy.yml

@@ -20,7 +20,7 @@ jobs:
       - uses: actions/checkout@v3
       - uses: actions/setup-node@v3
         with:
-          node-version: 18
+          node-version: 20
           cache: yarn
 
       - name: Install Yarn

.github/workflows/test-deploy.yml

@@ -15,7 +15,7 @@ jobs:
       - uses: actions/checkout@v3
       - uses: actions/setup-node@v3
         with:
-          node-version: 18
+          node-version: 20
           cache: yarn
 
       - name: Install Yarn

docs/build/basics/transactions.md

@@ -1,6 +1,9 @@
 ---
 sidebar_position: 3
-keywords: [Flow Transaction Speed, Flow Transaction Time, Transactions on Flow]
+keywords: 
+  - Flow Transaction Speed
+  - Flow Transaction Time
+  - Transactions on Flow
 ---
 
 # Transactions
@@ -19,7 +22,7 @@ In order for a transaction to be valid and executed it must contain signatures f
 
 ![Screenshot 2023-08-17 at 14.52.56.png](_transactions_images/Screenshot_2023-08-17_at_14.52.56.png)
 
-**Script**
+#### Script
 
 The script section contains instructions for transaction execution. This is a Cadence program in source code form (human-readable), and encoded as UTF-8. The transaction program must contain a `transaction` declaration. 
 
@@ -40,19 +43,19 @@ transaction(greeting: String) {
 }
 ```
 
-**Arguments**
+#### Arguments
 
 Transactions may declare parameters it needs during execution, these must be provided as input arguments when sending a transaction. You can think of them as function arguments. Currently, we provide [arguments in the JSON-Cadence Data Interchange Format](https://cadencelang.dev/docs/1.0/json-cadence-spec). Which is a human-readable JSON format. The sample script from above accepts a single `String` argument.
 
-**Reference Block**
+#### Reference Block
 
 A reference to a recent block used for expiry. A transaction is considered expired if it is submitted to Flow after reference block height + N, where N is a constant defined by the network. On mainnet current setting for N is 600 which amounts to approximately 10 minutes for expiry (please note this is subject to change).
 
-**Gas Limit**
+#### Gas Limit
 
 When a transaction is executed each operation consumes a predefined amount of computational units (we define more about that in the Fees documentation). This defines the maximum amount of computation that is allowed to be done during this transaction. If a transaction completes execution using fewer computational units than the limit, it remains unaffected. However, if it hits this limit during execution, the transaction will fail, its changes will be reverted, but fees will still be applied. The maximum computational limit for Flow mainnet is currently at 9999, but this might change. The maximum network limit is defined to protect the network from transactions that would run forever. 
 
-**Proposal Key**
+#### Proposal Key
 
 Each transaction must declare a proposal key, which can be an account key from any Flow account (App, User or Wallet). The account that owns the proposal key is referred to as the *proposer*. 
 
@@ -66,7 +69,7 @@ A proposal key definition declares the address, key ID, and up-to-date sequence
 - Key ID is an index number (starting at 0) that identifies the key on the account provided in the address.
 - Sequence Number is a number on each key that increments by 1 with each transaction. This ensures that each transaction executes at most once and prevents many unwanted situations, such as [transaction replay attacks](https://en.wikipedia.org/wiki/Replay_attack). Each key in an account has a dedicated sequence number associated with it. Unlike Ethereum, there is no sequence number for the entire account.
 
-**Authorizers**
+#### Authorizers
 
 Authorizers are accounts that authorize a transaction to read and mutate their state. A transaction can specify zero or more authorizers, depending on how many accounts the transaction needs to access.
 
@@ -90,7 +93,7 @@ that are required for the transaction to execute properly.
 This ensures that users who are signing transactions can understand
 what parts of their account a transaction can access.
 
-**Payer**
+#### Payer
 
 A payer is the account that pays the fees for the transaction. A transaction must specify exactly one payer. The payer is only responsible for paying the network and gas fees; the transaction is not authorized to access resources or code stored in the payer account. 
 

docs/build/core-contracts/06-staking-contract-reference.md

@@ -4,7 +4,7 @@ sidebar_position: 6
 sidebar_label: Staking Table
 ---
 
-# Contract
+## Contract
 
 The `FlowIDTableStaking` contract is the central table that manages staked nodes, delegation and rewards.
 
@@ -17,13 +17,13 @@ Source: [FlowIDTableStaking.cdc](https://github.com/onflow/flow-core-contracts/b
 | Testnet                   | `0x9eca2b38b18b5dfe` |
 | Mainnet                   | `0x8624b52f9ddcd04a` |
 
-# Transactions and Scripts
+## Transactions and Scripts
 
 Transactions for the staking contract are in the `flow-core-contracts` repo.
 Developers and users are advised to use [the staking collection transactions](../../networks/staking/14-staking-collection.md)
 to stake tokens instead of the basic transactions that are used for tests.
 
-## Getting Staking Info with Scripts
+### Getting Staking Info with Scripts
 
 These scripts are read-only and get info about the current state of the staking contract.
 
@@ -41,12 +41,12 @@ These scripts are read-only and get info about the current state of the staking
 | **`SC.10`** | Get All Info about a single Delegator      | [idTableStaking/delegation/get_delegator_info.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/delegation/get_delegator_info.cdc)                                       |
 | **`SC.11`** | Get a node's total Commitment              | [idTableStaking/get_node_total_commitment_without_delegators.cdc](https://github.com/onflow/flow-core-contracts/blob/master/transactions/idTableStaking/scripts/get_node_total_commitment_without_delegators.cdc) |
 
-## Delegator Transactions
+### Delegator Transactions
 
 Documentation for delegating with tokens is described in the staking documentation
 for [the staking collection](../../networks/staking/14-staking-collection.md)
 
-# Events
+## Events
 
 The `FlowIDTableStaking` contract emits an event whenever an important action occurs.
 See the [staking events Documentation](../../networks/staking/07-staking-scripts-events.md) for more information about each event.

docs/build/core-contracts/10-nft-storefront.md

@@ -74,15 +74,15 @@ The `NFTStorefrontV2` contract doesn’t support selling an NFT for multiple dif
 
 ![scenario_1](./scenario_1.png)
 
-Putting an NFT on sell called listing, seller can create a listing using [sell_item](https://github.com/onflow/nft-storefront/blob/main/transactions/sell_item.cdc) transaction by providing some required details to list an NFT, i.e. Receiving currency type, [Capability](https://cadence-lang.org/docs/language/capabilities) from where NFT will be deducted etc. If interested look [here](<#fun-createListing()>) for more details.
+Putting an NFT on sell called listing, seller can create a listing using [sell_item](https://github.com/onflow/nft-storefront/blob/main/transactions/sell_item.cdc) transaction by providing some required details to list an NFT, i.e. Receiving currency type, [Capability](https://cadence-lang.org/docs/language/capabilities) from where NFT will be deducted etc. If interested look [here](<#fun-createlisting>) for more details.
 
 To receive a different currency seller has to provide a different **Receiver currency type** , i.e. `salePaymentVaultType` As depicted in the above diagram, There are two listing formations with almost the same inputs. The only differentiator is the `salePaymentVaultType` parameter that needs to be different when creating duplicate NFT listings with different sale currency types.
 
 ### **Scenario 2:** Peer-to-Peer (p2p) listing of NFT: A listing anyone can fulfil.
 
 Dapps can leverage the **NFTStorefrontV2** to facilitate the creation of a listing for the seller independent of any marketplace. Dapps or marketplaces can list those listings on their platforms, or seller can settle it p2p.
 
-The seller can use [sell_item](https://github.com/onflow/nft-storefront/blob/main/transactions/sell_item.cdc) transaction to create a p2p listing, providing the `marketplacesAddress` with an empty array. The seller has a choice of providing [commission](#commission) to the facilitator of sale, which can also act as a discount if the facilitator and the purchaser are the same.
+The seller can use [sell_item](https://github.com/onflow/nft-storefront/blob/main/transactions/sell_item.cdc) transaction to create a p2p listing, providing the `marketplacesAddress` with an empty array. The seller has a choice of providing [commission](#enabling-marketplace-commissions-for-nft-sales) to the facilitator of sale, which can also act as a discount if the facilitator and the purchaser are the same.
 
 ### **Scenario 3:** The seller wants to list its NFT in different marketplaces.
 
@@ -179,7 +179,7 @@ An interface providing a useful public interface to a Listing.
 
 ### Functions
 
-**fun `borrowNFT()`**
+#### **fun `borrowNFT()`**
 
 ```cadence
 fun borrowNFT(): &NonFungibleToken.NFT?
@@ -190,7 +190,7 @@ if the NFT is absent, for example if it has been sold via another listing.
 
 ---
 
-**fun `purchase()`**
+#### **fun `purchase()`**
 
 ```cadence
 fun purchase(payment FungibleToken.Vault, commissionRecipient Capability<&{FungibleToken.Receiver}>?): NonFungibleToken.NFT
@@ -202,7 +202,7 @@ Respective saleCuts are transferred to beneficiaries and funtion return underlyi
 
 ---
 
-**fun `getDetails()`**
+#### **fun `getDetails()`**
 
 ```cadence
 fun getDetails(): ListingDetails
@@ -212,7 +212,7 @@ Fetches the details of the listings
 
 ---
 
-**fun `getAllowedCommissionReceivers()`**
+#### **fun `getAllowedCommissionReceivers()`**
 
 ```cadence
 fun getAllowedCommissionReceivers(): [Capability<&{FungibleToken.Receiver}>]?
@@ -262,7 +262,7 @@ fun init()
 
 ### Functions
 
-**fun `createListing()`**
+#### **fun `createListing()`**
 
 ```cadence
 fun createListing(nftProviderCapability Capability<&{NonFungibleToken.Provider, NonFungibleToken.CollectionPublic}>, nftType Type, nftID UInt64, salePaymentVaultType Type, saleCuts [SaleCut], marketplacesCapability [Capability<&{FungibleToken.Receiver}>]?, customID String?, commissionAmount UFix64, expiry UInt64): UInt64
@@ -273,7 +273,7 @@ Create and publish a Listing for an NFT.
 
 ---
 
-**fun `removeListing()`**
+#### **fun `removeListing()`**
 
 ```cadence
 fun removeListing(listingResourceID UInt64)
@@ -284,7 +284,7 @@ Remove a Listing that has not yet been purchased from the collection and destroy
 
 ---
 
-**fun `getListingIDs()`**
+#### **fun `getListingIDs()`**
 
 ```cadence
 fun getListingIDs(): [UInt64]
@@ -295,7 +295,7 @@ Returns an array of the Listing resource IDs that are in the collection
 
 ---
 
-**fun `getDuplicateListingIDs()`**
+#### **fun `getDuplicateListingIDs()`**
 
 ```cadence
 fun getDuplicateListingIDs(nftType Type, nftID UInt64, listingID UInt64): [UInt64]
@@ -306,7 +306,7 @@ Returns an array of listing IDs that are duplicates of the given `nftType` and `
 
 ---
 
-**fun `cleanupExpiredListings()`**
+#### **fun `cleanupExpiredListings()`**
 
 ```cadence
 fun cleanupExpiredListings(fromIndex UInt64, toIndex UInt64)
@@ -317,7 +317,7 @@ Cleanup the expired listing by iterating over the provided range of indexes.
 
 ---
 
-**fun `borrowListing()`**
+#### **fun `borrowListing()`**
 
 ```cadence
 fun borrowListing(listingResourceID: UInt64): &{ListingPublic}?
@@ -347,7 +347,7 @@ in a Storefront.
 
 ### Functions
 
-**fun `getListingIDs()`**
+#### **fun `getListingIDs()`**
 
 ```cadence
 fun getListingIDs(): [UInt64]
@@ -357,7 +357,7 @@ getListingIDs Returns an array of the Listing resource IDs that are in the colle
 
 ---
 
-**fun `getDuplicateListingIDs()`**
+#### **fun `getDuplicateListingIDs()`**
 
 ```cadence
 fun getDuplicateListingIDs(nftType Type, nftID UInt64, listingID UInt64): [UInt64]
@@ -367,7 +367,7 @@ getDuplicateListingIDs Returns an array of listing IDs that are duplicates of th
 
 ---
 
-**fun `borrowListing()`**
+#### **fun `borrowListing()`**
 
 ```cadence
 fun borrowListing(listingResourceID UInt64): &Listing{ListingPublic}?
@@ -377,7 +377,7 @@ borrowListing Returns a read-only view of the listing for the given listingID if
 
 ---
 
-**fun `cleanupExpiredListings()`**
+#### **fun `cleanupExpiredListings()`**
 
 ```cadence
 fun cleanupExpiredListings(fromIndex UInt64, toIndex UInt64)
@@ -387,7 +387,7 @@ cleanupExpiredListings Cleanup the expired listing by iterating over the provide
 
 ---
 
-**fun `cleanupPurchasedListings()`**
+#### **fun `cleanupPurchasedListings()`**
 
 ```cadence
 fun cleanupPurchasedListings(listingResourceID: UInt64)
@@ -398,7 +398,7 @@ Allows anyone to remove already purchased listings.
 
 ---
 
-**fun `getExistingListingIDs()`**
+#### **fun `getExistingListingIDs()`**
 
 ```cadence
 fun getExistingListingIDs(nftType Type, nftID UInt64): [UInt64]

docs/build/guides/account-linking/child-accounts.md

@@ -107,7 +107,7 @@ in a way that allows the receiving account to maintain that Capability and allow
 either end of the linkage - the user's main "parent" account and the linked "child" account. This is accomplished in the
 `HybridCustody` contract which we'll continue to use in this guidance.
 
-### Pre-requisitess
+### Pre-requisites
 
 Since account delegation is mediated by developer-defined rules, you should make sure to first configure the resources
 that contain those rules. Contracts involved in defining and enforcing this ruleset are

docs/build/guides/mobile/react-native-quickstart.md

@@ -299,7 +299,7 @@ In the `args` section, we are simply passing it our user's account address from
 
 Go ahead and click the "Send Query" button. You should see "No Profile." That's because we haven't initialized the account yet.
 
-## Initializing the Account
+## Initializing an Account
 
 For the Profile contract to store a Profile in a user's account, it does so by initializing what is called a "resource." A resource is an ownable piece of data and functionality that can live in the user's account storage. This paradigm is known is as "resource-oriented-programming", a principle that is core to Cadence and differentiates its ownership model from other smart contract languages, [read more here](https://cadence-lang.org/docs/#intuiting-ownership-with-resources). Cadence makes it so that resources can only exist in one place at any time, they must be deliberately created, cannot be copied, and if desired, must be deliberately destroyed.
 

docs/build/smart-contracts/overview.md

@@ -38,7 +38,7 @@ Permanence is a key property of blockchains; users trust that the data they stor
 
 ### Storage Limits & Fees
 
-However, there are practical constraints to storing data on a blockchain. Developer and user accounts must retain a small amount of FLOW tokens, known as the storage fee, for bytes of data stored in their accounts. The minimum storage fee will grant each account a minimum storage amount. If an account holds assets that demand more bytes of storage, the account will need to retain more FLOW tokens to increase the storage amount according to Flow's [fee schedule](../basics/fees.md#fees). A more compact data model can keep storage needs down. \
+However, there are practical constraints to storing data on a blockchain. Developer and user accounts must retain a small amount of FLOW tokens, known as the storage fee, for bytes of data stored in their accounts. The minimum storage fee will grant each account a minimum storage amount. If an account holds assets that demand more bytes of storage, the account will need to retain more FLOW tokens to increase the storage amount according to Flow's [fee schedule](../basics/fees.md#storage). A more compact data model can keep storage needs down. \
  \
 Furthermore, a single Flow transaction has a size limit of 4MB, which limits the rate at which large amounts of data can be transferred to the blockchain.
 

docs/networks/node-ops/access-onchain-data/access-nodes/access-node-setup.mdx → docs/networks/node-ops/access-onchain-data/access-nodes/access-node-setup.md

@@ -32,7 +32,7 @@ In order to join the network at epoch N+1, the access node **must** be registere
 Currently on mainnet, the staking auction starts every Wednesday at around 20:00 UTC and ends on the next Wednesday at around 12:00 UTC.
 Since this deadline may shift slightly from epoch to epoch, we recommend the node be staked by _Wednesday, 8:00 UTC_ to be able to join the network in the next epoch.
 
-Confirmation of a new node's inclusion in epoch N+1 is included in the [`EpochSetup` event](../../../staking/05-epoch-scripts-events.md#epochsetup).
+Confirmation of a new node's inclusion in epoch N+1 is included in the [`EpochSetup` event](../../../staking/05-epoch-scripts-events.md#flowepochepochsetup).
 
 ![Flow Epoch Schedule](../../node-operation/epoch-startup-order.png)
 
@@ -209,7 +209,7 @@ When you stake the node, the tokens will show up under the `tokensCommitted` buc
 If the node is not selected, the tokens are moved to the `tokensUnstaked` bucket.
 
 ### Check Using Flow Port
-You can check these balances on Flow Port before and after the epoch transition that will occur on Wednesday (see [timing](#Timing)).
+You can check these balances on Flow Port before and after the epoch transition that will occur on Wednesday (see [timing](#timing)).
 
 When you stake the node, you should see the following on Flow Port under `Stake & Delegate`
 
@@ -253,7 +253,7 @@ Account staking info:
 
 ### Epoch Setup Event
 
-Alternatively, if you can monitor events, look for [the epoch setup event](../../../staking/05-epoch-scripts-events.md#epochsetup) that gets emitted by the epoch contract. That event is emitted at the end of epoch N's staking auction and contains a list of node IDs that are confirmed for the next epoch.
+Alternatively, if you can monitor events, look for [the epoch setup event](../../../staking/05-epoch-scripts-events.md#flowepochepochsetup) that gets emitted by the epoch contract. That event is emitted at the end of epoch N's staking auction and contains a list of node IDs that are confirmed for the next epoch.
 
 ## Step 4 - Start Your Node
 

docs/networks/node-ops/access-onchain-data/access-nodes/accessing-data/access-api.md

@@ -1347,7 +1347,7 @@ message TransactionSignature {
 | [proposal_key](#proposal-key) | Account key used to propose the transaction                                                                                 |
 | payer                         | Address of the payer account                                                                                                |
 | authorizers                   | Addresses of the transaction authorizers                                                                                    |
-| signatures                    | [Signatures](#transaction-signatures) from all signer accounts                                                              |
+| signatures                    | [Signatures](#transaction-signature) from all signer accounts                                                              |
 
 The detailed semantics of transaction creation, signing and submission are covered in the [transaction submission guide](../../../../../build/basics/transactions.md#signing-a-transaction).
 

docs/networks/node-ops/index.md

@@ -75,7 +75,7 @@ Launch an access node using QuickNode
 
 :::info
 
-To run a self-hosted access node, follow this [guide](./access-onchain-data/access-nodes/access-node-setup.mdx)
+To run a self-hosted access node, follow this [guide](./access-onchain-data/access-nodes/access-node-setup.md)
 
 :::