Skip to main content

✨ Overview


Block SDK

Slinky is business-licensed software under BSL. It is source viewable, but reach out to us to us if you are interested in integrating! We are limiting the number of chains we work with to seven in 2024. We apologize if we run out of capacity.

Visit the GitHub repo here.

For support, join our discord!

🦾 Slinky Features​

✅ Runs on the chain validator set - Slinky leverages the chain’s security, giving the fastest updates possible, and removing the requirements for any 3rd party systems.

✅ Highly performant - Slinky can support over 2000 currency pairs and price feeds, allowing the launch of thousands of permissionless on-chain markets.

✅ Full operational support - comes with a 1-day SLAs for adding new feeds, and 24/7 on-call support and maintenance by the Skip team.

✅ Better Application UX - by leveraging new advancements in consensus like vote extensions & ABCI++, Slinky guarantees a millisecond-fresh oracle update every block, allowing applications to build without sacrificing UX for safety.

🏎️ The Slinky Sidecar​

  • The Slinky 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.
  • Validators use GRPC requests to the sidecar to fetch the latest updates to update on-chain prices from over 20+ providers.

Sidecar

⚡️ On-chain aggregation​

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

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

  • Slinky 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 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)