Reorganize layout, remove Guides tab

docs/1-intro.mdx

@@ -21,25 +21,23 @@ import useBaseUrl from "@docusaurus/useBaseUrl";
 
 ## Getting started
 
-- [Deploy your first smart contract](../guides/deploy-first-contract) — Build and deploy your first on-chain Flare smart contract, using only your browser.
+- [Deploy your first smart contract](/network/getting-started) — Build and deploy your first on-chain Flare smart contract, using only your browser.
 
 - [Learn how to use FTSOv2](./ftso/overview) — Leverage the latest upgrades to the Flare Time Series Oracle, with feeds now updating every ≈1.8 seconds
 
 - Start building on Flare with programming languages you may already know
 
-  - [JavaScript](../guides/flare-for-javascript-developers)
-  - [Python](../guides/flare-for-python-developers)
-  - [Rust](../guides/flare-for-rust-developers)
-  - [Go](../guides/flare-for-go-developers)
+  - [JavaScript](/network/guides/flare-for-javascript-developers)
+  - [Python](/network/guides/flare-for-python-developers)
+  - [Rust](/network/guides/flare-for-rust-developers)
+  - [Go](/network/guides/flare-for-go-developers)
 
 ## Understand the architecture
 
 Build a strong understanding of the core concepts that set Flare apart from other blockchains:
 
 - Flare's data protocols, [Flare Time Series Oracle (FTSO)](./ftso/overview) and [Flare Data Connector (FDC)](./fdc/overview), are enshrined into the core protocol of Flare, and inherit the economic security of the entire network.
 
