Contest Proposal: Bindings for TON Client Library
Short description
Implement TON Client library bindings for any language of participant’s choice.
Dates
October Xth, 2020, the beginning of day UTC - November Yth, 2020, the end of day UTC
Motivation
TON adoption depends on the ecosystem of DApps, which doesn’t exist yet. We need to provide a set of libraries, tools, and materials for developers to build TON Dapps on any language, platform, and architecture.
The contest is focused on the TON-SDK (especially TON Client) library bindings for different languages, which is the foundation for developers to build DApps.
We expect each participant of the contest to get a deeper understanding of SDK internals and technical concepts behind TON.
Task
- Create TON Client library bindings for your language of choice. These bindings should provide an API for all SDK Library methods
- Write either unit tests or example code which illustrate the usage of the interface you’ve implemented
Submission format and requirements
- Work should be submitted to the GitHub repository. The participant may use any GitHub account he/she wants to publish the repository
- To make the evaluation process faster, include a README file with instructions to install dependencies (if any) and compile/run tests/examples
- Submissions with failing builds/tests/samples will be rejected
- Submission should use v1.0.0 Core SDK release
Evaluation criteria
Considering the following criteria set, the submission score increase:
-
API coverage completeness
-
Test coverage completeness:
- amount of methods covered
- “negative” tests
- async request tested
- tests on method execution correctness when called from one/different client contexts
-
Internal SDK errors are handled using error handling approaches. Error codes and messages are consistent with SDK errors.
-
It is possible to solve the following routines using participants’ submission code:
- keypair derivation from TON Surf mnemonic
- contract deployment
- message / transaction sending
- fee estimation
- graphql queries execution
-
Asynchronous API (request with callback) binding implementation
-
Available via the appropriate package manager (e. g.
pipfor python ornpmfor js)
Considering the following criteria set, the submission score decrease:
- Not implemented SDK methods
- Binding mistakes causing SDK errors
- Memleaks
- Incomplete test coverage or tests inexistence
- No instructions for running tests/examples
- Bad code readability
- Core Implementation inconsistency
Notes
Don’t implement core logic. You should use the Core SDK dynamic library (v1.0.0) to create your bindings.
The Jury
- Strong technical background is a must.
- There should not be less than 5 jurors
Contest Rewards
The reward for TOP-3 among all participants:
-
100’000 -
75’000
-
50’000
The reward for TOP-3 among participants of given language:
-
50’000
-
25’000
-
10’000
30% of this amount will be paid as a contest reward immediately after voting ends.
Another 70% of this amount will be vested over a 12-month period with the monthly distribution.
Prize Evaluation Example
Python binding submission took 2nd place among all participants and his solution is the best among all Python submissions. It will receive 75’000 + 50’000 = 125’000
Reward Distribution
- Winners receive 30% of their rewards when contest results are evaluated.
- Another 70% will be vested over a 12-month period with the monthly payouts.
- To receive all 12 distributions, the solution should be supported for 1 year
- The binding should be updated (in a reasonable timeframe) according to the main library changes
- Major GitHub Issues should resolve within a reasonable timeframe
- The first vesting payout is paid one month after the end of the contest
- The first vesting payout 100
- Payouts increase exponentially over a month
Exponential Vesting Distribution
As an incentive to support the winning solution during the whole vesting period, payouts increase exponentially each month.
Use this to play with parameters
Voting: 1-10 / reject / abstain
- Each of the initial Free TON jurors can vote on your submission. Jurors whose team(s) intend to participate in this contest by providing submissions lose their right to vote in this contest.
- Each juror will vote by rating each submission on a scale of 0 to 10 or can choose to reject it if it does not meet requirements, or they can choose to abstain from voting if they feel unqualified to judge.
- Jurors will provide feedback on your submissions.
- Duplicate, sub-par, incomplete or inappropriate submissions will be rejected.
Jury Rewards: 5%
An amount equal to 5% of the sum total of all total tokens actually awarded to winners of this contest will be divided equally between all jurors who vote and provide feedback. Both voting and feedback are mandatory in order to collect this reward.
Procedural requirements
- All submissions must be accessible for the jury to open and view, so please double-check your submission. If the submission is inaccessible or does not fit the criteria described, the submission may be rejected by jurors.
- Contestants must submit their work before the closing of the filing of submissions. If not submitted on time, the submission will not count.
Disclaimer
Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.
100’000