diff --git a/docs/Data-Formatting-And-Processing b/docs/Data-Formatting-And-Processing new file mode 100644 index 00000000..90b77fef --- /dev/null +++ b/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. + + + + + +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) + + + + diff --git a/docs/Introduction.md b/docs/Introduction.md index 5d916bce..436f5f0b 100644 --- a/docs/Introduction.md +++ b/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/). - - - - - RedStone Architecure - - - diff --git a/docs/RedStone-Solutions.md b/docs/RedStone-Solutions.md new file mode 100644 index 00000000..29fe6abe --- /dev/null +++ b/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. diff --git a/docs/Security-And-Accuracy b/docs/Security-And-Accuracy new file mode 100644 index 00000000..cc7ccedb --- /dev/null +++ b/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. + diff --git a/docs/data-providers/_category_.json b/docs/data-providers/_category_.json index 14e569cd..b8984b89 100644 --- a/docs/data-providers/_category_.json +++ b/docs/data-providers/_category_.json @@ -1,5 +1,5 @@ { - "label": "⛴️ Data Providers", + "label": Data Providers, "position": 3, "link": { "type": "generated-index", diff --git a/docs/get-started/_category_.json b/docs/get-started/_category_.json index eb1bf858..5a453138 100644 --- a/docs/get-started/_category_.json +++ b/docs/get-started/_category_.json @@ -1,5 +1,5 @@ { - "label": "🚀 Get Started", + "label": " Get Started", "position": 2, "link": { "type": "generated-index", diff --git a/docs/get-started/chains-integration.md-hidden b/docs/get-started/chains-integration.md-hidden index 2c5238f6..d4114bef 100644 --- a/docs/get-started/chains-integration.md-hidden +++ b/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 diff --git a/docs/get-started/data-formatting-processing.md b/docs/get-started/data-formatting-processing.md deleted file mode 100644 index 07484074..00000000 --- a/docs/get-started/data-formatting-processing.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -sidebar_position: 3 -sidebar_label: "💻 Data Formatting & Processing" ---- - -# How Data Flows to the Blockchain - - - - - -# Overview -The price feeds provided to RedStone’s clients come from a diverse range of sources. This includes exchanges like Binance and Coinbase, decentralized exchanges (DEXs) like Uniswap and Sushiswap, and price aggregators like CoinMarketCap and CoinGecko. RedStone has over 150 sources integrated to date. The data is aggregated by independent nodes operated by data providers using various methodologies. Some methods include median, TWAP, and LWAP, which are all designed to capture the most accurate price by considering factors like the amount of liquidity available, and the average price during specific timeframes. - -Additionally, data-quality measures are implemented like detecting unexpected values (outlier detection), to ensure the data is correct. Afterward, the cleaned and processed data is then signed by node operators underwriting its quality. The feeds are broadcasted both on the Streamr, a decentralized data network, and directly to open-source gateways which could be easily spun-off when necessary. -The data could be pushed onto the blockchain either by a dedicated relayer operating under predefined conditions, like a specific change in price, by a bot (ie. performing liquidations), or even by end users interacting with the protocol. Inside the protocol, the data is unpacked and verified cryptographically confirming both the origin and timestamps. - -# Data Formatting & Processing - -### Context - -Transferring data to a blockchain requires packing an extra payload to a user’s transaction and processing the message on the blockchain. Said differently, the data that is put on the blockchain, such as a cryptocurrency’s price, is inserted into part of the data that makes up a user’s transaction. This is accomplishable because blockchains move from state-to-state and contain call data. RedStone is able insert its data into the call data of a user's transaction, thereby putting the data onto the blockchain. - -### How Data is Encoded Before Being Put on the Blockchain - - -_Note: All of the steps are executed automatically by the ContractWrapper and is transparent to the end-user_ - - -1. Relevant data must be fetched from the data distribution layer, powered by the Streamr network or the RedStone gateways. - -2. Data is packed into a message based on the structure of the ‘Transaction Payload’ diagram below… - - - - - -3. The package is appended to the original transaction message, signed, and submitted to the network. -
- -### How Data Is Unpacked, Verified and Then Aggregated On-Chain -Firstly, the appended data packages are extracted from the call data. Then, security steps are taken including verifying if the signature was created by a trusted provider and validating the timestamp, confirming the information is correct. Afterward, for each requested data feed RedStone calculates the number of received unique signers, extracts the value for each unique signer, and calculates the aggregated value. The middle value of all the values (median), is the default value that is provided. This logic is executed in the on-chain environment and its execution has been optimized using a low-level assembly code to reduce gas consumption to the absolute minimum. To increase the security of the RedStone Oracle system, we've created the on-chain aggregation mechanism. This mechanism adds an additional requirement of ensuring a minimum number of distinct data feeds are relied on. The values from different providers are then aggregated before returning to a consumer contract. By default, RedStone uses the median value calculation for aggregation. This way, even if a small subset of providers are corrupt (e.g. 2 of 10), it does not significantly affect the aggregated value. - - -
- -# Technical Considerations When Implementing RedStone's Data Feeds - -### On-Chain Aggregation Parameters in RedStone’s Consumer Base Contract: - - -`getUniqueSignersThreshold` function - - -Purpose: Determines the threshold number of unique signers required to validate a piece of data. RedStone relies on multiple independent signers to ensure its accuracy and integrity. - - -`getAuthorisedSignerIndex` function - - -Purpose: Returns the index of an authorized signer from a list of signers. It is used to verify if a given signer is authorized to sign data. - - -`aggregateValues` function (for numeric values) - - -Purpose: Aggregates numeric values from multiple data points. It could calculate an average like the median. Aggregating values from multiple sources helps in reducing the impact of any single erroneous data point. - - -`aggregateByteValues` function (for bytes arrays) - - -Purpose: Aggregates values specifically for byte arrays. - -### Types of Values Supported - -We support 2 types of data to be received in a contract: - -1. Numeric 256-bit values (used by default) -2. Bytes arrays with dynamic size - - -### Security Considerations -- Overriding `getUniqueSignersThreshold` may be a significant risk. We only recommend overriding it if you are 100% confident. - -- Pay attention to the timestamp validation logic. For some use-cases (e.g. synthetic DEX), you would need to cache the latest values in your contract storage to avoid arbitrage attacks. - -- Enable a secure upgradability mechanism for your contract (ideally based on multi-sig or DAO). - -- Monitor the RedStone data services registry and quickly modify signer authorization logic in your contracts in case of changes (we will also notify you if you are a paying client). - -### Recommendations -- Write smart contracts in a way where you do not need to request many data feeds in the same transaction. -- Approximately 3 required unique signers is our recommended balance to be secure and minimize gas costs. - - -# Benchmarks - -You can check the benchmarks script and reports [here.](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/benchmarks) diff --git a/docs/get-started/models/_category_.json b/docs/get-started/models/_category_.json index 693b59da..961ffba2 100644 --- a/docs/get-started/models/_category_.json +++ b/docs/get-started/models/_category_.json @@ -1,9 +1,9 @@ { - "label": "🗂️ Models", + "label": " Our Models", "position": 2, "link": { "type": "generated-index", - "description": "Depending on your needs RedStone could be integrated in 3 different ways" + "description": "RedStone offer four unique models that can be integrated into your dApp." }, "collapsed": true } diff --git a/docs/get-started/models/redstone-classic.md b/docs/get-started/models/redstone-classic.md index 36e45d28..28c5c9dd 100644 --- a/docs/get-started/models/redstone-classic.md +++ b/docs/get-started/models/redstone-classic.md @@ -1,13 +1,13 @@ --- sidebar_position: 2 -sidebar_label: "🏛 Classic (push model)" +sidebar_label: "Classic Model" --- -# 🏛 Classic Model -## Pushing feeds on chain +# Classic Model +The RedStone Classic Model is designed for dApps that would like access to data feeds that is compatable with the traditional design of oracles. To access cost-minimized and reduced latency data feeds check out the [RedStone Core Model](https://docs.redstone.finance/docs/get-started/models/redstone-core). -Although the pure on-demand fetching model ([RedStone Core](./redstone-core.mdx)) is more efficient and scalable we acknowledge that some protocols may prefer to stick to a traditional design when data is pushed on-chain. This setup could be reasonable if: +#### How Should use the Classic Model? - There is an existing well-audited codebase and the team prefers not to make even tiny amendments - The protocol is deployed on a private network or a chain where the gas costs are minimal - The prices don't need to be updated too frequently @@ -18,11 +18,10 @@ RedStone Classic has a significant advantage over traditional push Oracles. Our ## How RedStone Classic works -This approach is built on top of the [RedStone Core](./redstone-core.mdx) model maintaining the security of on-chain validation of data providers and timestamps. +This approach is built on top of the [RedStone Core](./redstone-core.md) model maintaining the security of on-chain validation of data providers and timestamps. The model consists of two main parts. The first one is the off-chain [relayer](#relayer) responsible for pushing data on-chain in a customized way using [environment variables](#environment-variables). The second part is the on-chain [contracts](#contracts) which enable storing prices and getting them through a familiar interface (e.g. the [Chainlink Aggregator](https://github.com/smartcontractkit/chainlink/blob/develop/contracts/src/v0.7/interfaces/AggregatorV3Interface.sol) ). RedStone Classic can be used on all EVM-compatible L1s & L2s + Starknet + Fuel Network. -![RedStone Classic diagram](/img/redstone-classic.png) ### Relayer diff --git a/docs/get-started/models/redstone-core.mdx b/docs/get-started/models/redstone-core.mdx index a4e25136..dced6668 100644 --- a/docs/get-started/models/redstone-core.mdx +++ b/docs/get-started/models/redstone-core.mdx @@ -1,235 +1,111 @@ --- sidebar_position: 1 -sidebar_label: "⚙️ Core (on-demand feeds)" +sidebar_label: "Core Model" --- -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# ⚙️ Core Model - -## Fetching prices on-demand - -This is our basic operating model when the data is automatically appended to user transaction. - -:::tip In Prod - -Core model is the most mature way to use RedStone, battle tested in production, protecting >$100M TVL of [DeFi Protocols](https://defillama.com/oracles/RedStone) (not all listed yet) across multiple mainnets. The price feeds have been injected to more than [~50K transactions](https://dune.com/hatskier/redstone). - -::: - -## Installation - -Install [@redstone-finance/evm-connector](https://www.npmjs.com/package/@redstone-finance/evm-connector) from NPM registry - -### Hardhat - - - - -```bash - yarn add @redstone-finance/evm-connector -``` - - - - -```bash -npm install @redstone-finance/evm-connector -``` - - - - - -### Foundry - -Foundry installs dependencies using git submodules. Thus additional steps are needed to [install dependencies](https://book.getfoundry.sh/projects/dependencies). - -In foundry project: - -1. Install `@redstone-finance/evm-connector` - it will install current code from main branch - -```bash -forge install redstone-finance/redstone-oracles-monorepo -``` - -2. Install `@OpenZeppelin` contracts (dependency of `@redstone-finance/evm-connector`) - it will install current code from main branch - -```bash -forge install OpenZeppelin/openzeppelin-contracts@v4.9.5 -``` - -3. Add libraries to `remappings.txt` - -```bash +# Core Model +This is our recommended model which provides data feeds to dApps only upon request, reducing the costs of putting data onto the blockchain. To learn more about how RedStone brings data on-chain, check out the [Data Formatting and Processing](https://docs.redstone.finance/docs/get-started/data-formatting-processing) section. +### Prerequisites Before You Begin: + +- **Knowledge of Smart Contracts:** Understanding how to implement and interact with smart contracts. +- **Familiarity with Hardhat or Foundry:** Knowing how to use these development environments for building and testing dApps. +- **OpenZeppelin Contracts:** Understanding and using OpenZeppelin's library. + +### Important Notes: +- **Solidity Version:** Ensure your smart contract uses Solidity version 0.8.4 or higher. If using an older version, refer to the manual payload method. +- **Testing Environment:** Remix is not supported for testing RedStone Oracles. +- **Upgradability:** Implement an upgradability mechanism (e.g., multisig or DAO) for your contracts to quickly replace data providers if needed. +- **Examples:** You can see examples of the `@redstone-finance/evm-connector` usage in our [dedicated repo with examples](https://github.com/redstone-finance/redstone-evm-examples). + + +# ****Step-by-Step Guide**** + +## 1. Install Prerequisites + +#### For Hardhat +1. To add the RedStone EVM connector package, type one of these commands: + - If you're using Yarn: + ```bash + yarn add @redstone-finance/evm-connector + ``` + - If you're using npm: + ```bash + npm install @redstone-finance/evm-connector + ``` + +#### For Foundry + +1. Open your terminal +2. Navigate to your Foundry project directory + ```bash + cd path/to/your/foundry/project + ``` + +3. Install the RedStone EVM connector + + ``` + forge install redstone-finance/redstone-oracles-monorepo + ``` + +4. Install the OpenZeppelin contracts, which the RedStone connector relies on. + + ``` + forge install OpenZeppelin/openzeppelin-contracts@v4.9.5 + ``` +5. Link these new libraries by adding their paths to a file called remappings.txt. + ```bash echo "@redstone-finance/evm-connector/dist/contracts/=lib/redstone-oracles-monorepo/packages/evm-connector/contracts/ @openzeppelin/contracts=lib/openzeppelin-contracts/contracts/" >> remappings.txt ``` -## Usage - -:::tip TLDR; -You need to do 2 things: - -1. [Adjust your smart contracts](#1-adjust-your-smart-contracts) to include the libraries responsible for data extraction and verification -2. [Adjust Javascript code of your dApp](#2-adjust-javascript-code-of-your-dapp) to inject the additional payload with data feeds (otherwise you will get smart contract errors). - - - -::: - -### 1. Adjust your smart contracts -:::caution Heads up -1. Our contracts require `solidity > 0.8.4`. If your code is written in an older version please use the [Manual Payload](#manual-payload). -2. If you work with 3rd party aggregators, make sure that they also support passing the additional payload. -3. Please don't use Remix to test RedStone oracles, as Remix does not support modifying transactions in the way that the evm-connector does -4. We strongly recommend having some upgradability mechanism for your contracts (it can be based on multisig or DAO). This way, you can quickly replace data providers in case of any issues. -::: - - -You need to apply a minimum change to the source code to enable smart contract to access data. Your contract needs to extend one of our [base contracts](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/contracts/data-services), depending on which data service are you going to use. - -
- List of base contracts with data services - - | Base Contract | Data service with the list of feeds | Status | - |----------------------------------------|------------------------------|-----------------| - | [MainDemoConsumerBase.sol](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/evm-connector/contracts/data-services/MainDemoConsumerBase.sol) | [redstone-main-demo](https://app.redstone.finance/#/app/data-services/redstone-main-demo) | Demo | - | [RapidDemoConsumerBase.sol](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/evm-connector/contracts/data-services/RapidDemoConsumerBase.sol) | [redstone-rapid-demo](https://app.redstone.finance/#/app/data-services/redstone-rapid-demo) | Demo | - | [StocksDemoConsumerBase.sol](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/evm-connector/contracts/data-services/StocksDemoConsumerBase.sol) | [redstone-stocks-demo](https://app.redstone.finance/#/app/data-services/redstone-stocks-demo) | Demo | - | [AvalancheDataServiceConsumerBase.sol](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/evm-connector/contracts/data-services/AvalancheDataServiceConsumerBase.sol) | [redstone-avalanche-prod](https://app.redstone.finance/#/app/data-services/redstone-avalanche-prod) | Production | - | [PrimaryProdDataServiceConsumerBase.sol](https://github.com/redstone-finance/redstone-oracles-monorepo/blob/main/packages/evm-connector/contracts/data-services/PrimaryProdDataServiceConsumerBase.sol) | [redstone-primary-prod](https://app.redstone.finance/#/app/data-services/redstone-primary-prod) | Production | - - - 💡 Note: Service with `Production` status have got multiple nodes deployed and are professionally monitored. -
+## 2. Adjust Your Smart Contracts +#### 1. Import RedStone Base Contract +Add this line at the top of your smart contract code. ```js import "@redstone-finance/evm-connector/contracts/data-services/MainDemoConsumerBase.sol"; - -contract YourContractName is MainDemoConsumerBase { - ... -} ``` -You should pass the data feed id converted to `bytes32`. - - - - -```js - uint256 ethPrice = getOracleNumericValueFromTxMsg(bytes32("ETH")); -``` - - - - -```js - bytes32[] memory dataFeedIds = new bytes32[](2); - dataFeedIds[0] = bytes32("ETH"); - dataFeedIds[1] = bytes32("BTC"); - uint256[] memory values = getOracleNumericValuesFromTxMsg(dataFeedIds); - uint256 ethPrice = values[0]; - uint256 btcPrice = values[1]; -``` - - - - - -For all the supported feeds we provide [UI with charts and historical data](https://app.redstone.finance) - -💡 Note: You can also override the following functions (do it at your own risk): - -- `isTimestampValid(uint256 receivedTimestamp) returns (bool)` - to enable custom logic of timestamp validation. You may specify a shorter delay to accept only the most recent price fees. However, on networks with longer block times you may extend this period to avoid rejecting too many transactions. - -- `aggregateValues(uint256[] memory values) returns (uint256)` - to enable custom logic of aggregating values from different providers (by default this function takes the median value). For example, you may request values from providers to be strictly equal while dealing with discrete numbers. - -- `getAuthorisedSignerIndex(address _signerAddress) returns (uint256)` - to whitelist additional signers or remove corrupted ones. - - -- `getUniqueSignersThreshold() returns (uint256)` - to modify number of required signers. The higher number means greater reliability but also higher gas costs. - -### 2. Adjust Javascript code of your dApp - -You should also update the code responsible for submitting transactions. If you're using [ethers.js](https://github.com/ethers-io/ethers.js/), we've prepared a dedicated library to make the transition seamless. - -#### Contract object wrapping - -First, you need to import the wrapper code to your project - - - +#### 2. Extend Your Contract +Make your contract use the new features by extending from MainDemoConsumerBase. ```js - const { WrapperBuilder } = require("@redstone-finance/evm-connector"); -``` - - - - -```js - import { WrapperBuilder } from "@redstone-finance/evm-connector"; -``` - - - -Then you can wrap your ethers contract pointing to the selected [RedStone data service id.](https://app.redstone.finance/#/app/data-services) You can (optionally) specify a number of unique signers, data feed identifiers, and URLs for the redstone cache nodes. - -```js -const yourEthersContract = new ethers.Contract(address, abi, provider); - -const wrappedContract = WrapperBuilder.wrap(contract).usingDataService( - { - dataFeeds: ["ETH", "BTC"], - }, -); +contract YourContractName is MainDemoConsumerBase { + // Your contract code goes here +} ``` +#### 3. Use Data Feeds +Inside your contract, you can now access data provided by RedStone. This code fetches the latest price of ETH and BTC. -Now you can access any of the contract's methods in exactly the same way as interacting with the ethers-js code: - +For a single price: ```js -wrappedContract.executeYourMethod(); +uint256 ethPrice = getOracleNumericValueFromTxMsg(bytes32("ETH")); ``` - -#### Testing - -##### Hardhat - -If you'd like to use the wrapper in a test context, we recommend using a mock wrapper so that you can easily override the oracle values to test different scenarios. To use the mock wrapper just use the `usingMockData(signedDataPackages)` function instead of the `usingDataService` function. - +For multiple prices: ```js -const { SimpleNumericMockWrapper } = require("@redstone-finance/evm-connector/dist/src/wrappers/SimpleMockNumericWrapper"); - -const wrappedContract = - WrapperBuilder.wrap(yourContract).usingSimpleNumericMock( - { - mockSignersCount: 10, - dataPoints: [ - {dataFeedId: "ETH", value: 1000} - ], - }, - ); - await wrappedContract.yourMethod(); +bytes32[] memory dataFeedIds = new bytes32[](2); +dataFeedIds[0] = bytes32("ETH"); +dataFeedIds[1] = bytes32("BTC"); +uint256[] memory values = getOracleNumericValuesFromTxMsg(dataFeedIds); +uint256 ethPrice = values[0]; +uint256 btcPrice = values[1]; ``` +For all the supported feeds we provide UI with charts and historical data. + +#### 4. About overriding the following functions (only if necessary - at your own risk) -You can see more examples of mocking data [here.](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/evm-connector/test/mock-wrapper) +```isTimestampValid(uint256 receivedTimestamp)``` returns (bool) - to enable custom logic of timestamp validation. You may specify a shorter delay to accept only the most recent price fees. However, on networks with longer block times you may extend this period to avoid rejecting too many transactions. -##### Foundry +```aggregateValues(uint256[] memory values)``` returns (uint256) - to enable custom logic of aggregating values from different providers (by default this function takes the median value). For example, you may request values from providers to be strictly equal while dealing with discrete numbers. -To use Redstone Oracles with Foundry in test context, we recommend using foundry `vm.ffi` function to generate mocked dataPackages. -We have prepared [repository](https://github.com/redstone-finance/minimal-foundry-repo) showing how we can integrate foundry with redstone. -- [consuming redstone payload in foundry contract](https://github.com/redstone-finance/minimal-foundry-repo/blob/main/test/Counter.t.sol) -- [generating mock redstone payload](https://github.com/redstone-finance/minimal-foundry-repo/blob/main/getRedstonePayload.js) +```getAuthorisedSignerIndex(address _signerAddress)``` returns (uint256) - to whitelist additional signers or remove corrupted ones. -## Manual payload -This approach is helpful if you need to pass the pricing data from one contract to another in your protocol. +```getUniqueSignersThreshold()``` returns (uint256) - to modify number of required signers. The higher number means greater reliability but also higher gas costs. -It's also a solution for a case, where your contracts are written in solidity in a version lower than `0.8.4` it could be problematic to extend from the `RedstoneConsumerBase` contract. -In that case we recomment to deploy a separate `Extractor` contract that will contain the verification logic: +#### 5. About a manual payload (if needed) +This approach is helpful if you need to pass the pricing data from one contract to another in your protocol. It's also a solution for cases where your contracts are written in Solidity in a version lower than 0.8.4, making it problematic to extend from the RedstoneConsumerBase contract. In such cases, we recommend deploying a separate Extractor contract that will contain the verification logic. ```js pragma solidity 0.8.4; @@ -242,17 +118,11 @@ contract RedstoneExtractor is RedstoneConsumerNumericMock { } } ``` - -and proxy the payload from your originating contract - ```js function getPriceFromRedstoneOracle(bytes32 feedId, bytes calldata redstonePayload) public view returns(uint256) { return redstoneExtractor.extractPrice(feedId, redstonePayload); } ``` - -The manual payload could be obtained using the following code on the client side: - ```js const redstonePayload = await (new DataServiceWrapper({ dataServiceId: "redstone-main-demo", @@ -262,7 +132,51 @@ const redstonePayload = await (new DataServiceWrapper({ // Interact with the contract (getting oracle value securely) const price = await yourContract.getPriceFromRedstoneOracle(redstonePayload); ``` +Working demo examples of the @redstone-finance/evm-connector usage can be found in our [dedicated repository with examples](https://github.com/redstone-finance/redstone-evm-examples). + + + +## 3. Adjust JavaScript Code of Your dApp + +#### 1. Import the Wrapper Code + +```js +const { WrapperBuilder } = require("@redstone-finance/evm-connector"); +// or using ES6 syntax +import { WrapperBuilder } from "@redstone-finance/evm-connector"; +``` + +#### 2. Wrap Ethers contract + +```js +const yourEthersContract = new ethers.Contract(address, abi, provider); + +const wrappedContract = WrapperBuilder.wrap(contract).usingDataService({ + dataFeeds ["ETH", "BTC"], +}); +``` + +#### 3. Use the Wrapped Contract -## Working demo +```js +wrappedContract.executeYourMethod(); +``` +## 4. Testing +For Hardhat +Mock Wrapper for Testing. +Use a mock wrapper to simulate different scenarios without using real data: +```js +const { SimpleNumericMockWrapper } = require("@redstone-finance/evm-connector/dist/src/wrappers/SimpleMockNumericWrapper"); + +const wrappedContract = WrapperBuilder.wrap(yourContract).usingSimpleNumericMock({ + mockSignersCount: 10, + dataPoints: [{ dataFeedId: "ETH", value: 1000 }], +}); + +await wrappedContract.yourMethod(); + +``` +For Foundry +Generate Mock Data: +Use Foundry's functions to create mock data packages for testing. Refer to the [foundry integration repository](https://github.com/redstone-finance/minimal-foundry-repo) for detailed examples. -You can see examples of the `@redstone-finance/evm-connector` usage in our [dedicated repo with examples](https://github.com/redstone-finance/redstone-evm-examples). diff --git a/docs/get-started/models/redstone-erc7412.md b/docs/get-started/models/redstone-erc7412.md index eeb53280..105c477e 100644 --- a/docs/get-started/models/redstone-erc7412.md +++ b/docs/get-started/models/redstone-erc7412.md @@ -1,29 +1,26 @@ --- sidebar_position: 4 -sidebar_label: "🌀 ERC7412 (classic + core)" +sidebar_label: "ERC-7412 Model" --- -# RedStone ERC7412 +# ERC-7412 Model -## Classic and Core models combined +The ERC-7412 model combines RedStone's Classic and Core Models relying on an newly proposed Ethereum standard. This model was introduced in light of the [ERC-7412](https://eips.ethereum.org/EIPS/eip-7412) standard. It is encouraged to familiarize yourself with it before implementating this model. -This model was introduced in form of [ERC7412](https://eips.ethereum.org/EIPS/eip-7412) - we encourage you to read it before implementation! The model was popularized by perpetual protocol [Synthetix](https://synthetix.io/). - -:::important Requirements -TLDR; You need to do 2 things: +#### Important Requirements 1. Deploy price feed -2. Modify you client code to use [erc7412](https://www.npmjs.com/package/@redstone-finance/erc7412) -::: +2. Modify you client code to use [ERC-7412](https://www.npmjs.com/package/@redstone-finance/erc7412) + -## Guide +## Step-By-Step Guide -### Deploy price feed contract +### 1. Deploy Price Feed Contract -1. Install dependency `npm install @redstone-finance/erc7412` -2. You have to extend contract `RedstonePrimaryProdWithoutRoundsERC7412` imported from `@redstone-finance/erc7412/contracts/RedstoneERC7412.sol` - 1. Implement `getTTL` method. It should return duration in second after which price in contract becomes stale. Stale means that price feed contract will revert on reads until price will be updated. Price updates will happen this is described in "Modify DAPP" section. - 2. Choose `dataFeedId` for which you want to deploy feed. Here is full list of [supported assets](https://app.redstone.finance/#/app/data-services/redstone-primary-prod) -3. Deploy contract +1. Install dependency `npm install @redstone-finance/erc7412`. +2. You have to extend contract `RedstonePrimaryProdWithoutRoundsERC7412` imported from `@redstone-finance/erc7412/contracts/RedstoneERC7412.sol`. +3. Implement `getTTL` method. It should return duration in second after which price in contract becomes stale. Stale means that price feed contract will revert on reads until price will be updated. Price updates will happen this is described in "Modify DAPP" section. +4. Choose `dataFeedId` for which you want to deploy feed. Here is full list of [supported assets](https://app.redstone.finance/#/app/data-services/redstone-primary-prod). +3. Deploy contract. **Example contract for BTC dataFeedId** ```sol @@ -39,15 +36,16 @@ contract BTCFeed is RedstonePrimaryProdWithoutRoundsERC7412 { } } ``` -### Modify DAPP -Your dapp has to be aware of erc7412. To allow users update prices when price in feed is stale. +### 2. Modify Your dApp -*Note: if it happens that user will have to update price they will need to pay extra money for gas transaction.* +- Your dApp has to be aware of ERC7412 to allow users to update prices when the price in feed is stale. +- Modification in your dApp requires extra function call `generate7412CompatibleCall` which should be executed just before user executing transaction. +- For now erc7412 lib depends on viem client. +- You have to prepare call to your contract, and in next step pass it to `generate7412CompatibleCall`. +- For a working example [click here](https://github.com/redstone-finance/erc7412-example). -Modification in your dapp requires extra function call `generate7412CompatibleCall` which should be executed just before user executing transaction. + *Note: if a user would like to update the price they will need to pay extra money for gas transaction.* -1. For now erc7412 lib depends on viem client. -2. You have to prepare call to your contract, and in next step pass it to `generate7412CompatibleCall` ```ts import { generate7412CompatibleCall } from "@redstone-finance/erc7412/generate7412CompatibleCall"; @@ -78,4 +76,3 @@ Modification in your dapp requires extra function call `generate7412CompatibleCa // data is already set in contract and it won't be necessary to update it until TTL passes console.log("BTC price:", await btcPriceFeed.read.latestAnswer()); ``` -Working example can be find [here](https://github.com/redstone-finance/erc7412-example) diff --git a/docs/get-started/models/redstone-x.md b/docs/get-started/models/redstone-x.md index 738c3df4..5dbcf434 100644 --- a/docs/get-started/models/redstone-x.md +++ b/docs/get-started/models/redstone-x.md @@ -1,97 +1,111 @@ --- sidebar_position: 3 -sidebar_label: "⏱ X (no front-running)" +sidebar_label: "X Model" --- -# ⏱ RedStone X -## An eXtreme protection against front-running +# X Model -The model implements a `Deferred execution pattern` where transactions are processed in two steps: +The RedStone X model is designed to meet the needs of advanced protocols, such as perpetuals, options, and derivatives. By providing price feeds at the very next block after users initiate transactions, this model eliminates front-running risks. -1. A user initiates the transaction by recording on-chain an intention to interact with the protocol (ie. open a perpetual position) without knowing the exact context (ie. price) in which the transaction will be executed. This mitigates any attempts to arbitrage the protocols by front-running price delivery from Oracles. +## Key Requirements +- **Adjust Contracts for 2-Phase Execution:** Modify your smart contracts to execute price-sensitive transactions in two phases: request and execution. +- **Deploy a Keeper Service:** Set up a keeper service that automatically fetches the price data and triggers the transaction execution. -2. The price is pushed on-chain only in the second step, which usually happens at the very next block. Anyone (including the user himself) could push the price, as its integrity is validated on-chain based on the protocol constraints. Such a price will be used to finally settle the transaction. +## How It Works +The model implements a `Deferred Execution Pattern`, where transactions are processed in two distinct steps: -This model was popularised by perpetual protocols such as [GMX](https://gmx.io/#/) and it enables a new wave of super-efficient DeFi projects that are rapidly growing despite the bear market. +1. **Transaction Initiation:** + A user initiates a transaction by recording an on-chain intention to interact with the protocol (e.g., opening a perpetual position) without knowing the exact context (such as price) at the time of execution. This mitigates front-running attempts by preventing price manipulation before the transaction is settled. -:::important Requirements -TLDR; You need to do 2 things: +2. **Price Delivery and Transaction Execution:** + The price is pushed on-chain in the next step, typically in the very next block. Anyone, including the user, can push the price, as its integrity is validated on-chain according to the protocol's constraints. This price is then used to finalize the transaction. -1. Adjust your contracts to execute price-sensitive transactions in 2-phases (request -> execution). +## Step-by-Step Guide to Update Smart Contracts -2. Deploy a keeper service that automatically fetches the price and triggers the execution. -::: - -![RedStone X diagram](/img/redstone-x.png) +### Phase 1: Transaction Request -## Updating smart contract code +When a user wants to execute a price-sensitive transaction, we need to collect some collateral, record request parameters, and ask keepers to provide price data. -### Phase 1 - request +#### Example: Swapping ETH to USDC -When a user wants to execute a price-sensitive transaction we need to collect some collateral, record request parameters, and ask keepers to provide price data. +For illustrative purposes, consider a simple protocol that allows swapping a native currency (like ETH) for a stablecoin (like USDC). The code for recording the transaction might look like this: -To clarify the steps, let's look at them in the context of a more concrete example. There is a simple protocol that allows swaping a native currency (like ETH) to a stable coin (like USDC). The sample code to record the transaction may look as follows: -``` +```solidity function changeEthToUsdc() external payable { - bytes32 requestHash = calculateHashForSwapRequest( - msg.value, - msg.sender, - block.number - ); - requestedSwaps[requestHash] = true; - - emit NewOracleDataRequest(msg.value, msg.sender, block.number); - } + bytes32 requestHash = calculateHashForSwapRequest( + msg.value, + msg.sender, + block.number + ); + requestedSwaps[requestHash] = true; + + emit NewOracleDataRequest(msg.value, msg.sender, block.number); +} ``` +#### Explanation: -In the function above we: - -1) Collect the collateral from the user keeping the eth that is attached to the transaction. This protects us from spamming the protocol with empty requests. +1. **Collateral Collection:** + - The contract collects the ETH attached to the transaction as collateral. + - This prevents us from spamming the protocol with empty requests. -2) Notarize all the necessary parameters of the user's request that will be necessary to validate the execution step. In the context of our example, let's seal the values of: -- amount of funds to swap `msg.value` -- address of the caller `msg.sender` -- time when the transaction is submitted (it will be necessary to deliver a matching price) `block.number` (Keeping the timestamp as block number or hash is better because the on-chain timestamping may not be fully synchronized with the global clock posing a risk of malicious arbitrage). +2. **Notarizing Request Parameters:** + The contract notarizes all the necessary parameters of the user's request that will be necessary to validate the execution step. We do not need to store all the data on-chain; it is sufficient to record a hash of the values mentioned above. Keeping the timestamp as a block number or hash is better because on-chain timestamping may not be fully synchronized with the global clock, posing a risk of malicious arbitrage. -We do not need to store all the data on-chain. It's sufficient to record a hash of the values mentioned above. + In this example, the following parameters are sealed: + - Amount of ETH to swap (`msg.value`) + - Address of the caller (`msg.sender`) + - Block number when the transaction is submitted (`block.number`) -3) Notify the keepers' network about the new request to receive price data by emiting the `NewOracleDataRequest` event. +3. **Keeper Network Notification:** + - The contract emits the `NewOracleDataRequest` event to notify the keepers' network of the new request. + - This signals the need for price data to complete the transaction in the next phase. -### Phase 2 - execution +### Phase 2: Transaction Execution -In this phase, the request from a user is executed with data received from the keeper network. -Let us analyse the necessary steps in the context of our example with swapping eth -> usdc. +In this phase, the request from a user is executed with data received from the keeper network. Let us analyse the necessary steps in the context of our example with swapping ETH to USDC +. +#### Example: Executing ETH to USDC Swap -``` +```solidity function executeWithOracleData( uint256 ethToSwap, address requestedBy, uint256 requestedAtBlock - ) external payable { - - // Check if the request actually exists - bytes32 requestHash = - calculateHashForSwapRequest(avaxToSwap, requestedBy, requestedAtBlock); - require(requestedSwaps[requestHash], - "Can not find swap request with the given params"); +) external payable { + + // Verify that the request exists + bytes32 requestHash = calculateHashForSwapRequest( + ethToSwap, requestedBy, requestedAtBlock + ); + require(requestedSwaps[requestHash], + "Cannot find swap request with the given parameters"); delete requestedSwaps[requestHash]; - // We need to validate the timestamp (block.number) + // Validate the timestamp (block number) uint256 dataPackagesBlockNumber = extractTimestampsAndAssertAllAreEqual(); - require(dataPackagesBlockNumber == requestedAtBlock, "Block number mismatch in payload and request"); + require(dataPackagesBlockNumber == requestedAtBlock, + "Block number mismatch between payload and request"); // Transfer USDC to the user uint256 usdcAmount = getExpectedUsdAmount(ethToSwap); usdc.transfer(requestedBy, usdcAmount); } + ``` +#### Explanation: -1) We need to validate if the parameters provided by keepers match the ones notarized by the user. +1. **Parameter Validation:** + - We need to validate if the parameters provided by the keepers match the ones notarized by the user. -2) Then we check if the timestamp (block number) for which the price is sourced matches the time when the request was recorded. +2. **Timestamp Verification:** + - Then we check if the timestamp (block number) for which the price is sourced matches the time when the request was recorded. -3) If all of the above checks are fine, we can send the appropriate value of usdc back to the user who originated the request +3. **Final Settlement:** + - If all of the above checks are fine, we can send the appropriate value of USDC back to the user who originated the request. + :::info Full code for the example The full code for the example above is available in [our workshop explaining 3 different models](https://github.com/redstone-finance/avalanche-workshop). ::: + + diff --git a/docs/get-started/nft-data-feeds.md b/docs/get-started/nft-data-feeds.md index b7f82d66..002a6881 100644 --- a/docs/get-started/nft-data-feeds.md +++ b/docs/get-started/nft-data-feeds.md @@ -1,9 +1,9 @@ --- sidebar_position: 6 -sidebar_label: "🐵 NFT Data Feeds" +sidebar_label: "Supported NFT Data Feeds" --- -# 🐵 NFT Data Feeds +# NFT Data Feeds RedStone delivers floor price data for 20 popular NFT collections from OpenSea. [Check the NFT tab in the redstone web app](https://app.redstone.finance/#/app/tokens?selected-tab=2) to see the historical data and corresponding data feed ids. diff --git a/docs/get-started/price-feeds.md b/docs/get-started/price-feeds.md index c30e7b00..681078c6 100644 --- a/docs/get-started/price-feeds.md +++ b/docs/get-started/price-feeds.md @@ -1,6 +1,6 @@ --- sidebar_position: 5 -sidebar_label: "💹 Price Feeds" +sidebar_label: "Price Feeds We Support" --- import Tabs from '@theme/Tabs'; diff --git a/docs/get-started/randomness.md b/docs/get-started/randomness.md deleted file mode 100644 index 18ff3764..00000000 --- a/docs/get-started/randomness.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -sidebar_position: 7 -sidebar_label: "🎲 Randomness" ---- - -# 🎲 Randomness - -Verifiable cross-chain randomness is under development. Please reach out to us if you want to be notified about the progress. diff --git a/docs/get-started/selecting-redstone-model.md b/docs/get-started/selecting-redstone-model.md index 2735b449..ff2d1576 100644 --- a/docs/get-started/selecting-redstone-model.md +++ b/docs/get-started/selecting-redstone-model.md @@ -1,28 +1,33 @@ --- sidebar_position: 1 -sidebar_label: "👀 Selecting a RedStone Model" +sidebar_label: "Select Your Model" --- -# RedStone Offers Three Solutions +# RedStone Offers Three Models ## 1. [RedStone Core Model](./models/redstone-core) -In RedStone’s innovative Core Model, data is dynamically injected into user transactions achieving maximum gas efficiency. This approach is user-friendly as the whole process fits into a single transaction. The Core Model significantly reduces the costs for dApps to access data feeds. -#### Best suited for dApps that would like access to several price feeds with frequent and cost-effective updates. +In RedStone’s innovative **Core Model**, data is dynamically injected into user transactions, achieving maximum gas efficiency. This approach is user-friendly as the whole process fits into a single transaction. The Core Model significantly reduces the costs for dApps to access data feeds. +**Best suited for:** +dApps that need access to several price feeds with frequent and cost-effective updates. ## 2. [RedStone Classic Model](./models/redstone-classic) -RedStone’s Classic model is designed for applications looking for the traditional oracle model of data being put onto the blockchain with longer intervals providing full control of the data source and the conditions for updates. -#### Best suited for dApps that require a lower frequency of data updates, fewer price feeds, or would like to be interchangeable with other oracle providers. +RedStone’s **Classic Model** is designed for applications looking for the traditional oracle model of data being put onto the blockchain at longer intervals, providing full control of the data source and the conditions for updates. +**Best suited for:** +dApps that require a lower frequency of data updates, fewer price feeds, or want to be interchangeable with other oracle providers. -## 3. [RedStone X model](./models/redstone-x) +## 3. [RedStone X Model](./models/redstone-x) -The X model is designed to fulfill the needs of advanced protocols such as perpetuals, options, and derivatives. By providing price feeds at the very next block after users' interactions the X model eliminates any [front-running](https://hacken.io/discover/front-running/) risks. -#### Best suited for perpetuals, options and derivative protocols. +The **X Model** is designed to fulfill the needs of advanced protocols such as perpetuals, options, and derivatives. By providing price feeds at the very next block after users' interactions, the X Model eliminates any [front-running](https://hacken.io/discover/front-running/) risks. +**Best suited for:** +Perpetuals, options, and derivative protocols. # Why We Recommend Our Core Model -The easiest way to make data accessible for applications that use smart contracts is by storing data directly on a blockchain. This approach is effective for large update intervals and a small number of assets. However, an increasing number of decentralized financial (DeFi) applications and modern derivative protocols require lower latency. To solve this problem, RedStone proposes an innovative modular design where data is first put into a [data availability layer](https://www.alchemy.com/overviews/data-availability-layer) and then put on a blockchain only when necessary. This allows for broadcasting a large number of assets more frequently while also reducing the costs for decentralized applications (dApps). +The easiest way to make data accessible for applications that use smart contracts is by storing data directly on a blockchain. This approach is effective for large update intervals and a small number of assets. However, an increasing number of decentralized financial (DeFi) applications and modern derivative protocols require lower latency. + +To solve this problem, RedStone proposes an innovative modular design where data is first put into a data delivery layer and then put on a blockchain only when necessary. This allows for broadcasting a large number of assets more frequently while also reducing the costs for decentralized applications (dApps). diff --git a/docs/get-started/tokens.md b/docs/get-started/tokens.md index a059d837..599f4fd5 100644 --- a/docs/get-started/tokens.md +++ b/docs/get-started/tokens.md @@ -1,6 +1,6 @@ --- -sidebar_position: 9 -sidebar_label: "🪙 Tokenomics" +sidebar_position: 5 +sidebar_label: "Tokenomics" --- # 🪙 Tokenomics