Distributed Validator-Oracle Contest

Contest dates

  • Submission period: 2 months after approving this proposal in the governance interface
  • Judging period: 2 weeks after the submission period


An oracle service in Free TON is needed to implement different services, such as stable coin, but not only.

The goal is to implement a distributed Oracle Validator as described in “NOT a TON binary system” paper.

General requirements

  1. Implement NOT the VALIDATOR module that submits price feeds into the smart contracts
  2. Implement a “NOT the Elector” smart contract
  3. Provide a testing system that takes TON/USD price stream from an external source, submit it into NOT the ELECTOR smart contract, agrees on price via NOT the ELECTOR logic, emits the event with the agreed price, and slash malicious NOT a VALIDATOR


NOT a Validator must transmit the TON/USD Price Feed into NOT the Elector Smart contract via an internal or external message (participants are free to choose the implementation). As well as participate in the commit-reveal mechanism described in NOT the Elector contract specifications below.

“Let’s imagine NOT also having validators. Let’s call them “NOT the Validators”. Instead of blocks NOT the Validators will create, submit and come to a consensus about prices of the TON/USD pair in the outer world. Let’s call them “NOT the blocks”. They will transfer their stake in TON DePools to the Issuer smart contract (let’s call it NOT the Elector, of course) for the duration of their stake in TON. Once submitted those stakes will participate in elections to become NOT a Validator in NOT the Elector smart contract. Much like the Elector smart contract, the stake they transfer to NOT the Elector can be “slashed” if the validator is providing wrong data to NOT the blocks. More on that later.

It is worth mentioning that while transferred to NOT the Elector smart contract TON stakes will continue earning rewards in the TON blockchain. The motivation to become NOT the Validator is that on top of these rewards NOT the Validators will earn a commission on all NOTs that will be issued. Thus the Validator of the TON blockchain can now effortlessly become NOT the Validator and earn additional rewards. Of course, technically it means connecting their node to a data feed from some exchanges and supplying the correct data to NOT the Elector. In fact, we can not care less how the prices ending up in NOT the Blocks, as long as this data is correct.”

NOT The Elector smart contract

The described algorithms that should be implemented in NOT the Elector contract may be amended to accommodate for a particular method of commit reveal scheme the participant may choose to implement within the boundaries of what is possible in TVM.

NOT the Elector contract may be implemented as a system of contracts rather than one contract as long as it provides all the functionality described below.

The agreed-upon price event should be sent into a proxy smart contract that other smart contracts could subscribe to.

“NOT the Elector contract is designed to collect the external TON/USD pricing value and is permanently running and therefore collects the data in an instant way. But the collecting is made in an encrypted way. The revealing mechanism is not performed on each data collection.

A quotation is made based on a decentralized and blind (sealed bidding) scheme by NOT the Validators. This ensures no one of the validators is aware of the quotes made by others in the commit-reveal scheme as discussed below. More sophisticated ZKP algorithms could also be implemented to raise the non-disclosure properties.

At a computationally unpredicted (cryptographically random) moment, the check of the given prices is performed. That is, all the data is to be revealed by submitters, and then checked with the given hash (commit) and analyzed. The correct in just mentioned sense values are considered as the initial price set. Those participants who cannot correctly reveal the data are considered pre-malicious.

Those participants whose values lie between the 25th and 75th quartile are considered honest and are rewarded. Those participants who feed the outlying data are considered as pre-malicious with some cumulative rank and they lose the current reward which goes to the honest participants with respect to this rank.

So let rank r be a number in [0,1] real-valued interval. We set that r = 0 corresponds to the honest participant and r = 1 to a malicious one. Initially, all participants have rank = 0. With the given rank the reward is calculated as (r-0.5)*r0 where r0 is the reward for an honest participant.

The rank is updated as follows: new rank is r’ = r*(1-a) + a*rc, where r is old rank, a - some constant in [0,1] and rc - the rank of the currently analyzed feed. rc is calculated based on the difference between the median value which is assumed as consensus value (see also explanations below) and given by the current participant.

