Skip to main content

🤫 Upcoming Features

What's next for Slinky?

Slinky has a number of major releases already in the works. Below, we outline a couple of the research and product directions we're building.

🔀 New Types of Data

Estimated: April 2024

As a fast follow to our support for prices, Slinky will be able to provide chains with Verifiable Randomness Functions, offchain asset reserve proofs (to support RWA tokens), and light client support (to borrow security and post data to other protocols, like EigenLayer or Celestia).

🤝 Validator Subsetting

Estimated: June 2024

In it's standard implementation, all validators running Slinky are expected and accountable for posting prices for all currency pairs every block. Although Slinky is optimized to do this for over a thousand currency pairs, it can scale further if subsets of validators are selected to report specific prices.

Our excitement is for this feature to enable an active marketplace, with users and traders creating incentive pools for validators that support their desired currency pair, and validators opting-into additional committments to do so.

🌈 Rollup Support

Estimated: August 2024

Already, Slinky integrators are using the oracle to gossip prices to rollups that use their chain as a settlement or DA layer. We plan to expand the tooling to more easily support rollups in general, and help our integrators become hubs for fast, verifiable data provisioning across the L2 landscape.

Currently, we are working with Celestia and RollKit team to build out a first version.

💻 Sidecar Restaking Services

Estimated: November 2024

Slinky is a restaked operation by design. However, the incentive and slashing mechanisms tied to the operation of the Slinky oracle can be extended to other services that validators can offer chains. For example, this would include:

  1. Running IBC-relayers within Slinky in an on-chain, verifiable way, and rewarding validators on a per-packet basis.
  2. Running indexers and servers within the sidecar to service decentralized frontends.
  3. Running bridge software (e.g. "Peggo") to give chains guaranteed interoperability with outside networks.
  4. Running generalized offchain computation and posting ZK proofs (e.g. optimal routing, fee markets) to lighten node binary computation burden while still having verifiable ways of posting computation results.
  5. Running an external transaction gossip network to lower bandwidth load on Comet/Tendermint, allowing chains to finalize significantly faster.

Our integration partners will be invited to test and influence these features, effectively leveraging their existing operator set for greater and greater value.