RedStone

RedStone is a modular oracle delivering price data through three models: Pull (on-demand data in calldata), Push (classic Chainlink-compatible on-chain feeds), and RedStone X (frontrunning-protected delayed execution). It supports 1000+ data feeds across Ethereum, Arbitrum, Optimism, Base, Avalanche, BNB Chain, and other EVM chains.

What You Probably Got Wrong

• RedStone Pull model is NOT like Chainlink push model -- In RedStone Pull, price data is NOT stored on-chain. It arrives in the transaction calldata, injected by the frontend SDK (@redstone-finance/evm-connector). Your contract inherits RedstoneConsumerBase and extracts the price from calldata at execution time. If you try to read a storage slot for the price, you will get nothing. This is the core mental model shift.

• You must wrap transactions on the frontend -- The contract alone is not enough. The frontend must use WrapperBuilder from @redstone-finance/evm-connector to attach signed price data to every transaction that reads an oracle value. Without this wrapping step, the contract reverts with CalldataMustHaveValidPayload.

• getOracleNumericValueFromTxMsg returns a uint256 with 8 decimals -- RedStone prices use 8 decimal places by default. ETH at $3,000 returns 300000000000 (3000 * 10^8). This matches Chainlink USD feed conventions. Override getUniqueSignersThreshold() to set how many data providers must agree.

• Push model exists and IS Chainlink-compatible -- RedStone also offers classic push feeds that implement AggregatorV3Interface. These are drop-in replacements for Chainlink feeds. Use push when you need composability with existing Chainlink-consuming contracts. Use pull when you want cheaper gas and on-demand freshness.

• Data feed IDs are bytes32, not strings -- Feed identifiers like ETH, BTC, USDC are encoded as bytes32 using bytes32("ETH") in Solidity. The SDK handles string-to-bytes32 conversion automatically, but in Solidity you must use the bytes32 form.

• RedStone X is a two-phase commit, not a simple price read -- RedStone X protects against frontrunning by splitting execution into: (1) user submits intent, (2) keeper executes with delayed price data. The price used is from AFTER the intent was submitted, so the user cannot frontrun the oracle update.

• Timestamp validation is mandatory -- RedStone data packages include timestamps. The contract validates that package timestamps are within an acceptable range of block.timestamp. Override isTimestampValid(uint256) if you need custom staleness logic. Default allows 3 minutes of drift.