NEVER Phase 2 (Auctions)

Contest Proposal: NEVER Phase 2 (Auctions)

Contest dates

  • Submission period: 6 weeks after the proposal acceptance date.
  • Voting period: 2 weeks after the submission period end.

Short Description

The contestants must provide their ready-to-production implementation of the auctions for NEVER stable coins in exchange of native EVER 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 EVER 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. NEVER Electors and NEVER Validators - implemented at Defi#24
  2. Auctions and D’Auctions - the task for the present contest
  3. NEVER 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.

Fair play

As per Procedural remarks on contests.

Common technical requirements

  1. The solution MUST implement the auctions for NEVER 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 NEVER Tokens MUST be referred via the interface (or set of interfaces) that MUST be applicable, at least, both for NEVER native tokens (Currency Collections) and for TIP-3 style NEVER 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 NEVER 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 EVER/NEVER and NEVER/EVER. While the internal mechanics of NEVER will be implemented at the next phase the TIP-3 compatible interface MUST be defined for NEVER operations.

  1. Auction is performed on demand with a minimum lot size. It sells as many NEVERs 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 NEVER the Elector that was implemented during the first stage of the NEVER 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 NEVER the validators, and as a payment for larger liquidity (because of minimum lot value).
  9. After the auction ends every participant can buy the desired amount of NEVERs by the price determined at the last auction increased by some factor
  10. Participants are encouraged to base their solutions on the existing implementations of Vickrey auctions (see DevEx SG contests #26 and #16). However, it’s up to participants to decide if such solutions are applicable or should be developed from scratch.

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 Everscale.


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. Exact algorithm, set of variable parameters and system of timings are not determined and should be proposed by solution. 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 must 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.

Evaluation criteria and conditions for winning

Hard criteria

  • Implementation of Auction and D’Auction contracts (as well as auxiliary contracts) that satisfy to the requirements above
  • The contract system must be deployed to any testnet. The submitter must provide the clear instructions how to demonstrate it works as well as to demonstrate it at AMA session
  • All the elements to be developed at the later stages may be substituted with some dummy implementations. However, these dummies still must not prevent the system from demonstration its workability
  • The submission must be accompanied with the full documentation that should contain:
    • Generic description of the solution
    • Technical description of the solution
    • Clear build and deployment instructions
  • All the configurable constants must be moved to a separate file and clearly described
  • The configurable parameters describing D’Action strategy must be clearly described. The D’Action contract must provide all the getters to fully understand its strategy

Soft criteria

  • Everyday English to make technical documentation easier to understand. Additional languages will be an advantage.
  • Completeness and readiness of the product for actual use in the mainnet.
  • Additional interfaces, de-bots, unit-tests, mobile apps will be a plus.


  • Source code of all the implemented smart contracts (published at github or any other widely recognized repository storage)
  • Documentation in PDF or MD format
  • Addresses of the contracts published in the testnet
  • Evaluation instructions


Prize places

As per Procedural remarks on contests.

Selected calculation mode: DEFAULT.


Place Prize, EVER
1 150 000
2 100 000
3 80 000
4 50 000
5 30 000

Procedural remarks for jurors

As per Procedural remarks on contests.

For the sake of this contest the Hard threshold is set to 6 points.

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
Boris Ivanovsky @bivanovsky 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2
Nikita Monakhov @keshoid 816747e3c1e0c3be11797a76ffd5f823a1c933586cac2f170bc1395f1f25e15b 0:66e01d6df5a8d7677d9ab2daf7f258f1e2a7fe73da5320300395f99e01dc3b5f
Evgeniy Shishkin @unboxedtype 6ff61c1a7bb09795f7b5d5514dd710efb72e9557654d362ef208fde545ba7a33 0:612410a54714de99c56eead2d1a4c2a3afdf2edcc392c9d7120f1505b666770d
Andrey Nedobylsky @lailune fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b
Yaroslav Anishchenko @yanmsk c696f383a2d839b9fc7c036ab145982e644a3f14d2a57cd9429729f8bcb79eab 0:fff3ff48a6f00c5eda84bbac4781735ab0e7994950f55493a85c967f295760e7

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.

CONTEST mode was declared over last year. CONTEST causes most of the tokens to be meaninglessly outflowed.
Why would there still be a competition?

Pruvendo team is going to send its solution shortly. For all the questions feel free to ask me at SergeyEgorovSPb

Post for submission.

Post for submission by Radiance Team

Hi! Here is our submission:
Contact on Telegram: @Abionics, @get_username
Wallet: 0:fa94171cb0565789224814561cc558e59315971ee9d03085de3dcb5f8b94d95e

Solution Summary:

Submission 1

Basic requirements for Auction and DAuction are met
For Never, a solution has been implemented for both the TIP3 variant and the CurrenceCollection.
There is a general and technical description of the solution

Features: DAuction uses an offline calculation of the weighted bid of all participants. The developer motivated by the fact that online calculation allows you to get information about the rate in advance, before the moment of disclosure.

What is missing:
Tools and descriptions of the deployment process, checking the result and performance. There is no frontend.
The only address indicated in the documentation is not in the devnet.
There is no demonstration.

SUMMARY: the solution looks working and meets the requirements technically (Hard criteria), but there are no deployed contracts and it is difficult to check the performance. There is also a bit of a lack of detailed documentation.

Submission 2

Solution from Radiance team
Satisfies hard criteria, except that only the TIP3 interface is implemented for the Never token (there is no native Never yet, this is true, but there was such a requirement)
There is a good front that allows you to create an auction and check the performance of the solution.
Contracts are deployed in the test network. There is a general and technical description, instructions for deploying and testing the solution.
The code is neat and well documented.
The constants are placed in a separate file.

Of the minuses:
DAuction stores member deposits in a mapping, which can be a bottleneck. Other participants did not use mappings, but adhered to the concept of distributed programming.
Also, only the TIP3 variant for the Never token has been implemented, although the requirements also indicated the need for a CC version.

Submission 3

All Hard criteria are met, Never tokens have both TIP3 and CC interface.
Mappings are not used, everything is on separate contracts.
There is a front that allows you to see past auctions.
Contracts are deployed in devnet
There is a demo with deployment instructions
There are tests, the code is well commented.

In this solution, I did not find anything to dig into.

Submission 4

The solution seemed a bit crude to me.
There is no implementation of the TIP3 interface for Never tokens, only CC.
There are a lot of commented out pieces in the code and questions to hisself, how best to do it here. It seems that not everything works correctly.
There is no front.
There is no separate constant contract, although it was in the requirements.

Contracts are deployed in the dev network. There are shell scripts for deployment and use.
Mappings are not used.
There are also tests in TS4.

In general, the solution looks working and meets many requirements, it seems that the developer did not have enough time.

My results:

Submission 1-5
Submission 2-7
Submission 3-10
Submission 4-5

1 Like