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

1 Like

Contest Proposal: NOT Phase 2 (Auctions)

Short Description

The contestants must provide their ready-to-production implementation of the auctions for NOT stable coins in exchange of native TON cryptocurrency. As a mandatory supplement the implementation of the cooperative auction participant (D’Auction) must be developed. The detailed requirements are provided throughout the present document.


While the native TON cryptocurrency is considered as an investment instrument (that is supposed to increase its value over time) it can hardly be used as a means of exchange. Briefly, the owners of an asset that is supposed to grow are encouraged to hold it rather than to spend.

The former statement leads to, for the full ecosystem, another instrument, that acts as a means of exchange must exist. The proposed detailed architecture is fully described at the Winning document of Defi#14.

The implementation of the concept mentioned above is splitted into three phases:

  1. NOT Electors and NOT Validators - implemented at Defi#24
  2. Auctions and D’Auctions - the task for the present contest
  3. NOT Tokens and overall integration - the task for a further contest

General requirements

Described at Procedural remarks

Additionally the following requirements must be followed:

  • Solidity or C++ languages for smart contracts should be used
  • Contest code must be submitted to 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
  • It’s highly recommended to check ForMet SG for the kind of specification desired by them.

Common technical requirements

  1. The solution MUST implement the auctions for NOT tokens automatically initiated upon price reveal as implemented by Defi#24

  2. The auctions MUST fulfill the requirements mentioned in the corresponding section

  3. The D’Auctions MUST be implemented fulfilling the requirements mentioned in the corresponding section

  4. The NOT Tokens MUST be referred via the interface (or set of interfaces) that MUST be applicable, at least, both for NOT native tokens (whatever it means) and for TIP-3 style NOT tokens

  5. The evidence of workable solution MUST be provided:

  6. The solution MUST be deployed to any test network (local usage is not enough)

  7. The demonstration of the workable solution MUST be provided (both at AMA session as well as at the personal environment of each juror)

  8. The manual for verifying the solution MUST be provided and MUST provide extremely clear and detailed instruction

  9. In case the implementation of NOT token is required for the demonstration its stub implementation MUST be provided

  10. All the contestants MUST provide their contact information as a Telegram ID

  11. All the participants are strongly encouraged to reuse the results of Defi#14, otherwise they MUST provide a strong explanation and description of their approaches.

Any violation of the requirements mentioned above will lead either to the complete rejection of the submission or to strong penalties.


