Ari corrections

docs/Data-Formatting-And-Processing

@@ -0,0 +1,89 @@
+---
+sidebar_position: 4
+sidebar_label: "Data Formatting & Processing"
+---
+
+# Data Flow to the Blockchain: Process and Architecture
+
+## Overview of Data Integration
+
+RedStone’s price feeds are sourced from a wide array of platforms, including centralized exchanges like Binance and Coinbase, decentralized exchanges (DEXs) such as Uniswap and Sushiswap, and price aggregators like CoinMarketCap and CoinGecko. With over 150 integrated sources, RedStone ensures that data is aggregated by independent nodes using methodologies like median, Time-Weighted Average Price (TWAP), and Liquidity-Weighted Average Price (LWAP). These methods focus on capturing accurate prices by accounting for factors such as available liquidity and price averages over specific timeframes.
+
+To maintain data quality, RedStone employs outlier detection mechanisms to filter unexpected values. The processed data is then signed by node operators to guarantee its integrity. These data feeds are distributed through the Streamr decentralized network and open-source gateways, which can be easily deployed if needed.
+
+Data can be pushed to the blockchain by a dedicated relayer operating under predefined conditions (e.g., specific price changes), a bot (e.g., performing liquidations), or even by end users interacting with the protocol. Once inside the protocol, the data is unpacked and cryptographically verified, ensuring the authenticity and accuracy of both its origin and timestamp.
+
+## Data Encoding and Processing
+
+### Context: Understanding Data Transfer to the Blockchain
+
+When transferring data to a blockchain, an additional payload is added to the user’s transaction, which is then processed on-chain. This means that data, such as a cryptocurrency’s price, is embedded within the transaction data. Because blockchains transition from one state to another and contain call data, RedStone can insert its data into the call data of a user’s transaction, effectively recording the data on the blockchain.
+
+### How Data is Encoded Before Blockchain Submission
+
+_Note: All steps are automatically handled by the ContractWrapper, making the process transparent to the end user._
+
+1. **Data Retrieval**: Relevant data is fetched from the data distribution layer, powered by the Streamr network or RedStone gateways.
+2. **Data Packaging**: The data is structured according to the ‘Transaction Payload’ diagram.
+
+<a href="https://raw.githubusercontent.com/redstone-finance/redstone-docs/main/static/img/redstone-tx-wrapping.png">
+ <img src="/img/redstone-tx-wrapping.png" target="_blank"/>
+</a>
+
+3. **Data Submission**: The package is appended to the original transaction message, signed, and submitted to the network.
+
+### On-Chain Data Processing: Unpacking, Verification, and Aggregation
+
+1. **Unpacking**: The appended data packages are extracted from the call data.
+2. **Verification**: Security checks are performed, including signature verification from trusted providers and timestamp validation to confirm data accuracy.
+3. **Aggregation**: 
+   - RedStone calculates the number of received unique signers for each requested data feed.
+   - The median value of all the values provided by unique signers is calculated and used as the default value.
+   - This process is optimized using low-level assembly code to minimize gas consumption.
+4. **Security Mechanisms**: 
+   - RedStone’s on-chain aggregation mechanism ensures that a minimum number of distinct data feeds are required.
+   - Values from different providers are aggregated before being returned to the consumer contract.
+   - The default aggregation method is median value calculation, ensuring that even if a small subset of providers is compromised, it does not significantly affect the final value.
+
+## Technical Guidelines for Implementing RedStone Data Feeds
+
+### Key On-Chain Aggregation Parameters
+
+- **`getUniqueSignersThreshold` Function**  
+  Purpose: Determines the minimum number of unique signers required to validate a piece of data. This ensures data accuracy and integrity by relying on multiple independent signers.
+
+- **`getAuthorisedSignerIndex` Function**  
+  Purpose: Returns the index of an authorized signer from a list of signers, verifying whether a given signer is authorized to sign data.
+
+- **`aggregateValues` Function (for numeric values)**  
+  Purpose: Aggregates numeric values from multiple data points, typically calculating an average or median to mitigate the impact of any single erroneous data point.
+
+- **`aggregateByteValues` Function (for byte arrays)**  
+  Purpose: Aggregates values specifically for byte arrays.
+
+### Supported Data Types
+
+RedStone supports two types of data in a contract:
+
+1. Numeric 256-bit values (default)
+2. Byte arrays with dynamic size
+
+### Security Best Practices
+
+- **Threshold Modification**: Overriding `getUniqueSignersThreshold` can be risky. Only proceed if you are absolutely confident in your changes.
+- **Timestamp Validation**: Pay close attention to the timestamp validation logic. In certain use cases (e.g., synthetic DEX), you may need to cache the latest values in your contract storage to prevent arbitrage attacks.
+- **Upgradability**: Implement a secure upgradability mechanism for your contract, preferably using multi-sig or DAO governance.
+- **Monitoring**: Continuously monitor the RedStone data services registry and promptly update signer authorization logic in your contracts in case of changes. We will also notify you if you are a paying client.
+
+### Implementation Recommendations
+
+- **Data Feed Requests**: Design your smart contracts to minimize the number of data feeds requested in a single transaction.
+- **Signer Threshold**: We recommend requiring approximately three unique signers to balance security with gas efficiency.
+
+## Performance Benchmarks
+
+You can check the benchmarks script and reports [here.](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/benchmarks)
+
+<a href="https://raw.githubusercontent.com/redstone-finance/redstone-docs/main/static/img/architecture.png">
+ <img src="/img/architecture.png" target="_blank"/>
+</a>