{ rc = 0, for v25 < v < v75 ;
rc = 1-P (vi < v), for v ≤ v25 ;
rc = 1-P (vi > v), for v ≥ v75

where P (v ⋳ V) is the empirical probability that some random vi from the current price set lies in the interval V. So 1 - P (vi > v) ⟶ 1 with v → “max given number” and the same way 1 - P (vi < v) ⟶ 1 with v ⟶ “min given number”. v25 and v75 correspond to the edges of the honesty interval defined above. The iterative relation r’ = r*(1-a) + a*rc accumulate “errorness” of the feed with some rate a. The rate can be understood if we suggest the constant values i.e.

{ r0 = 0
rn+1 = rn*(1-a) + rc*a
rn ⟶ rc if n ⟶ ∞

Besides this, the validator is banned forever (excluded from the validators’ set) if it has undecreased rank > 0.5 during a certain number of checks. Note that if the validator would give the correct answers its rank will be instantly decreasing as a < 1 and therefore before it gets the total ban it could potentially clear the cumulative malicious rank.

Refusing to feed the price value is considered the same as feeding data with some constant rank which is a subject to determine based on convergence experiments on the pre-implementation (PoC) phase.
We realize that the quotation can be performed in an automatic or semiautomatic way, e.g. by feeding the contract with the real deal prices from any exchange they trust. That, in particular, means that they cannot verify each fed value on each step and therefore permanently punish them for the “incorrect” price would be unfair. And that is why we give them the pre-malicious status as a kind of warning to check their systems. On the warning, they can stop all feeding processes and fix them.

In the case when the Schelling mechanism cannot provide a single price (e.g. multimodal distribution) or when the normality check fails the quoting contract can

  • provide a series of values (activating a correspondent number of auctions);
  • refuse to provide any value, adjusted all participants with a certain rank (is a subject to investigate during the PoC);
  • in the case of multiple values, the winner auction ranks the losing modes with a certain rank of suspiciousness.

Incentivization to make a quote should take the following aspects into account:

  1. Quote makers are to be incentivized to make a quote - that is to feed the protocol with some information (the price value in our case).
  2. They are to be incentivized to feed a correct quote - that is the given price value should be close to real market price as much as possible.

We assume that quote makers are incentivized to do their job for the following reasons:

  1. To stabilize network common consensus
  2. To make the NOT issuing justified and reasonable
  3. To bring the correct economic characteristics in the system
  4. Not to lose the validators reward
  5. Not to lose their stake at all
  6. To gain rewards from stakes made with TONs from NOT the Auction
  7. To gain extra reward when suspicious participants slashed

To perform consensus on the given data the Schelling point mechanism is proposed. It had been originally introduced in 1960 by Thomas Schelling in his book “The Strategy of Conflict” and basically is used to represent the method to acquire the common knowledge which is based on unbiased human behavior in an informationally symmetric world (which we assume as the working case).

We use the same notions and ideas which originally come from Vitalik Buterin and roughly repeat the main steps of the quoting protocol (based on the commit-reveal scheme):

  1. During each block, all participants can submit a salted hash of the TON/USD price together with their TON address (commit).
  2. During the quoting phase (as well as the check phase, see above), users can submit the value and salt whose hash they provided at the previous stage (reveal).
  3. Define the “correctly submitted values” as all values N, where Hash (N+ADDR+Salt) was submitted in the first block and N, was submitted in the second block, both messages were signed/sent by the account with address ADDR, and ADDR is one of the allowed participants in the system.
  4. Sort the correctly submitted values.
  5. Every user who submitted a correct value between the 25th and 75th percentile gains a reward of a certain amount of TON which is collected from the suspicious participants.
  6. The quoting phase makes the same procedure for suspicious and malicious accounts as at the check phase.

As mentioned in the same paper, “the protocol does not include a specific mechanism for preventing Sybil attacks; it is assumed that proof of work, proof of stake or some other similar solution will be used” (Proof Of Stake in the Free TON case).

The current final price estimation is basically calculated as the median value of the correct dataset. It is later used in auction contracts (the consensus value is a subject to adjust if anomalies have been observed in distribution shapes and parameters).”

Evaluation criteria and winning conditions

  • Solidity or C++ languages for smart contracts should be used
  • Contest code must be submitted to Free TON · GitHub for evaluation and the following support
  • Distributed smart contracts are always preferable, the participants should avoid operations on large data sets as much as possible
  • System software languages are not limited, but Rust is always preferred

Fair play

As per Procedural remarks on contests.

Procedural remarks to jurors

As per Procedural remarks on contests.

External jurors

This contest involves external jurors from DevEx subgovernance in addition to DeFi Jury to assess the quality of smart contracts as per the remarks On external jurors involvement.

Name Telegram Public key Wallet address
Sergey Tyurin @Custler 2c0ec55a109eb466d9db5ee7c3adb075e77627ade83ae17cea847671ab8f0a85 0:77772d4f5ecefb9e7ce02bca4a13cf81b65b4903ead16671e935850075fc6b4c
Alexander Khramtsov @aleksandr_h 3bdb99452a6ed9138af385d035e0967250d0e2da6f58b90245f285daf250915c 0:625e7dda96d7b916d8779b1a44af8aa1e16e5cf6d029151207b0e359327ec7b9
Boris Ivanovsky @bivanovsky 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2
Pavel Khachatrian @get_username d89e20f2e164f4e64a3637cc6926baf66482bf8c875e4e7eebedd6f28024998c 0:32b2ab6941e3e08e98d1cb483f22bce8360643762405adf548d0fc785ae9879c
Nikita Monakhov @keshoid 816747e3c1e0c3be11797a76ffd5f823a1c933586cac2f170bc1395f1f25e15b 0:66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f
Evgeniy Shishkin @unboxedtype 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 0:612410a54714de99c56eead2d1a4c2a3afdf2edcc392c9d7120f1505b666770d
Dmitry Senitsky @senitsky 2937d687e7b39d2ffd3fe8f33476ded49b6aec6ec5b57fac88407b8181ca8fd1 0:f9a5517af619a16d1615d0e24ec3fb4ee8f9944cfd67610ce6a355090680fa94
Yaroslav Anishchenko @yanmsk c696f383a2d839b9fc7c036ab145982e644a3f14d2a57cd9429729f8bcb79eab 0:fff3ff48a6f00c5eda84bbac4781735ab0e7994950f55493a85c967f295760e7
Paul Mikhailov @pafaul 7657b6b62ec6846e6341315ba3b8d611afe2ef79e8ee3214d45cc4ede3c50972 0:b68e4c06f8d547d12a08af03975e5130c2bd7dd1171fd0407a2875956ea7588d
Andrey Nedobylsky @lailune fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b

Jury rewards

As per Procedural remarks on contests.

Governance rewards

As per Procedural remarks on contests.

Procedural reminders to all contestants

As per Procedural remarks on contests


Amendment: Distributed Validator-Oracle Contest


May 11, 2021 Distributed Validator-Oracle Contest started, but in the approved proposal rewards section was missed.

Below is a proposed Rewards section for this contest.


1st place …. 100k TONs

2nd place … 75k TONs

3rd place …. 50k TONs

4-5th places … 10k TONs

Proposal accepted :+1:

Contest Date Extension Proposal: Distributed Validator-Oracle Contest

As discussed on the Weekly DeFi Call #39, I propose to extend the end of contest period #24 Distributed Validator-Oracle Contest

New contest deadline

Tuesday, August 31th, 2021, 23:59

Contest Extension: Distributed Validator-Oracle Contest

Due to the complexity of the contest I propose to extend the submission period by two weeks.


#24 Distributed Validator-Oracle Contest

New submission deadline

Thursday, Sep 14th, 2021, 23:59

HI all, Pruvendo team is going to submit its solution in a few minutes. If you have any questions please contact me via Telegram @SergeyEgorovSPb