-- [Delegated Proof-of-Stake (DPoS)](../guides/flare-dpos-mechanism) — Flare's users are incentivized to reward honest validators, and punish dishonest ones.
-
 <ThemedImage
   alt="Flare Architecture"
   sources={{

docs/fdc/1-overview.mdx

@@ -9,7 +9,8 @@ FDC is currently under development.
 
 For more information, see the three part State Connector guide:
 
-- [Part 1: State Connector](/guides/how-to-state-connector)
-- [Part 2: Attestation Types](/guides/attestation-types)
-- [Part 3: EVM Connectivity](/guides/evm-connectivity)
-  :::
+- [Part 1: State Connector](guides/state-connector)
+- [Part 2: Attestation Types](guides/attestation-types)
+- [Part 3: EVM Connectivity](guides/evm-connectivity)
+
+:::

guides/2024-06-11-how-to-state-connector.mdx → docs/fdc/guides/part1-state-connector.mdx

@@ -1,10 +1,11 @@
 ---
-slug: how-to-state-connector
+slug: state-connector
 title: Part 1 - State Connector
 authors: [lukaavbreht, filipkoprivec]
-description: Learn how to bridge data across blockchains using the State Connector, understand the CCCR protocol, and attest to a Bitcoin transaction.
+description: Learn how to bridge data across blockchains.
 tags: [quickstart, bitcoin, fdc]
 keywords: [quickstart, bitcoin, flare-data-connector, flare-network]
+sidebar_position: 1
 ---
 
 The State Connector bridges the gap between different blockchains, enabling the smooth exchange of information and synchronization of smart contracts and state changes. In this guide, you will learn how to:
@@ -18,7 +19,7 @@ The State Connector bridges the gap between different blockchains, enabling the
 This guide includes code snippets to recreate the process of attesting to a payment on the Bitcoin network and using the proof on the Flare Network. The complete setup and full code are available on the [Flare Demo examples](https://github.com/flare-foundation/flare-demo-examples) repository. You are encouraged to follow along and try it yourself. The repository contains all the necessary code and instructions to set up the environment and run the code.
 
 :::info
-If you are new to Flare, make sure you first understand the [Flare Network](/network).
+If you are new to Flare, make sure you first understand the [Flare Network](/network/overview).
 
 Starter packs for [Hardhat](https://github.com/flare-foundation/flare-hardhat-starter) and [Foundry](https://github.com/flare-foundation/flare-foundry-starter) are available to help you get started with Flare development.
 :::

guides/2024-06-12-attestation-types.mdx → docs/fdc/guides/part2-attestation-types.mdx

@@ -5,9 +5,10 @@ description: Learn about Flare State Connector attestation types
 authors: [lukaavbreht, filipkoprivec]
 tags: [intermediate, fdc]
 keywords: [quickstart, bitcoin, flare-data-connector, flare-network]
+sidebar_position: 2
 ---
 
-In [Part 1](/guides/how-to-state-connector) of this series, you learnt the basics of the State Connector protocol, and how to use it to prove a payment on an external chain. In this guide you will learn:
+In [Part 1](state-connector) of this series, you learnt the basics of the State Connector protocol, and how to use it to prove a payment on an external chain. In this guide you will learn:
 
 - How to prepare requests for different attestation types.
 - What information you need to provide.
@@ -25,7 +26,7 @@ Out of the [full specification](https://github.com/flare-foundation/songbird-sta
 
 - [ReferencePaymentNonexistence](https://github.com/flare-foundation/songbird-state-connector-protocol/blob/main/specs/attestations/active-types/ReferencedPaymentNonexistence.md). Prove that a payment with the specified reference does not exist on the specified chain. This is useful for proving that someone did not honor a payment request.
 
-The specification also includes `EVMTransaction`, which is more complex and powerful. This will be covered in [Part 3](/guides/evm-connectivity) of this series.
+The specification also includes `EVMTransaction`, which is more complex and powerful. This will be covered in [Part 3](evm-connectivity) of this series.
 
 Each attestation type is designed to prove a specific aspect, whether it be about transactions, blocks, or offloading expensive computations off-chain to have the results available on-chain. The team has carefully studied the most important use cases and designed the attestation types to be safe, well-defined, and efficient.
 
@@ -59,7 +60,7 @@ Before diving into different attestation types, let's explore the generated Swag
 
 Open the page `${ATTESTATION_HOST}/verifier/btc/api-doc#/` (replace `btc` with the network you are interested in), where you'll find the full documentation of the API. Here, you can see all available endpoints, the types they accept, and what they return. Remember to authorize yourself with the API key before trying them out (you can do this in the top right corner of the page).
 
-Let's start by preparing a request for the `Payment` type, which was covered in [Part 1](/guides/how-to-state-connector), and see what is returned. Pick a Bitcoin transaction from the block explorer and prepare the request for it. If you're doing this on a test network, ensure the `sourceId` in the example request is correct (it should be `testBTC`). If you execute a request with an incorrect `sourceId`, the attestation client will reject it and provide an error message indicating what needs to be fixed.
+Let's start by preparing a request for the `Payment` type, which was covered in [Part 1](state-connector), and see what is returned. Pick a Bitcoin transaction from the block explorer and prepare the request for it. If you're doing this on a test network, ensure the `sourceId` in the example request is correct (it should be `testBTC`). If you execute a request with an incorrect `sourceId`, the attestation client will reject it and provide an error message indicating what needs to be fixed.
 
 {/* <!--TODO: add example image--> */}
 
@@ -1319,7 +1320,7 @@ Successful non existence proofs:
 
 And there is a sub-specification for each chain that specifies the rules for the address validity for each chain. Be careful: Bitcoin and Dogecoin have different rules for validity on the mainnet and testnet, so make sure to check the correct specification with the correct verifier.
 
-This is a very simple attestation type that can prove that a string constitutes a valid address on the specified chain. Importantly, unlike the `Payment` type we saw in [Part 1](/guides/how-to-state-connector), this type does not require a transaction to be proven. It just offloads the computation of the address validity to the verifier so that expensive computation does not have to be done on-chain.
+This is a very simple attestation type that can prove that a string constitutes a valid address on the specified chain. Importantly, unlike the `Payment` type we saw in [Part 1](state-connector), this type does not require a transaction to be proven. It just offloads the computation of the address validity to the verifier so that expensive computation does not have to be done on-chain.
 
 This is useful if you want to ensure that the address is valid before using it in your protocol. For example, fAssets need to make sure that an address is valid before they can be used in the protocol, and this is a good way to offload difficult computation regarding when the bitcoin address is valid to off-chain entities.
 
@@ -1685,6 +1686,6 @@ This approach ensures that complex and resource-intensive computations can be pe
 
 Congratulations — you made it this far! Now you see what the State Connector can do, how to use it, and some details you need to be careful about. As usual, check the repository for the full code and try to play around.
 
-In [Part 3](/guides/evm-connectivity), we will explore how information from EVM chains can be relayed and what we can do with it.
+In [Part 3](evm-connectivity), we will explore how information from EVM chains can be relayed and what we can do with it.
 
 A word of warning: while it might be tempting to save the whole proof structure in your smart contract (if you want to do some later operations), this is terribly inefficient from a gas standpoint, as you are writing a lot of data to memory and decoding nested structures is expensive. Additionally, since the structures are nested, even operating on them when in memory (or copying them from `calldata` to `memory`) generates large bytecode, which makes contract deployment more expensive or even impossible if you exceed the limit.

guides/2024-06-13-evm-connectivity.mdx → docs/fdc/guides/part3-evm-connectivity.mdx

@@ -2,12 +2,13 @@
 title: Part 3 - EVM Connectivity
 slug: evm-connectivity
 authors: [lukaavbreht, filipkoprivec]
-description: Learn how to connect EVM chains with the Flare State Connector and what kind of attestations you can get from it.
+description: Learn how to connect EVM chains to Flare.
 tags: [intermediate, ethereum, fdc]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
+sidebar_position: 3
 ---
 
-In [Part 1](/guides/how-to-state-connector) and [Part 2](/guides/attestation-types) of the series, you you have learned how the State Connector works and what kind of different attestations you can get from it. In this guide, you will:
+In [Part 1](state-connector) and [Part 2](attestation-types) of the series, you you have learned how the State Connector works and what kind of different attestations you can get from it. In this guide, you will:
 
 - Move from the world of UTXO chains to the world of EVM chains with a new `EVMTransaction` attestation type.
 - Understand the implications of connecting account-based chains, and the additional possibilities that smart contracts bring.

docs/ftso/1-getting-started.mdx

@@ -27,7 +27,7 @@ import QueryLatestFeeds from "/static/img/ftso-getting-started/6-query-latest-fe
 You can use FTSOv2 to connect your smart contracts with real-world data feeds. FTSOv2 leverages Flare's network of 100 independent data providers to fetch off-chain data and deliver it on-chain. This section demonstrates how to consume FTSOv2's block-latency feeds on Flare using an on-chain Solidity contract.
 
 :::info
-If you are new to smart contract development, learn how to [deploy your first smart contract](/guides/deploy-first-contract) before you start this guide.
+If you are new to smart contract development, learn how to [deploy your first smart contract](/network/getting-started) before you start this guide.
 :::
 
 ## Sample contract
@@ -95,7 +95,7 @@ contract FtsoV2FeedConsumer {
 ## Compile, deploy, and run the contract
 
 :::info
-If you have not already configured your MetaMask wallet to support Flare Testnet Coston2 and funded it with testnet C2FLR, learn how to [deploy your first smart contract](../../guides/deploy-first-contract).
+If you have not already configured your MetaMask wallet to support Flare Testnet Coston2 and funded it with testnet C2FLR, learn how to [deploy your first smart contract](/network/getting-started).
 
 You can get testnet C2FLR from the [Coston2 Faucet](https://faucet.flare.network/coston2).
 :::

docs/ftso/guides/make-volatility-incentive.mdx

@@ -26,7 +26,7 @@ Before reading this guide, make sure you understand the [FTSOv2 Architecture](/f
 
 This guide provides code examples demonstrating how to make an FTSOv2 volatility incentive offer using various programming languages. To make a volatility incentive offer, you need three key pieces of information:
 
-1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can use a node provider service or point to your own client. A comprehensive list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](../../network#configuration) page.
+1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can use a node provider service or point to your own client. A comprehensive list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](/network/overview#configuration) page.
 
 2. **Contract Address:** The address for the `FastUpdateIncentiveManager` contract varies by network. You can obtain this address in two ways:
 
@@ -35,10 +35,10 @@ This guide provides code examples demonstrating how to make an FTSOv2 volatility
    **OR**
 
    - **Query the FlareContractRegistry Contract:** The `FlareContractRegistry` contract has the same address across all networks. You can query it to get the `FastUpdateIncentiveManager` contract address. Refer to the specific language guides for examples:
-     - [JavaScript](/guides/flare-for-javascript-developers#make-query)
-     - [Python](/guides/flare-for-python-developers#make-query)
-     - [Rust](/guides/flare-for-rust-developers#make-query)
-     - [Go](/guides/flare-for-go-developers#make-query)
+     - [JavaScript](/network/guides/flare-for-javascript-developers#make-query)
+     - [Python](/network/guides/flare-for-python-developers#make-query)
+     - [Rust](/network/guides/flare-for-rust-developers#make-query)
+     - [Go](/network/guides/flare-for-go-developers#make-query)
 
 3. **Cost of Increasing the Sample Size:** FTSOv2 allows you to dynamically increase the sample size, i.e., the expected number of providers who can submit a block-latency feed update. The cost for this increases dynamically with the expected sample size. A single volatility incentive lasts for a period of 8 blocks.
 

docs/ftso/guides/query-feed-configuration.mdx

@@ -22,7 +22,7 @@ import Tabs from "@theme/Tabs";
 
 This guide provides code examples demonstrating how to read FTSOv2 feed configurations off-chain using various programming languages. To achieve this, you need two key pieces of information:
 
-1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can either use a node provider service or point to your own client. A list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](../../network#configuration) page.
+1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can either use a node provider service or point to your own client. A list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](/network/overview#configuration) page.
 
 2. **Contract Address:** The address for the `FastUpdatesConfiguration` contract varies by network. You can obtain this address in two ways:
 
@@ -31,10 +31,10 @@ This guide provides code examples demonstrating how to read FTSOv2 feed configur
      **OR**
 
    - **Query the FlareContractRegistry Contract:** The `FlareContractRegistry` contract has the same address across all networks. You can query it to get the `FastUpdatesConfiguration` contract address. Refer to the specific language guides for examples:
-     - [JavaScript](/guides/flare-for-javascript-developers#make-query)
-     - [Python](/guides/flare-for-python-developers#make-query)
-     - [Rust](/guides/flare-for-rust-developers#make-query)
-     - [Go](/guides/flare-for-go-developers#make-query)
+     - [JavaScript](/network/guides/flare-for-javascript-developers#make-query)
+     - [Python](/network/guides/flare-for-python-developers#make-query)
+     - [Rust](/network/guides/flare-for-rust-developers#make-query)
+     - [Go](/network/guides/flare-for-go-developers#make-query)
 
 :::tip
 

docs/ftso/guides/read-feeds-offchain.mdx

@@ -22,7 +22,7 @@ import Tabs from "@theme/Tabs";
 
 This guide provides code examples demonstrating how to read FTSOv2 feeds off-chain using various programming languages. To read a block-latency feed off-chain, you need three key pieces of information:
 
-1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can use a node provider service or point to your own client. A comprehensive list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](../../network#configuration) page.
+1. **RPC Endpoint URL:** The RPC Endpoint URL determines which network your code will interact with. You can use a node provider service or point to your own client. A comprehensive list of public and private RPC endpoints for all Flare networks is available on the [Network Configuration](/network/overview#configuration) page.
 
 2. **Contract Address:** The address for the `FastUpdater` contract varies by network. You can obtain this address in two ways:
 
@@ -31,10 +31,10 @@ This guide provides code examples demonstrating how to read FTSOv2 feeds off-cha
      **OR**
 
    - **Query the FlareContractRegistry Contract:** The `FlareContractRegistry` contract has the same address across all networks. You can query it to get the `FastUpdater` contract address. Refer to the specific language guides for examples:
-     - [JavaScript](/guides/flare-for-javascript-developers#make-query)
-     - [Python](/guides/flare-for-python-developers#make-query)
-     - [Rust](/guides/flare-for-rust-developers#make-query)
-     - [Go](/guides/flare-for-go-developers#make-query)
+     - [JavaScript](/network/guides/flare-for-javascript-developers#make-query)
+     - [Python](/network/guides/flare-for-python-developers#make-query)
+     - [Rust](/network/guides/flare-for-rust-developers#make-query)
+     - [Go](/network/guides/flare-for-go-developers#make-query)
 
 3. **Feed Indexes:** The feeds you want to read are uniquely identified by their index. A list of feed indexes is provided on the [Block-Latency Feeds](../feeds) page.
 

docs/ftso/guides/read-feeds-onchain.mdx

@@ -20,7 +20,7 @@ This guide provides code examples demonstrating how to read FTSOv2 feeds off-cha
 2. **Feed Indexes:** The feeds you want to read are uniquely identified by their index. A list of feed indexes is provided on the [Block-Latency Feeds](../feeds) page.
 
 :::info
-If you are familiar with Hardhat or Foundry, use the [Hardhat and Foundry Starter Kit](/guides/hardhat-foundry-starter-kit) to get started with Flare development.
+If you are familiar with Hardhat or Foundry, use the [Hardhat and Foundry Starter Kit](/network/guides/hardhat-foundry-starter-kit) to get started with Flare development.
 :::
 
 <Tabs block>