This is an introductory post aimed at giving some context as to what we're doing here. What is special about blockchain and why are we using it? This post will also define some basic terms like *smart contract* and *gas*. If you're feeling lost, this is a good place to start.

## The old Internet (Web2)

The term [Web 2.0](https://en.wikipedia.org/wiki/Web_2.0) is used to describe the traditional Internet as you know it. This Internet is operated primarily by large corporations like [Google](https://abc.xyz/investor/). The formal reason for the existance of corporations is to [generate profit for their shareholders](https://corpgov.law.harvard.edu/2020/08/05/on-the-purpose-and-objective-of-the-corporation/). This means that the global good or the benefits of their users are a byproduct and not the end goal.

Let's take a Web2 service like [Gmail](https://gmail.com). You, as a user of this service, are inherently not equal to the creator of the service, Google. We call this property ***centralization***. Centralized services don't provide users with true ownership. If Google decides that you've breached its terms of service, for example, it is allowed to take your email access away from you. Centralized services are also ***permissioned***, meaning that to use the service and send an email you must ask for permission. If Google decides that your email is spam, it is not required to send it.

Centralization is based on ***trust***. Users allow Google to maintain a position of power because they trust Google with this power.

## The new Internet (Web3)

Many of us view the Internet as a common good. We see it as a tool that turns the world into a global village. A tool that allows users to communicate and form communities. As such, we would like to see a shift of power from corporations to users. Web3 is the implementation of this ideal, what we would like to see as the next stage of evolution of the Internet.

Under this ideal, you, as a user of a Web3 service, must be inherently equal to the creator of the service. We call this property ***decentralization***. Decentralized services provide users with true ownership. This is not only true for data, but also for assets. Decentralized assets like your Bitcoins or your TON coins are yours, and nobody can take them away from you. Decentralized services are also ***permissionless***, meaning that to transfer your TON coin to somebody else requires nobody's permission but your own. Nobody can stop this from happening or censor you.

Decentralization allows systems to be ***trustless***. Since there are no positions of authority, authority cannot be abused to hurt users.

## The blockchain

The ideal of Web3 sounds great on paper, but is it practical? As developers, how can we implement services where we are inherently equal to our users? Implementing a service normally requires the developer to write a *backend*. This backend runs on some server. Who owns the server? the developer. The developer can change the server without asking or even take it down. This relationship is inherently not equal. Backend servers are ***centralized***.

Blockchain technology was invented to solve this problem and allow developers to create backends that are ***decentralized***. Who runs this backend? The users do. Since the relationship is equal, any user that wishes to participate in running this backend is allowed to do so. Blockchain runs as a collaboration between its users.

Collaboration is governed by ***consensus***. For an execution result to hold true, multiple users, a majority to be exact, must all vote to confirm the result. This makes blockchains very inefficient since every calculation must be executed by many users. This also makes blockchains expensive to run compared to a traditional centralized server.

## The token

We mentioned that execution results require voting. How does it work? Is it - one user, one vote - like in democratic elections? It turns out that this doesn't work on the Internet due to something known as the [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). It is very easy to create fake users on the Internet. Since Web3 is decentralized, we can't have a centralized source of authority that decides who's fake and who's real.

A popular decentralized solution to this problem is to revolve voting rights around a ***token***. If you own 10 tokens, you have 10 votes. Tokens cannot be faked, it is very easy to tell between a real token and a fake one. The TON blockchain revolves around the [TON coin](https://coinmarketcap.com/currencies/toncoin/). The Ethereum blockchain revolves around [Ether](https://coinmarketcap.com/currencies/ethereum/). This means that every blockchain is also an economy. The token acts as an incentivization tool to make sure that the decentralized community is all pulling in the same direction.

## Network validators

All blockchains are networks because they are operated by a group of users. Users that do the heavy lifting of operating the network and actively participate in the consensus process are called ***validators***. The voting weight of every validator is proportional to the amount of tokens they hold. To keep validators honest, they are normally required to put their tokens **at stake**. If the consensus deems that a validator is dishonest, their tokens will be taken away as punishment. This governance process is called ***proof-of-stake***.

Being a network validator is usually hard work. You need to run the ***[blockchain node](https://ton.org/docs/participate/nodes/run-node)*** code on a server that you own and stake it with a lot of tokens. Smaller users that want to participate but don't have enough tokens to warrant going to all this effort can often delegate their tokens to one of the larger validators. These participants are called ***nominators***.

## Gas fees

We said earlier that blockchains are economies. The equipment for network validators is not free, so they must be paid for their efforts. Payment naturally takes place with the token of the blockchain. On the TON blockchain, users pay fees using the TON coin. TON network validators earn TON coin for performing the validation process and executing all the apps that are running on the blockchain.

When a user is performing some action on the blockchain, they must send a ***transaction***. The transaction includes a [fee payment](https://ton.org/docs/develop/smart-contracts/fees) called ***gas***. The analogy comes from cars. Just like a car needs gas to run, so does a blockchain transaction. Users must ***sign*** transactions using their blockchain ***wallets***. This signature guarantees that only the owner of the wallet can authorize the payment of gas and sending the transaction.

## Dapps

We said earlier that the purpose of blockchains is to run decentralized backends. A simpler name for these services that run on the blockchain network is *apps* - decentralized apps to be exact or ***dapps*** for short. Developers create dapps and have network validators execute them. Users interact with dapps by sending them transactions. The developer of a dapp is equal to the dapp's users. The developer should have no special priviliges since the app is decentralized.

Let's reiterate over the last point with an example. Let's take a Web2 service like Google Search. The developer of the service, Google, ranks search results for the benefit of users. Google enjoys this position of power and is allowed to promote its own products in search results. For example, when searching for "storage", Google can promote the result "Google Drive" over a competitor like "Dropbox". In a Web3 version of Google Search, the developer of the service will not be allowed to promote their own products in search.

## Smart contracts

Every Web2 service like Google Search has terms of service. If a user feels that they were wronged under these terms, they can sue and ask a judge to rule on the dispute. Web3 is decentralized and cannot have centralized sources of authority like judges. On blockchain, code is law. The code of the dapp is the only agreement between its users. Unlike traditional legal agreements, this agreement is not open to interpretation. Code always executes in the same way.

Blockchain replaces legal contracts with code. The code of the dapp is therefore called a ***smart contract***. Before users decide to participate in a dapp, by sending it transactions for example, they are expected to [review](https://verifier.ton.org) the dapp's source code to understand its terms. Just like you wouldn't sign a lease contract for your apartment without reading the contract, you should not sign a transaction without reviewing the smart contract. Since not all users are tech savvy enough to do this, communities often rely on each other for this purpose.

After the developer finished writing the smart contract, the act of publishing this contract to the blockchain is called ***deployment***. The contract code is deployed on to the chain where everybody can find it by its ***[contract address](https://ton.org/docs/learn/overviews/addresses)***.

## Blocks and explorers

We said earlier that network validators must vote on the execution result of every transaction. To streamline this process, groups of transactions are batched together in ***blocks***. Every block of transactions gets its own ***block number*** and undergoes the consensus process where a majority of network validators is required to approve it. When you order all the blocks one after the other you get a chain of blocks - this is the source of the word ***blockchain***.

After sending a transaction, a user must wait until this transaction is included in a block. A new block on TON blockchain is created every 5 seconds on average. Users can inspect transactions, check if they succeeded or not and see which block they were added to by using a tool called a ***block explorer***, or an [explorer](https://tonscan.org) for short.

## So what is blockchain good for?

In this post we mostly covered what blockchain is and defined a lot of the terminology involved. It sounds like an awful lot of trouble to achieve abstract benefits like *decentralization* and *trustlessness*. Can we give a more practical example where blockchain can improve your life?

Back in 2018 I wrote a well received 2-part post series about this very topic. Part 1 is ["How a Blockchain Can Help You on a Deserted Island"](https://talkol.medium.com/why-decentralized-consensus-blockchain-is-good-for-business-5ff263468210) and part 2 is ["How to Run a Blockchain on a Deserted Island with Pen and Paper"](https://talkol.medium.com/how-to-run-a-blockchain-on-a-deserted-island-with-pen-and-paper-899949ec555b). If you like the old TV series [Lost](https://www.imdb.com/title/tt0411008/), give it a read, I'm sure that you'll enjoy it.

Happy coding!

---

*Tal is a founder of [Orbs Network](https://orbs.com). He's a passionate blockchain developer, open source advocate and a contributor to the TON ecosystem. Follow Tal on [GitHub](https://github.com/talkol) and [Twitter](https://twitter.com/koltal). If you found any mistakes in this post, please let Tal know on [Telegram](https://t.me/talkol).*


What is blockchain? What is a smart contract? What is gas?

TON is a very modern blockchain that brings some radical new ideas to smart contract development. It was designed quite
some time after Ethereum was launched and had the luxury to learn what works well in the EVM model and what can be
improved.

If you have some prior smart contract experience, you're probably familiar with Ethereum's Solidity language and its EVM.
When learning TON development you should be aware of certain design differences that make things on TON behave quite
differently from what you expect. The purpose of this post is to highlight some of these differences and give you some
general ideas as to why they came to be.

#### *Moving from data to big data*

The main thing to understand about TON is that it was designed to bring blockchain to the hands of every human on earth.
This means massive scale - billions of users sending billions of transactions per day.

Think of this as the shift from *data* to *big data*. When you need to store the menu of a restaurant, an SQL database
is a great choice - it can run powerful and flexible queries because all the data is readily available. When you need to
store the Facebook posts of every human on earth, an SQL database is probably not the route to take. These amounts of "
big data" must be sharded aggressively - limiting the flexibility of the queries you can run. Different tradeoffs for
different purposes.

---

Here are six unique aspects of TON blockchain that will probably surprise most Solidity developers:

## 1. Your smart contract needs to pay rent and charge its users

The blockchain as an immutable and eternal store of data, is a great concept on paper, but as we'll soon see, is quite
impractical to scale. The fee model of Ethereum is inspired from that of a *bank*. You want to send some money, you pay
the bank a transaction fee. Who is responsible for paying the fee? The user who initiated the transfer.

What about storing data on the blockchain - for example deploying the bytecode for a new smart contract? The Ethereum
model dictates that the person sending the deploy transaction will pay the fee. But this fee is paid only once, yet if
data on the chain is eternal, miners will have to keep paying infrastructure costs to retain this data for years to
come. These fee economics don't add up, and if you try to scale them to billions of users, they will eventually
collapse.

#### *Moving from a bank to an instant messenger*

The fee model on TON is quite different. Instead of emulating a bank account, TON is inspired from web apps like *
instant messengers*. Who is paying the cost to send a message on Facebook Messenger? It's definitely not the person
initiating the transfer. The app developer, Facebook Inc (or Meta Inc, I don't follow, I use Telegram myself), is
actually covering the costs, and it's up to Facebook Inc to recover these costs somehow and fund itself.

Accordingly, in TON, the dapp itself needs to pay for its own resource costs. Every smart contract holds a TON token
balance and uses this balance to pay rent. If the smart contract runs out of money, it will eventually be deleted (don't
worry, everything is recoverable). Notice that paying for chain storage doesn't happen once, the rent payment is
continuous. If you only hold data for a short period of time, you will pay significantly less. These fee economics are
more in line with the costs of miners and thus easier to scale.

Very similar to Facebook Inc, the contract developer in TON has a lot of freedom to choose how to fund its operation.
The developer can fund the contract with TON tokens out of pocket and subsidize its users; or it can charge gas from
users for different actions and keep this gas in its balance for future rent payments.

## 2. Calls between smart contracts are asynchronous and not atomic

One of the great enablers of a powerful DeFi ecosystem on Ethereum is the seamless composability of contracts. In a
single transaction, you can take some WBTC, supply it as collateral with a contract
by [Compound](https://compound.finance/), and use it to borrow USDC, trade this USDC with a contract
by [Uniswap](https://uniswap.org/) for more WBTC - and thus leverage your WBTC position. The whole process is even
atomic - if any of these steps fails, even the last, the whole transaction rolls back like it never happened.

When your smart contract calls a method of a different smart contract, the call will be processed immediately in the
same transaction. Ethereum in this regard is very similar to running your entire backend on a single server. Every part
of your backend will be able to synchronously access every other part - an approach that is very easy to reason about.
It has but one caveat, it can only grow as long as it fits in one place.

#### *Moving from a single server to a cluster of microservices*

If you imagine Ethereum as a monolith on a single server, TON is more similar to a cluster of microservices. Think that
every smart contract may be running on a different machine. If two smart contracts want to call each other, just like
two microservices communicating, they can send a message over the network. This message takes some time to travel, so
communication is suddenly asynchronous! This means that when your smart contract calls a method of a different smart
contract, the call will be processed after the transaction terminates, on some different future block.

This is much more difficult to reason about. What happens if conditions change from when the message was sent and until
it was received? For example, the calling contract balance had one value, but by the time the second contract processes
the call, the balance has changed. Maintaining consistency is more difficult and bugs can creep up. What about
atomicity? What happens if you chain three calls and only the last one fails? If you need to roll back all the changes,
you will have to do so manually.

## 3. Your smart contract cannot run getter methods on other contracts

This is actually a different face of the previous item on the list. On Ethereum, where calls between contracts are
synchronous, reading data from a different smart contract is straightforward. Let's say that my contract has a balance
of USDC. Since USDC is also a contract by itself, in order to know its own balance, my contract will have to call
the `getBalance` method of the USDC contract.

Remember the monolith running on a single server? One of the great benefits of this approach is that every service can
read directly the state memory of every other service.

#### *Moving from a single server to a cluster of microservices*

When we have separate microservices running on different machines, reading state memory across services is suddenly
impossible. Smart contracts on TON can only communicate by sending asynchronous messages. If you need to query data from
another contract and you require the answer immediately, you're out of luck.

It actually gets even stranger. If you see getter methods on a TON smart contract, such as `getBalance` - these methods
are not accessible from other smart contracts. Getter methods can only be called by off-chain clients, similar to how
your Ethereum wallet can use a full node like Infura to query any smart contract state.

## 4. Smart contract code is not immutable and can easily be modified

The original inspiration for dapps on Ethereum is legal documents drafted by *lawyers* - hence the name "smart
contracts". The developer programs the terms of the legal contract as code, and code, as you know, is law. When two
parties in the real world sign a contract, the contract is immutable. If any of the parties wants to change the terms of
the contract, they would draft a new contract instead.

True to this approach, the code of smart contracts on Ethereum was designed to be immutable and never be modified. Over
the years, the developer community has learned to overcome this limitation and generated some cumbersome patterns that
rely on tricks like a proxy contract that points to a different contract in order to implement upgrades.

#### *Moving from a lawyers to software engineers*

Unlike lawyers, *software engineers* are taught that every piece of code has a bug in it. And even if mistakes would
never happen, requirements still change over time and code often must be upgraded and modified.

Under TON, the pretence that contracts should be immutable is dropped completely. Smart contracts are free to modify
their own code just like writing to any other state variable. If a contract writes to the code variable, it is mutable,
and if it doesn't, it is immutable. This isn't a big change in practice, it just makes the cumbersome proxy pattern
redundant.

## 5. You should not have unbounded data structures in your contract state

This is a tricky one that takes a while to understand, but will explain why some smart contracts on TON are architected
the way they are.

Unbounded data structures are state variables in smart contracts that can grow indefinitely. Consider the ERC20 contract
implementing the USDC token. This contract needs to maintain a map of balances per user address. The number of different
USDC holders can grow indefinitely since USDC can be minted in large amounts and broken down to tiny pieces. In other
words, the number of keys in the map can be as large as you want.

What happens if an attacker tries to spam the contract by adding more and more entries? Would they be able to cause some
DoS attack and prevent other honest users from using this contract? Ethereum solves this problem quite elegantly for
smart contract developers. The Ethereum fee model dictates that the user who writes new state data pays the fee for this
data. This means our attacker will have to pay a high cost for their spam. In addition, the gas cost for writes to a map
on Ethereum is constant and does not depend on how much data this map contains, which means other users will not suffer
from the spam. The bottom line is that spamming maps on Ethereum is not economical and the protection is provided by the
system.

#### *Moving from unbounded maps to unbounded contracts*

Unfortunately for TON smart contract developers, the system does not protect against spamming unbounded data structures
in contract state. The TON gas fee model dictates that writes are not constant in cost, the cost is normally
proportional to how much data exists in the data structure. This behavior stems from TON's reliance on the "Bag of
Cells" architecture - contract state is divided to 1023 bit chunks called "cells" that the developer is required to
maintain. Maps are implemented as a tree of cells, and writing to a leaf in the tree requires writing new hashes along
its entire height. If an attacker were to spam keys in the map, some user balances would be pushed so low in the tree
that updating them would be pass the gas limit.

The best practice in TON is therefore to avoid unbounded data structures in state. This will protect the contract from
crafty DoS vulnerabilities. This topic probably deserves its own independent blog post, but the solution in short is to
rely on contract sharding. If we have a potentially infinite number of user balances in our USDC contract, we should
break the single contract to multiple child contracts - each child holding the balance for a single user.

This should explain why [NFT](https://github.com/ton-blockchain/token-contract/tree/main/nft) collection contracts on
TON place every item in its own separate contract (the number of items can be unbounded); and
why [fungible token](https://github.com/ton-blockchain/token-contract/tree/main/ft) contracts on TON place every user's
balance in its own separate contract.

We normally provide a bit of the reasoning as to why TON is designed this way. The Ethereum gas fee model where map
writes are fixed and independent of map size is over simplified. In reality, as maps grow in size, miners require more
effort to change their contents. This extra effort is negligible as long as the maps are small, but when maps can grow
to billions of entries, this is no longer the case.

## 6. Wallets are contracts and one public key can have mutliple wallets deployed

On Ethereum, a user's wallet is synonymous to their address, and an address is derived directly from a public key (and
its corresponding private key). This is a 1:1 relationship, there's one address per public key and one public key per
address. As long as the user knows their private key, they could never lose their wallet.

In addition, a user on Ethereum doesn't have to do anything special to have a wallet. The Ethereum address is the
wallet. The address can hold the native currency ETH, the address can hold ERC20 tokens and NFTs and the address can
send and sign transactions to other smart contracts directly.

#### *Moving from address to contract*

On TON, wallets are not implied, they are independent smart contracts that must be deployed like any other smart
contract. When a new user wants to start using TON blockchain, their first step would be to deploy a wallet on-chain.
The address of this wallet is derived from the wallet contract code and various init parameters like the user's public
key.

This means that a user can have more than one wallet deployed, each with its own address. The wallets can differ on
their code (different official code versions are published by the foundation from time to time) or on their init
parameters (one of these parameters is normally a sequence number). This also means that a user that knows their private
key must still make a conscious effort to remember their wallet address (or the init parameters used in its
construction).

Sending a transaction to some dapp on TON involves signing a message using the user's private key. Unlike Ethereum, this
transaction is not sent to the dapp smart contract, but to the user's wallet contract, which will in turn forward the
message to the dapp smart contract.

This design approach opens up a new dimension of flexibility on TON. New wallet contracts can be invented by the
community over time, for example consider a wallet without a nonce (transaction sequence number) that allows multiple
transactions to be sent in parallel from different clients without prior synchronization. In addition, special wallets
like multi-sig wallets (that also on Ethereum require a special smart contract to be deployed), behave just like their
regular counterparts.

---

Tal is a founder of [Orbs Network](https://orbs.com). He's a passionate blockchain developer, open source advocate and a
contributor to the TON ecosystem.
For Tal's work on TON, follow on [GitHub](https://github.com/ton-defi-org). For Tal's personal work, follow
on [GitHub](https://github.com/talkol) and [Twitter](https://twitter.com/koltal).


Six unique aspects of TON Blockchain that will surprise Solidity developers

How to shard your TON smart contract and why - studying the anatomy of TON's Jettons

There's a lot of discussion going on in the TON community about the [proposal](https://t.me/tonblockchain/178) for "Tokenomics Optimization". The proposal is to freeze inactive genesis mining wallets for 48 months. To be more specific, 194 wallets holding 1,081,425,847 Toncoin. The list of addresses is available here: https://tontech.io/stats/early-miners

Like many members of the community, I formed my own opinion on the matter. I even changed my mind a couple of times when I understood a few things that weren't initially clear. To help educate the community on the subject, I decided to put my personal opinion in writing. We may even have a community vote on this proposal, which makes educated decision-making even more important.

If you don't know me, I've been an active contributor to the TON ecosystem for a while now. I'm the co-founder of [Orbs](https://orbs.com) and I [submit pieces](https://blog.ton.org/six-unique-aspects-of-ton-blockchain-that-will-surprise-solidity-developers) to this blog from time to time. I [speak about TON](https://www.youtube.com/watch?v=rqoqt1b4h2k) in conferences and do (uncompensated) ambassadorial work for our ecosystem. I believe that TON is a game changer and I love our community. It's important to note that I'm not part of the TON Foundation and, in any case, the opinions written here are my own.

## Freezing accounts - wtf?

This was my knee-jerk reaction to this proposal when I first saw it. The TON community has some members that come from web2 backgrounds and members that come from web3. If you know me, you already know that I come from web3 and [deeply believe](https://www.youtube.com/watch?v=_n6PLEW4Pmk) in decentralization. I'm the author of the [DeFi belief system](https://defi.org/defi-belief-system) and known to be a maximalist in my views.

Now, for a decentralization maximalist to hear about freezing accounts - indeed wtf? A fundamental principle of web3 is true ownership. What gives us the right to freeze anyone's tokens?

The source of not wanting to freeze others' tokens stems from the fear that one day in the future, somebody may want to freeze my own. My tokens belong to me and no community vote should be able to touch them.

It took a closer reading to understand that this proposal does not violate this principle. The proposal discusses the genesis mining program of TON. As you know, as part of the genesis, TON coins were distributed by a [2 year PoW mining program](https://ton.org/mining) that ended in June 2022. The proposal brings to discussion some parameters of this mining program and its tokenomics. The tokens up for a freeze are only tokens that were mined directly from the genesis PoW Giver contracts and were not fully claimed until today. **Nobody in TON will ever dream of freezing a regular token in somebody's wallet.**

## The market cap of TON

Market cap is probably the most important metric in any token-based ecosystem. This is the primary metric by which the industry ranks projects. Entire websites are dedicated for this metric like https://coinmarketcap.com. It is well known that Bitcoin is currently number 1 and Ethereum is number 2. Number 1 in what exactly? In market cap.

It turns out that projects throughout the years often attempt to manipulate and inflate their market cap artificially in order to climb up in the rankings. Everybody wants to be a top 10 coin. One of the ways to do this is to mint a large amount of tokens that aren't actually traded (they can be locked somewhere). Since they're not actually traded, minting them will not create sell pressure and bring the token price down. But when calculating market cap naively, they will take part of the calculation and inflate the numbers. Easy win.

To combat such manipulations, websites like [coinmarketcap.com](https://coinmarketcap.com) have algorithms that only take *circulating supply* into account. Meaning only tokens that touch the market and can actually be traded are counted towards the market cap.

Now we all know that TON is a top 30 project and we all expect it to even climb to the top 5. But, if you were looking in [coinmarketcap.com](https://coinmarketcap.com) just a few months ago, you would see TON ranked in market cap somewhere around place 250. Many legitimate TON coins were not taken into account and the market cap was incorrectly low.

## Fixing the circulating supply

It is in the community's best interest to identify and signal the **true circulating supply** of TON. Take an artificial number that is too low - then TON drops in the rankings since the market cap drops. Take an artificial number that is too high - then you signal to investors that many tokens can hit the market and the token price drops.

To help find the true number, the community has been actively telling holders for a while, mainly genesis holders, to move their tokens. This is particularly important if these tokens have never been moved since they were mined. It's enough just to send them to another wallet that you control. What this action does is signal that these tokens are part of the circulating supply.

The issue we have is that a significant number of tokens, that all came from genesis mining, have not been moved. Even worse, these tokens are in wallets that were never even deployed. As you know, unlike Ethereum, TON wallets are smart contracts. When you use a wallet, you must first deploy the smart contract code that operates it to the chain. Until you do so, the wallet is uninitialized. It turns out that the tokens that never moved are in wallets that are not even initialized.

The project needs to give certainty to the market as to how many tokens were mined during the genesis program. This is what this proposal is all about.

## A gentle solution

First, the proposal is only applicable to miners that have lost access to their coins. If a genesis miner has access, they are free to move the coins once and thus take them out of the list of uninitialized wallets. We know from other ecosystems like Bitcoin that a large percentage of mined coins are lost forever to wallets that don't have properly functioning private keys.

Second, the proposal is very light and doesn't freeze uninitialized coins forever. It asks to freeze them only for 48 months. What this does is gives certainty to the market for the next 4 years about the number of coins distributed in the genesis mining program.

This is why the proposal is described as dealing with "Tokenomics". A big part of TON tokenomics is the number of coins generated by genesis mining. This number could have been chosen to be somewhat arbitrary. The market prices TON coin accordingly.

## Bottom line decisions

My personal opinion is that this proposal should pass. I'm not concerned that somebody will ever take or freeze my tokens. I think that parameters like how many tokens were actually mined are important to set accurately. I think the market is waiting to see if the community makes a responsible decision and if the proposal passes, investor confidence in the project will rise.

---

*Tal is a founder of [Orbs Network](https://orbs.com). He's a passionate blockchain developer, open source advocate and a contributor to the TON ecosystem. Follow Tal on [GitHub](https://github.com/talkol) and [Twitter](https://twitter.com/koltal).*


Tal Kol