FreeTON Decentralized Account Management Stage 0 Proposal

Hi folks,

Here you can find an early draft for decentralized account management stage 0 proposal, your comments, crytics and suggestions are more then welcome:

Contest dates

  • Warm-up period: 15-24 January 2021
  • Submission period: 25-31 January 2021

Short description

Prepare a detailed whitepaper for the proposed Free TON account management architecture that will allow the fast and easy integration with various entities dealing with accounts: trading venues, wallets of any kind, payment systems, billing systems.

It’s a real pain to deal with Free TON accounts at the moment. To be honest - is a headache. It’s also hard to integrate one more blockchain to every crypto exchange or either to vote for smthg if you are not familiar with the command line. It’s not one more ERC20 to be honest.

And it’s just the start of mass adoption - time to provide a lot of help to ones who do contribute by integrating Free TON - standard elegant APIs for the node, unified account management allowing to vote from each wallet. Nothing will work without pretty cool stable interfaces and ones who adopt will be glad to avoid drama and just simply do their job without doubts.


Account management is a critical part for the adoption of the DeFi ecosystem. Easing the step of integration and providing a user experience of unified account management for each part of Free Ton ecosystem is the mission to be completed as soon as possible to grow the number of adoptions.

It’s a crazy long period of time to list crystals on crypto exchange just because there is no API and there are plenty of addresses and shards are not helping to make it easier. It will become worse in case of liquidity pools where one will need to check all payment and account status changes almost online and users will need to see all changes in UI.

And if one from traditional finance (banking or centralized payment systems) will need to integrate - it can be a complete nightmare with current geeky code without wraps and intermediary layers. Just ask any crypto wallet - are they able to integrate Free TON fast and curious about the kindness of current technology.

One more in list of hard needs is the idea of servicing accounts by multiple tools from an ecosystem like one can order the debit virtual card in one service, hardware wallet on another service and simultaneously wants to fill the balance in his lovely content provider account from the same account (and it’s subaccounts). Even though - it can be a basement for the next stage of decentralized governance with the landing of an account to the exact tax system chosen by the user.

General requirements

Your submission should include:

  • The set of account management interfaces to be used by entities dealing with accounts - what will be integrated with what?
  • The general technical architecture of the solution along with the proposed user experiences
  • Detailed technical specification of the proposed implementation with the justification of the selected approach: interfaces principles, interfaces description, default entity app mockups.
  • Basic list of technologies and services to be applied if applicable (self sovereign identity, KYC/AML services of any kind to be used etc)
  • Sequence of R&D with phases to be done after
  • 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;
  • Implementable. Keep in mind the peculiarities and goals of Free TON;
  • Consistent. Its elements should not contradict each other and the Free TON Declaration of Decentralization;
  • Safe. It must ensure a due level of funds security;
  • Modern. Inspire by the leading market solutions.

Evaluation criteria and winning conditions

Hard criteria

  • Free TON API sets for trading venues/wallets/billing
  • Full set of architecture documentation for proposed solution (any kind of UML diagram applicable as well as other modelling standards);
  • At least one review of architecture from potential users from the list (trading venues/wallets/billing);
  • At least one mockup of default app to show the concept working
  • Technology stack to be used will be advantage


  • Google Doc with the whitepaper open for commenting and containing the backlink to the submission.

Soft criteria

  • Detailed and easily understandable explanation and charts;
  • Brevity;
  • Mostly everyday English to facilitate understanding;
  • Readiness to participate in the implementation of the solution in the next stage;
  • Additional use cases to be covered (banking, issuance of derivatives etc), will be an advantage


1 place……………………….…50,000 TONs

2 place……………………….…25,000 TONs

3 place………….………………12,500 TONs

4-10 place…………………………2,500 TONs

Special rewards

  • Specification of new use case - +1,000 TONs to the main reward;
  • Additional reviews of architecture from users, recognized and acceptable by jury, with Telegram contacts of ones who done and name of entity- +1,000 TONs to the main reward for each;.


  • Jury members who vote in this contest must have a solid understanding of the technology. Those jurors who don’t, should not vote or choose “Abstain.”
  • 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 1 to 10 or can choose to reject it if it does not meet requirements or choose to abstain from voting if they feel unqualified to judge.
  • Jurors will provide feedback on your submissions.
  • The Jury will reject duplicate, sub-par, incomplete, or inappropriate submissions.

Jury rewards

An amount equal to 5% of the prize fund will be divided equitably between all jurors who vote and provide feedback based on their votes’ quantity and quality. Both voting and feedback are mandatory to collect this reward.

Procedural reminders to all contestants

  • Accessibility. 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, jurors may 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 may reject your submission.
  • Content. The content published in the forum and the provided PDF file should not differ, except for formatting. Otherwise, jurors may reject the submission.
  • Well-formed links. If your submission has links to the work performed, the content of those links must have the contestant’s contact details, preferably a Telegram username, so jurors can match it and verify whom the work belongs. If not, jurors may 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 may 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.


Anyone can participate, but Free TON cannot distribute Tons to US citizens or US entities.



  • We don’t have a list of TIP-3 tokens and user wallets to integrate with other apps.
  • We don’t have any API for for working with wallets. For example, notifications about the receipt of tokens on wallet.
  • We can’t use TIP-3 without expanding of standard to integrate with other smart-contracts.

I’ve thought a lot about this and join the contest.

I think that 6 days is too short for detailed whitepaper. It takes more time. 10 - 14 days eg.


This is a very important topic, one which I agree with very much. I think the date should be extended.

1 Like
  1. Could you expand on the “ is a headache” point?
  2. What do you mean by API? sdk? An http api?