> ## Documentation Index
> Fetch the complete documentation index at: https://skip-connect.mintlify.site/connect/llms.txt
> Use this file to discover all available pages before exploring further.

> Learn how Connect works with ABCI++

# Architecture

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.

<img src="https://mintcdn.com/skip-connect/zi50PqjyY4lkGsRj/img/sidecar.svg?fit=max&auto=format&n=zi50PqjyY4lkGsRj&q=85&s=37fdfa5030197c35349281f3e1817ec3" alt="Sidecar" width="1225" height="636" data-path="img/sidecar.svg" />

## On-chain aggregation

Connect uses <b>[ABCI++](https://docs.cometbft.com/v0.38/spec/abci/)</b> to separate Oracle aggregation into secure and efficient steps.

<img src="https://mintcdn.com/skip-connect/zi50PqjyY4lkGsRj/img/connect-arch.png?fit=max&auto=format&n=zi50PqjyY4lkGsRj&q=85&s=13da3e64c6d6981f2c3dd2ce1cb4bd9f" alt="Connect Architecture" width="2556" height="1139" data-path="img/connect-arch.png" />

### 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.

<img src="https://mintcdn.com/skip-connect/zi50PqjyY4lkGsRj/img/prepare.svg?fit=max&auto=format&n=zi50PqjyY4lkGsRj&q=85&s=5646b53d0692f0ffdb5b7b356315fbc5" alt="Prepare Proposal" width="806" height="311" data-path="img/prepare.svg" />

For more information on vote extensions in general, refer to <b>[the Cosmos SDK docs](https://docs.cosmos.network/main/build/abci/vote-extensions)</b>.

### 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)