Totally agree with you on that. IMO we should take it step by step. Lets run this contest and see whats happening. The proposal allows for additional contests. Also remember that we are only talking about initial set of validators at mainnet launch. The particular role of this set is decentralization, so lets try to optimize for this before we optimize for other things such as performance or say, geo coverage, services etc etc
2 Likes
Contest proposal updated, folks!
3 Likes
Если мы новый валидатор, мы можем участвовать в конкурсе или нужно было проходить квалификацию в тест нете?
Конкурс - это и есть квалификация в тест-нете. Участвуйте! Пока не началось 
If we are a new validator, can we participate in the competition or did we need to qualify in the test net?
Competition is qualification in a test net. Take part! Until it started
Leaderboard Score
The contest participants are ranked on the Leaderboard by their Score in (almost) real-time - data is updated every 10 minutes:
Score = Metric_1 * Metric_2
Metric 1: Uptime → Share of signed blocks (reciprocal to share of missed blocks)
Metric_1 = av_number_block_signatures / total_number_masterblocks
where
av_number_block_signatures = number_signed_blocks / av_nodes_per_round
Here number_of_signed_blocks = number of masterblocks signed by the validator with his node_id(s) during the contest period.
If the validator runs more than one node, number_of_signed_blocks is adjusted by av_nodes_per_round , which is calculated as total_number_nodes / current_round.
Here total_number_nodes = the number of validator keys participating in the elections during the contest and current_round is the current validation cycle number since the contest start (there are 9 rounds in the weekly contest).
Playground query for number_of_signed_blocks signed by a particular node_id:
query {
aggregateBlockSignatures(
filter: {
gen_utime: {gt: start_of_period le: end_of_period}
signatures: { any: {
node_id: {eq:"1f763281013ab430d52fb0e8239733cdd155c517d45dfae4e0b948580562580d"}
}}
}
)
}
Playground query for total_number_masterblocks = number of blocks issued in Masterchain during the contest period:
query {
aggregateBlocks(
filter: {
workchain_id: {eq: -1}
gen_utime: {ge: start_of_period le: end_of_period}
}
)
}
Metric 2: Staking efficiency
Metric_2 = max {1, total_amount_recovered / total_amount_staked}
where total_amount_staked = sum of stakes sent by the validator to the Elector contract from a particular wallet in the contest period.
Playground query for total_amount_staked with an example wallet:
query {
aggregateMessages(
filter: {
src: {eq:"-1:e118a08ddf394f29a1682e9a114764cb94c481647cb67efd52a573d897da149d"}
dst: {eq:"-1:3333333333333333333333333333333333333333333333333333333333333333"}
created_at: {ge: start_of_period - elections_start_before
lt: end_of_period - elections_start_before}
value: {ge: "100000000000"}
}
fields: [{field:"value" fn:SUM}]
)
}
total_amount_recovered - sum of amounts received by the validator from the Elector contract in the contest period.
Playground query for total_amount_recovered with and example wallet:
query {
aggregateMessages(
filter: {
src: {eq:"-1:3333333333333333333333333333333333333333333333333333333333333333"}
dst: {eq:"-1:e118a08ddf394f29a1682e9a114764cb94c481647cb67efd52a573d897da149d"}
created_at: {ge: start_of_period + validators_elected_for + stake_held_for
lt: end_of_period + validators_elected_for}
value: {ge: "100000000000"}
}
fields: [{field:"value" fn:SUM}]
)
}
2 Likes
Здравствуйте, -" не проиграть выборы, использовать всю отправленную ставку и т. Д. Все это максимизирует относительное вознаграждение." подскажите пожалуйста, где можно почитать про инструменты регулирования этих моментов??
и что может быть не так, если в валидаторы выбран, а подписанных блоков нет?
Про неподписанные блоки советую посмотреть запись сегодняшнего звонка: https://youtu.be/KiGMFinVQfk
Какие правила проведения выборов можно почитать здесь: https://documentcloud.adobe.com/link/review?uri=urn:aaid:scds:US:65e168aa-d73b-4a57-a5e3-94b77c170563
Все доступные материалы пока к сожалению не английском.
3 Likes
The Crystal Game Winners - How Ratings Points Work
For each participant in GameX:
- Week 1 → w1_points = divide score by w1_max_score and multiply by 10,
- Week 2 → w2_points = divide score by w2_max_score and multiply by 20,
- Week 3 → w3_points = divide score by w3_max_score and multiply by 30,
- Week 4 → w4_points = divide score by w4_max_score and multiply by 40,
where wN_max_score - is the top score in week N of GameX.
total_rating_points = w1_points + w2_points + w3_points + w4_points
For all participants in GameX:
average_rating_points = mean(total_rating_points > 1),
min_rating_threshold = average_rating_points * 0.35,
where average rating points are calculated over all GameX participants with total_rating_points > 1 to exclude starting nodes from the average results.
Magister Ludi Title in GameX:
if now < w4_end and total_rating_points < min_rating_threshold:
print("Try harder")
if now < w4_end and total_rating_points >= min_rating_threshold:
print("Waiting for you")
if now >= w4_end and total_rating_points >= min_rating_threshold:
print("KYC required")
else:
print("Not granted")
where now is the current unix timestamp and w4_end is the unix timestamp in the rightmost column of the GameX timetable.
Up to 300 winners who achieve the minimal rating threshold (TBD) will be selected out of all those who participate in the KYC procedure.
1 Like
Announcement
A player named Quirky Napier (-1:bc9) has been fined in week 2 of Game 2 by removing the last recovered message from the results. Consciously or accidentally, this player did not perform a separate return of stakes and rewards falling in different weeks, which led to an overstatement of metric 2 in the second week. This deprived the organizers of the opportunity to remove excess returns from week 2 without affecting the returns attributed to week 2 itself. For participants in the Crystal Games, please provide a separate return of stakes and rewards related to different weeks.
4 Likes
I have a proposal about “missed cycles” and its impact on final Rating Points.
Motivation
Let’s assume validator has stable uptime about 0.97 of signed blocks and he/she missed one validation cycle. Now it will lead to a huge impact for final rating points. If validator node will continue to hold 0.97 uptime, week result can be no more than 0.862 which is a deep down of rating table.
Giving an example of missed cycle impact based on game1 and game2 week 3 rating table:
g1:
0.97 - top20
0.862 - top85
0.754 - top95
g2:
0.97 - top22
0.862 - top87
0.754 - top89
I took networks 1 and 2 because of their uptime stats similarity.
Most of us are beginners and we are learning how to work with TON technology during the game. Sometimes we are making mistakes and sometimes it leads to inability to continue validating on next cycle. I’m sure that penalty of kicking such validators to deep down of rating table is too severe.
For example some of us missed validating cycle because of misunderstanding how it works. Specifically some of validators faced an issue then they didn’t had enough tokens to return stake (value in contract + fees) and had to request additional tokens from devs, because there is no other way to receive them. The request was fulfilled but much later then elections closed, so the cycle was missed. Because of that such validator will become TOP-80 with no chance to go back up somehow, because restoration of 3-4 out of 100 Rating Points is nearly impossible.
Nevertheless some penalty should have a place.
Proposal
In case if validator missed the whole cycle (has 0 signed blocks in one cycle) “virtual uptime” should be applied at the rate of minimum non-zero uptime between all validators in this cycle minus 0.00001.
In this case affected validators remains the worst in this cycle, which is quite fair. Penalty becomes huge but not fatal to give up competition.
2 Likes
Yes, most of us are beginners and we’re learning how to work with TON so you could consider this as a lesson you paid for. I also missed a whole cycle and I don’t blame anyone but myself.
In the main blockchain if you don’t stake for the next circle for any reason you will miss it. The same is here. I think this is fair.
A draft version of the updated Crystal Game rules for discussion:
There is truth, my boy. But the doctrine you desire, absolute, perfect dogma that alone provides wisdom, does not exist. Nor should you long for a perfect doctrine, my friend. Rather, you should long for the perfection of yourself.
— Hermann Hesse
Short description :
The Crystal Game will ask validators to compete in validation cycles recurrently in order to win the title of Magister Ludi. The participants of the Crystal Game are allocated randomly to 4 games with maximum of 100 nodes per game. Winners for each of the GameX are determined based on the total score for 4 weeks with different weights for each week depending on the transaction load.
Prizes: Prizes will be sent from Givers on Free TON to a DePool contract to each winner in amounts ranging from 375,000 TONs to 750,000 TONs (Subsidy) depending on the winner’s rating, which will be returned over a period of 1 to 2 years. Additionally, winners will receive a direct reward of 120,000 to 240,000 TONs vested over a 12-month period, also depending on the winner’s rating.
For the security reasons the distribution of prizes will be made in two phases:
Phase 1 - DePools will be deployed only with lock stake for a period of 1 to 2 months and part of the vesting stake may be directly distributed to the multisig wallets of the winners;
Phase 2 - a new DePool contract will be deployed for the rest of the locked and vesting period.
Type: 4 week cyclical contest
Starting Date : June 22, 2020 as per tables
Game0
Game1
Game2
Game3
Motivation :
To choose the best validators for Free TON
To provide additional long-term incentives for validation
To subsidize capital required to run high performance validators
To provide continuous motivation for supporting DePools as the main tool for decentralization
To disconnect the “staking” layer from the “validation” layer as much as possible
General requirements: Run at least one validator node.
Proposed reward: The total subsidized amount will peak at 300,000,000 Tons (6% of total supply). This amount may be increased in the future.
The reward of each winner in GameX is determined by the following formulas:
individual_coeff = (rating - min_rating)/(max_rating - min_rating)
375,000 * (1 + individual_coeff) - for Subsidies,
120,000 * (1 + individual_coeff) - for Direct rewards with vesting,
where min_rating and max_rating are the minimum and maximum rating points of the winners in GameX.
KYV: Any one team can earn a reward just once. No US residents can get a reward. Before reward distribution a moderate KYV procedure will be performed.
Rules:
List of all validators on the network will be obtained automatically. Each validator will be assigned a random, quirky pseudonym, but can change that name via a transaction to a special smart contract.
List is updated when a new wallet address is used to send messages to the Elector contract.
Note that if you are going to participate with several nodes under the same validator name, the average metric across all your nodes will be counted.
Contest participants are ranked by their score in real-time, and the data is available on the Leaderboard at the gameX.ton.live site.
The Magister Ludi title will be issued after the contests end, beginning with top rated winners.
Game rules may change at any time. Game conditions can be amended to any cycle by virtue of community voting; respectively, so may reward amounts increase.
Week 1 (9 validation cycles)
Contest Network : gameX.ton.dev
Contest Mode : normal validation
Contest Metrics :
- Metric 1: Uptime → Share of blocks signed by a validator (average if several nodes)
- Metric 2: Staking efficiency → max {1; Total amount recovered/ total amount staked)
- Score: 1 x 2
Rating points : 1-10
Week 2 (9 validation cycles)
Contest Network : gameX.ton.dev
Contest Mode : network load
Contest Metrics :
- Metric 1: Uptime → Share of blocks signed by a validator (average if several nodes)
- Metric 2: Staking efficiency → max {1; Total amount recovered/ total amount staked)
- Score: 1 x 2
Rating points : 1-20
Week 3 (9 validation cycles)
Contest Network : gameX.ton.dev
Contest Mode : network high load
Contest Metrics :
- Metric 1: Uptime → Share of blocks signed by a validator (average if several nodes)
- Metric 2: Staking efficiency → max {1; Total amount recovered/ total amount staked)
- Score: 1 x 2
Rating points : 1-30
Week 4 (9 validation cycles)
Contest Network : gameX.ton.dev
Contest Mode : network overload
Contest Metrics:
- Metric 1: Uptime → Share of blocks signed by a validator (average if several nodes)
- Metric 2: Staking efficiency → max {1; Total amount recovered/ total amount staked)
- Score: 1 x 2
Rating points : 1-40
Winner selection:
The winners who achieve the minimal rating threshold (MRT) and pass the KYV procedure will be selected out of all those who participate in the Crystal Games.
MRT should be calculated as 35% of the average rating for all participants in GameX with total rating points > 1 to exclude technical nodes that are out of the contest. MRT is not recalculated after the KYV procedure.
Any participant in GameX with a rating equal or more than MRT can participate in the KYV procedure.
Additional rewards:
- The Master of Update title was earned by Game0 participants for successful and timely update of their nodes on 4th July - 1000 TONs for each of the 92 participants on the Week2 Leaderboard;
- Special bonus goes to a validator with multisig wallet -1:70bb8659d72a5d11d935368c0f5ab902a151a7d2b9c37977ca3cca63b14a91e7, who answered the Quiz and found “oddities” in Game3 - 5000 TONs;
Game0 Week2 Leaderboard:
| # | nickname | accountId |
|---|---|---|
| 1 | Affectionate Banach | -1:974d7e4935d6ea97be3587e5b7ab9476c0b0d39da644de8fe019eea777c73fcc |
| 2 | Admiring Franklin | -1:44c41789a4ada6b03212eaaefafb0ed19cf6d27fabdd580dcd28097a8924e2d5 |
| 3 | Youthful Satoshi | -1:e1b14b42f0b4902b9ee2de6e781755ebc12bb31f050f1b662ce9886e3f39cbe6 |
| 4 | Festive Darwin | -1:7dc7920fc7a475b31d696da9b6a4aaf0e58f0206ef05e21dee880dc72a8b7360 |
| 5 | Stanislav | -1:bf84f197bc2d1584e5f31161bd0e2d1a5b55f529f5a757c5d62acea0a0724e78 |
| 6 | TonyWar | -1:3e2396c43da56628716bfb873f21738a383d97d222c3285b3ca24fce3aa93860 |
| 7 | Brave Mccarthy | -1:94fd53af612568e92071a1295da7bf1612db50bf1fbfd44f8bf73f78dbe92de0 |
| 8 | Laughing Vaughan | -1:225194877c0d16b2780a5d7df46ad5ef1af4b29614eda5dc5bd88d3be9d46c7e |
| 9 | Youthful Grothendieck | -1:e4d84176b94f00c09da7707bf469bd8d6bfb23a85348fd1bf4b8a833247d092c |
| 10 | Affectionate Varahamihira | -1:aa267f1acbc4258e2b098c4efe5a8225df0630fb2c93080dad8a6272521eac38 |
| 11 | Admiring Ritchie | -1:61de96fd3796674103210d92f26de76e4ef5de1878eafc9b5d5f13f3a92bbe58 |
| 12 | Ecstatic Blackburn | -1:8ddf0cd307c38e1d1a67d8a4b55ed1e3f5353d4998b6159017b51466329f682c |
| 13 | Genesis Lab | -1:8702c47e4c4d09e31633453071c975c6e51685cafa3df373acd028719794b334 |
| 14 | Zealous Tesla | -1:cd91cb26d3f5f6e2b80453d6956c199a81b04d4d18ac506aaab6c79171d98a14 |
| 15 | Cool Williams | -1:beec31d4c70f64d06b7a8c5eea6436195d0e28b402408f6a3c4f1a71057d9528 |
| 16 | Sleepy Bassi | -1:4859ee922f8bd79834205f4d6f274496c11ec597e0741abc58185f995e7e60c4 |
| 17 | Determined Ride | -1:2033d87c99684d1f49d453c3938c51073cd74da5ccc8580612b8a949dc5820cc |
| 18 | Strange Burnell | -1:0d957353482494a4469f736deead1c182684ab6cf506051447d8fd7547cbd0ec |
| 19 | Keen Spence | -1:827f1f2fd76f4d5d6acaeff4be9da806a80e565eaf5922c04f328ab22574405c |
| 20 | Clever Bose | -1:06b5f49fc646202c2b3166ee7522e671059d449d5de7944cfd90e19c822dcb44 |
| 21 | Silly Maxwell | -1:8e15cf6153cca32e9b4dbded29d2f3bb2ad1c782971cef42969d55b33b5bd170 |
| 22 | Busy Yonath | -1:597a3b7c543155ce0c2875e3745f2e1600b817e0ba5431b14f9ee2edfb53e72c |
| 23 | Intelligent Hawking | -1:ea484fdadb0faeae3d03633e95407b417a08cbfc27c7171382c0ddebbad09838 |
| 24 | Frosty Wing | -1:544539890c94650b03117336fc09a8024a5ed6798229e3492d97a4f5e51452f8 |
| 25 | Mystifying Turing | -1:77c9a774558a8fc82324ad7dc30419646513c74faf0d22b65a8b33273dde3118 |
| 26 | Stoic Moore | -1:9064edb5cc728e1cbc89913ada8280911eb4745d159f0f8bec5703d48744c300 |
| 27 | Vibrant Wilson | -1:8ca0d9e265a207c0fa4a513f0c6b91e93359af7eae8156fad1d51c9b080ca3c4 |
| 28 | Vigilant Yalow | -1:3a6a285afbbb8eacc0fdd1ad2e20f169597305b0e7f976b2c0f1635b1c51cca8 |
| 29 | Mystifying Blackburn | -1:cd02f49122476b0445e0cd6e496f7ca50e6f1d8ef83aa48a27104108cb472a94 |
| 30 | Admiring Khayyam | -1:067069e384f6e873fd68c1bc48305d8de2bf882a66b2ab03e94e71d68590a09c |
| 31 | Wizardly Yonath | -1:1b0fc62910b116beab2664c4b4f32ba40f978ff6c90cba98c1c1a2419bfbdb88 |
| 32 | Vibrant Brown | -1:c6e93298250f23f472d8dbe81dc4732866fb8e4e56ed10bbb33a6b2d42f80e34 |
| 33 | Upbeat Chatelet | -1:3dc86729000e2ee6301c95ce09f602aa0819f0c0e7a48b23b552c60ed8a598ee |
| 34 | Epic Bardeen | -1:7ad08712faf7501e0bb717e314a071008342840c137f570e778a6cca0d9c7988 |
| 35 | Busy Dirac | -1:9e8e00e5859256719767386cc8d1ec003f8a4b90363b2950fd735502314673f4 |
| 36 | Tender Knuth | -1:e7dc1a2619d4344db99eb12755be76fa441b50441e30340a711741625c82d65c |
| 37 | Modest Grothendieck | -1:0c0a4a3cdc46042a44aee9931d8188b137db96f750902916a0d300fa18589290 |
| 38 | Vibrant Sanderson | -1:cf5b733bf72717d0c3a44c327688a9e7e0521681a1dc8046963f4fd7c527cf58 |
| 39 | Vigilant Wright | -1:68e5aa5c95a23451e1fe86d96e73add4d294564f0fbe43a8508bb2c8a3c4cf50 |
| 40 | Amazing Ritchie | -1:b0dc969a1d08363d5988ee52024a65137fe31fc2d0f3a6daf157622363f38200 |
| 41 | Zealous Almeida | -1:f22bf29e5f6f323aa0a119ac8c4feeebe4c8fd3c0237addeb2e0b0e16fcc9fa4 |
| 42 | Epic Aryabhata | -1:01165f6ef94dbf4e9fb6d8c2d458b05197d7b26f3839f2755121d271b6f6d308 |
| 43 | Admiring Hertz | -1:c63f34804cfd09287e4ca5506acb71265039fe3f1b92e97868577be15afc6924 |
| 44 | Festive Swanson | -1:9ffa05660344665577fd8c9c0062d23503964297a748018057389a9c05676a00 |
| 45 | Competent Hugle | -1:8fc843155efdfd2bfb7ba708e946e06b78df07fb55032ffe08e5890057091204 |
| 46 | Intelligent Brahmagupta | -1:f80fa14a6e05d5fe95c6e198a6cf22a3219d16cd99fcd936aa8c8849d53f03ac |
| 47 | Beautiful Robinson | -1:19be5302df1c4da243e64cd69ec63d569268c05bfecc33e4b82dc487d3147d74 |
| 48 | Adoring Blackburn | -1:0a0cfdd8961d0252cd543c928b532bd7238c4cc882ec94cc3f770edbe6b40e9c |
| 49 | Vibrant Germain | -1:977c3c1586ee2db87e15cf1f1605647c8eb4ced3b0c8fba32d1674733d198204 |
| 50 | Wonderful Volhard | -1:7dd7d5f8eec35950165b92d26bd2b7f5565d263e586d9f4ca55af5caf6b89090 |
| 51 | Wizardly Mccarthy | -1:06b0c378b02da5cbdca4164e37dbda4f1ec860e1f061c666085218b40f3f9e48 |
| 52 | Adoring Newton | -1:37106bcd2dab5f024c79f3d301229f529eae0572ea6aef88370f01b547b0de44 |
| 53 | Eager Hellman | -1:0fd949ad148da5677572a77c17c41a5ba9b2bafd7ffacdf35654382c2557c5a4 |
| 54 | Frosty Cori | -1:b65dd9d6f47fc0437f4e2aea1335e07a30ea7d8ad0052dce4646fcb7d29cb838 |
| 55 | Blissful Northcutt | -1:94f037dbc7622bb3834849d045f95d5e7d8044ac293e8e3eaee40620c1e40570 |
| 56 | Beautiful Tu | -1:d3ffdc4f2127f670b1e3717b934ce4e0f1ca5251dd3d66d8df513406e6e3c480 |
| 57 | Cool Yalow | -1:2e81eb9b67269e6b2abc184f07d923f8936a092cf9b4773e6452088a07ef4ccc |
| 58 | Suspicious Jepsen | -1:0569fc49ba17715583f9e0d8877baa394286b23d117dc3e89b8eaddde52e809c |
| 59 | Admiring Hypatia | -1:f1e7e86f0c22d9a45c7410af29a1a17c8c932f88e25b1ccef61afb2fd4ed4c04 |
| 60 | Focused Bardeen | -1:992723779a35cf2cdb563e6f48ee45c6198b6dd5b3ca8e269d094f7b036bc5e0 |
| 61 | Wonderful Turing | -1:8d9f03848127ac2964f503ef4830423fe11b3fc52670085d026afdf48db46e08 |
| 62 | Admiring Chandrasekhar | -1:8d6359fbc0651d3d96e05194fc4e30f431dc08064c0334d706dd7d14563b7f28 |
| 63 | Suspicious Carson | -1:53e090e6ed8a837a8f901d4fd9b722eac36cec5b8f6180d3ff03c6756fa709b0 |
| 64 | Crazy Noyce | -1:21ecda2379da32bad19898ce81a5f2af4d68b5c8dee434ff8da5d330be749238 |
| 65 | Romantic Driscoll | -1:bbde213ca9f7329faaba2f53119535246536323a24aaf58d4d9aa19013840758 |
| 66 | Recursing Mendeleev | -1:17d80e55ad02b6a4eb641100e319f5b7df3ab74e900c2a0c8922bf6edcd5a410 |
| 67 | Upbeat Almeida | -1:d58668c67211a2a137547b2e5c0239cdf20fe38333e306fbca67280d76405958 |
| 68 | Lucid Euler | -1:e301b3286ca99a6bfeecbf0f4d5ad11adbdb561ac94fc9144544537cf00b4af0 |
| 69 | Kind Jang | -1:f6bb8a3468f7ccbc4ad4b1ed1958f54df0cead05c8908aa4e9cc27174738c9f8 |
| 70 | Sleepy Williams | -1:a4b0691925184b2d7db41e795541a3f1372714d3200f4c5c91ce92a00f5a2bd0 |
| 71 | Youthful Hodgkin | -1:d8877afb9e1c6f4261b0ac09097fad1d6e45962f9db97a310660bf9446d51d20 |
| 72 | Vigorous Dirac | -1:acf4141689c461950ea395094a86d1d5822dc30941fa63a4db2115cedddb73ac |
| 73 | Naughty Bell | -1:12f677ee6545624e6c84d5d9212c1018c39caf4dd159e26c8c980900d7b13ec8 |
| 74 | Wizardly Chatelet | -1:1accaf51a7bb608335566be9bdba29987006272ca3a044bb279a95d578ede3f0 |
| 75 | Boring Mclaren | -1:2e65cde53ce75217879ce1a1bfa2f36b8611e583f8adef303b28a3e7b425fba8 |
| 76 | Optimistic Kapitsa | -1:330490214c4e2a3c0b3f4e79e3f247a3537312890faeff8527aa3c412102a1cc |
| 77 | Awesome Albattani | -1:2edee06850d286d349d3fab3b2f838bdbc5561fbfc2d6e7b729bfd9bac1327b0 |
| 78 | Epic Blackburn | -1:e4d7f730dea1f210937f208192aca7bc132735b07147fe41746b628b4a9c9e68 |
| 79 | Laughing Black | -1:1bc51ff005a328f84cfcd36a34dc3ae61b96605b40ba30008934f27b4ebe9454 |
| 80 | Zealous Montalcini | -1:85f48a5142d5e28c80c8a0c8fe6234dcc0eb5999f58d5f5deeb354527c7d8a54 |
| 81 | Affectionate Yalow | -1:b215c854e4bc39d9507e250cd23b96b8bd0aa7766c8c861656d5306504421ef8 |
| 82 | Optimistic Yonath | -1:ef6b60ad175ea2099c4b9b3116949f45621fba0af26d444508baedb394afef74 |
| 83 | Interesting Williams | -1:e89640198eddcc654dcf3b15123bcf16f5af17f39ee7638a72bdbdfe8557f384 |
| 84 | Condescending Ishizaka | -1:4bcb93a21b9e043dc8434d0e5dfc6c8c446953773d8282ced0629a1bad52d480 |
| 85 | Cool Bouman | -1:908a87b267848f70aed207e9f342b28fed1841c9c56503642a7e5ac3a35dea60 |
| 86 | Jolly Villani | -1:6897059fb69b612ed721b8201d9420cfc02a2e8c926468fe521e547efc17e088 |
| 87 | Blissful Einstein | -1:4d596d7df7d74f8fd95a9f7e7dcc0ec4a2baf69e6993d1b819ba361c64c5e3c0 |
| 88 | Crazy Yalow | -1:86bb0e9bcd5db353019ed039dade0a1cfbf25e699f09936e9ef9f035907aa917 |
| 89 | Pensive Lamport | -1:a61784e6b56866c84ec156de9be5228259235f1a61e5e40f96f4a6a7d1f002d3 |
| 90 | Flamboyant Lewin | -1:64b9890a1e1cb306e53cf9d8461fafda92111ed8944233611a451d7ad0063214 |
| 91 | Elegant Blackwell | -1:113774c73d1c34c685f68a7db8e2451f4a6024862438c3aa4248242566f9f515 |
| 92 | Nostalgic Darwin | -1:f5e0b9acdc27aedc7d569ee539ef04aa532bf92352a7eeb8a5b37fb312323224 |
Disclaimer:
Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.
Subsidy stakes will not be eligible for voting.
3 Likes
@szaitseff Thanks for the update.
I wonder how is possible to change the “Winner selection” without letting the community know and discuss first?
It actually means you can change anything…then why setting the rules in the first place? I know “rules may be changed” but why don’t you communicate with the validator’s community to discuss before updating it?
If the proposer can change anything at anytime, why setting those rules?
1 Like
There are no “changes”. Just the clarification of exact reward rules (which was supposed to be clarified) and just compiling the changes that was stated previously (i.e. exact final contest weeks’ beginning and ending dates) 
The purpose of this update is exactly to let the community know and discuss the updated Crystal Game rules and approaches. As you know, we have de facto 4 games instead of one game as per original proposal, and some other statements need clarification. To enable organizers to distribute rewards and other prizes to the participants of 4 games, we need to vote for updated rules that are drafted here for discussion. Therefore, your feedback is appreciated.
How KYC will be processed? TON will reach participants or need to fill some forms?
I just wanted to remind the team that it was stated that the issue that happened in first election of week 1 in game 2 would be corrected somehow. This was originally discussed in meetup #8 (link goes to exact time it was discussed):
https://youtu.be/E0BRqs-tJ1s?t=779
It was also discussed in meetup #15 (link goes to exact time it was discussed):
https://youtu.be/mMu8mM8VnuE?t=3156
I don’t think the actual method that would be used was stated, but there were several statements made that something would be done to correct it. Thank you.
3 Likes
An average number of block signature per cycle has been added to uptime on the Leaderboard for such participants.
2 Likes