Merge branch 'main' into fixes

dineshpinto · web-flow · commit 45aa1948d39e · 2025-07-21T18:08:06.000+04:00
diff --git a/docs/fassets/1-overview.mdx b/docs/fassets/1-overview.mdx
@@ -38,7 +38,6 @@ Anyone on the Flare blockchain can mint FAssets, which are wrapped versions of o
 ### Minting
 
     - A user (minter) selects an agent and pays a fee to reserve collateral.
-    - If the agent requires a handshake, the user's address is verified before proceeding with collateral reservation.
     - The user sends the underlying asset (e.g., BTC) to the agent.
     - The FDC verifies the transaction.
     - The equivalent FAssets (e.g., FBTC) are minted as ERC-20 tokens on Flare.
diff --git a/docs/fassets/3-minting.mdx b/docs/fassets/3-minting.mdx
@@ -105,24 +105,6 @@ The executor is the actor who submits the payment proof to the Asset Manager, fi
 
 This design ensures timely and reliable minting finalization without relying on a centralized party.
 
-### Trailing Fees
-
-To ensure that agents and collateral pool providers receive steady income, the FAsset system offers an option to enable FAsset token transfer fees, also known as trailing fees.
-
-Whenever FAssets are transferred, a small proportional fee is deducted and contributed to a common pool. In a regular transfer, this fee is subtracted from the payment, meaning the sender pays the exact amount specified in the transfer request, while the receiver ends up receiving a slightly lower amount.
-
-There is also a method where the receiver gets the exact amount specified in the call, while the sender pays more. The fee percentage is a system setting and is typically quite small.
-
-The fees are collected over a certain period, known as an epoch, after which they are distributed among all agents in proportion to each agent's average backed amount during that epoch.
-
-An agent can claim their portion of the fees for an epoch at any time after the epoch ends and before it expires. When making a claim, the fee is distributed between the agent and the pool in the same manner as the minting fee, based on the agent's settings.
-
-## Handshake
-
-Certain jurisdictions may require agents to confirm that those minting or redeeming assets are not engaged in illegal activities. Although the FAsset system does not impose this requirement, it does provide agents with the option to utilize an external service to verify the identities of minters and redeemers before proceeding with minting or redemption.
-
-To enable the handshake, the agent must configure this setting in the agent settings. Once this is enabled, minting and redemption will involve an additional step.
-
 ### Minting
 
 The FAssets agent verifies the minter after the user completes the collateral reservation and pays the collateral reservation fee. The agent is responsible for confirming or rejecting the minter's status. If the agent does not respond within a certain timeframe, the minter has the option to cancel the reservation and receive a full refund of the collateral reservation fee.
@@ -133,16 +115,6 @@ Users must wait up to 60 seconds before they can cancel their request. If the ag
 
 When the agent rejects the minter's request or the minter decides to cancel, the minter will receive a refund of the collateral reservation fee, minus a small percentage (e.g., 5%) that is burned. This burned amount is designed to prevent abuse of the agent by stopping someone from repeatedly reserving collateral from a sanctioned address. If the burned percentage were zero, an attacker could exploit the system without any cost.
 
-### Redemption
-
-The agent has a few minutes to verify the redeemer's addresses and either approve or reject the redemption. If rejected, another agent can take over. If no one takes over, the minter receives the full amount plus a small premium from the rejecting agent, with the premium for a handshake rejection being smaller than for a redemption default.
-
-:::info
-
-An agent may only fulfill part of a request due to insufficient minting or too many small tickets. In these situations, the system allows for a “partial takeover”, where the remaining portion can either be taken over by another agent or covered by collateral from the agent who declined the redemption.
-
-:::
-
 ## Payment Failure
 
 To finalize the minting, the minter must pay the agent on the underlying chain and prove the payment was received.