docs/Introduction.md

@@ -1,50 +1,20 @@
 ---
 sidebar_position: 1
-sidebar_label: "♦️ What is RedStone Oracles?"
+sidebar_label: "Introduction"
 ---
+# Introduction
 
 ## Overview
+There is a growing need for decentralized applications (dApps) to access data feeds that are frequently updated, reliable, and secure. RedStone Oracles is a leading oracle provider directly fulfilling this need. Trusted by 100+ dApps and securing billions of dollars of value, RedStone provides customizable and cost-efficient data streams for builders, empowering the next generation of dApps. 
 
-There is a growing need for decentralized applications (dApps) to access data feeds that are frequently updated, reliable, and secure. RedStone Oracles is a leading oracle provider directly fulfilling this need. Trusted by 100+ dApps and securing billions of dollars of value, RedStone provides customizable and cost-efficient data streams for builders empowering the next generation of dApps. RedStone also provides data feeds to blockchains and layer 2 scaling solutions across the entire blockchain ecosystem that are both EVM and non-EVM compatible. The current model of oracle systems suffers from key inefficiencies, all of which RedStone Oracles was specifically designed to solve from the bottom up. This makes RedStone a unique oracle service.
+RedStone also provides data feeds to blockchains and layer 2 scaling solutions across the entire blockchain ecosystem that are both EVM and non-EVM compatible. The current model of oracle systems suffers from key inefficiencies, all of which RedStone Oracles was specifically designed to solve from the bottom up. This makes RedStone a unique oracle service.
 
