# TON Distribution Overview

Authored by DW. Strictly confidential, not for public consumption. All IP rights retained by the author.

## General Comments

### Naming conventions

'Referal distribution'

I think this is a misnomer, as 'referals' can be taken to be overly specific.

Airdrop: another bad word. Really this should be avoided as again, it's too focused on a single use case. It also draws on old ICO terms which are detrimental to the publicity of the project.

I would suggest simply 'public distribution', though there might be a better name.

### Distribution timeline

Some consensus should be reached about the amount of coins distributed over time to devs and public.

This is important, because it will need to be kept in check to avoid huge amounts of coin being distributed at once and causing wild economic fluctuations.

I posit that the number could be based on the validator rewards over time, which is already present in the blockchain.

### Restrictions on selling distributed coins

I understand there is an attempt being made to create a 1-year vesting period, but some coins will be released sooner. Like other things, this needs to be spelled out much more clearly.

I would like to point out that it's going to be very difficult to restrict the movement of coins. Once they're provided by the giver, the only recourse we have to stop a bad actor is to not give them any MORE coins.

The result of this attempt at control is inevitably penalizing those who comply, and penalizing those who are most active on the network (i.e. using all the coins that aren't tied up to do transactions and real-world commerce)

The lock-up of coins versus which coins will be spendable should be carefully considered to make sure we do righty by early adopters.

## Developers

> Developers are MUCH MORE important than validators or even the public adoption of TON. Validators can easily be replaced much more easily, and without developers, the public support will never come!

### TIPs: the heart of TON development

The structure of TIPs should loosely follow successful models such as BIP.

### A better model: Grants to Distributed Teams

we can model successful organizations with distributed teams by creating a grant program.

Instead of dealing with individual developers, we should distribute coins to organizations who will govern the secondary distribution to their respective team members.

Each organization must qualify and will receive traunches of funding pending periodic voting, based on several factors.

Developers are encouraged to join multiple organizations, and negotiate their own compensation with each.

### Why contests are not a good idea

Like with 'Airdrop', we are borrowing too much from the ICO world.

In addition, we have borrowed from Telegram's contests, which IMHO will not work for us.

It's clear that we are all competing in some sense. BUT, the word 'contest' is extremely limiting. 'Bounties' suggests that things can be divided into singular goals that can only be achieved once.

These models also promote secrecy, which will slow the overall process.

Multiple teams will attack the same problem, reinventing the wheel, only to find mostly duplicated implementations at the end of the contest.

In a 'contest' model only a few developers or organizations get paid, and not very often.

### TIP problems

Instead of real TIPs, we could have potentially have just 'tasks' which might even be written with a specific developer in mind. One might even say that the competitions promote nepotism.

If TIPs were too broad in scope, any one developer or team would be ineligible to complete it.

Thus the natural format of TIPs would be severely violated.

Teams or developers that specialize only in certain areas might be completely ruled out of participating in ANY competition if TIPs are too broad in scope.

if TIPs are too focused, we will need too many of them, and thus teams will attempt to take on multiple TIPs, which will exacerbate the issue of multiple teams doing the same work.

### What a distributed team grant system offers

In an effective distributed team model, collaboration and sharing are first-class citizens.

A system of checks and balances is created through this delegation of token spending power.

Developers are much more likely to join if they don't need to 'wait' for a new contest, and are assured that even small contributions can be rewarded.

Since organizations are not rewarded for secrecy, they can instead benefit from collaboration.

Because rewards are given to organizations as a whole on their performance and not on individual tasks, improvements and projects do not need to be based on TIPs in order to receive attention and compensation.

More developers will receive compensation, and they will receive it more often.

Governance becomes simple and free of scaling issues. So only a handful of votes (one per organization) must occur at every funding interval, even if there are 10000 developers.

TIPs become what they were meant to be, and multiple teams can collaborate to realize a TIP.

## Validators

This 'contest' needs to be described in much greater detail.

1. A "promise" to keep a validator online for 1 year isn't worth anything by itself.

2. 200000 TONs reward. It all depends on the distribution speed of the 5B. Coming up with amounts 'willy-nilly' is going to result in unjust distribution.

3. The qualifications are a bit too closed. Nodes should also be rewarded for getting online during this stage.

### Referal-based distribution mechanics

> DEC'IZE it!

While necessary and useful, these distributions definitely should NOT be limited to a single scheme or design.

> We need to avoid an "ICO" feel, at ALL COSTS!

Any anti-spam measures will have a centralized element and therefore present logistics and privacy issues. Here are 2 concepts that address these issues:

'DRY RUNS': Each proposed public airdrop should be classified in one of several categories, and allocated a fixed amount of funds as a "test run", essentially allowing several designs to be tested in the real world, without giving up too many tokens to potentially terrible ideas.

'DRIP-FEED for success' mentality: In addition, even once a proposal and the people who are required to execute it has been proven to work, ALL anti-spam measures will certainly have a centralized element. Therefore, funds should be allocated to launched proposals in pieces of for example 200,000 TONs, requiring a vote each time. This will prevent issues in case of force majeure.

## A proposed distribution solution

### Network Onboarding

Wallets that are registered to receive coins will receive them over time from a 'giver' smart contract that uses oracles driven by telegram bots.

The onboarding process is facilitated by an app that makes it easy for people to refer each other either in person or remotely, which is also a wallet/key manager AND an unofficial Telegram client.

32 levels of 'downline' allow people to be rewarded for those that they refer.

### Telegram ID verification

Anti-spam measures are achieved using a stand-alone telegram bot run by one of the validators that verifies Telegram ID is valid and not on the combot CAS spam list, and works with a smart contract.

### Retroactive reward boosts

A group administrator bot which volunteers can run in their groups alongside Combot, in approved groups. This bot would measure and reward group participation.

### What defines a succesful anti-spam solution

1. Cannot *easily* sign up for a lot of accounts

2. Cannot sign someone else up for an account without their knowledge

3. Cannot create a lot of dummy data/bloat in the blockchain

4. Should not require unreasonable effort on the part of verifiers or users.

5. Should uphold the privacy of its legitimate users.

Nothing is 100% spam proof. No. thing. is. 100%. spam. proof.

The acceptable level of spam is 5%. We just have to accept this reality.

### Why this solution works

1. Telegram requires a valid SIM / phone number to register an account in the airdrop. It is 'free SIM verification' and only the Telegram USER ID is required.

2. CAS.chat offers the CAS ban list up to the public which any good solution will almost certainly employ.

3. Wrapping in an unofficial telegram client streamlines the entire process for users and upholds their privacy.

### Why pure SIM verification isn't the best idea

1. Pure SIM / cell phone number verification through a service such as Twilio or Nexos costs half of 1 cent 0.005 USD per verification. It exposes the entity running the verification service to financial risk, and makes it very difficult to later make the verification system more distributed/decentralized.

2. While SIM cards are easy to come across, they *DO* cost money and any methods which verify phone numbers are extremely effective as a deterrent.

## Possible improvements

### Turnkey segmented distribution

A particular organization with access to funds they wish to distribute could deploy something of a turnkey solution.

### Telegram passport

Integrating the verification bot with future upgrades to the Telegram Passport program may provide additional information. Organizations running segmented distribution might be well-served to use this, for example, if they require KYC.

### Web-of-trust style reward boosts

An oracle program that's fully integrated with the blockchain could analyze blockchain activity and reward network participation. Service providers could then independently verify Telegram IDs (Login with Telegram/Telegram Passport) to achieve this without privacy concerns.

### Decentralizing the telegram verification bot

While the telegram bot idea requires an individual bot to chat with users who register one at a time, multiple bots could be deployed who all have access to the contract, and trust for these bots could be managed so as to revoke access for bad actors or those who do not maintain their services. This does present some unification issues.

Actually putting the entire process on-chain would require some serious effort and part of the reason why Telegram bots work is that Telegram is centralized. Still, this is worth thinking about.

### Using 3rd party data, FB/Google/Exchanges

Facebook/Google account linking presents privacy issues, while a completely open system (except for Telegram account verification) presents an easier path for spammers.

Again, while a centralized bot or such thing can add features like FB or Google verification to increase the airdrop reward or to qualify individuals, the privacy issue here is immense, and let's not forget people in China don't have access to these things.

Exchanges' policies are (or should be) geared towards privacy. The amount of effort on their part and the compensation they would ask for doing this method would likely outweigh the supposed advantage of "real people" getting more coins.

KYC data can also be faked, especially if it's just for this purpose.

Using telegram passport and a web-of-trust system as described in this document might mitigate these issues, but will take months to build.

## Conclusion/TL;DR

An anti-spam airdrop to users is possible, but should be done in a variety of different ways by a DEC'IZED group of entities who are each rewarded tokens in small chunks pending the ongoing success of their proposed solutions.

An unofficial Telegram client and telegram bot is the best way to do this.

Verifying Telegram ID and Telegram CAS ban status are the best methods to defeat spam. Other methods have issues with cost, privacy, or sustainability, which might be fixed with further research and development.

Organizations could use a turnkey deployment provided by developers to quickly deploy semi-private distribution groups.