I suggest to move “Notifications on events” to “Soft criteria”. If you make extension by google recommendation “persistent: false”, you can send events only over outside centralized server. For instance, extraTON will never do it.
Please, don’t be greedy.
I perfectly know the cost of development of such toolset that is asked within this contest, and it is worth 2 full-stack developers with salaries well under $3k.
The main prize in this contest is 35k TONs, which is $17.5k roughly, and the TON rate is growing now. Even if you pay your developers $3k each for two months, you get a $5.5k profit.
Next, if you compare this contest and DeX, the latter is at least five times harder, that’s why the main prize differs accordingly.
Last, but not least: I extremely simplified the contest to let the maximum number of participants step in, and there will be at least two or three contests for improvement coming, with their own prize fund.
So it’s up to you to participate in this contest or not 
Agree, that’s fair. I will move it to soft criteria.
That’s not about greedy.
I perfectly know the cost of development of such toolset that is asked within this contest, and it is worth 2 full-stack developers with salaries well under $3k.
I definitely sure that you are mistaken about knowledges of such toolset development.
Next, if you compare this contest and DeX, the latter is at least five times harder, that’s why the main prize differs accordingly.
Yes, i agree that DEX contest is harder. And due to that my calculations of rewards fund is one third that:
1st place………… 120 000 TON
2nd place………… 70 000 TON
3rd place………… 30 000 TON
4-5th place……… 10 000 TON
Total prize amount: 230 000 TON
And it’s not much more than your suggestion, but your stairs of rewards is very strange: 35, 30, 25, 20, 15, 5*5. It is conducive to just participate, but not to make best solution.
My point being that original proposal is well-ballanced as it offers a minimal features set which can be developed within a month. Such an approach lets community to see several open-source solutions on Stage #1.
The prize fund of 120k per 1st place can be slightly redcuced - I’m not sure why the point of ‘greed’ is raised. Having a good award encourages developers to offer best solutions possible, healthy competition. At least 2 community members showed interest in participating.
There are examples of contests with 1 submission - ain’t sure if it’s best practice.
The doc with all features should become stages #2-6 (or more, it’s a subject to be discussed) with 1 month per stage. With essential features as the core and extra features as a plus - to be within the market.
1 Like
After the discussion with the community, we have elaborated this updated version:
Contest dates
- Warm-up period: 3 days after approving this proposal in the governance interface;
- Submission period: 2 calendar months after the warm-up period;
- Judging period: 1 month after the submission period.
Abstract
Create a detailed, well-grounded, scalable, and secure Free TON extension for popular web browsers: Chrome (and Chromium-based browsers), Firefox, Brave, Edge.
Motivation
Many of us use mobile and desktop wallets to interact with Free TON. Surf, Crystal Wallet, Kilox, Extraton, Broxus, and many other applications make our life easier.
We aim to bring even more convenience to every common or business user of Free TON with web browser extensions with this contest.
If you ever worked with Ethereum, for sure, you know Metamask and how useful it is. Operate with tokens, submit transactions, interact with smart contracts, stake in depools, and many other things were made simple with this browser extension.
Now is the time to have such extensions in Free TON.
Stages
- Basic browser wallet
- Multisig wallet, tokens support, multiaccounts and multitransactions
- DePools support, Web3-like connection, smart-contracts interaction
General contest requirements
Your submission should include:
- The general technical architecture of the solution including all of the features listed below in the hard evaluation criteria section, along with the proposed customer journeys
- Detailed technical specification of the proposed implementation with the justification of the selected approach: smart contracts, integration layer, interfaces
- Name and contact information of the contestant for communication (Telegram username, e-mail)
Your work and the proposed solution must be:
- Original. It should not include more than 10% of other contestants’ works and citing from other works available on the Internet;
- Implementable. Keep in mind the peculiarities and goals of FreeTON;
- Consistent. Its elements should not contradict each other and the FreeTON Declaration of Decentralization;
- Safe. It must ensure a due level of funds security;
- Modern. Inspire by the leading market solutions like Metamask;
- Open-sourced. All the results of your efforts should be accessible in an open way, without password protection, and licensed under an open-source license, preferably Apache 2.0 or GPL 3.0. If your submission includes code, all dependencies source code should also be available openly.
Evaluation criteria and winning conditions
Hard criteria
- Generic
- English language of the interface;
- Support of Google Chrome;
- Absence of analytical trackers (Google Analytics, Yandex Metrika, etc.);
- Support of mainnet and testnet(s);
- On-chain activity history (transactions, messages, contract interactions, etc.);
- Any calls that require the user’s keys must ask for the password input to decrypt them from the local storage.
- Wallet features
- Native support of any open-sourced non-custodial Free TON wallets, e.g.:
- Original TON wallets (Wallet v. 3);
- TON Labs’ wallets (SafeMultisig, SetCodeMultisig);
- Random seed phrase generation;
- 12 or 24 words wallet initialization (based on wallet contract);
- Wallet seed phrase backup and restoration;
- Public and private keys generation, backup, and restoration;
- Encrypted local key storage;
- Password protection;
- Support of sending a memo with messages (or encoded payload).
- Native support of any open-sourced non-custodial Free TON wallets, e.g.:
Soft criteria
- Multilanguage support;
- The extension is published in the Chrome store;
- Support of additional browsers (Firefox, Brave, Edge, Safari, Opera);
- Browser notifications on events;
- Detailed and easily understandable charts explaining the architecture and business processes;
- Brevity;
- Mostly everyday English to facilitate understanding;
- Readiness to participate in the implementation of the solution in the next stage;
- Verifiable extension security along with the process to verify the equality of published version with source code.
Artifacts
- Technical paper in PDF format explaining the architecture in details along with detailed user scenarios;
- Source code for all modules published in any open repository like GitHub, GitLab, BitBucket, etc.
Licensing
- All works published under this contest enter the public domain immediately after the publication;
- The work should use any copyleft license (preferably Apache 2.0 or GNU GPL v. 3).
Procedural reminders to contestants
Keep in mind these simple principles to make sure your submission is well-formed:
- Accessibility. All submissions must be accessible for the Jury to open and view without a password, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, jurors have the right to reject the submission.
- Timing. Contestants must submit their work before the closing of the filing of applications. If not submitted on time, the submission will not count.
- Contact information. All submissions must contain the contestant’s contact information, preferably a Telegram username by which jurors can verify that the submission belongs to the individual who submitted it. If not, jurors have the right to reject your submission.
- Content. The content published in the forum and the provided PDF file should not differ, except for formatting. Otherwise, jurors have the right to reject the submission.
- Well-formed links. Suppose your submission has links to the work performed. In that case, the content of those links must have the contestant’s contact details, preferably a Telegram username, or backlink to your submission at the FreeTON forum, so jurors can match it and verify to whom the work belongs. If not, jurors have the right to reject your submission.
- Multiple submissions.
- Each contestant has the right to provide several submissions if they contain different approaches to the contest problem’s solving. However, if works are not unique enough or differ just in insignificant details, jurors have the right to reject such repeating submissions.
- If the contestant wants to make an additional submission that overrides the one previously published, he must inform the Jury about this fact and indicate the correct revision to assess. In this case, only the indicated work will count. If the contestant hasn’t indicated the updated submission as the correct one, only the first one will count, the Jury will reject all the others.
Fair play
It is not enough to win to enjoy the fruits of success. Triumph must be measured by absolute fair means, honesty and just play.
As a contestant, you agree to follow these simple rules to ensure fair play among contestants.
- Respect. Fair play requires unconditional respect for opponents, jurors, governance, and community members.
- Friendship. Rivalry in the contest does not exclude friendship. On the contrary, friendship could grow from noble rivalries.
- Solidarity. It is important to support each other and share feelings, aims and dreams. Mutual support brings mutual success on and off the field.
- Tolerance. The willingness to accept behavior or decisions you may not agree with develops your self-control. Ultimately, that could be the deciding factor when it comes to winning or losing.
- Plagiarism-free. Your work should be the product of your own mind and contain at least 90% of the original content. If some part of your work is taken from another source or submission, you must clearly cite the source.
- Public domain.
- The work you submit for the contest enters the public domain immediately after publication, even if it doesn’t win any prize places.
- If your work has been made partly or in full by someone else, it is your responsibility to get and publish the proper waivers from this person. If any juror discovers that the submission violates the original author’s rights, it gets immediately disqualified, even if other jurors have already assigned some points to the work.
- Free TON, its Subgovernances, or any of its members shall in no case be liable for any possible claims from the original content owner(s), public authorities, or any other person or body.
Procedural remarks for jurors
Jurors play an extremely important and vital role for the entire Free TON community. You and only you affect the quality and the perception of Free TON, in whole, and in parts.
This is a technology-intensive contest that requires a deep understanding of the contest subject from your side.
Voting process
As a juror, you agree to follow these simple rules at the moment of judging:
- Technology understanding. Jury members who vote in the contest must have a solid understanding of the technology. Those jurors who don’t should choose “Abstain.”
- Contest participation. Jurors whose team(s), relatives or friends intend to participate in the contest by providing submissions lose their right to vote in the contest and should choose “Abstain” for all works. They shall also clearly and publicly indicate this to other jurors.
Suppose anyone discovers that the juror violates this requirement. In that case, his scores will not be considered when calculating the resulting participants’ ranking, and he will not get rewarded for judging this contest.
- Feedback. Jurors shall provide valuable feedback on each submission justifying their decision.
- Quality filter. The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.
Submissions assessment
- Quorum.
- Assessing the submissions is considered legitimate if at least 50%+1 of jurors have cast their votes, be it “Accept”, “Reject” or “Abstain”, to the submission with the least number of votes.
For example, if a group consists of 16 jurors, then at least 9 of them must assess the submissions.
- However, if the number of jurors who have voted “Accept” or “Reject” (all together) will not exceed 3 (three), the contest submissions assessment is not considered legitimate and must be repeated from scratch.
I.e., one poorly voted submission may fail the whole contest, and you will need to re-vote again.
- Scale. A juror shall assess a submission on a scale of 1 to 10 (10 is the highest score, 1 is the lowest score) or vote to “abstain” or “reject”.
- The “Abstain” vote means that the juror is not qualified or eligible to assess the submission. Such a vote is not taken into account when a rating score is calculated.
Example. If a submission was assessed by 3 jurors as follows: “10”, “2” and “Abstain”, then the resulting score will be equal to (10 + 2) / 2 = 6.
- The “Reject” vote means that a submission does not meet at least one of the contest conditions and should be disqualified.
- If a juror considers a submission useless, although it formally meets contest requirements, he/she must notify its author and clearly state in feedback a reason for a low rating.
- Average score. The average score of the submission is calculated per the following formula: Sum(Score) / Sum(N_Accept + N_Reject), where:
- Score - the number of points assigned by a juror when casting the “Accept” vote
- N_Accept - the number of “Accept” votes
- N_Reject - the number of “Reject” votes
It means that “Reject” votes count as a zero score and lower the average score.
Example. A submission got the following votes: 5 (Accept), 3 (Accept), 4 (Accept), Reject, Reject. It means its average score will be (5 + 3 + 4)/(3 + 2)=2.4.
- Threshold. The submission shall be eligible for participation in contest ranking and competing for prizes only if it meets the following criteria:
- Soft majority acceptance. The total number of “Accept” votes exceeds the total number of “Reject” votes.
For the avoidance of doubts, in the case of an equal number of “Accept” and “Reject” votes, the submission is considered rejected.
- Hard threshold. The average score of the submission is at least 4 points.
Rewards
Prize fund
| Place | Prize, TON |
|---|---|
| 1 | 80,000 |
| 2 | 70,000 |
| 3 | 60,000 |
| 4-10 | 10,000 |
Prize payout and vesting
- Winners receive no more than 10,000 TON of their rewards after contest results are finalized;
- The remaining amount will be distributed within six months in equal parts monthly;
- The contestant should support the solution for six months to receive all vesting distributions:
- Major reported issues should be resolved within a reasonable timeframe - one month maximum.
Jury
This contest will be judged by a joint team of professional jurors from the DevEx and DeFi subgovernances as per the list below:
| Juror name | Public key | Wallet address |
|---|---|---|
| Vladimir Maslyakov | deb93a951c20140785ad7a9e7fa85fa6da5332cda85fbff6ef7784c805e963d3 | 0:7dd2b7e0067f4beda7505ff0b9e2ae524e64acbb886dcab68db8c02b8d6115e0 |
| Sergey Shashev | b0d4540c2d160266d9f3f487f571f591673fe1445ec6169086677f6d1cb23986 | 0:e2b874ee05cd7e5d1475d90bab04d26974e67fe7aef97d730c2adcba5ea895c3 |
| Nimrod Lehavi | 1f6ae87d306ec85695e456ee7faf825fde4beeac5646444343dd9bf118b50241 | 0:345309e3eee831dbfc361176f4ed439f8b8365df5f0e02c8882c3132b54dcd88 |
| Alexey Vorobiev | d856d4786b530491ef68a57b852a025c5c76b61d74c8b7c0a70f0ede2ab383fa | 0:1c8de9089ecddf6ccb34efa87f81381315f8a6f1b80c326ad3caf2ba752afabb |
| Vladimir Kanin | 86f8519e70ebf07bb0188dfe751a72c7ef526f9996541b1dc471177816cff326 | 0:deb918bd1621288605c0f8af4acb594dd0181e6680d65148a05fac9489b052be |
| Zurab Kazhiloti | ba9fe16ae2fc0a4579f3865c0a4bab0c3ac76f8a69e40c76c3ded5ce1f2747a8 | 0:0109697d325e6cfde8eba3c5df9b050a8d883ad6fe67c0286a77b5a5b9967b60 |
| Alexandr Vat | 2e47421b83dad034656341f00efd9bfcee545f26b98e0fb3dc291747746bddde | 0:418d17406d0b6cf306e2f2b7bcc55578fecde7a42804fcbe19966b5209b8b91e |
| Sergey Potekhin | 4ae8805d074de685094cd917a97cb6a93ba5b9c83a54defe2962cabcad59c156 | 0:2e10bf781ccf0b42036fc4f35732fc847f27f4e22f82cf0c76a77f58047433fc |
| Ignat Shapkin | d46cdc0a204a390cd2a01cee7078deb52d73ab313fee0ed69241209009465ef2 | 0:9ee55e89c3b48603d34d65f67e4c638863a1a3920b79dd662d7cd8c484f77445 |
| Andrew @ DefiAlert | 4492f389d8160d50ba2a58b349b69253ace196f34560ac01dc5827daae7eb530 | 0:f8603be35430ba13025d493504bc153f199185649c74f5ded84080dd07e5a829 |
| Andrey | 80c3447d22fc688a6e6da0114f7b81684852c0d029c24291bb7f700c56cb3c36 | 0:fb78684663132770da436010294cf05248da29cdc6dc69172b9975a083d499a6 |
| Mitja Goroshevskiy | 6ff322ad669dfad2f396b98bdc8690cc49926f6a10cd7f10d07f031841cf09ef | 0:583228a98701dea50703b10b797e7e43a270b6172f5223b10ca877b0adaed702 |
| Ilya Bugaev | 69058bb4ffef28284b538babf9da6a11558e87b48d79efce0f48c5ab38fffeff | 0:6f9591ee5a7d4531121c33fbde3a3132754f117fda9acfe2bcf1dc1255b7b2b6 |
| Ilya Podoynitsyn | 9833f9523c7966d60fc9e1cb0fe9fd4edb7539a10820456a9802274ddcdf03a9 | 0:2409a5faaa7af6e858074d2b0f9165987db8540fdc9d5809a2a93782bdfe0147 |
| Denis | 79c46c1272e796c129b09de892744fcb2e367ade180cb90da7e9812acfab06ee | 0:24485b1570b6d8fa29986e80770b51671a3373e4e4819349f2bb8205827e2709 |
| Alex | 0c216e3d93677a191272fccfd66a5cab714ffcfc56cc893003d7169add4700b2 | 0:1db4191855bd895a16ce6060d7fde134eb70e902f33d501cf3cd8be7c1833105 |
| Andrey Nedobylsky | fb2fe560bfbdda910798e1365d9419ff6e0a75ed5262410b714f162434a88af6 | 0:c1f2b2941fe3ed16960c484db49186363ed4bbb7c825a8128f46d787f973ff2b |
| Sergey Tyurin | 2c0ec55a109eb466d9db5ee7c3adb075e77627ade83ae17cea847671ab8f0a85 | 0:77772d4f5ecefb9e7ce02bca4a13cf81b65b4903ead16671e935850075fc6b4c |
| Peter Fedorov | 9e808b1540babb85c428b9197b8df87860882d2db70607dfa134774a0513db30 | 0:b6ed2e819e29ac08c95af2e4d4b8fd7ad6179329e1c9712067ccdcfd4247820b |
| Aleksandr Hramcov | 3bdb99452a6ed9138af385d035e0967250d0e2da6f58b90245f285daf250915c | 0:625e7dda96d7b916d8779b1a44af8aa1e16e5cf6d029151207b0e359327ec7b9 |
| Konstantin Konstantinov | 0f07a7cb924c7420520d0d98afad87d9b5e1765920fda698c22da6d0cd3354b9 | 0:5b833e39e1a1c4e971c7905fc5139e03831d5fc4746a4a3c8c799db1417b3279 |
| Boris Ivanovskiy | 1a99622e54b4e87d603dd87c9cc936b388b2a0e1979bb56d4039cfad0fbadc8c | 0:d2cd1ff399d441ca84c1585f634b60a16b65b46c27209fbd9cf928f97465bed2 |
| Pavel Khachatrian | d89e20f2e164f4e64a3637cc6926baf66482bf8c875e4e7eebedd6f28024998c | 0:32b2ab6941e3e08e98d1cb483f22bce8360643762405adf548d0fc785ae9879c |
| Paul Mikhailov | 7657b6b62ec6846e6341315ba3b8d611afe2ef79e8ee3214d45cc4ede3c50972 | 0:b68e4c06f8d547d12a08af03975e5130c2bd7dd1171fd0407a2875956ea7588d |
Jury rewards
An amount equal to 5% of the prize fund will be divided equitably between all jurors who vote “Accept” and/or “Reject” and provide feedback, based on their votes’ quantity and quality. Both voting and feedback are mandatory to collect this reward.
This percentage will be awarded on the following basis:
- The percentage of tokens awarded to the jury will be distributed based on the number of votes each juror casts. For example, if one juror votes 20 times and another juror votes 5 times, the juror who votes 20 times will get 4 times more tokens than the juror who votes 5 times.
- Detailed feedback is mandatory in order to collect any rewards.
7 Likes
Chrome extension is the past
what are the dates сontest?
developers community should have interactive discussion with user community to know user trends and expectations.
Could you please more explain this item?
Support of sending a memo with messages (or encoded payload).
It is a little bit ambiguous for me.
Does the meaning to allow send transaction with data or allow to use “memo” to send encrypted payload (keystore) by email (mailto way)?
A MultisigWallet contract can send a payload to another contract. Payload can contain the message we see in ton.live. It’s called a memo. The contract can also write information to the payload that will tell the other contract which method to call and with what parameters. You need to implement support for all this functionality.
Example of memo:
link
Very appreciate. I need to learn the math )) because in other blockchains this names “to send a transaction”
Wow, cool this is your extension. I will use it, thanks guys! I’m waiting for updates!
Hi Guys, should I send Contest proposal to this forum thread, or create a new one?
Hi. If you have a proposal for a contest, you should create a new post at first page of forum by using " + New Topic" button. If you want to submit into “Free TON wallet as a Chrome extension” contest, you can use “reply” to the main text of proposal here.
Got you, thanks a lot!
Created MegaTon - chrome extension wallet as part of Free TON wallet as a Chrome extension contest
https://github.com/ArsenMkrt/mega-ton
Waiting to be approved in chrome store. Planning to port as a mobile application as well.
You are welcome to use and comment.
Update: Uploaded into google store
Happy Using
Regards
4 Likes
Hey guys, submitted proposal, as a description.pdf attached architectural document, but I see others are just attaching contest description… hope this is not a problem?
Regards
I have a question about this item:
- Any calls that require the user’s keys must ask for the password input to decrypt them from the local storage.
Our team has realized web extension with the master password approach, that means the situation when keys stores in db in the encrypted view before the user will enter the master password to decrypt the wallet. But on each transaction this password is not demanded. Will this approach violate the item described above?
Just, Metamask doesn’t ask password for the confirmation on each transaction where user’s keys are demanded. They have realized the same approach - unlocking the keys for accounts by the one password.