-## The Problems RedStone Solves ♦️
-
-### Problem # 1: The standard approach of providing data to applications is inefficient and expensive. 
-- The standard method of providing data is to ‘push’ the data onto the blockchain regardless of whether it is used by an application. This results in paying more for data and dedicating resources that could be used elsewhere. 
-
-#### Our Solution
-
-RedStone allows data to be provided on-demand rather than on a fixed schedule, reducing the costs of putting data 'on-chain'. This is achieved by storing data off of the blockchain as cryptography signed packages and allowing smart contracts of dApps to fetch data when necessary. 
-
-_A note on data integrity_: To maintain data integrity RedStone also provides data feeds to Arweave, a decentralized network that provides data storage. Arweave's decentralized network makes it tamper-proof, therefore any data provided by RedStone to Arweave acts as a unbiased source of truth about the historical data provided by RedStone. 
-
-Overall, RedStone's approach improves efficiency for dApps and significantly reduces the costs for dApps to access data feeds. 
-
-
-### Problem #2: The typical monolithic architecture of oracles limits scalability.
-
-- A consequence of a monolithic architecture is that makes it challenging for protocols to reduce latency and list new assets.
-
-#### Our Solution
-
-RedStone was designed with a modular architecture making it easy to incorporate new assets and reduce latency, allowing dApps to scale more efficiently. This means constructing the oracle in such a way that its various components—such as data sources, validation mechanisms, and delivery methods—can be easily interchanged, updated, or augmented without disrupting the system’s overall functionality.
-
-
-
-## Key facts
+## Facts 
 
 - RedStone secures [billions of dollars](https://defillama.com/oracles/RedStone?borrowed=true&doublecounted=true) of value in Web 3.0
 - Data Integrity is fundamental to Redstone and is ensured from start to finish (from source to smart contract)
 - There are [3 different ways](./get-started/selecting-redstone-model) to integrate our service tailored to your needs
 - We provide feeds for more than [1000 assets](https://app.redstone.finance/#/app/tokens) integrating [~180 data sources](https://app.redstone.finance/#/app/sources)
-- We are present on [20+ chains](https://showroom.redstone.finance/)
-- Our code was audited by multiple security experts including [ABDK](https://abdk.consulting/) [Peckshield](https://peckshield.com/), and a co-founder of [L2Beat](https://pl.linkedin.com/company/l2beat#:~:text=Join%20Piotr%20Szlachciak%20Cofounder%20%26%20CEO,insights%20shaping%20the%20%23DeFi%20landscape!).
+- We are present on [50+ chains](https://showroom.redstone.finance/)
+- Our code was audited by multiple security experts including [ABDK](https://abdk.consulting/), [Peckshield](https://peckshield.com/), [Quantstamp](https://quantstamp.com/), and a co-founder of [L2Beat](https://pl.linkedin.com/company/l2beat#:~:text=Join%20Piotr%20Szlachciak%20Cofounder%20%26%20CEO,insights%20shaping%20the%20%23DeFi%20landscape!).
 - RedStone supports leading projects like [Morpho](https://morpho.org/), [Venus](https://venus.io/), and [Pendle Finance](https://www.pendle.finance/).
-
-
-
-<a href="https://raw.githubusercontent.com/redstone-finance/redstone-docs/main/static/img/redstone-architecture-simple.png">
-  <img alt="RedStone Architecure" src="/img/redstone-architecture-simple.png" target="_blank"/>
-</a>
-
-

docs/RedStone-Solutions.md

@@ -0,0 +1,20 @@
+---
+sidebar_position: 2
+sidebar_label: "Why RedStone"
+---
+
+## Why RedStone?
+
+The current model of oracle systems suffers from significant inefficiencies, which RedStone Oracles was specifically designed to solve from the ground up.
+
+### Problem #1: Inefficient and Expensive Data Provision
+The standard approach of providing data to applications involves ‘pushing’ the data onto the blockchain regardless of whether it is used by an application. This results in unnecessary costs and resource allocation.
+
+**Our Solution:**  
+RedStone offers an on-demand data provision model instead of a fixed schedule. This approach reduces the costs associated with putting data 'on-chain'. By storing data off-chain as cryptographically signed packages, RedStone allows smart contracts of dApps to fetch data only when necessary.RedStone’s innovative approach significantly enhances efficiency for dApps and reduces the costs to access data feeds.
+
+### Problem #2: Limited Scalability Due to Monolithic Architecture 
+Monolithic architectures in traditional oracles make it difficult for protocols to reduce latency and add new assets quickly.
+
+**Our Solution:**  
+RedStone is built with a modular architecture, making it easy to incorporate new assets and reduce latency. This modular design ensures that components like data sources, validation mechanisms, and delivery methods can be interchanged, updated, or augmented without disrupting overall functionality. This modularity enables dApps to scale more efficiently, adapting to changing needs and integrating new features seamlessly.

docs/Security-And-Accuracy

@@ -0,0 +1,35 @@
+---
+sidebar_label: "Security & Accuracy"
+---
+
+## Security and Accuracy
+RedStone has secured billions of dollars to date without being hacked or reporting a compromised price feed. This strong track record is a testament to the robust security and accuracy measures in place.
+
+## Security
+
+### Cryptographic Signatures and Auditing
+
+To ensure the integrity of incoming data feeds, RedStone nodes cryptographically sign incoming data from over 180 data providers. All data is signed using the elliptical curve signature, secp-256, commonly used in Ethereum Virtual Machine (EVM) environments. This process attributes the data to its source, providing proof of origin and ensuring the data is tamper-proof. The signed data is pushed to the blockchain, where it can be verified by RedStone and any party wishing to evaluate its integrity. The availability of on-chain data serves as a historical record, ensuring a permanent and verifiable audit trail.
+
+RedStone's commitment to security is further demonstrated through regular auditing of their smart contracts by reputable firms, including Audit One, PeckShield, and ABDK. These smart contracts are also open-source, allowing public scrutiny at any time.
+
+### Reliability
+
+RedStone continuously monitors its price feeds for abnormalities, checking liquid staking price feeds for slippage every 10 seconds. Node operators use RedStone’s software to detect any suspicious activity, ensuring data accuracy. RedStone relies on Arweave, a decentralized data storage network, to store some of its processed data, allowing individuals to verify the accuracy of data used by decentralized applications (dApps). To enhance data reliability, RedStone sources its data from a diverse range of centralized exchanges (CEXs), decentralized exchanges (DEXs), and data aggregators. If one source is compromised, it can be immediately removed, allowing dApps to customize their data feeds.
+
+For use cases prone to front-running, RedStone implements a system where users initiate transactions by recording their intent to interact with a protocol on-chain, without including the price at the time of execution. This approach mitigates the risk of arbitrage attempts through front-running. RedStone also implements rigorous internal processes to protect against potential attacks, ensuring ongoing system security.
+
+### Redundancy
+
+RedStone incorporates liquidity weighting to automatically detect low liquidity and high slippage in data sources. Multiple layers of redundant monitoring are employed across the system. For example, RedStone uses multiple relayers for data pushing and broadcasting, ensuring that anyone can push price data on-chain. Geographically distributed gateways on multiple infrastructure providers further enhance data broadcasting. RedStone also leverages Pub/Sub networks like StreamR for decentralized data distribution through a network of nodes, supporting continuous data feeds.
+
+RedStone’s decentralized gossiping nodes allow anyone to spin up a node and participate in the data network, enhancing decentralization and resilience. The data delivery system includes master relayers supported by shadow relayers that automatically activate if primary relayers fail. Gelato automation further enhances system reliability. The relayer code is open-source, allowing anyone to push data on-chain without permission.
+
+RedStone avoids single points of failure by minimizing dependence on third parties and sourcing data directly from liquidity pools and providers like Kaiko. The modular architecture ensures that if one service fails, others automatically take over. Together, these features make RedStone Oracles secure and reliable.
+
+## Accuracy
+
+RedStone ensures accurate price feeds through several mechanisms. Liquidity weighting accounts for the size of liquidity pools, preventing smaller pools from significantly impacting overall price accuracy. Outlier detection monitors for price deviations, safeguarding against inaccuracies. By sourcing data directly from liquidity pools of a diverse range of DEXs and CEXs, RedStone minimizes the risk of a single point of failure and speeds up data retrieval.
+
+RedStone also calculates the median value from its data sources, reducing the risk of misreporting. Implementing RedStone’s smart contracts allows dApp developers to choose their data sources and immediately stop receiving data from a specific source, ensuring continuous accuracy. These mechanisms have ensured that RedStone has never reported an incorrect price feed that harmed protocol users, demonstrating a strong commitment to client needs.
+

docs/data-providers/_category_.json

@@ -1,5 +1,5 @@
 {
-  "label": "⛴️ Data Providers",
+  "label": Data Providers,
   "position": 3,
   "link": {
     "type": "generated-index",

docs/get-started/_category_.json

@@ -1,5 +1,5 @@
 {
-  "label": "🚀 Get Started",
+  "label": " Get Started",
   "position": 2,
   "link": {
     "type": "generated-index",

docs/get-started/chains-integration.md-hidden

@@ -1,6 +1,6 @@
 ---
 sidebar_position: 8
-sidebar_label: "⛓ Chains integration"
+sidebar_label: "Chains We Support"
 
 # We've hidden this page, cause we don't want ppl to write their own adapters
 # as they turn out to be buggy and we right now prefer charging for chains