Contest proposal: Free TON wallet as a Chrome extension

Governance contests Finished Contests
#30

I support this contest as well, we need more DApps now from perspective of API and SDK testing and improving.

3 Likes
#31

I love it, I will join to the contest

1 Like
#32

I think that timing for this contest should be 4 weeks at least.

#33

great, I agree with this proposal,
But I recommend:
Contract support: TON Surf contracts, safemultisig contracts, others as a plus.
Because safemultisig contracts are the default contracts given by the official deployment node, safemultisig contracts are needed in many places, so I strongly recommend supporting safemultisig contracts.

2 Likes
#35

Have experience in this matter, if necessary, I will tell you more. but the main message is that there is no need to focus on chrome, since chrome does not support extensions on mobile phones.
it is much more useful to target browsers that support mobile extensions. it can be Yandex, Brave or better your own Free Ton browser.

4 Likes
#36

After several discussions, we decided to split the contest into several stages.

The first stage will be for a simple wallet extension, whereas multisig options, depools, tokens, contracts interaction will come further.

As the first stage is the most time-consuming (besides pure development, there are configurations, CI/CD procedures, store publication, etc.), I left the period of 2 months.

Future stages will also take 2 months each, but may be splitted into smaller steps.

Updated proposal is available under the same link:

2 Likes
TIP-32 - TON provider javascript API
#37

Absolutely agree with you, but this is just the beginning.

Desktop extension is needed at first hand to support different dApps (including those developed by DeFi and DevEx subgovs).

1 Like
#38

It will come in the next stage.

1 Like
#39

Great idea. And then the winner or the contestant will be able to contact the w&d to improve the visual design.

2 Likes
#40

Everything okay except the one thing:
The Prize Fund
It’s ridiculous, it’s really ridiculous.
Just try to draw a parallel between this contest and contest “Dex Implementation Stage 1”. It’s 650k TON Crystals fund.

You offer 35k TON crystals for 1st place. I will just provide the figures:
For realize product with this set of features you need team with minimum 5 members: professional programmers, designer, lead with salary ≈3-5k$/month. Also you need order translations.
Also. I not so understand this requirement: “Verifiable extension security”. But i guess it’s security audit. For example, in Certik Shield it costs 10k$ per 1 iteration.
Totally net is around 35k$. It’s 70k TON crystals now. With potential downside of ton to 20c with current volatility plus the winning team should have some margin imho.

So if you multiply budget in proposal by 5 it will be fair.

#41

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.

#42

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 :man_shrugging:

#43

Agree, that’s fair. I will move it to soft criteria.

#44

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.

#45

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
#46

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

  1. Basic browser wallet
  2. Multisig wallet, tokens support, multiaccounts and multitransactions
  3. 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.:
    • 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).

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
Lending and borrowing on FreeTON - Essay contest
#47

Chrome extension is the past

#48

what are the dates сontest?

#49

It’s always worth checking actual dates at gov.freeton.org

image

#50

developers community should have interactive discussion with user community to know user trends and expectations.