Merge branch 'FLR-934-glossary-updates' into 'main'

Flr 934 glossary updates

See merge request flarenetwork/docs-team/docs!5

docs/dev/reference/ftso.md

@@ -17,7 +17,7 @@ Using prices as an example, the following diagram shows the flow of data, querie
 
 The following list describes the most relevant contracts and their purposes:
 
-* **[FTSO](Ftso.md)**: Each data type is handled by its own FTSO contract, including calculation of the filtered feed.
+* **[FTSO](Ftso.md)**: Each data type is handled by its own FTSO contract, including calculation of the filtered [data feed](glossary.md#data_feed).
 
     To retrieve information about a data type, access this contract.
 

docs/dev/tutorials/ftso/getting-data-feeds.md

@@ -7,7 +7,7 @@ search:
 
 # Getting FTSO Data Feeds
 
-This tutorial shows the simplest way to use the [FTSO system](../../../tech/ftso.md) to retrieve a specific data feed, like the price of Bitcoin.
+This tutorial shows the simplest way to use the [FTSO system](../../../tech/ftso.md) to retrieve a specific [data feed](glossary.md#data_feed), like the price of Bitcoin.
 
 The tutorial shows:
 

docs/infra/data/managing-ecosystem/exploring-collusion.md

@@ -128,7 +128,7 @@ This section describes the similarity metric used to obtain the [cluster map](#c
 To estimate collusion, the similarity metric assigns a value of similarity between data submitted by pairs of data providers.
 As previously stated, collusion between data providers is evident when they submit similar data that is relatively distant from the median because similar algorithms will make similar mistakes.
 
-For data providers DP1 and DP2 during a given range of price epoch for comparison, the prices `P1` and `P2` submitted for each cryptocurrency pair and epoch are checked.
+For data providers DP1 and DP2 during a given range of price epoch for comparison, the prices `P1` and `P2` submitted for each cryptocurrency [pair](glossary.md#price_pair) and epoch are checked.
 If both prices are available alongside the median price `M`, the contribution to the collusion metric is calculated in the following way:
 
 ``` js

docs/tech/archive/flare-launch-process.md

@@ -76,7 +76,7 @@ The following distribution plans were offered. The FIP.01 Distribution Plan was
 * **FIP.01 Distribution Plan**:
 
     * The new airdrop was sent to those who registered for the `$FLR` distribution upon the TDE, and the DIP was distributed to all `$FLR` token holders (actually, wrapped `$FLR` holders) over 36 months. Flare employees and companies were excluded.
-    * Inflation is 10% of available supply in the first year, then 7% the following year, 5% the year after and in perpetuity, except that from year 3 onwards inflation is capped at 5bn `$FLR` per year.
+    * Inflation is 10% of available supply in the first year, then 7% the following year, 5% the year after and in perpetuity, except that from year 3 onwards [inflation](glossary.md#inflation) is capped at 5bn `$FLR` per year.
     * Inflation distribution: 70% to [FTSO](../ftso.md) rewards, 20% to [validator](../validators.md) rewards and 10% to the default Attestation Provider Set of the [state connector](../state-connector.md).
 
 ## Launch Phases

docs/tech/automatic-claiming.md

@@ -21,7 +21,7 @@ Instead, users can enlist the services of **executors** to claim for them, putti
 Automatic claiming through an executor saves user time and inconvenience, optimizes the opportunity for compound interest, and avoids unnecessary exposure of users' cold wallets.
 
 Automatic claiming is secure because the executor cannot claim to any address but the ones the user provides.
-It is trustless (does not require trust) because it is managed by a smart contract, not the executor.
+It is [trustless](glossary.md#trustless) (does not require trust) because it is managed by a smart contract, not the executor.
 
 For executors, automatic claiming is an opportunity to earn a fee for performing claiming as a service to users.
 
@@ -81,7 +81,7 @@ With a registered executor, all agreements happen on-chain.
 Here is how the registered claiming process works, with applications performing these actions on behalf of executors and users:
 
 1. Executors who want to make themselves publicly available to users register as executors, paying a registration fee.
-The fee to register as an executor is burned.
+The fee to register as an executor is [burned](glossary.md#burn).
 2. Registered executors post their fee for claiming rewards.
 3. Users who have accrued rewards and want an executor to claim on their behalf can choose from the list of registered executors.
 4. These users pay a setup fee to enable a registered executor to claim their rewards.

docs/tech/fassets/minting.md

@@ -61,7 +61,7 @@ The following fees are paid to mint FAssets:
   { #crf }
 
     When the minter does not pay on the underlying chain, this fee compensates the agent and the CPT holders for the time their collateral was locked while the mint processed.
-    If the minter pays on the underlying chain, the CRF is burned.
+    If the minter pays on the underlying chain, the CRF is [burned](glossary.md#burn).
 
     For underlying chains on which proving payments takes a long time, the fee might be higher than the fee on chains that quickly prove payments.
 

docs/tech/fassets/redemption.md

@@ -24,7 +24,7 @@ This is the summary of the redemption process:
     The number of chosen redemption tickets is capped to avoid high gas consumption.
     If the redemption amount requires too many tickets, only a partial redemption is done.
 
-2. The system burns FAssets from the redeemer’s account in the amount of the total of the selected redemption tickets.
+2. The system [burns](glossary.md#burn) FAssets from the redeemer’s account in the amount of the total of the selected redemption tickets.
     If the redeemer's account does not contain enough FAssets, the redemption fails immediately.
 
 3. Each chosen ticket belongs to an agent.

docs/tech/flare.md

@@ -9,29 +9,29 @@ search:
     ![Flare logo](logo-FLR.png){ .allow-zoom }
 
 Flare is the blockchain for data.
-It is a [layer 1](glossary.md#layer1), EVM smart contract platform designed to expand the utility of blockchain.
+It is a [layer 1](glossary.md#layer1), [EVM](glossary.md#evm) [smart contract](glossary.md#smart_contract) platform designed to expand the utility of blockchain.
 
 Flare's aim is to provide data as a public good, meaning that data is not controlled by a centralized entity and is available to all.
-The infrastructure providers, which perform doubly as [validators](../tech/validators.md) and [data providers](../infra/data/operating.md), enable two native oracles, the [FTSO](./ftso.md) and the [State Connector](./state-connector.md).
-This native processing provides developers on Flare with efficient access to large amounts of data and data proofs at minimal cost.
+The infrastructure providers, which perform doubly as [validators](../tech/validators.md) and [data providers](../infra/data/operating.md), enable two native [oracles](glossary.md#oracle), the [FTSO](./ftso.md) and the [State Connector](./state-connector.md).
+This [native](glossary.md#native) processing provides developers on Flare with efficient access to large amounts of data and [data proofs](glossary.md#data_proof) at minimal cost, with which to build software on the platform.
 
-By giving developers trustless access to the broadest range of data, Flare can advance the development of more blockchain use cases where data is important, such as in DeFi, gaming, NFT, music, and social networks.
+By giving developers [trustless](glossary.md#trustless) access to the broadest range of data needed by the software they build, Flare can advance the development of more blockchain use cases where data is important, such as in [DeFi](glossary.md#defi), gaming, [NFT](glossary.md#nft), music, social networks, Real World Assets [(RWAs)](glossary.md#rwa), Machine Learning (ML), and Artificial Intelligence (AI).
 
 ## Flare Protocols
 
 Flare has the following native data acquisition protocols at these stages of development:
 
-* The **[Flare Time-Series Oracle (FTSO)](./ftso.md)** provides continuous estimations of changing data, such as price pairs.
+* The **[Flare Time-Series Oracle (FTSO)](./ftso.md)** provides continuous estimations of changing data, such as [price pairs](glossary.md#price_pair).
 * The **[State Connector](./state-connector.md)** allows querying of verifiable, non-changing data from other chains and the internet.
 * The **[FAssets](./fassets/index.md)** system is being developed by Flare Labs. It allows tokens on blockchains that do not support smart contracts to be used trustlessly with smart contracts on the Flare blockchain.
-* Flare **LayerCake** is being developed by Flare Labs to provide a decentralized, trustless bridging system between smart contract networks. For an overview of trustless bridges, see [LayerCake](https://flare.network/layercake/).
+* Flare **LayerCake** is being developed by Flare Labs to provide a [decentralized](glossary.md#decentralized), trustless bridging system between smart contract networks. For an overview of trustless bridges, see [LayerCake](https://flare.network/layercake/).
 
 ## Developing on Flare
 
 Flare developers can work in a familiar Ethereum-like environment.
 It offers the same [API](../apis/index.md) and uses the Ethereum Virtual Machine ([EVM](glossary.md#evm)), so Ethereum's Solidity smart contracts can be used directly.
-Like Ethereum, Flare supports other assets, such as [NFTs](glossary.md#nft).
-See [Developer Docs](../dev/index.md).
+Like Ethereum, Flare supports other assets, such as NFTs.
+See [Getting Started](../dev/getting-started/index.md).
 
 The Flare native currency, `$FLR`, works the same as `$ETH` on the Ethereum blockchain.
 For those contracts that can only work with [ERC-20](glossary.md#erc20) tokens, `$FLR` can be easily [wrapped](../user/wrapping-tokens.md) as `$WFLR`, which is an ERC-20 representation of `$FLR`.

docs/tech/ftso.md

@@ -11,7 +11,7 @@ To achieve a secure, decentralized system, a set of **independent data providers
 
 !!! note "Important"
 
-    When FTSOs were initially designed, they supported only cryptocurrency price pairs. Now, they support all types of data. However, contract names and methods still refer to prices and price epochs, and price pairs are used in the following information to show how FTSOs work.
+    When FTSOs were initially designed, they supported only cryptocurrency [price pairs](glossary.md#price_pair). Now, they support all types of data. However, contract names and methods still refer to prices and price epochs, and price pairs are used in the following information to show how FTSOs work.
 
 The following diagram shows how price pairs are submitted to and filtered by the FTSO system.
 
@@ -144,7 +144,7 @@ Delegating 100% of your vote power to reliable data providers committed to provi
 For the duration of the delegation, you will earn rewards that are commensurate with vote power and the performance of the chosen data providers.
 Rewards accumulate, and they become claimable for each reward epoch that is finalized.
 
-Inflation is distributed to everyone who participates in the FTSO system, which includes data providers and entities that delegate their vote power to the data providers.
+[Inflation](glossary.md#inflation) is distributed to everyone who participates in the FTSO system, which includes data providers and entities that delegate their vote power to the data providers.
 Delegated tokens are **not locked**, meaning that they remain in the user's control and the delegation can be removed at any time.
 
 Any `$WFLR` or `$WSGB` that is newly wrapped, sent, or received will automatically update your actual delegated vote power.
@@ -179,7 +179,7 @@ If you are an advanced user, you can [delegate manually](../user/block-explorers
 
 ## Rewards
 
-A percentage of the annual network **inflation** is reserved to reward FTSO data providers and distributed uniformly among the year's reward epochs.
+A percentage of the annual network **[inflation](glossary.md#inflation)** is reserved to reward FTSO data providers and distributed uniformly among the year's reward epochs.
 The mechanism that distributes rewards to data providers consists of several bands:
 
 * **Primary reward band**: This band rewards [50% of submitted data, weighted by vote power and centered around the median price](#how-results-are-calculated).
@@ -216,7 +216,7 @@ If you delegated to a data provider, the amount of your rewards depends on multi
 You can claim your rewards at the end of each reward epoch.
 
 You must claim your rewards within 90 days of their availability.
-After 90 days, unclaimed rewards on Flare are burned, and on Songbird, they are reallocated.
+After 90 days, unclaimed rewards on Flare are [burned](glossary.md#burn), and on Songbird, they are reallocated.
 
 ### Reward-Claiming Procedure