Skip to main content

🏛 Push Model

Pushing feeds on chain​

Although the pure on-demand fetching model (RedStone Pull) 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:

  • 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
info

RedStone Push has a significant advantage over traditional push Oracles. Our modular design gives you a decisive voice on when and how the price is updated (with other Oracles you have to accept dictated parameters).

How RedStone Push works​

This approach is built on top of the RedStone Pull 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 responsible for pushing data on-chain in a customized way using environment variables. The second part is the on-chain contracts which enable storing prices and getting them through a familiar interface (e.g. the Chainlink Aggregator ). RedStone Push can be used on all EVM-compatible L1s & L2s + Starknet + Fuel Network.

RedStone push diagram

Relayer​

The relayer is a service that works in a customizable way based on environment variables. It periodically checks a defined set of conditions, pushing the prices when they are satisfied. It is possible to pass multiple conditions to the UPDATE_CONDITIONS, then the relayer will work in the manner that if any conditions are met prices would be updated. Currently, two conditions are implemented:

  • a time condition described by UPDATE_PRICE_INTERVAL variable in milliseconds, which states how often prices should be updated (aka heartbeat), code

  • a value-deviation condition described by MIN_DEVIATION_PERCENTAGE variable which indicates how much value should change in order to trigger the price update, code.

info

Relayers are permissionless and anyone could run the service as the data is eventually validated on-chain using conditions defined by the protocol stakeholders. Moreover, the relayers are designed to work in parallel and we recommend having multiple (ideally independent) instances to mitigate the risks of a single point of failure and censorship.

Contracts​

The on-chain relayer is based on the PriceFeedsAdapter contract which is responsible for:

  • storing all price feeds' symbols (mappings to RedStone dataFeedId),
  • storing price feeds values,
  • updating price feeds values in batch,
  • storing information regarding the round number and timestamp of the last update,
  • getting prices for multiple feeds' values in a single call.

Additionally, if the protocol wants to be 100% compatible with the Chainlink PriceFeed architecture, it's possible to deploy additional PriceFeed contracts to mimic this solution.

Environment variables​

VariableDescription
RELAYER_ITERATION_INTERVALTime interval in which the relayer tries to update prices
UPDATE_CONDITIONSArray of parameters that describes what decides if prices can be updated, currently acceptable parameters are 'time' and 'value-deviation'
UPDATE_PRICE_INTERVALTime interval that describes how often prices should be updated if UPDATE_CONDITIONS contains the "time" parameter
MIN_DEVIATION_PERCENTAGEMinimum deviation of the prices that triggers prices update if UPDATE_CONDITIONS contains "value-deviation"
RPC_URLURL of RPC for interaction with blockchain
CHAIN_NAMEChain name of the blockchain relayer should work on
CHAIN_IDChain id of the blockchain relayer should work on
PRIVATE_KEYPrivate key of the wallet with funds on a proper network to push prices to the adapter contract
ADAPTER_CONTRACT_ADDRESSAddress of the adapter contract deployed on a proper network
DATA_SERVICE_IDRedStone Wrapper parameter that describes what data services should be used to fetch the price
UNIQUE_SIGNERS_COUNTRedStone Wrapper parameter that describes how many unique signers should sign price data
DATA_FEEDSRedStone Wrapper parameter that describes what tokens will be used
CACHE_SERVICE_URLSRedStone Wrapper parameter that describes what cache services URLs will be used to fetch the price
GAS_LIMITGas limit used to push data to the price feed contract