Contest Proposal: Bindings for TON Client Library
Implement TON Client library bindings for any language of participant’s choice.
September 21st, 2020, the beginning of day UTC - October 7th, 2020, the end of day UTC
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.
- 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
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 or
Considering the following criteria set, the submission score decrease:
- Not implemented SDK methods
- Binding mistakes causing SDK errors
- Incomplete test coverage or tests inexistence
- No instructions for running tests/examples
- Bad code readability
- Core Implementation inconsistency
JS and Rust bindings are allowed, but WASM bindings we don’t expect
Don’t implement core logic. You should use the Core SDK dynamic library (v1.0.0) to create your bindings.
- Strong technical background is a must.
- There should not be less than 5 jurors
The reward for TOP-3 among all participants:
The reward for TOP-3 among participants of given language:
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
- 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.
- 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.
Anyone can participate, but Free TON cannot distribute tokens to US citizens or US entities.