Staking is an essential component when designing an on-chain Oracle for a layer 1 Substrate NPOS chain. There are two competing staking designs:

  1. Create new staking/sessions modules for the Oracle. Those who wish to become a data provider must bond stake here.
  2. Share the NPOS stakes and validators. Any node that qualifies as a validator is also qualified to provide data. Rewards/slashes go here too.

The primary motivation for going with option (2) is to increase the cost of a 51% attack. If separate pools are required for each of NPOS and the Oracle, then the 51% threshold for either pool will be much easier to reach than a single large pool.


  1. Are there counter-arguments to why this route is not advisable? If so, why, and what's better? Note that use of an off-chain oracle solution is not preferred.

  2. What are the issues to be mindful of if going this route? One is managing sharing of rewards to incentivize activity on both fronts. Any others, such as security concerns or interfering with the original functionality of NPOS aspect?

1 Answer 1


In principle, one might explore zk oracle flavors too. If for example, you could get price quotes by email or better binding trade offers, then these libraries might be useful:



In principle, we could verify email DKIM signatures directly on polkadot much cheaper, but maybet he privacy winds up important somehow.

An example project that uses zk verification of DKIM signatures and email contents.


As for validators being oracle nodes..

We've some W3F grant recipient doing TCP packet verification too, so zk proofs into packets routed via their own attestor nodes. You'd need stake for the attestor nodes, who attest to the packets' origin. A priori, attestors would be their own parachain nodes though, which creates oracle staking concerns.

In theory, approval checkers (validators) could provide this service with much greater security, or some more specilized oracle service, except..

We depend upon reaching concensus in the approval checker system, so they cannot each vote differently because some external party acted differently. Indeed, we'd slash backing validators 100% if the vote went badly for them.

We'd need para blocks to only "request" that an oracle script run, and then approval checkers results all become mere gossip messages, not block contents. Any individual approval checker's results could then be posted somewhere, but..

We never actually have concensus upon who approval checked some particular parachain block, so how would you know you've sampled all the approval checkers? In theory, we might block finality upon requested messages from all approval checkers being attached. It's kinda doable, but really nasty in practice: These interaction scripts could easily require more than 1s, which causes us problems.

  • My question could've been clearer--I am seeking to build an independent chain, not parachain (hence having NPOS). I am debating the merits of modifying the existing staking pallet to so the NPOS-staked amounts can qualify an Oracle data provider, versus creating another staking pool just for the Oracle.
    – RavenMan
    Mar 6 at 22:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.