chore(docs): textlint one-sentence-per-line + prettier sweep

Author: nikerzetic-aflabs

docs/2-run-node.mdx

@@ -68,7 +68,8 @@ You can track validator status, uptime, and software versions on the [Flare Vali
 
 Runs alongside a Validator to provide crucial data for Flare's FTSO and FDC protocols.
 Required for full reward eligibility.
-Requires a running [Validator Node](#validator-node). To set up a Flare Entity:
+Requires a running [Validator Node](#validator-node).
+To set up a Flare Entity:
 
 <DocCardList
   items={[

docs/fassets/developer-guides/4-fassets-settings-node.mdx

@@ -284,7 +284,8 @@ Timestamp: 1756977702
 
 ## Summary
 
-Congratulations! You have built a TypeScript script that connects to the Coston2 network and retrieves the FAsset configuration settings and the price of XRP in USD.
+Congratulations!
+You have built a TypeScript script that connects to the Coston2 network and retrieves the FAsset configuration settings and the price of XRP in USD.
 
 :::tip[What's next]
 

docs/fdc/1-overview.mdx

@@ -62,11 +62,13 @@ Operating a DA Layer is permissionless—anyone can run a DA Layer service by so
 
 ## Attestation Types
 
-FDC currently supports seven attestation types, each serving specific verification needs. Below is an overview of these types, with detailed explanations available in their respective sections:
+FDC currently supports seven attestation types, each serving specific verification needs.
+Below is an overview of these types, with detailed explanations available in their respective sections:
 
 - **AddressValidity**: Validates the format and checksum of addresses on specified chains.
 - **EVMTransaction**: Verifies and retrieves transaction details from EVM-compatible chains (`ETH`, `FLR`, `SGB`).
-- **JsonApi**: Fetches and processes any Web2 data using a JQ transformation, then returns it as ABI-encoded output. (Currently only on Coston & Coston2).
+- **Web2Json**: Fetches and processes any Web2 data using a JQ transformation, then returns it as ABI-encoded output.
+  (Currently only on Coston & Coston2).
 - **Payment**: Confirms and fetches payment transaction details from non-EVM chains (`BTC`, `DOGE`, `XRP`).
 - **ConfirmedBlockHeightExists**: Verifies block existence and confirmation status.
 - **BalanceDecreasingTransaction**: Validates if a transaction reduces an address's balance.
@@ -124,7 +126,8 @@ Due to the waiting period between steps **2** and **3**, where the round is fina
 7. **Sign and Submit**: Collect signatures representing 50%+ weight and submit the Merkle root to the [`Relay`](/network/fsp/solidity-reference/IRelay) contract.
 8. **Serve Data**: Provide attestation responses and proofs via the DA Layer.
 
-The **Flare Data Connector (FDC)** is a critical infrastructure component for the Flare ecosystem, enabling smart contracts to access **secure, attested external data** while maintaining trustless verification through **Merkle proofs**. By integrating the FDC, developers can create more **reliable, decentralized applications** across multiple blockchains.
+The **Flare Data Connector (FDC)** is a critical infrastructure component for the Flare ecosystem, enabling smart contracts to access **secure, attested external data** while maintaining trustless verification through **Merkle proofs**.
+By integrating the FDC, developers can create more **reliable, decentralized applications** across multiple blockchains.
 
 ## Watch the video
 

docs/fdc/2-getting-started.mdx

@@ -33,7 +33,8 @@ Learn how to [deploy your first smart contract](/network/getting-started) on Fla
 
 :::
 
-At its core, FDC enables any smart contract on Flare to query immutable, verifiable information from supported blockchain networks. The protocol achieves consensus through the BitVote-reveal mechanism within the Flare Systems Protocol suite, allowing dapps to validate external blockchain data using Merkle proofs.
+At its core, FDC enables any smart contract on Flare to query immutable, verifiable information from supported blockchain networks.
+The protocol achieves consensus through the BitVote-reveal mechanism within the Flare Systems Protocol suite, allowing dapps to validate external blockchain data using Merkle proofs.
 
 Currently supported networks include:
 
@@ -100,7 +101,8 @@ The Data Connector operates in separate environments for mainnets and testnets,
 ## Prepare the attestation request
 
 To attest to transaction data, we need to encode it in a format that the Flare Data Connector (FDC) can process.
-This is done through a verifier service. While you can set up your own verifier, we'll use Flare's testnet verifier service available at `https://fdc-verifiers-testnet.flare.network/`.
+This is done through a verifier service.
+While you can set up your own verifier, we'll use Flare's testnet verifier service available at `https://fdc-verifiers-testnet.flare.network/`.
 You can explore the API through their Swagger interface at `https://fdc-verifiers-testnet.flare.network/verifier/api-doc`.
 
 ### Request structure
@@ -164,7 +166,10 @@ If consensus fails, you'll need to resubmit the request.
 <details>
     <summary>Understanding the structure of `abiEncodedRequest`.</summary>
 
-    The structure of `abiEncodedRequest` may seem complex, but it's essentially a concatenated hex string (with the initial 0x removed) representing different parts of the request. Each part is 32 bytes long (64 characters in hex). Here's a breakdown of the string:
+    The structure of `abiEncodedRequest` may seem complex, but it's essentially a concatenated hex string (with the initial 0x removed) representing different parts of the request.
+
+Each part is 32 bytes long (64 characters in hex).
+Here's a breakdown of the string:
 
     ```text
     45564d5472616e73616374696f6e000000000000000000000000000000000000
@@ -187,7 +192,10 @@ If consensus fails, you'll need to resubmit the request.
 
     - **Second line:** `toHex("testETH")`
 
-    - **Third line:** Message Integrity Code (MIC). This is a hash of the whole response salted with a string `Flare`. It ensures the integrity of the attestation and prevents tampering.
+    - **Third line:** Message Integrity Code (MIC).
+
+This is a hash of the whole response salted with a string `Flare`.
+It ensures the integrity of the attestation and prevents tampering.
 
     - **Remaining lines:** ABI encoded request body (as solidity struct).
       The structure of the body is defined in the accompanying attestation [type specification](https://github.com/flare-foundation/songbird-state-connector-protocol/blob/main/contracts/interface/types/EVMTransaction.sol#L68).
@@ -305,7 +313,8 @@ This data is now ready to be used in your smart contract to:
 
 ## Verify and use the data
 
-Let's examine how to verify and utilize the data from the DA Layer API in your smart contract. We'll focus on a practical example: listening for and verifying USDC transfer events.
+Let's examine how to verify and utilize the data from the DA Layer API in your smart contract.
+We'll focus on a practical example: listening for and verifying USDC transfer events.
 
 ### Data structure
 
@@ -387,7 +396,8 @@ Don't forget to set the EVM version to `cancun` in Remix before compiling the co
 
 1. **Proof Verification**
 
-   The contract uses the `ContractRegistry` library to access Flare's official verifiers. The verification process:
+   The contract uses the `ContractRegistry` library to access Flare's official verifiers.
+   The verification process:
    - Retrieves the current verifier through the Flare governance-managed registry
    - Uses `isEVMTransactionProofValid` to verify the Merkle proof and data integrity
    - Requires successful verification before proceeding with any data processing

docs/fdc/6-troubleshooting.mdx

@@ -150,7 +150,8 @@ If the API returns multiple fields, use `postProcessJq` to extract only the fiel
 
 ### Root Cause: Query Parameters Embedded in the URL
 
-The [`Web2Json`](/fdc/attestation-types/web2-json) attestation type provides a dedicated `queryParams` field for query parameters. If you include query parameters directly in the `url` field (e.g., `https://api.example.com/data?key=value`), attestation providers may not process the request correctly, leading to consensus failure.
+The [`Web2Json`](/fdc/attestation-types/web2-json) attestation type provides a dedicated `queryParams` field for query parameters.
+If you include query parameters directly in the `url` field (e.g., `https://api.example.com/data?key=value`), attestation providers may not process the request correctly, leading to consensus failure.
 
 ### Solution: Use the `queryParams` Field
 

docs/fdc/attestation-types/_addresses.mdx

@@ -120,7 +120,8 @@ Decoded addresses have the format:
 #### Validation Criteria
 
 1. Address contains only characters from the Base58 dictionary.
-2. Length is **26 to 34 characters**. Decoded hex form is **25 bytes**.
+2. Length is **26 to 34 characters**.
+   Decoded hex form is **25 bytes**.
 3. Valid leading byte:
    - **Mainnet**: Starts with `D`, `A`, or `9`.
    - **Testnet**: Starts with `n`, `m`, or `2`.
@@ -152,7 +153,8 @@ Decoded to hexadecimal:
 #### Validation Criteria
 
 1. Address contains only characters from the XRPL Base58 dictionary.
-2. Length is **25 to 35 characters**. Decoded hex form is **25 bytes**.
+2. Length is **25 to 35 characters**.
+   Decoded hex form is **25 bytes**.
 3. Address starts with `r`.
 4. The checksum is valid.
 

docs/fdc/attestation-types/address-validity.mdx

@@ -32,7 +32,8 @@ Assertion whether a given string represents a **valid address** on an external b
 
 ## Verification process
 
-The address is verified against the validity criteria specific to the chain identified by `sourceId`. If the address meets all criteria:
+The address is verified against the validity criteria specific to the chain identified by `sourceId`.
+If the address meets all criteria:
 
 1. `isValid` is set to `true`.
 2. The `standardAddress` and its `standardAddressHash` are computed.

docs/fdc/attestation-types/balance-decreasing-transaction.mdx

@@ -65,7 +65,8 @@ The verification process is chain-specific and can be computed with a [balance d
 #### Data Calculation
 
 - `sourceAddress`: Address associated with the specified transaction input.
-- `spentAmount`: Calculated as `Sum of all inputs with sourceAddress - Sum of all outputs with sourceAddress`. The value can be negative.
+- `spentAmount`: Calculated as `Sum of all inputs with sourceAddress - Sum of all outputs with sourceAddress`.
+  The value can be negative.
 - `blockTimestamp`: The **mediantime** of the block.
 
 ### Account-based chains (XRPL)
@@ -77,7 +78,8 @@ The verification process is chain-specific and can be computed with a [balance d
 
 #### Data Calculation
 
-- `spentAmount`: Difference between the balance of the address **after** and **before** the transaction. Can be negative.
+- `spentAmount`: Difference between the balance of the address **after** and **before** the transaction.
+  Can be negative.
 - `blockTimestamp`: The **close_time** of the ledger, converted to Unix time.
 - `standardPaymentReference`: [Standard payment reference] for `Payment` transactions, otherwise zero.
 

docs/fdc/attestation-types/json-api.mdx

@@ -12,7 +12,8 @@ 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/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.
+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.
 
 :::warning[Testnet Only]
 

docs/fdc/attestation-types/payment.mdx

@@ -120,7 +120,8 @@ The payment summary for Bitcoin and Dogecoin is derived using specified indices
 
 #### Data Sources
 
-- For Bitcoin, all transaction details are retrieved using the `getrawtransaction` endpoint (verbosity 2) and `getblock`. This requires a Bitcoin node version ≥ 25.0.
+- For Bitcoin, all transaction details are retrieved using the `getrawtransaction` endpoint (verbosity 2) and `getblock`.
+  This requires a Bitcoin node version ≥ 25.0.
 - For Dogecoin, since `getrawtransaction` with verbosity 2 is not supported, alternative methods must be used to access input transaction data.
 
 | Field                      | Description                                                                                                                                     |