Renaming State Connector to Flare Data Connector

docs/index.md

@@ -51,7 +51,7 @@ Descriptions of Flare’s products
 Quick links:
 
 * [FTSO](https://dev.flare.network/ftso/overview)
-* [State Connector](./tech/state-connector.md)
+* [Flare Data Connector](./tech/data-connector.md)
 * [FAssets](./tech/fassets/index.md)
 
 </div>

docs/products/index.md

@@ -3,7 +3,7 @@
 In this section you can read more about Flare's core protocols and products. 
 
 * [FTSO](../tech/ftso/index.md)
-* [State connector](../tech/state-connector.md)
+* [Flare Data connector](../tech/data-connector.md)
 * [FAssets](../tech/fassets/index.md)
 * [Validator nodes](../tech/validators.md)
 * [API Portal](../tech/api-portal.md)

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

@@ -77,7 +77,7 @@ The following distribution plans were offered. The FIP.01 Distribution Plan was
 
     * 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](glossary.md#inflation) is capped at 5bn `$FLR` per year.
-    * Inflation distribution: 70% to [FTSO](../ftso/index.md) rewards, 20% to [validator](../validators.md) rewards and 10% to the default Attestation Provider Set of the [state connector](../state-connector.md).
+    * Inflation distribution: 70% to [FTSO](../ftso/index.md) rewards, 20% to [validator](../validators.md) rewards and 10% to the default Attestation Provider Set of the [Flare Data connector](../data-connector.md).
 
 ## Launch Phases
 

docs/tech/state-connector.md → docs/tech/data-connector.md

@@ -3,25 +3,25 @@ search:
   boost: 2
 ---
 
-# State Connector
+# Flare Data Connector
 
 ## Introduction
 
-The **State Connector** is a smart contract running on the Flare network that allows anyone to query **non-changing, verifiable information** (such as blockchain or geographic data) from **outside the Flare network**.
-Data that changes, such as the latest BTC to USD conversion rate, and non-verifiable data, such as data behind a paywall, are not available through the State Connector.
+The **Flare Data Connector (FDC)** is a smart contract running on the Flare network that allows anyone to query **non-changing, verifiable information** (such as blockchain or geographic data) from **outside the Flare network**.
+Data that changes, such as the latest BTC to USD conversion rate, and non-verifiable data, such as data behind a paywall, are not available through the Data Connector.
 
-The State Connector accesses data in a **decentralized manner** (no single party is in control of the process) and **securely** (it takes a lot of effort to disrupt the process).
+The Data Connector accesses data in a **decentralized manner** (no single party is in control of the process) and **securely** (it takes a lot of effort to disrupt the process).
 This is accomplished by using a set of **independent attestation providers** which fetch the required information from the world and deliver it to the Flare network.
-The State Connector smart contract then checks if there is **enough consensus** among the received answers and **publishes the results** if so.
+The Data Connector smart contract then checks if there is **enough consensus** among the received answers and **publishes the results** if so.
 
 As an added security measure, individual validators can also define **local attestation providers** which, when in disagreement with the rest, cause the validator to **branch** into an idle, safe state while the situation is resolved.
 
 <figure markdown>
-  ![The State Connector](SC-intro.png){ loading=lazy .allow-zoom width=500px }
-  <figcaption>The State Connector.</figcaption>
+  ![The Data Connector](SC-intro.png){ loading=lazy .allow-zoom width=500px }
+  <figcaption>The Data Connector.</figcaption>
 </figure>
 
-The State Connector can, for instance, **check whether a deposit has been made on another blockchain**, opening the door to more advanced mechanisms like FAssets or bridges.
+The Data Connector can, for instance, **check whether a deposit has been made on another blockchain**, opening the door to more advanced mechanisms like FAssets or bridges.
 
 This page gives technical details about the whole procedure, the different security and scalability measures that have been taken into account in its design and the kind of queries that can be performed.
 
@@ -30,13 +30,13 @@ This page gives technical details about the whole procedure, the different secur
 This is how user queries are processed. The following sections contain more details.
 
 <figure markdown>
-  ![State Connector procedure.](SC-architecture.png){ loading=lazy .allow-zoom }
-  <figcaption>State Connector procedure overview.</figcaption>
+  ![Data Connector procedure.](SC-architecture.png){ loading=lazy .allow-zoom }
+  <figcaption>Data Connector procedure overview.</figcaption>
 </figure>
 
 ### 1. Request
 
-Anybody, be it a smart contract running on Flare or an application, can **request the attestation of a specific event** from the State Connector.
+Anybody, be it a smart contract running on Flare or an application, can **request the attestation of a specific event** from the Data Connector.
 
 Requests are **yes/no questions** regarding things that happened outside the Flare network, for example, "Has transaction 0xABC been confirmed on the Bitcoin network enough times?".
 The answers, though, might contain any kind of additional data attached, like the content of transaction 0xABC, for example.
@@ -47,7 +47,7 @@ Section [Adding New Attestation Types](#adding-new-attestation-types) below cont
 
 ### 2. Request forwarding
 
-The State Connector simply **forwards the request** to all connected attestation providers through an [EVM](glossary.md#evm) event.
+The Data Connector simply **forwards the request** to all connected attestation providers through an [EVM](glossary.md#evm) event.
 Therefore, the request is **not** stored on the blockchain and **its gas cost is very low** for the requester.
 
 ### 3. Data retrieval
@@ -63,7 +63,7 @@ To prevent attestation providers from peeking at each other's answers, these are
 
 ??? example "Submitting an attestation (For attestation provider developers)"
 
-    Attestation providers use the `submitAttestation` method (#3) of the [StateConnector contract](https://gitlab.com/flarenetwork/flare-smart-contracts/-/blob/master/contracts/genesis/implementation/StateConnector.sol#L92):
+    Attestation providers use the `submitAttestation` method (#3) of the [Data Connector contract](https://gitlab.com/flarenetwork/flare-smart-contracts/-/blob/master/contracts/genesis/implementation/StateConnector.sol#L92):
 
     ```solidity
     function submitAttestation(
@@ -84,7 +84,7 @@ To prevent attestation providers from peeking at each other's answers, these are
 If **at least 50%** of the attestation providers submitted the same answer, it is made public.
 Otherwise, **no consensus is achieved**: requests remain **unanswered** and must be issued again.
 
-**The answers are stored in the State Connector smart contract for a week**, where anybody can read them, including the original requester.
+**The answers are stored in the Data Connector smart contract for a week**, where anybody can read them, including the original requester.
 
 ## Attestation Protocols
 
@@ -105,9 +105,9 @@ Phases happen in 90-second windows, and the Choose and Commit phases share the s
   <figcaption>The Collect-Choose-Commit-Reveal (CCCR) protocol.</figcaption>
 </figure>
 
-* **Collect phase**: Users send their requests to the State Connector contract which forwards them to every attestation provider.
+* **Collect phase**: Users send their requests to the Data Connector contract which forwards them to every attestation provider.
 * **Choose phase**: Attestation Providers vote on which requests they will be able to answer in the current round.
-* **Commit phase**: Attestation providers send **obfuscated** answers to the State Connector, so they cannot cheat by peeking at each other's submissions.
+* **Commit phase**: Attestation providers send **obfuscated** answers to the Data Connector, so they cannot cheat by peeking at each other's submissions.
 * **Reveal phase**: Attestation providers send the **deobfuscation key** so their previous answers are revealed.
   When all data is available, answers are made public if there is enough consensus.
 
@@ -128,7 +128,7 @@ This means that new requests can be made without waiting for the previous ones t
 
 Each round, attestation providers build a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) with the hashes of **all valid answers** to the requests that were agreed upon during [the "Choose" phase](https://github.com/flare-foundation/attestation-client/blob/main/docs/attestation-protocol/bit-voting.md).
 The obtained **Merkle root** is then called the **Attestation Proof**, since it is proof of the presence of each individual answer.
-Finally, the attestation proof is submitted to the State Connector for consensus evaluation.
+Finally, the attestation proof is submitted to the Data Connector for consensus evaluation.
 
 <figure markdown>
   ![Attestation Proof packing using a Merkle tree](SC-attestation-provider.png){ loading=lazy .allow-zoom }
@@ -139,7 +139,7 @@ This allows **any number of requests to be answered with a single hash**, greatl
 Furthermore, the gas cost for attestation providers is **constant** each round, no matter how many requests they are answering.
 
 A request is only **valid** (and therefore added to the proof) if it is well-formed and it **matches reality**.
-Different providers might have different views on what reality is, and this is why the State Connector runs a consensus algorithm on the received answers.
+Different providers might have different views on what reality is, and this is why the Data Connector runs a consensus algorithm on the received answers.
 
 Additionally, the allowed request types are **carefully designed to minimize the probability of contention**.
 For example, requiring some time for **transactions to settle** before inquiring about them, and forcing requests to include the hash of a later block that confirms the transaction.
@@ -148,7 +148,7 @@ Attestation providers keep the actual retrieved data for a week, in case it cont
 Users can request this data directly from the providers through the [Proof API](https://github.com/flare-foundation/attestation-client/blob/main/docs/end-users/apis.md#proof-api-on-attestation-provider-server).
 
 !!! note
-    Please note that this data is **safe to use** even though it is obtained directly from the provider, because **its hash is consistent with the Attestation Proof** agreed upon by the State Connector's consensus.
+    Please note that this data is **safe to use** even though it is obtained directly from the provider, because **its hash is consistent with the Attestation Proof** agreed upon by the Data Connector's consensus.
 
     See the "Proof unpacking" box below to learn how to verify the data.
 
@@ -160,11 +160,11 @@ Additional points worth noting:
 
 * **Hashes are sorted** before being added to the tree, just to have a **consistent ordering** (albeit arbitrary).
 
-* The exact way in which the root hash is calculated can be changed without impacting the State Connector contract, which will continue to vote only on the hash value.
+* The exact way in which the root hash is calculated can be changed without impacting the Data Connector contract, which will continue to vote only on the hash value.
 
 ## Branching Protocol
 
-Besides the consensus algorithm that runs on all received attestations, the State Connector provides **one further security mechanism**:
+Besides the consensus algorithm that runs on all received attestations, the Data Connector provides **one further security mechanism**:
 the ability of any individual validator node to **fork and halt execution** if attestation providers specially trusted by it disagree with the majority.
 
 ### Attestation Provider Sets
@@ -173,14 +173,14 @@ To achieve this, two **sets** of attestation providers are defined:
 
 * **Default attestation providers set**
 
-    Anybody can submit attestations to the State Connector, but the contract will only accept submissions from attestation providers in the [**default set**].
+    Anybody can submit attestations to the Data Connector, but the contract will only accept submissions from attestation providers in the [**default set**].
     **Every validator node** in the Flare network relies on this set.
 
 * **Local attestation providers set**
 
     Additionally, each node operator can provide a list of **local** attestation providers to be accepted besides the ones from the default set.
 
-    Local providers are the same kind of nodes as default providers, and they are treated exactly the same by the State Connector.
+    Local providers are the same kind of nodes as default providers, and they are treated exactly the same by the Data Connector.
     Furthermore, providers can belong to both sets.
 
 <figure markdown>
@@ -203,22 +203,22 @@ To achieve this, two **sets** of attestation providers are defined:
 This gives local attestation providers the capacity to **stop results from being approved** if they don't agree with their own observations.
 Ideally, local providers are managed by the same entity controlling the validator node using them, so they can be **trusted implicitly**.
 
-As a consequence of different validators using different attestation providers, sometimes State Connector queries can get different results on some validators, which naturally leads to **chain forks**.
+As a consequence of different validators using different attestation providers, sometimes Data Connector queries can get different results on some validators, which naturally leads to **chain forks**.
 
 Typically, blockchains allow every branch in a fork to **coexist and grow independently**, until the discrepancy is detected and resolved.
 At that point, any branches deemed invalid are removed and all the validators that were following them experience a **rollback**:
-All transactions that happened after the fork are **reverted** and the state of those validators is synchronized with the rest of the network.
+All transactions that happened after the fork are **reverted** and the Data of those validators is synchronized with the rest of the network.
 
-When dealing with forks caused by the State Connector, the Flare network implements an **extra security measure**:
+When dealing with forks caused by the Data Connector, the Flare network implements an **extra security measure**:
 Validators whose local attestation providers disagree with the default set **halt execution after the fork**, ensuring that they will not suffer any rollback once the fork is resolved.
 
 In other words, these validators remain in a **safe state** in which the disputed query is **undecided** and therefore no action is taken based on it.
 
 !!! example
 
     <figure markdown>
-      ![State Connector forks](SC-local-AP-2.png){ loading=lazy .allow-zoom }
-      <figcaption>State Connector forks.</figcaption>
+      ![Data Connector forks](SC-local-AP-2.png){ loading=lazy .allow-zoom }
+      <figcaption>Data Connector forks.</figcaption>
     </figure>
 
     In the **example picture**, all validator nodes use the attestation providers from the default set (not shown), but validators on the rightmost column, **additionally, employ local providers**.
@@ -303,7 +303,7 @@ This type can serve as proof that a user's payment obligations to a DeFi protoco
 
 ## Adding New Attestation Types
 
-New real-world event-type integrations are introduced to the State Connector via acceptance by the default attestation providers, without requiring any changes to the core voting or branching protocols described above.
+New real-world event-type integrations are introduced to the Data Connector via acceptance by the default attestation providers, without requiring any changes to the core voting or branching protocols described above.
 This enables rapid deployment of new use-cases without any validator-level code changes.
 
-See the [state-connector-attestation-types repository](https://github.com/flare-foundation/songbird-state-connector-protocol) for more information.
+See the [data-connector-attestation-types repository](https://github.com/flare-foundation/songbird-state-connector-protocol) for more information.

docs/tech/fassets/collateral.md

@@ -42,7 +42,7 @@ If governance deprecates a type, agents must switch to a supported type.
 Each vault is associated with a single, unique address on the underlying chain called the agent's underlying address.
 It receives underlying assets when they are minted into FAssets and sends underlying assets to the redeemer's address when they are redeemed.
 
-When an agent creates a vault, the underlying address is checked for validity using the State Connector.
+When an agent creates a vault, the underlying address is checked for validity using the Flare Data Connector.
 Otherwise, malicious agents could provide an address that systematically blocks payments and exploit the [minting process](./minting.md) to their advantage.
 
 ### Pool Collateral

docs/tech/fassets/index.md

@@ -26,7 +26,7 @@ You can then use these FAssets in smart contracts and decentralized applications
 The system is enabled by these Flare protocols:
 
 * [FTSO](../ftso/index.md), whose contracts provide decentralized price feeds for multiple tokens.
-* [State Connector](../state-connector.md), which brings payment data from any connected chain into Flare.
+* [Flare Data Connector](../data-connector.md), which brings payment data from any connected chain into Flare.
 
 FAssets are backed by collateral provided by entities in the following roles that maintain the infrastructure of the system and hold Flare's native assets.
 All these entities are independent of the Flare Foundation.