diff --git a/docs/fassets/7-operational-parameters.mdx b/docs/fassets/7-operational-parameters.mdx
@@ -52,10 +52,6 @@ To get the default agent settings, you need to call the `getSettings` function o
 
 <OperationalParameters sectionTitle="Transfer Fees" />
 
-### Handshake
-
-<OperationalParameters sectionTitle="Handshake" />
-
 ## Default Agent Settings
 
 To get the default agent settings, you need to call the `getAgentInfo` function on the `IAssetManager` interface. Read more about the `IAssetManager` interface [here](/fassets/reference/IAssetManager).
diff --git a/docs/fassets/developer-guides/7-fassets-redeem.mdx b/docs/fassets/developer-guides/7-fassets-redeem.mdx
@@ -309,9 +309,6 @@ The FAssets agent should perform the redemption, and the user must retrieve the
 If the agent is unable to redeem the assets on the underlying chain in the specified time.
 In that case, the user can execute the [`redemptionPaymentDefault`](/fassets/reference/IAssetManager#redemptionpaymentdefault) function to receive compensation from the agent's collateral.
 
-If the agent rejects the redemption request and no other agent takes over the redemption, the redeemer or appointed executor calls [`rejectedRedemptionPaymentDefault`](/fassets/reference/IAssetManager#rejectedredemptionpaymentdefault) method and receives payment in collateral.
-The agent can also call default if the redeemer is unresponsive to payout the redeemer and free the remaining collateral.
-
 ## Next Steps
 
 :::tip
diff --git a/docs/fassets/guides/4-custom-handshake.mdx b/docs/fassets/guides/4-custom-handshake.mdx
diff --git a/docs/fassets/guides/4-faq.mdx b/docs/fassets/guides/4-faq.mdx
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 5
+sidebar_position: 4
 slug: faq
 title: FAssets Agent FAQs
 description: Frequently Asked Questions by FAssets Agents.
diff --git a/docs/fassets/guides/5-export-private-keys.mdx b/docs/fassets/guides/5-export-private-keys.mdx
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 6
+sidebar_position: 5
 slug: export-private-keys
 title: Export Private Keys
 description: Export private keys for minting and redeeming
diff --git a/docs/fassets/guides/6-agent-bot-notifications.mdx b/docs/fassets/guides/6-agent-bot-notifications.mdx
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 7
+sidebar_position: 6
 slug: agent-bot-notifications
 title: Agent Bot Notifications
 description: Learn how to set up agent bot notifications for FAssets.
diff --git a/docs/fassets/guides/7-infrastructure.mdx b/docs/fassets/guides/7-infrastructure.mdx
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 8
+sidebar_position: 7
 slug: infrastructure
 title: FAssets Agent Infrastructure
 description: Configuring the FAsset Bot to Use Custom Infrastructure
diff --git a/docs/fassets/reference/IAssetManager.mdx b/docs/fassets/reference/IAssetManager.mdx
@@ -147,62 +147,16 @@ Parameters:
 - `_lots`: Number of lots for which to reserve collateral
 - `_maxMintingFeeBIPS`: Maximum minting fee (BIPS) that can be charged by the agent - best practice is to copy the current agent's published fee; used to prevent agent from front-running reservation request and increasing fee
 - `_executor`: Account that is allowed to execute minting (besides minter and agent)
-- `_minterUnderlyingAddresses`: Array of minter's underlying addresses - needed only if handshake is required
 
 ```solidity
 function reserveCollateral(
     address _agentVault,
     uint256 _lots,
     uint256 _maxMintingFeeBIPS,
     address payable _executor,
-    string[] calldata _minterUnderlyingAddresses
 ) external payable;
 ```
 
-### `approveCollateralReservation`
-
-Agent approves the collateral reservation request after checking the minter's identity.
-
-Parameters:
-
-- `_collateralReservationId`: Collateral reservation ID
-
-```solidity
-function approveCollateralReservation(
-    uint256 _collateralReservationId
-) external notEmergencyPaused;
-```
-
-### `rejectCollateralReservation`
-
-Agent rejects the collateral reservation request after checking the minter's identity.
-The collateral reservation fee is returned to the minter.
-
-Parameters:
-
-- `_collateralReservationId`: Collateral reservation ID
-
-```solidity
-function rejectCollateralReservation(
-    uint256 _collateralReservationId
-) external nonReentrant;
-```
-
-### `cancelCollateralReservation`
-
-Minter cancels the collateral reservation request if the agent didn't respond in time.
-The collateral reservation fee is returned to the minter.
-
-Parameters:
-
-- `_collateralReservationId`: Collateral reservation ID
-
-```solidity
-function cancelCollateralReservation(
-    uint256 _collateralReservationId
-) external nonReentrant;
-```
-
 ## Execute Minting
 
 ### `executeMinting`
@@ -267,21 +221,6 @@ function redemptionPaymentDefault(
 ) external;
 ```
 
-### `rejectedRedemptionPaymentDefault`
-
-If the agent rejected the redemption request and no other agent took over the redemption, the redeemer or appointed executor calls this method and receives payment in collateral.
-The agent can also call default if the redeemer is unresponsive, to payout the redeemer and free the remaining collateral.
-
-Parameters:
-
-- `_redemptionRequestId`: ID of an existing redemption request
-
-```solidity
-function rejectedRedemptionPaymentDefault(
-    uint256 _redemptionRequestId
-) external;
-```
-
 ## Core Vault Settings
 
 Reference for managing and interacting with FAssets `ICoreVaultSettings` contract which is inherited by the `IAssetManager` contract.
diff --git a/docs/fassets/reference/IAssetManagerEvents.mdx b/docs/fassets/reference/IAssetManagerEvents.mdx
@@ -194,3 +194,17 @@ event RedemptionTicketUpdated(
     uint256 indexed redemptionTicketId,
     uint256 ticketValueUBA);
 ```
+
+### `RedemptionPerformed`
+
+The event is emitted when the agent provides proof of redemption payment, and the agent's collateral is released.
+
+```solidity
+event RedemptionPerformed(
+    address indexed agentVault,
+    address indexed redeemer,
+    uint64 indexed requestId,
+    bytes32 transactionHash,
+    uint256 redemptionAmountUBA,
+    int256 spentUnderlyingUBA);
+```
diff --git a/docs/fdc/guides/_available_testnet.mdx b/docs/fdc/guides/_available_testnet.mdx
@@ -0,0 +1,5 @@
+:::info
+
+The `Web2Json` attestation type is currently only available on the Flare Testnet Coston2 .
+
+:::
diff --git a/docs/fdc/guides/foundry/web-2-json-for-custom-api.mdx b/docs/fdc/guides/foundry/web-2-json-for-custom-api.mdx
@@ -7,11 +7,15 @@ keywords: [ethereum, flare-data-connector, evm, flare-network]
 sidebar_position: 12
 ---
 
+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 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.
 
+<AvailableTestnet />
+
 ## Necessary modifications
 
 In order to run on custom data, the example code needs to be modified in four places only.
diff --git a/docs/fdc/guides/foundry/web-2-json.mdx b/docs/fdc/guides/foundry/web-2-json.mdx
@@ -7,9 +7,13 @@ keywords: [ethereum, flare-data-connector, evm, flare-network]
 sidebar_position: 8
 ---
 
+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).
 
+<AvailableTestnet />
+
 We will now demonstrate how the FDC protocol can be used to collect the data of a given [Star Wars API](https://swapi.dev/) request.
 It will be a `GET` request to the URL `https://swapi.info/api/peaople/3`.
 The same procedure works for all public APIs.
diff --git a/docs/fdc/guides/hardhat/web-2-json-for-custom-api.mdx b/docs/fdc/guides/hardhat/web-2-json-for-custom-api.mdx
@@ -7,11 +7,15 @@ keywords: [ethereum, flare-data-connector, evm, flare-network]
 sidebar_position: 12
 ---
 
+import AvailableTestnet from "../_available_testnet.mdx";
+
 The [Web2Json guide](/fdc/guides/hardhat/web-2-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 Hardhat starter](https://github.com/flare-foundation/flare-hardhat-starter) repository.
 In this guide, we will see how the `Web2Json` example script within the Flare Hardhat 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.
 
+<AvailableTestnet />
+
 ## Necessary modifications
 
 In order to run on custom data, the example code needs to be modified in four places only.
diff --git a/docs/fdc/guides/hardhat/web-2-json.mdx b/docs/fdc/guides/hardhat/web-2-json.mdx
@@ -8,9 +8,13 @@ sidebar_position: 8
 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).
 
+<AvailableTestnet />
+
 We will now demonstrate how the FDC protocol can be used to collect the data of a given [Star Wars API](https://swapi.dev/) request.
 The request we will be making is `https://swapi.info/api/people/3`.
 The same procedure works for all public APIs.
diff --git a/docs/run-node/2-from-source.mdx b/docs/run-node/2-from-source.mdx
@@ -184,7 +184,7 @@ If the node gets stuck during bootstrap (or it takes far longer than the estimat
 
 ### CLI parameters
 
-These are some of the most relevant CLI parameters you can use. Read more about them in the [Avalanche documentation](https://docs.avax.network/nodes/maintain/avalanchego-config-flags).
+These are some of the most relevant CLI parameters you can use. Read more about them in the [Avalanche documentation](https://build.avax.network/docs/nodes/configure/configs-flags).
 
 {/* prettier-ignore */}
 - [`--bootstrap-ips`](https://build.avax.network/docs/nodes/configure/configs-flags#--bootstrap-ips-string),
@@ -205,6 +205,10 @@ These are some of the most relevant CLI parameters you can use. Read more about
 
 #### Sample JSON configuration:
 
+Most of the C-Chain configuration options can be found in the [Avalanche C-Chain Configuration docs](https://build.avax.network/docs/nodes/chain-configs/c-chain).
+Note that the default values are overridden only if specified in the given config file.
+Only provide values which differ from the defaults to avoid issues with future updates.
+
 ```json title="<chain-config-dir>/C/config.json"
 {
   "snowman-api-enabled": false,
diff --git a/docs/run-node/3-using-docker.mdx b/docs/run-node/3-using-docker.mdx
@@ -105,6 +105,9 @@ Mounting these allows you to manage them directly without entering the container
    ```
 
 2. **Create configuration file:** Create a `config.json` file. This example provides a standard configuration for a public RPC node.
+   Most of the C-Chain configuration options can be found in the [Avalanche C-Chain Configuration docs](https://build.avax.network/docs/nodes/chain-configs/c-chain).
+   Note that the default values are overridden only if specified in the given config file.
+   Only provide values which differ from the defaults to avoid issues with future updates.
 
    ```json title="/opt/flare/conf/config.json"
    {
diff --git a/docs/run-node/4-register-validator.mdx b/docs/run-node/4-register-validator.mdx
@@ -67,6 +67,9 @@ Failure to implement these measures significantly increases the risk to your nod
 
 As described in [Secure the node](#secure-the-node), a validator node should have minimal APIs enabled.
 Below is a sample `config.json` demonstrating a secure configuration with limited `eth-apis` and disabled admin APIs:
+Most of the C-Chain configuration options can be found in the [Avalanche C-Chain Configuration docs](https://build.avax.network/docs/nodes/chain-configs/c-chain).
+Note that the default values are overridden only if specified in the given config file.
+Only provide values which differ from the defaults to avoid issues with future updates.
 
 ```json title="config.json"
 {
diff --git a/src/components/FAssets/operational-parameters.ts b/src/components/FAssets/operational-parameters.ts
