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.
Motivation
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:
- NEVER Electors and NEVER Validators - implemented at Defi#24
- Auctions and D’Auctions - the task for the present contest
- 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
-
The solution MUST implement the auctions for NEVER tokens automatically initiated upon price reveal as implemented by Defi#24
-
The auctions MUST fulfill the requirements mentioned in the corresponding section
-
The D’Auctions MUST be implemented fulfilling the requirements mentioned in the corresponding section
-
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
-
The evidence of workable solution MUST be provided:
-
The solution MUST be deployed to any test network (local usage is not enough)
-
The demonstration of the workable solution MUST be provided (both at AMA session as well as at the personal environment of each juror)
-
The manual for verifying the solution MUST be provided and MUST provide extremely clear and detailed instruction
-
In case the implementation of NEVER token is required for the demonstration its stub implementation MUST be provided
-
All the contestants MUST provide their contact information as a Telegram ID
-
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
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.
- 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).
- It is designed as Vickrey auction (sealed-bid, second price).
- The bid sealing is performed by the commit-reveal scheme
- 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.
- The quoting price should not be disclosed before the auction starts (according to #2).
- The winner address, winning and paid (second) price are disclosed at the end of auction.
- If no one wins, the auction is considered as failed and the lot is not sold.
- 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).
- 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
- 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.
D’Auctions
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:
- 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.
- Participant. Account which gives the contract rights to bid from her name acting together with aggregator
- 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.
- 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.
Deliverables
- 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
Rewards
Prize places
As per Procedural remarks on contests.
Selected calculation mode: DEFAULT.
Prizes
| 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.