[PROPOSAL 931] Slinky Beta Proposal


Neutron V4 introduces the Slinky oracle module developed by Skip Protocol.

Slinky relies on vote extensions and requires validators to run a very lightweight piece of software called the Sidecar to publish fresh data to the network. To ensure validators are able to smoothly onboard Slinky, the module will initially be introduced without jailing for failing to submit data as part of the vote extension process.

This proposal seeks 360,000 NTRN from the Cosmos Hub community pool to be distributed as performance incentives to Cosmos Hub validators based on their Slinky uptime during the Slinky Beta.

Background on Slinky

Designed for DeFi, Slinky brings oracles on-chain to minimize dependencies and offer faster, more secure price feeds. It relies on a specific Cosmos SDK module and ABCI++ to publish off-chain data such as prices on-chain at every block.

Slinky comes with a highly optimized and reliable piece of software called the Sidecar, which validators run in tandem with chain binaries to fetch prices safely and reliably from over 20+ providers; running aggregation logic to combine them into a single price for each feed.

Skip provides full operational support for Neutron and Cosmos Hub validators with 1-day SLAs for adding new feeds, and 24/7 on-call support and maintenance by the Skip team.

Security Model

With Slinky, data is only submitted if 2/3rds of the voting power agrees on its validity. As a result, the oracle is trust-minimized (just like IBC) since it does not introduce additional trust assumptions beyond the honesty of the network’s validator set. This ensures that the published data is as reliable as the network itself.

If less than 2/3rd of the voting power comes to consensus, the data is not published. If this happens multiple blocks in a row, the available data, for example a price feed, could become increasingly stale, which can pose a threat to the applications (restaking, DeFi, etc) that rely on it.

To prevent this issue, Slinky will implement downtime jailing. Just like traditional CometBFT behavior: validators that consistently fail to vote on prices will stop receiving block rewards until they resume participation. As long as validators follow the correct operation guides and act honestly, jailing should never happen.

As described below, jailing will NOT be enabled in the initial release, which is considered a Beta.

Slinky Beta

To ensure a smooth onboarding experience for Cosmos Hub validators, Slinky will launch under Beta and with oracle-price-update jailing disabled. The Beta phase will start upon Slinky’s launch on Neutron’s mainnet and last 3 months or until Cosmos Hub validators have achieved a high degree of stability and performance, whichever occurs first.

During this period, core contributors from Skip Protocol and Hadron Labs will assist validators with properly setting up and operating the sidecar. Skip Protocol has developed dedicated documentation about the deployment which can be found here.

Performance incentives

To encourage excellence among the set, we propose to make validators eligible to rewards up to 2000 NTRN based on the percentage of Beta-period blocks in which they successfully published updated data. This has been modified according to validator feedback as follows:

  • Less than 90% - No reward
  • 90-95% - 500 NTRN
  • 95-99% - 1000 NTRN
  • More than 99% - 2000 NTRN

NTRN rewards would be provided by the Cosmos Hub Community Pool in line with the ‘Cooperation’ clause agreed in respect of the Hubs NTRN holdings in proposal 835. These performance rewards would come as a bonus on top of the existing validator subsidy approved in Cosmos Hub proposal 867.


This proposal includes an executable transfer message for 360,000 NTRN from the Cosmos Hub Community pool to a 2/3 multisig composed of members from Informal Systems, Hypha and CryptoCrew Validator.




Christian - CryptoCrew - cosmos1y6vfcekl4wycqfmfkwlchpr876wehd7yz74lvn

Brian - Informal - cosmos1vy22e0s5e9pj3w2ur2f4sgp3gd3qdqldhk533a

Dante - Hypha - cosmos12lprpucjwul7kqyvlvc0u4x9atymmex0s6d2zc

Any excess NTRN not paid out to validators as rewards for their price update performance during the Beta period will be returned to the Hub Community Pool by the multisig at the end of the beta period.

Important note to application developers

During the Slinky Beta, the oracle may experience major price deviations, price update delays, or other sudden issues. It will only be intended to be used for experimentation and training purposes by developers and validators. We advise against using Slinky to secure meaningful amounts of funds or to power production deployments of protocols during the beta phase.


  • Early June (exp. June 12th): Slinky launches on Pion-1 Testnet as part of Neutron V4 upgrade
  • Mid June (exp. June 19th): Proposal to upgrade Neutron mainnet to V4
  • Early July (exp. July 3rd): Neutron V4 Mainnet Upgrade
  • Q3-Q4 (End of beta phase): Price update downtime jailing is enabled. Performance rewards are paid out. Excess NTRN is returned to the Cosmos Hub community pool.

Governance votes

The following items summarize the voting options and what they mean for this proposal:

YES: You wish to signal your approval for the distribution of NTRN performance incentives from the Cosmos Hub community pool to Cosmos Hub validators based on the % of blocks in which they successfully publish updated prices during the Slinky Beta.

NO: You oppose the distribution of NTRN performance incentives from the Cosmos Hub community pool to the Cosmos Hub validators for their participation in publishing price updates on Slinky.

ABSTAIN: You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

NO WITH VETO: A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.


Does it require validators to run additional infrastructure at any point?

Validators must run a sidecar (separate binary) that is pretty lightweight, so this should have a very small impact on current performance. Skip Protocol has developed dedicated documentation about the deployment which can be found here.

1 Like

We think this is good proposal, it should give sufficient incentive to have a widespread deployment of the sidecar and therefore offer better decentralization. To provide constructive feedback to this proposal we would suggest to revise the performance grades to a higher standard.

We propose:

  • Less than 90% - No reward
  • 90-95% - 500 NTRN
  • 95-99% - 1000 NTRN
  • More than 99% - 2000 NTRN

We note an expected high correlation between the sidecar sign rates and the actual block signs of each validator. Upon examination of the existing operational data, it is evident that the network consistently maintains a sign rate exceeding 99%.

Source: https://analytics.smartstake.io/cosmos/stats#performance

We propose updating the tiers to reflect these statistics, thus enhancing excellence within the group. In the event of any disruption caused by potential bugs in slinky on the mainnet affecting the entire validator set, we suggest excluding such downtime from the counts. It’s crucial to remember that validators are a key product that the hub offers to the broader ecosystem. High-efficiency execution should be a fundamental expectation, reinforced by appropriate incentives.

Thanks for reading,


Thanks for the feedback, I’m adjusting the proposal to incorporate that change.


Proposal has been published and is available for voting:

1 Like