flare-foundation · nikerzetic-aflabs · Sep 23, 2025 · Sep 23, 2025
@@ -9,7 +9,7 @@ unlisted: true
 :::danger
 Since May 2025 this spec is considered deprecated.
 The `JsonApi` attestation type has been update to a new version, `Web2Json`.
-You can find the updated version of this spec [here](/fdc/attestation-types/web-2-json).
+You can find the updated version of this spec [here](/fdc/attestation-types/web2-json).
 :::
 
 Data retrieval from **Web2 JSON APIs** with JQ transformations. This attestation type allows smart contracts to access and process external JSON data in a verifiable way.

@@ -1,10 +1,11 @@
 ---
-title: Address Validity
+title: AddressValidity
+slug: address-validity
 authors: [nikerzetic, filipkoprivec]
 description: Check the validity of a Bitcoin, Dogecoin, or XRPL address.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 3
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,10 +1,11 @@
 ---
-title: EVM Transaction
+title: EVMTransaction
+slug: evm-transaction
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve the transaction data from Ethereum, Flare, or Songbird.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 6
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,10 +1,11 @@
 ---
 title: Payment
+slug: payment
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve a Payment transaction data from Bitcoin, Dogecoin, or XRPL.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,16 +1,17 @@
 ---
 title: Web2Json
+slug: web2-json
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 The `Web2Json` attestation type enables data collection from an arbitrary Web2 source.
-You can learn more about it in the official [specification repo](/fdc/attestation-types/web-2-json).
+You can learn more about it in the official [specification repo](/fdc/attestation-types/web2-json).
 
 <AvailableTestnet />
 

@@ -13,13 +13,13 @@ keywords:
     proof-of-reserves,
     web2json,
   ]
-sidebar_position: 12
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 This is a guide on how to build a simple dApp using the [Flare Data Connector](/fdc/overview).
-It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json), can be combined within the same app.
+It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json), can be combined within the same app.
 
 The app that we will be building is called `proofOfReserves`, which enables onchain verification that a stablecoin's circulating supply is backed by sufficient offchain reserves.
 We will first describe what issue the app is addressing, and then provide a detailed walkthrough through its source code.
@@ -39,7 +39,7 @@ Implementing this verification system presents three technical challenges:
 2. **Reading onchain state**: We need to access the total token supply data from various blockchain networks.
 3. **Cross-chain data collection**: We need to aggregate token supply information across multiple chains.
 
-The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web-2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
+The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
 For reading onchain state, we deploy a dedicated contract that reads the token supply and emits this data as an event.
 
 This guide will walk through all the components needed to build the complete `proofOfReserves` verification system.

@@ -15,12 +15,12 @@ keywords:
     insurance,
     oracle,
   ]
-sidebar_position: 14
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
-In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web-2-json) attestation type.
+In this guide, we will examine an example of a simple insurance dApp that uses the FDC's [Web2Json](/fdc/guides/hardhat/web2-json) attestation type.
 The dApp will allow users to create insurance policies for temperatures at specific coordinates falling below a specified threshold.
 Other users will be able to claim those policies, and the policies will be settled automatically by the contract.
 
@@ -63,7 +63,7 @@ With that we can now focus on the technical aspects of the procedure described a
 
 The contract that we will define will be called `MinTempAgency`.
 This name coincides with the field name in the response on a call to the [OpenWeatherMap API](https://openweathermap.org/api), which we will be using to acquire weather data.
-We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web-2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
+We will use the [Flare Data Connector](/fdc/overview) to collect the weather data so, in keeping with the [Web2Json guide](/fdc/guides/hardhat/web2-json), we start by defining a `DataTransportObject` which will determine how the FDC should encode the data.
 
 ```solidity title="src/weatherInsurance/MinTempAgency.sol"
 struct DataTransportObject {
@@ -281,7 +281,7 @@ function resolvePolicy(uint256 id, IWeb2Json.Proof calldata proof) public {
 }
 ```
 
-The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web-2-json).
+The `IWeb2Json.Proof` is validated as demonstrated in the [Web2Json guide](/fdc/guides/hardhat/web2-json).
 
 ```solidity title="src/weatherInsurance/MinTempAgency.sol"
 function isWeb2JsonProofValid(IWeb2Json.Proof calldata _proof) private view returns (bool) {
@@ -454,7 +454,7 @@ contract ClaimPolicy is Script {
 forge script script/MinTemp.s.sol:ClaimPolicy --rpc-url $COSTON2_RPC_URL --broadcast --sig "run(uint256)" <POLICY_ID>
 ```
 