Auctions are designed against the pair TON/NOT and NOT/TON. While the internal mechanics of NOT will be implemented at the next phase the TIP-3 compatible interface MUST be defined for NOT operations.

  1. Auction is performed on demand with a minimum lot size. It sells as many NOTs as demanded by the winners but filtering participants by the required amount (one cannot participate if bids are valued smaller than predefined).
  2. It is designed as Vickrey auction (sealed-bid, second price).
  3. The bid sealing is performed by the commit-reveal scheme
  4. It has the predefined zero position based on quoting result, so that the participant has to submit the bid higher (or same) than quoting price to get the bid accepted. The quoting price is taken from NOT the Elector that was implemented during the first stage of the NOT set of contests.
  5. The quoting price should not be disclosed before the auction starts (according to #2).
  6. The winner address, winning and paid (second) price are disclosed at the end of auction.
  7. If no one wins, the auction is considered as failed and the lot is not sold.
  8. Auction is paid (so the bids must be locked and predefined fees are supposed to be taken for storage and winning), and the payment is to go to NOT the validators, and as a payment for larger liquidity (because of minimum lot value).
  9. Bids implementation has to support DePool stakes as well as plain bids in TONs
  10. After the auction ends every participant can buy the desired amount of NOTs by the price determined at the last auction increased by some factor

The participant has a right to propose another mechanics of the auctions, however a clear and evident explanation MUST be accompanied with and corresponds to the common network design and principles of Free TON.


While auctions are supposed to have a pretty large minimal amount the participants with smaller budgets are supposed to collaborate into the collective auction participants called as D’Auctions. That is made in a very analogous way dePools are designed.

The contract MUST contain the following roles:

  1. Aggregator (representor). Account which owns the dAuction contract. It’s obligations include making a proper bid (which should be not less than a certain percentage of cumulative buying demand, algorithmical way to calculate the bid is preferrable), making a bid in a main auction at proper time.
  2. Participant. Account which gives the contract rights to bid from her name acting together with aggregator
  3. Intermediate media. Accumulates the bids in a proper way, allows the representor to make a price bid, sends the bid to the auction contract, pays all correct fees, collects the results and distributes the won lot between them all and returns or rebids the original bids if the contract loses the auction. Should be implemented in a decentralized way where the specific implementation of the items mentioned above is spreaded between Aggregator and mostly Participant.
  4. The aggregator and participants’ buy price is finally adjusted by their amounts and roles (aggregator has some additional benefits as a reward for being a representor) All the D’Auction constants are subject to be determined at implementation phase, may vary from one contract to another and should establish adequate incentives for all players.

D’Auction can be performed once or at an instant (until win) way. If some participant exists the D’Auction decreasing total buy potential less than minimum lot size, D’Auction needs to find new participants to fit the requirements. If D’Auction wins it distributes the bought lot and closes (or reinvests the participant’s bids for the next auction), .

The D’Auction participants in any way should have more benefits than any user in the after auction phase to incentivize participants to enter it. As the D’Auction representor should not be a validator no punishment mechanism is currently proposed as well as no reputation is recorded as we suggest that the new auction allows participants to reorganize in a new D’Auction.

The list of currently available open D’Auction should be also available with all important parameters transparently given to let newcomers easily choose and participate based on their internal preferences. The duration of D’Auction non-winning lifetime can also be specified in advance, after which D’Auction is closed and returns the collected bids back independently on status.

The participant has a right to propose another mechanics of the D’Auctions, however a clear and evident explanation MUST be accompanied with.

Contest Dates

15 Nov 2021 - 20 Dec 2021

Voting duration

10 days

Proposed Prices

The contestant awards are distributed as follows:

  • Place 1 - 150 kTON
  • Place 2 - 100 kTON
  • Place 3 - 80 kTON
  • Place 4 - 50 kTON
  • Place 5 - 30 kTON

The following administrative expenses will be in place:

  • Jurors - 2 kTON each for each submission analyzed (voted, not abstained, with at least three lines of comments)
  • Submitter of the present document(@SergeyEgorovSPb) - 3 kTON
  • The Secretary of the SubGov (@BigSpaceRoach) - 3 kTON
  • Authors of original idea (@andruiman, @Futurizt) - 3 kTON each

The Jury

Jury team

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. The exact names of jurors should be determined by a special proposal submitter 2-3 weeks before the end of the present contest.

Basic rules

  • Jurors whose team(s) intend to provide submissions in this contest shall lose their right to vote in this contest
  • Each juror shall vote by rating each submission on a scale of 0 to 10 (0 equalling rejection of the proposal); jurors may abstain from voting if they do not see themselves sufficiently qualified to judge such proposal
  • A juror that has voted on a submission shall provide detailed feedback (at least, three lines of comments) on it otherwise he is not eligible for awards

Jury Guidelines

Described at Procedural remarks


  • All the awards MUST be distributed within two weeks after the completion of voting
  • Each rejected submission gets nothing
  • Each submission that gets at least 5 points receives its award according to the Proposed Prices
  • Each submission that earned fourth or lower place receives its award according to the Proposed Prices
  • Each other submission gets a half of its award according to the Proposed Prices . The second half is vested for one month that is paid exclusively in case the quality of the submission is brought up to the required standards (that is managed by the separate proposal voting)

Extensions and respins

  • The contest can be extended when and only when:
    • No submissions are provided by the deadline - in this case the contest MUST be extended by two weeks
    • It was a system outage for the last eight hours of the contest (such as a mainnet downtime, lack of funds on the voting contract etc.) - in this case the contest MUST be extended for one day
    • The scope and/or conditions of the contest has been changed throughout the contest - it MUST be handled by a separate proposal
  • The voting can be extended when and only when:
    • Less than two votes were received by the deadline - in this case the voting MUST be extended for three days
    • It was a system outage for the last eight hours of the voting (such as a mainnet downtime, lack of funds on the voting contract etc.) - in this case the contest MUST be extended for one day
  • In case that no submissions were accepted :
    • Jurors and administrators get their payments
    • If somebody request a full respin from scratch within three days the full respin MUST be conducted
    • Otherwise, a short fix-up sprint with the same prices as original and duration not longer than 2 weeks MUST be overtaken

Procedural Limitations

  • Only one submission per contestant shall be accepted. Multiple submissions, including but not limited to updated versions of the initial submission, are not allowed.
  • Submissions shall be made within the time frame defined above in the Contest Dates section. Late submissions shall be rejected by the Jury.
  • All submissions shall contain the contestant’s contact information (preferably a Telegram ID) to ensure that the jury can match the submission to the specific contestant. If such contact information is missing, the submission shall be rejected.
  • If the submission contains links to external material (reports on further work by the contestant), this material shall have the contestant’s contact details (preferably a Telegram ID), to ensure that the jury can match the material to the specific contestant. If such contact information is missing, the submission shall be rejected.
  • Under any circumstances the decision of jurors can not be questioned or appealed
  • Any juror or participant can request an AMA session and this session MUST be granted if it was requested at least five days before the voting end.