The Connect sidecar is an out-of-process service that efficiently fetches prices from various data sources and runs aggregation logic to combine them into a single price for each feed. The application uses GRPC requests to the sidecar to fetch the latest updates to update on-chain prices from over 20+ providers. Sidecar

​
On-chain aggregation

Connect uses ABCI++ to separate Oracle aggregation into secure and efficient steps. Connect Architecture

​
Extend Vote / Verify Vote

The ExtendVote and VerifyVote methods of ABCI++ are where a price is first queried.
  • The validators fetch prices from the sidecar from a series of providers (e.g. Binance / Coinbase) for each currency pair.
  • For each pair, the median is taken between all providers.
  • Each validator then submits their final prices to the chain via the ABCI++ ExtendVote method.
  • VerifyVote is used to ensure that the submitted data is valid—i.e. it can be unmarshalled by another validator.

​
Prepare Proposal

During PrepareProposal, the vote extensions from the previous block are aggregated by the block proposer into their block proposal, after various checks are run on them.
  • Connect ensures that the set of vote extensions comprise the required minimum stake required for a price update (default of 2/3).
  • It also ensures that the vote extensions are valid and can be understood by the application.
  • Finally, it encodes the vote extensions and injects them into the top of the block proposal as a pseudo-transaction ignored by the chain.
Prepare Proposal For more information on vote extensions in general, refer to the Cosmos SDK docs.

​
Process Proposal

ProcessProposal is identical to PrepareProposal, except it is run on every validator to validate the block proposal.
  • If the validator comes to the conclusion that the injected votes are valid and comprise the required minimum stake, it will accept the proposal.
  • If not, the validator will reject the proposal.

​
Finalize Block

The end of a price’s journey is in the Preblock step.
  • Here, the injected transaction data is unmarshalled back into vote extensions, and the application takes a stake-weighted median of the prices reported by every validator.
  • The resulting canonical price for each pair is stored in the x/oracle module and can be queried by any application or RPC.

​
Full Flow

  • This full set of steps repeats on every block resulting in a continuous stream of guaranteed prices. The oracle is enshrined in the application by the validator set, and so is fundamentally equivalent to chain liveness (i.e. the oracle can’t go down without the chain going down)