-The script for resolving a policy is slightly more complicated. It involves making a Web2Json attestation request to the FDC and providing the returned proof to the `MinTempAgency` contract. To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web-2-json), or its [spec](/fdc/attestation-types/web-2-json).
+The script for resolving a policy is slightly more complicated. It involves making a Web2Json attestation request to the FDC and providing the returned proof to the `MinTempAgency` contract. To learn more about the Web2Json attestation request look at the [related guide](/fdc/guides/hardhat/web2-json), or its [spec](/fdc/attestation-types/web2-json).
 
 The URL we will be submitting to the FDC is the one already mentioned above. We prepare the URL using a helper function in our script, dividing the coordinates by 10<sup>6</sup> to return them to their original value.
 

@@ -1,15 +1,16 @@
 ---
 title: Web2Json for Custom API
+slug: web2-json-for-custom-api
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 12
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
-The [Web2Json guide](/fdc/guides/foundry/web-2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
+The [Web2Json guide](/fdc/guides/foundry/web2-json) demonstrates how the Flare Data Connector can be used to fetch Web2 and store it on the chain.
 The code for this and other examples is available within the [Flare Foundry starter](https://github.com/flare-foundation/flare-foundry-starter) repository.
 In this guide, we will see how the `Web2Json` example script within the Flare Foundry starter can be modified to work with custom data and custom contracts.
 That way, the example code can serve as the base building block for a custom project.

@@ -1,10 +1,11 @@
 ---
 title: Cross-Chain Payment
+slug: cross-chain-payment
 authors: [anthonyamadia]
 description: Use an EVMTransaction proof to verify a payment on another chain and mint an NFT.
 tags: [fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, cross-chain, payment]
-sidebar_position: 9
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";

@@ -6,13 +6,13 @@ description: Use the FDC data on a non-Flare, like the XRPL EVM Sidechain.
 tags: [fdc, foundry]
 keywords:
   [ethereum, flare-data-connector, evm, cross-chain, web2json, relay, xrpl]
-sidebar_position: 11
+sidebar_position: 1
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 This guide demonstrates a powerful cross-chain workflow using the Flare Data Connector (FDC).
-We will fetch data from a public Web2 API using the [Web2Json](/fdc/attestation-types/web-2-json) attestation type on a Flare network (Coston2) and then use the resulting proof to trigger a state change on a different EVM-compatible blockchain, the XRPL EVM Sidechain Testnet.
+We will fetch data from a public Web2 API using the [Web2Json](/fdc/attestation-types/web2-json) attestation type on a Flare network (Coston2) and then use the resulting proof to trigger a state change on a different EVM-compatible blockchain, the XRPL EVM Sidechain Testnet.
 
 The key to this cross-chain interaction is the `Relay` contract.
 For a non-Flare chain to verify FDC proofs, the Merkle root of each finalized voting round on Flare must be transmitted to the target chain.

@@ -12,7 +12,7 @@ unlisted: true
 
 Since May 2025 this guide is considered deprecated.
 The `JsonApi` attestation type has been update to a new version, `Web2Json`.
-You can find the updated version of this guide [here](/fdc/guides/foundry/web-2-json).
+You can find the updated version of this guide [here](/fdc/guides/foundry/web2-json).
 
 :::
 

@@ -1,10 +1,11 @@
 ---
-title: Address Validity
+title: AddressValidity
+slug: address-validity
 authors: [nikerzetic, filipkoprivec]
 description: Check the validity of a Bitcoin, Dogecoin, or XRPL address.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 3
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,10 +1,11 @@
 ---
-title: EVM Transaction
+title: EVMTransaction
+slug: evm-transaction
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve the transaction data from Ethereum, Flare, or Songbird.
 tags: [intermediate, ethereum, fdc, foundry]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 6
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,10 +1,11 @@
 ---
 title: Payment
+slug: payment
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve a Payment transaction data from Bitcoin, Dogecoin, or XRPL.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 

@@ -1,17 +1,18 @@
 ---
 title: Web2Json
+slug: web2-json
 authors: [nikerzetic, filipkoprivec]
 description: Retrieve arbitrary Web2 data.
 tags: [intermediate, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 8
+sidebar_position: 1
 unlisted: false
 ---
 
 import AvailableTestnet from "../_available_testnet.mdx";
 
 The `Web2Json` attestation type enables data collection from an arbitrary Web2 source.
-You can learn more about it in the official [specification](/fdc/attestation-types/web-2-json).
+You can learn more about it in the official [specification](/fdc/attestation-types/web2-json).
 
 <AvailableTestnet />
 
@@ -89,7 +90,7 @@ In the case of `Web2Json`, `requestBody` is a JSON containing the fields:
 
 ### Reference Documentation
 
-- [Web2Json Specification](/fdc/attestation-types/web-2-json)
+- [Web2Json Specification](/fdc/attestation-types/web2-json)
 - [Verifier Interactive Docs](https://jq-verifier-test.flare.rocks/api-doc#/)
 
 ### Example Values

@@ -1,18 +1,19 @@
 ---
 title: Proof of Reserves
+slug: proof-of-reserves
 authors: [nikerzetic, filipkoprivec]
 description: Verifying stablecoin reserves with FDC.
 tags: [advanced, ethereum, fdc, hardhat]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
-sidebar_position: 10
+sidebar_position: 1
 unlisted: false
 ---
 
 import CodeBlock from "@theme/CodeBlock";
 import VerifyReservesScript from "!!raw-loader!/examples/developer-hub-javascript/fdc_verify_proof_of_reserves.ts";
 
 This is a guide on how to build a simple dApp using the [Flare Data Connector](/fdc/overview).
-It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json), can be combined within the same app.
+It demonstrates how multiple attestation types, namely the [EVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json), can be combined within the same app.
 
 The app that we will be building is called `proofOfReserves`, which enables onchain verification that a stablecoin's circulating supply is backed by sufficient offchain reserves.
 We will first describe what issue the app is addressing, and then provide a detailed walkthrough through its source code.
@@ -32,7 +33,7 @@ Implementing this verification system presents three technical challenges:
 2. **Reading onchain state**: We need to access the total token supply data from various blockchain networks.
 3. **Cross-chain data collection**: We need to aggregate token supply information across multiple chains.
 
-The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web-2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
+The [Flare Data Connector (FDC)](/fdc/overview) provides solutions for both accessing Web2 APIs through the [Web2Json](/fdc/attestation-types/web2-json) attestation type and collecting cross-chain data via the [EVMTransaction](/fdc/attestation-types/evm-transaction) attestation type.
 For reading onchain state, we deploy a dedicated contract that reads the token supply and emits this data as an event.
 
 This guide will walk through all the components needed to build the complete `proofOfReserves` verification system.
@@ -171,8 +172,8 @@ The contract defines several important components:
 
 - **Access Control**: The `updateAddress` function, protected by the `onlyOwner` modifier, provides a secure mechanism to update the registry mapping.
 
-To properly decode data from the [Web2Json](/fdc/attestation-types/web-2-json) attestation, we need to define a data structure that matches our expected format.
-Following patterns from the [Web2Json attestation type guide](/fdc/guides/hardhat/web-2-json), we create a simple `DataTransportObject` struct:
+To properly decode data from the [Web2Json](/fdc/attestation-types/web2-json) attestation, we need to define a data structure that matches our expected format.
+Following patterns from the [Web2Json attestation type guide](/fdc/guides/hardhat/web2-json), we create a simple `DataTransportObject` struct:
 
 ```solidity title="contracts/proofOfReserves/ProofOfReserves.sol"
 struct DataTransportObject {
@@ -552,7 +553,7 @@ Next, we define an `AttestationRequest` type.
 This will allow us to present the request data in a better organized format.
 Then, we prepare a list of requests, each populated with the data specified by its corresponding attestation type.
 The only two attestation types we need for this example are `IEVMTransaction` and `Web2Json`.
-For a more detailed explanation of the included fields, look at the appropriate type specification ([IEVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web-2-json)).
+For a more detailed explanation of the included fields, look at the appropriate type specification ([IEVMTransaction](/fdc/attestation-types/evm-transaction) and [Web2Json](/fdc/attestation-types/web2-json)).
 
 In this guide, we will be comparing the total supplies of previously deployed tokens (with an arbitrary initial supply of `666`), to the claimed reserves of a real stablecoin.
 We will obtain the dollar reserves from the API at the address: `https://api.htdigitalassets.com/alm-stablecoin-db/metrics/current_reserves_amount`.