fix(docs): general refactoring and improvements (#676)

Author: dineshpinto

CONTRIBUTING.md

@@ -27,16 +27,17 @@ We welcome contributions via:
     **Format:** `<type>(<scope>): <description>`
 
     **Common Types:**
-    | Type | Description |
+
+    | Type       | Description                               |
     | :--------- | :---------------------------------------- |
-    | `feat` | New feature |
-    | `fix` | Bug fix |
-    | `docs` | Documentation updates |
-    | `chore` | Maintenance tasks (build, deps) |
-    | `test` | Adding or improving tests |
+    | `feat`     | New feature                               |
+    | `fix`      | Bug fix                                   |
+    | `docs`     | Documentation updates                     |
+    | `chore`    | Maintenance tasks (build, deps)           |
+    | `test`     | Adding or improving tests                 |
     | `refactor` | Code improvements without feature changes |
-    | `style` | Formatting changes (whitespace, etc.) |
-    | `ci` | CI pipeline changes |
+    | `style`    | Formatting changes (whitespace, etc.)     |
+    | `ci`       | CI pipeline changes                       |
 
     **Example:**
 
@@ -67,15 +68,17 @@ We welcome contributions via:
 
 For consistency, follow these styles when creating or updating diagrams:
 
-| Element                      | Light Mode | Dark Mode | Notes                      |
-| :--------------------------- | :--------- | :-------- | :------------------------- |
-| Arrow Width                  | `1px`      | `1px`     |                            |
-| Arrow Color                  | `#595959`  | `#ffffff` |                            |
-| Border Width                 | `1px`      | `1px`     |                            |
-| **Border Color (Highlight)** | `#e62058`  | `#e62058` | Use for emphasis           |
-| Border Color (Normal)        | `#595959`  | `#ffffff` | Default border             |
-| **Onchain Border Style**     | `Solid`    | `Solid`   |                            |
-| **Offchain Border Style**    | `Dashed`   | `Dashed`  | _Use only if mixing types_ |
+| Element                  | Light Mode | Dark Mode | Notes                                              |
+| :----------------------- | :--------- | :-------- | :------------------------------------------------- |
+| Arrow Width              | `1px`      | `1px`     |                                                    |
+| Arrow Color              | `#595959`  | `#ffffff` |                                                    |
+| Border Width             | `1px`      | `1px`     |                                                    |
+| Border Color (Highlight) | `#e62058`  | `#e62058` | Use for emphasis                                   |
+| Border Color (Normal)    | `#595959`  | `#ffffff` | Default border                                     |
+| Onchain Border Style     | `Solid`    | `Solid`   |                                                    |
+| Offchain Border Style    | `Dashed`   | `Dashed`  | \_Use only if mixing onchain and offchain elements |
+
+See the architecture diagram on the homepage as an [example](https://dev.flare.network/#understand-the-architecture).
 
 ## Need Help?
 

README.md

@@ -118,7 +118,7 @@ To generate Solidity documentation:
 
 1. **Update addresses and feeds:**
 
-   This script updates JSON files used by custom components (e.g., feed tables, contract address lists) by fetching data from the `ContractRegistry` on-chain and referencing risk data defined in `automations/*_risk.json`.
+   This script updates JSON files used by custom components (e.g., feed tables, contract address lists) by fetching data from the `ContractRegistry` onchain and referencing risk data defined in `automations/*_risk.json`.
 
    ```bash
    npm run automations

docs/fassets/6-core-vault.mdx

@@ -113,11 +113,11 @@ Multisig signers validate all outgoing transactions against a pre-approved rule
 
 1. **Escrow Expiry Adds Funds**
 
-   An expired escrow (size L) adds XRP to the vault’s available pool.
+   An expired escrow (size L) adds XRP to the vault's available pool.
 
 2. **Withdrawals & Payouts**
 
-   Users request withdrawals; multisig operators validate Flare’s offchain instructions and process payouts.
+   Users request withdrawals; multisig operators validate Flare's offchain instructions and process payouts.
 
 3. **Re-escrow Excess & Maintain Reserve**
 

docs/fassets/developer-guides/2-fassets-asset-manager-settings-solidity.mdx

@@ -19,7 +19,7 @@ You will deploy the contract using Hardhat and interact with it via a TypeScript
 
 ## Prerequisites
 
-- [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit#hardhat)
+- [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit)
 - [Flare Network Periphery Contracts](https://www.npmjs.com/package/@flarenetwork/flare-periphery-contracts)
 - Node.js, TypeScript, and hardhat.config.ts with the Songbird Testnet Coston network configured
 

docs/fassets/developer-guides/3-fassets-redeem.mdx

@@ -20,7 +20,7 @@ See the [Redemption](/fassets/redemption) overview for more details.
 
 ## Prerequisites
 
-- [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit#hardhat)
+- [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit)
 - [Flare Network Periphery Contracts](https://www.npmjs.com/package/@flarenetwork/flare-periphery-contracts)
 
 ## Redeem FAssets Smart Contract
@@ -46,7 +46,7 @@ In this example, you are not using the executor vault address, but you can use i
 
 ## Deploy and Interact with the Smart Contract
 
-To deploy the contract and redeem FAssets, you can use the [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit#hardhat).
+To deploy the contract and redeem FAssets, you can use the [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit).
 
 Create a new file, for example `scripts/fassets/redeem.ts` and add the following code:
 
@@ -225,7 +225,7 @@ main().catch((error) => {
 
 ### Run the Script
 
-To run the script, use the [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit#hardhat) with the following command:
+To run the script, use the [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit) with the following command:
 
 ```bash
 npx hardhat run scripts/fassets/getLotSize.ts --network coston

docs/fdc/1-overview.mdx

@@ -3,7 +3,7 @@ sidebar_position: 1
 slug: overview
 title: FDC
 authors: [lukaavbreht, filipkoprivec]
-description: The Flare Data Connector (FDC) enables secure, on-chain attestation of external data.
+description: The Flare Data Connector (FDC) enables secure, onchain attestation of external data.
 tags: [intermediate, ethereum, fdc]
 keywords: [ethereum, flare-data-connector, evm, flare-network]
 unlisted: false
@@ -19,7 +19,7 @@ It allows users to submit attested data that smart contracts can trust, eliminat
 ## Key Features
 
 - **Network-Level Security**: Data attestation requires reaching a 50%+ signature weight from data providers, ensuring decentralized consensus.
-- **Efficient On-chain Storage**: Verified data is stored in a Merkle tree, with only the Merkle root stored on-chain to minimize costs.
+- **Efficient Onchain Storage**: Verified data is stored in a Merkle tree, with only the Merkle root stored onchain to minimize costs.
 - **Easy Offchain Accessibility**: Data providers serve attestation responses and Merkle proofs offchain through a Data Availability (DA) Layer, ensuring efficient data retrieval.
 - **Proof-Based Verification**: Smart contracts validate Merkle proofs against the stored Merkle root, ensuring only authentic data triggers contract actions.
 - **Extensible Attestation Types**: New attestation types and data sources can be added through provider consensus, ensuring adaptability.
@@ -35,7 +35,7 @@ It allows users to submit attested data that smart contracts can trust, eliminat
 />
 
 1. **Data Verification**: The FDC verifies user-submitted attestation requests.
-2. **Merkle Representation**: Verified responses are organized into a Merkle tree, with only the Merkle root stored on-chain.
+2. **Merkle Representation**: Verified responses are organized into a Merkle tree, with only the Merkle root stored onchain.
 3. **Attestation Usage**: Users retrieve attestation responses and Merkle proofs from data providers and submit them to smart contracts.
 
 :::tip[Interested in learning more?]
@@ -45,7 +45,7 @@ For a detailed explanation of the FDC mechanism, read the [FDC whitepaper](/pdf/
 ### Data Availability Layer
 
 The Data Availability Layer (DA Layer) provides API endpoints for querying offchain attestation data.
-Accessing this data is trustless, as users can independently compute and compare Merkle roots against the on-chain version.
+Accessing this data is trustless, as users can independently compute and compare Merkle roots against the onchain version.
 
 Operating a DA Layer is permissionless—anyone can run a DA Layer service by sourcing data from an [FTSOv2 data provider](/run-node/ftso-data-provider) and [FDC attestation provider](/run-node/fdc-attestation-provider).
 

docs/fdc/2-getting-started.mdx

@@ -68,7 +68,7 @@ Here's how the attestation process works:
 
 4. **Extract proof and data**
 
-   After the Merkle root is stored on-chain, we'll use the Data Availability (DA) Layer service to retrieve the complete transaction data for our smart contract logic and the Merkle proof needed to verify the data's authenticity.
+   After the Merkle root is stored onchain, we'll use the Data Availability (DA) Layer service to retrieve the complete transaction data for our smart contract logic and the Merkle proof needed to verify the data's authenticity.
 
 5. **Verify and use the data**
 
@@ -203,7 +203,7 @@ The attestation will be processed in the current FDC round, which typically fina
 
 :::info
 
-While you can retrieve a proof before round finalization, it won't be valid until the round completes and its Merkle root is stored on-chain.
+While you can retrieve a proof before round finalization, it won't be valid until the round completes and its Merkle root is stored onchain.
 
 :::
 
@@ -217,7 +217,7 @@ After submitting the request, wait for round finalization before proceeding to p
 
 ## Extract proof and data
 
-Once the FDC round is finalized and its Merkle root is stored on-chain, we can retrieve the full data and proof for our attestation request.
+Once the FDC round is finalized and its Merkle root is stored onchain, we can retrieve the full data and proof for our attestation request.
 The Data Availability (DA) Layer API provides a streamlined way to access this information.
 
 ### Using the DA Layer API
@@ -405,7 +405,7 @@ Don't forget to set the EVM version to `london` in Remix before compiling the co
 
 This two-phase approach provides robust security against malicious data providers:
 
-- While the data comes from an offchain source (DA Layer API), it must match the on-chain Merkle root
+- While the data comes from an offchain source (DA Layer API), it must match the onchain Merkle root
 - Any attempt to provide manipulated data will fail at the proof verification stage
 - Only data that has achieved consensus through the FDC protocol can pass verification
 

docs/fdc/guides/foundry/address-validity.mdx

@@ -369,7 +369,7 @@ Base.writeToFile(
 
 ## Submit request to FDC
 
-This step transitions from offchain request preparation to on-chain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
+This step transitions from offchain request preparation to onchain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
 
 ### Submit request
 
@@ -651,12 +651,12 @@ The decoded `IAddressValidity.Response` struct is:
 
 ## Verify proof
 
-FDC optimizes on-chain storage costs by implementing a hybrid data verification system.
-Instead of storing complete datasets on-chain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
+FDC optimizes onchain storage costs by implementing a hybrid data verification system.
+Instead of storing complete datasets onchain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
 This approach significantly reduces gas costs while preserving data integrity.
 
 When requested, data providers supply the original data along with its corresponding Merkle proof.
-The protocol verifies data authenticity by comparing the provided Merkle proof against the on-chain Merkle root.
+The protocol verifies data authenticity by comparing the provided Merkle proof against the onchain Merkle root.
 A successful match confirms the data's integrity and authenticity within the FDC system.
 
 While data verification is optional if you trust your data provider, FDC ensures transparency by making verification possible at any time.

docs/fdc/guides/foundry/evm-transaction.mdx

@@ -392,7 +392,7 @@ Base.writeToFile(
 
 ## Submit request to FDC
 
-This step transitions from offchain request preparation to on-chain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
+This step transitions from offchain request preparation to onchain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
 
 ### Submit request
 
@@ -817,12 +817,12 @@ The decoded `IEVMTransaction.Response` struct is:
 
 ## Verify proof
 
-FDC optimizes on-chain storage costs by implementing a hybrid data verification system.
-Instead of storing complete datasets on-chain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
+FDC optimizes onchain storage costs by implementing a hybrid data verification system.
+Instead of storing complete datasets onchain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
 This approach significantly reduces gas costs while preserving data integrity.
 
 When requested, data providers supply the original data along with its corresponding Merkle proof.
-The protocol verifies data authenticity by comparing the provided Merkle proof against the on-chain Merkle root.
+The protocol verifies data authenticity by comparing the provided Merkle proof against the onchain Merkle root.
 A successful match confirms the data's integrity and authenticity within the FDC system.
 
 While data verification is optional if you trust your data provider, FDC ensures transparency by making verification possible at any time.

docs/fdc/guides/foundry/json-api.mdx

@@ -401,7 +401,7 @@ Base.writeToFile(
 
 ## Submit request to FDC
 
-This step transitions from offchain request preparation to on-chain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
+This step transitions from offchain request preparation to onchain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
 
 ### Submit request
 
@@ -714,12 +714,12 @@ The decoded `IEVMTransaction.Response` struct is:
 
 ## Verify proof
 
-FDC optimizes on-chain storage costs by implementing a hybrid data verification system.
-Instead of storing complete datasets on-chain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
+FDC optimizes onchain storage costs by implementing a hybrid data verification system.
+Instead of storing complete datasets onchain, it stores only Merkle proofs, while maintaining the actual data through trusted offchain providers.
 This approach significantly reduces gas costs while preserving data integrity.
 
 When requested, data providers supply the original data along with its corresponding Merkle proof.
-The protocol verifies data authenticity by comparing the provided Merkle proof against the on-chain Merkle root.
+The protocol verifies data authenticity by comparing the provided Merkle proof against the onchain Merkle root.
 A successful match confirms the data's integrity and authenticity within the FDC system.
 
 While data verification is optional if you trust your data provider, FDC ensures transparency by making verification possible at any time.