Free TON

Free TON Collaboration Guide

Free TON Collaboration Guide

The following guidelines are based on experience from previous and ongoing collaborations. They get updated frequently, so please check back now and again as the community evolves.

A). Collaboration proposals should be posted on the discussion forum in the partnership section by creating a “New Topic” (top right of page) approximately 1 - 3 weeks (suggested) prior to expecting it to be put to a vote by the community. It is then the proposing party’s responsibility to monitor the chat, respond to comments, answer questions, add to the thread, and so on. It is recommended to amend the proposal in the thread (not the original proposal but as a reply to comments so the community can track changes) in response to any critique. The amount of positive feedback and activity determines whether or not the proposal should go to a vote on the voting site. In the end, if the amount of negative comments outweigh the number of positive, a vote is unlikely to happen.

B). Each collaboration proposal should contain the following:

  1. Detailed information about the proposing party, including their website, principal business and statistics, including number of users, number of transactions, volumes, active users, paying users, etc (approximate). All of these are important for the community to make informed decisions and must be accompanied with links and data to statistics that can be verified by the community.

  2. Detailed information about the primary reason for the collaboration itself.

  • How will the proposing party benefit from Free TON integration and vice versa?
  • What additional functionality/value will proposing party/Free TON users get?
  • Forecast implementation time and user engagement.
  • Mechanics of token distribution or token incentives, expectation of how it will use the tokens received.

3). Detailed description of the implementation process, including costs, timing, developers required (seniority, hours/days/months necessary to implement).

4). Initial/upfront token requests

Integration:

a. Should be slit into 2 parts. Part 1 is the proposing party’s internal side of the process, and when necessary, the external end of it that Free TON members can assist with. The external part needs to be presented as a contest proposal, the winners of which will receive tokens to assist in the external portion of the integration process.

b. The proposing party’s internal part of the integration should be based on the complexity of the implementation process and should be calculated on the basis of direct costs. For example, “We request 100K tokens to integrate our product, which will require two months of full time work by 2 senior C++/Rust/any developers, 1 junior developer, and 30% engagement by the product lead.” Something like that.

Initial tokens for distribution/promotion: proposing party should define the primary mechanics of distribution and promotion. For example, “For each active user buying our product with TON tokens, the user will get a 10% discount or 10% cashback in TONs,” or, “For the opportunity to be able to use our voting program, each user will get 5 tokens to vote for ABC,” and so on.

5). Additional token requests

  • The proposing party should provide a detailed description of user engagement that such a collaboration will bring, including defining what is considered an active user of the Free TON collaboration product; for example, a user who creates a wallet in Free TON, a user who buys/gets something from the proposing party with TON tokens via distribution, or perhaps further activities that the user will perform by receiving X amount of tokens to be used for payments for the proposing party’s product or service.

  • Proposing party should clearly define how many additional tokens per user are going to be distributed to its users based on some kind of activity and how many tokens they expect to receive; for example, if the proposing party requests 4 tokens per active user and the user pays for the proposing party’s product or service with TON Crystals, then they receive 3 tokens cashback for this purchase and 1 token remains a premium for the proposing party.

6). All token requests must have an overall cap. If the proposing party meets or exceeds all KPIs within the proposed time frame, a new proposal can be drafted with an additional token request.

7). Every proposal should have a summary table somewhere at the top, perhaps after the introduction/abstract that clearly summarizes the following: How many tokens? What for? When?

C). The proposing party shall pass through a KYP (“know your partner”) procedure through a 3rd party KYP service provider of the Free TON community’s choosing in order to confirm that the collaboration proposal is being proposed by the proposing party or by its authorized representative. In the event of the proposal being prepared by an authorized representative, the proposing party must provide a signed 1-page authorization on their letterhead that shall be verified. The purpose of this is to avoid the risk of fraudulent collaboration proposals on behalf of existing companies by individuals that have no authority to do so.

D). In the event that a collaboration proposal is written in a language other than English, a translated English version must be provided. In the event of any discrepancies, the English language will be considered as the official proposal.

E).Every proposal must indicate the wallet address to which tokens will be sent.

F). Proposals that involve any up front tokens in exchange for something viable, such as integration or other KPIs, should provide a monthly report that includes verifiable details about 1) how many tokens were spent, 2) what they were spent on, 3) what has been done thus far (what KPIs were achieved), 4) how many users were attracted to install wallets or buy TONs, etc., and how many TONs were distributed to users. Basically a progress report depending on the specificity of the collaboration case. This report must be presented for review before the following token distribution can be sent by uploading this report to the forum where the original proposal was uploaded for community review, and as a reply in the thread, with a request to release the next portion of tokens. This request will be sent to a vote before the next portion of tokens can be distributed.

G). Whenever the collaboration proposal leaves enough ambiguity where the forum discussion thread is not enough to rectify opposing views or answer a multitude of questions, the proposing party should be willing to partake in an AMA (Ask Me Anything) video session with members of the Free TON community. In most cases this has been a great tool to mitigate uncertainties.

22 Likes

Long overdue. Just to be clear, there are always exceptions. Monster whales who say they want to integrate will likely never see this end of it, but let’s be honest. We’re a ways away from that. So for the time being this is a very good check list.

4 Likes

Valuable guide. Thanks.
Is it already approved or it is here for discussion purpose?

1 Like

I am very happy to see this. Our community needs more business discipline with partnership negotiation and approval. If we do not improve this quickly, all future potential partners will propose and expect unreasonable rewards. It is also important to recognize the value the partner company receives from Free TON integration. $500,000,000 and several years of development were invested into the code and it is the highest performing blockchain in the world. The benefits are mutual and the rewards should consider this.

3 Likes

Thanks for guidelines.

For discussion for now. Every idea needs community feedback

1 Like

I think it’s very reasonably and timely proposal.
Almost all controversial topics are covered.

I’d suggest to discuss how we can better manage upfront payments. Not completely against them, but it’s better to have them as low as possible so that partners have stronger intention to benefit from the results.

And, I’d suggest to discuss how we are going to verify that a) partner is moving in the way he wrote in the proposal b) end user token mechanics are in the way he wrote in the proposal.

1 Like

I think we need to add something about requiring verification of all claims (partner’s customer base, market penetration, partner growth, past results/track record, advertising views/engagement etc.)

Also, I think all partnerships should be done in as many stages as practical (the guide should say this) and we should make it clear that any governance approvals are only a commitment for the first stage only (additional governance approvals are required for each stage).

Our community should develop standard Terms and Conditions for these partnerships that detail these and all other important points. The more clear the agreements and T&Cs are, the less disagreements and issues there will be in the future.

1 Like