chore(deps): update project and example deps

CONTRIBUTING.md

@@ -18,7 +18,6 @@ We welcome contributions via:
     ```
 
 2.  **Follow Style Guides:**
-
     - **Code/Docs:** Run `npm run format` to apply Prettier formatting. Match existing code style.
     - **Diagrams:** Adhere to the [Diagram Style Guide](#diagrams-style-guide) below for consistency.
 

docs/fassets/3-minting.mdx

@@ -158,7 +158,6 @@ The Data Connector's [payment nonexistence attestation type](https://gitlab.com/
    At the time the request is received, the last mined block on the Bitcoin chain is number 92, with timestamp 09:00 AM.
 
    The Asset Manager answers with the following threshold settings to complete the payment:
-
    - Block 100
    - Timestamp 11:00 AM
 
@@ -172,7 +171,6 @@ The Data Connector's [payment nonexistence attestation type](https://gitlab.com/
    In this case, 7 blocks on the Bitcoin blockchain are enough blocks to assume finality.
 5. The agent sends a nonpayment attestation request, which includes the payment reference, the underlying amount that was expected, the last block (100), and the last timestamp (11:00).
 6. Attestation providers attest to the following facts:
-
    - Block 102 is finalized and has both the number and timestamp larger than required.
    - Until this block, the required payment either was not made or was not sufficient.
 
@@ -250,19 +248,16 @@ The following example shows how the redemption queue works.
 3.  Charlie mints 5 FXRP with Agent 1.
 
     After Bob, Alice, and Charlie have minted their FAssets, the redemption queue according to the FIFO method is:
-
     1. Agent 1 with 10 FXRP.
     2. Agent 2 with 20 FXRP.
     3. Agent 1 with 5 FXRP.
 
 4.  Dana redeems 25 FXRP.
     To redeem 25 FXRP:
-
     1. Agent 1 pays 10 FXRP.
     2. Agent 2 pays 15 FXRP.
 
     Now, the redemption queue according to the FIFO method is:
-
     1. Agent 2 with 5 FXRP.
     2. Agent 1 with 5 FXRP.
 

docs/fassets/4-redemption.mdx

@@ -22,7 +22,6 @@ This is the summary of the redemption process:
 
 3. Each chosen ticket belongs to an agent.
    For every agent participating in the redemption, the system issues an event with the following redemption payment information:
-
    - Redeemer's underlying address.
 
      Agents can use the Data Connector to ensure the validity of this address.
@@ -45,7 +44,6 @@ This is the summary of the redemption process:
    The executor role is responsible for ensuring that the system can finalize redemptions even if the agent is unresponsive or if the flow is managed by a central entity (such as the Core Vault executor).
 
    The redemption ticket is required to:
-
    - Prove the payment has occurred.
    - Trigger burning of the FAssets.
    - Release the corresponding agent's vault collateral and pool collateral.

docs/fassets/5-liquidation.mdx

@@ -60,7 +60,6 @@ However, an agent can still self-close positions to avoid paying a premium to li
 Using BTC as underlying and USDC as collateral, an agent creates a vault to mint FBTC FAssets.
 
 1.  Initial conditions:
-
     - The agent is backing 1 FBTC, currently valued at $20K, according to the FTSO system.
     - The minimal CR is **1.3** for the vault collateral and **2.5** for pool collateral.
     - The agent must hold 20% of the pool's minimal CR.
@@ -69,7 +68,6 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
     - The liquidation premium factor is 1.1, of which 1.0 is paid in vault collateral, and 0.1 is paid in pool collateral.
 
     At this point, the 1 FBTC is backed by:
-
     - 0.5 BTC underlying.
     - $26K worth of USDC vault collateral.
 
@@ -81,7 +79,6 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
 
 2.  Now the price of BTC increases from \$20K to $21K.
     As a result:
-
     - The vault CR is $$\frac{\text{\$26K}}{\text{\$21K}} \approx 1.24$$, **below the vault's 1.3 minimal CR**.
     - The pool CR is $$\frac{\text{\$60K}}{\text{\$21K}} \approx 2.86$$, still above the pool's 2.5 minimal CR.
       :::warning
@@ -94,14 +91,12 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
 3.  A liquidator notices the CR levels and decides to liquidate $10K worth of FAssets by returning 0.48 FBTC to the FAssets system.
 
     The liquidation premium factor is 1.1, so the liquidator receives $11K worth of assets:
-
     - $10K worth of USDC from the agent's vault collateral.
     - $1K worth of FLR from the agent's portion of the collateral pool.
 
       The corresponding $1K worth of CPTs are burned, so their price is unaffected.
 
     At this point, the agent is backing 0.52 FBTC with:
-
     - 0.5 BTC underlying.
 
       The ratio is $$ \frac{0.5}{0.52} \approx 0.96 $$, well above the 50% underlying backing factor.
@@ -128,7 +123,6 @@ The same setup and initial conditions as in Example 1 are used:
 Using BTC as underlying and USDC as collateral, an agent creates a vault to mint FBTC FAssets.
 
 1.  Initial conditions:
-
     - The agent is backing 1 FBTC, currently valued at $20K, according to the FTSO system.
     - The minimal CR is **1.3** for the vault collateral and **2.5** for pool collateral.
     - The agent must hold 20% of the pool's minimal CR.
@@ -137,7 +131,6 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
     - The liquidation premium factor is 1.1, of which 1.0 is paid in vault collateral, and 0.1 is paid in pool collateral.
 
     At this point, the 1 FBTC is backed by:
-
     - 0.5 BTC underlying.
     - \$26 K worth of USDC vault collateral.
 
@@ -149,7 +142,6 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
 
 2.  Now the price of BTC increases from \$20K to $30K.
     As a result:
-
     - The vault CR is $$ \frac{\text{\$26\ K}}{\text{\$30\ K}} \approx 0.87 $$, **way below the vault's 1.3 minimal CR**.
     - The pool CR is $$ \frac{\text{\$60\ K}}{\text{\$30\ K}} = 2 $$, **below the vault's 2.5 minimal CR**.
 
@@ -160,14 +152,12 @@ Using BTC as underlying and USDC as collateral, an agent creates a vault to mint
 3.  A liquidator notices this situation and decides to liquidate 1 FBTC, currently worth $30K.
 
     The liquidation premium factor is 1.1, so the liquidator receives $33K worth of assets:
-
     - \$26 K worth of USDC, which is all of the collateral in the agent's vault.
     - \$7 K worth of FLR.
 
     Note that the portion of payment in FLR is higher than in Example 1 because enough USDC in collateral did not exist.
 
     At this point, the agent is backing 0 FBTC, and the remaining collateral is:
-
     - 0.5 BTC underlying.
     - \$0 worth of USDC in vault collateral.
     - \$53 K worth of FLR in pool collateral, of which \$3 K belongs to the agent.
@@ -251,7 +241,6 @@ Therefore, consider these actions:
 
 - **Maintain the underlying balance**: Agents must ensure that the payment plus the transaction fee for a redemption never reduce their balance to an amount lower than the amount required to back the FAssets.
   Agents can ensure that redemptions do not reduce that balance in several ways:
-
   - They can honor redemptions from some other address.
     On UTXO chains, they can also honor redemptions from a combination of addresses.
   - They can top up the underlying address and then send proof of payment to update the tracked balance.
@@ -298,7 +287,6 @@ This challenge is performed in the following way:
 
 1. The challenger obtains proof of the illegal payment using the FDC.
 2. The challenger presents the proof to the FAssets system, which triggers:
-
    - A vault collateral payment from the agent's vault to the challenger's address as a reward.
    - The agent's state for the address is set to [full liquidation](#liquidation-process).
 

docs/fassets/developer-guides/8-fassets-swap-redeem.mdx

@@ -66,22 +66,18 @@ It initializes the token as the first token in the swap path.
 The `swapAndRedeem` is the core function that executes the swap and redemption flow.
 
 - **1. Validation**
-
   - Ensure the caller has sufficient WCFLR balance.
   - Confirm the contract has enough FXRP allowance for redemption.
 
 - **2. Transfer**
-
   - Move WCFLR from the caller to the contract.
   - Approve the router to spend WCFLR on behalf of the contract.
 
 - **3. Swap**
-
   - Perform the swap from WCFLR to FXRP using the specified swap path.
   - Apply a 10-minute deadline for the swap operation.
 
 - **4. Redemption**
-
   - Redeem the obtained FXRP through the FAssets system.
   - Transfer the resulting XRP to the caller's XRPL address.
 
@@ -100,23 +96,19 @@ To execute the swap and redeem process, you need to deploy the smart contract in
 ### Code Breakdown
 
 - **1. Dependencies and Constants**
-
   - `ASSET_MANAGER_ADDRESS`: The address of the FAssets Asset Manager contract.
   - `LOTS_TO_REDEEM`: The number of FAsset lots to redeem (typically set to 1).
   - `UNDERLYING_ADDRESS`: The XRPL address that will receive the redeemed assets.
   - `SWAP_ROUTER_ADDRESS`: The address of the Uniswap V2-compatible swap router.
   - `SWAP_PATH`: An array of token addresses defining the swap path from WCFLR to FXRP.
 
 - **2. Deploy and Verify**
-
   - Deploys the `SwapAndRedeem` contract and verifies it using [Flare Hardhat Starter Kit](/network/guides/hardhat-foundry-starter-kit).
 
 - **3. Calculate Redemption Amounts**
-
   - Calls `calculateRedemptionAmountIn` to determine the required WCFLR amount.
 
 - **4. Approve Tokens**
-
   - Uses the ERC-20 `approve` method to allow the contract to spend WCFLR.
     :::warning
     In a production environment, you should use a secure method to approve spending the tokens.

docs/fassets/guides/2-create-fasset-agent-ui.mdx

@@ -56,7 +56,6 @@ Once you have saved the information and initiated the process, please allow some
    The **Vault options** menu is displayed.
 
 2. In the **Agent Vault Operations** section you have three options:
-
    - **Deposit Collateral (Lots)**: Deposit collateral into the vault in lots.
    - **Deposit Vault Collateral**: Deposit collateral into the agent vault.
    - **Deposit Pool Collateral**: Deposit collateral into the agent pool.

docs/fdc/2-getting-started.mdx

@@ -243,7 +243,6 @@ Here's how to retrieve the proof and data:
 The API returns two key components:
 
 - `response`: Contains the complete transaction data, including:
-
   - Attestation type and source chain
   - Transaction details (block number, timestamp, addresses)
   - Input data and execution status
@@ -359,7 +358,6 @@ The response consists of several key components:
 1. `requestBody`: Contains an exact copy of your original attestation request data.
 
 2. `metadata`: Includes verification-critical information:
-
    - `votingRound`: Identifies the specific FDC consensus round
    - `lowestUsedTimestamp`: Ensures data freshness and proper round assignment
 
@@ -390,15 +388,13 @@ Don't forget to set the EVM version to `london` in Remix before compiling the co
 1. **Proof Verification**
 
    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
 
 2. **Event Processing**
 
    After verification, the `collectTransferEvents` function handles the business logic:
-
    - Processes the verified transaction data
    - Filters for USDC Transfer events
    - Decodes and stores relevant event data

docs/fdc/attestation-types/referenced-payment-nonexistence.mdx

@@ -52,12 +52,10 @@ This Information can be used, for example, to justify the liquidation of funds l
 ## Verification process
 
 1. **Block Confirmation**:
-
    - If the `firstOverflowBlock` cannot be determined or lacks the required [number of confirmations](#finality), the request is rejected.
    - The request is also rejected if `firstOverflowBlockNumber` is less than or equal to `minimalBlockNumber`.
 
 2. **Search Range**:
-
    - The search range includes blocks from `minimalBlockNumber` to `firstOverflowBlockNumber` (exclusive).
    - If the verifier does not have complete visibility of all blocks in this range, the request is rejected.
 

docs/fdc/guides/foundry/create-attestation-type.mdx

@@ -51,7 +51,6 @@ Ensure you have the following tools installed:
    </details>
 
 3. **Modify `@custom` props:**
-
    - `@custom:name`: Rename to `@custom:CustomType`.
    - `@custom:supported`: Indicate the data source, currently supported sources - `BTC`, `DOGE` ,`XRP`, `FLR`, `SGB`, `ETH` and `WEB2`. A single type can support multiple data sources.
    - `@custom:verification`: Add instructions on how to construct a response from the request.
@@ -74,12 +73,10 @@ Ensure you have the following tools installed:
    :::
 
 2. **Define data sources:**
-
    - **Single data source:** Change the source in the constructor of `ICustomType.service.ts` to the one specified in the type definition.
      Modify the `verifyRequest` function to match the verification rules defined by your attestation type.
 
    - **Multiple data sources:** Each source needs its own service and controllers.
-
      1. **Create services for each source:** In `ICustomType.service.ts` for each source, create a new class, e.g. `<SourceID>ICustomTypeVerifierService`, that implements `verifyRequest` function for the source.
 
      2. **Create controllers for each source:** In `ICustomType.controller.ts` for each source, create a new class, e.g. `<SourceID>ICustomTypeVerifierController`, and set the type of verifierService to the one created for this type:

docs/ftso/guides/create-custom-feed.mdx

@@ -97,7 +97,6 @@ It then exposes this price through the `IICustomFeed` interface.
 - **`verifyPrice(IWeb2Json.Proof calldata _proof)`**:
   This is the heart of the contract.
   It accepts a proof from the FDC and performs a series of checks before updating the `latestVerifiedPrice`.
-
   1. **Parses the API URL** from the proof to ensure the data is from the expected source.
 
   2. **Verifies the proof's authenticity** by calling the FDC's onchain `verifyJsonApi` function.

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

@@ -37,11 +37,9 @@ This guide provides code examples demonstrating how to make an FTSOv2 volatility
 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 RPC node](/run-node#rpc-node). 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:
-
    - **From the Solidity Reference page:** Find the `FastUpdateIncentiveManager` address for each network on the [Solidity Reference](/ftso/solidity-reference) page.
 
    **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](/network/guides/flare-for-javascript-developers#make-query)
      - [Python](/network/guides/flare-for-python-developers#make-query)

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

@@ -31,7 +31,6 @@ This guide provides code examples demonstrating how to read FTSOv2 feed configur
 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 RPC node](/run-node#rpc-node). 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:
-
    - **From the Solidity Reference page:** Find the `FastUpdatesConfiguration` address for each network on the [Solidity Reference](/ftso/solidity-reference) page.
 
      **OR**

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

@@ -31,7 +31,6 @@ This guide provides code examples demonstrating how to read FTSOv2 feeds offchai
 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 RPC node](/run-node#rpc-node). 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:** Feeds are served on the `FtsoV2` contract, whose address varies by network. You can obtain this address in two ways:
-
    - **From the Solidity Reference page:** Find the `FtsoV2` address for each network on the [Solidity Reference](/ftso/solidity-reference) page.
 
      **OR**

docs/ftso/scaling/3-anchor-feeds.mdx

@@ -14,7 +14,6 @@ Scaling's anchor feeds update every 90 seconds with each new voting epoch on Fla
 Each anchor feed is uniquely identified by an ID composed of three components in a structured encoding process:
 
 1. **Category:** Indicates the type of asset:
-
    - Crypto: `01`
    - Forex: `02`
    - Commodity: `03`

docs/network/0-overview.mdx

@@ -335,7 +335,6 @@ Discover suitable options for your needs on the [Flare Wallets](https://flare.ne
 - **Transaction format:** Matches Ethereum, complies with [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718), encoded with [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/).
 
 - **Transaction fees:**
-
   - **Type0** (Legacy) - Fee is calculated as `gasUsed * gasPrice`.
 
   - **Type2** (EIP-1559) - Fee is calculated as `(baseFee + priorityFee) * gas`. Both the base and priority fees are burned.
@@ -363,7 +362,6 @@ Discover suitable options for your needs on the [Flare Wallets](https://flare.ne
 - **Transaction ordering:** Determined by the block proposer (leader), the default behavior is priority gas auction.
 
 - **Participants (Validators):**
-
   - Nodes must meet a [minimum self-bond requirement](https://proposals.flare.network/FIP/FIP_5.html) (defined by governance) to become validators.
   - Validators participate in consensus voting and are randomly selected as leaders to propose new blocks, weighted by their total stake (self-bond + delegated stake).
   - The network currently features [around 90 validators](https://flarescan.com/validators) (median stake ≈0.7%, max stake ≈3.3%).
@@ -383,7 +381,7 @@ Discover suitable options for your needs on the [Flare Wallets](https://flare.ne
 Integrating Flare is similar to integrating Ethereum or other EVM chains.
 To add it to your exchange set up an [RPC node](/run-node#rpc-node) and use the appropriate [network configuration](#configuration) for Flare Mainnet.
 
-Additional resources: [Flare Media Kit](https://flare.network/media/), [go-flare source code](https://github.com/flare-foundation/go-flare)
+Additional resources: [Flare Brand Kit](https://flare.network/media/), [go-flare source code](https://github.com/flare-foundation/go-flare)
 
 :::
 

docs/network/fsp/2-rewarding.mdx

@@ -118,7 +118,6 @@ Once claimed, both the unclaimed amount and weight are reduced accordingly, and
 Sub-protocols are designed to encourage fast signature deposition and finalization:
 
 1. **Signing Deposition Rewards**:
-
    - Data providers submitting signatures within a grace period (10s) from the signature start time will automatically receive rewards.
    - Signatures submitted until the block of finalization are also rewarded.
    - If finalization happens after a **hard limit**, the end of the voting round during which the signing round started, then only those signatures submitted before the hard limit are considered for rewards, and only if they exceed a 30% weight threshold.

docs/network/guides/gasless-usdt0-transfers.mdx

@@ -107,7 +107,6 @@ The relayer is a Node.js Express service responsible for submitting the user's s
    ```
 
 2. Develop your relayer script (`Relayer.ts`). This script will:
-
    1. **Connect** to Flare using `JsonRpcProvider`, create a `Wallet` from `RELAYER_PRIVATE_KEY`, and instantiate the USD₮0 contract with that wallet.
    2. **Spin up an Express server** with CORS and JSON parsing.
    3. **Expose a health-check** at `GET /` to confirm the service is running.
@@ -149,7 +148,6 @@ The frontend allows users to authorize transfers without directly paying gas. It
    ```
 
 2. Develop the frontend component (`App.tsx`). The main application component will handle:
-
    1. **Connect the wallet** (`window.ethereum`) and request an account.
    2. **Instantiate** an `ethers.BrowserProvider` and `Signer`.
    3. **Fetch** the token's EIP-712 domain (name, version, chainId, contract).