so ton is a complicated system and nothing could be even more complicated than ton than it's model of transaction costs and fees so let's uh take a deep dive into what kind of fees exist in t but first of all let's talk about why this is important so ton is a public network and like any public network it is subject to attacks by anyone who wishes to do so and so Extra Care should be taken of uh protecting this uh shared resource from denial of service attacks and this means that if there is any non-trivial
cost uh that some participants in the network bear that could be Amplified by the external actors uh this creates a huge risk for the uh liveliness of the whole ecosystem and that's why anything that has any noticeable cost uh and can be Amplified must be accounted for explicitly in terms of fees now in tone there are generally three categories of fees this is the gas cost the rent and the message fees let's talk about each of them in detail and what are the gas fees uh ton is a computation platform uh your contract may contain
arbitrary code and anyone can upload into the network any code they want so once they do that then the whole network will process messages running this code and so this code could contain Loops it could you know create extra large amounts of data and all of this should be accounted for in terms of some payment so that uh everyone who Bears this cost uh get in return transaction fees and deter attackers from exploiting their resources the term gas comes from the gasoline like a fuel for the execution and it was originally invented in ethereum uh
the idea is that for each operation in your code there is a nominal gas cost that allows you to specify how some operations are more or less expensive than others and then there is a global parameter that specifies the gas price that specifies how much all of these gas uh units cost at the present prices and the idea is that the price of the uh ton coin could vary from time to time H and therefore the gas price should be adjusted to reflect the real cost of execution so for instance if ton coin uh is
increased in price uh 10 times then you probably want to adjust the gas price down by a factor of 10 to uh to not make the computation more prohibitively expensive and ton is designed unlike ethereum or Bitcoin in a way that doesn't produce the market for the scarse amount of gas or the block size instead it chars INF infinitely so that if you pay one gas price today and tomorrow you have uh much higher load then the validators of the network will earn higher fees but the users will not have to compete on fees and
will pay the same price just the network will scale out horizontally now mechanically what happens in the TVM when the code is executed every instruction is checked for correctness and then uh your balance is reduced by the cost of the gas that this instruction incurred and by the end of the execution if your balance didn't run out of money then execution is is completed successfully but if you do run out of balance due to gas costs then the execution aborts in the middle and all the gas payments are collected meaning that your your new balance
will be recorded as such but the new uh storage for the contract will not be applied and you as a designer have to take care of a couple of considerations regarding gas you should take care of uh deciding who is going to pay for the gas costs whether it's your contract or it's the sender of a message that sends the message to this contract and more often than not uh the best strategy is to put all the costs on the sender and design your contract in a way that the costs are more or less predictable
to the senders so they could attach um enough coins to their message to cover the gas cost and then the code of the contract will just limit the gas usage to this amount that they received and and if the ran out of this amount then the contract will not change its state and it's just the center of the message will lose their money on fruitless computation um sometimes you want to for convenience or for whatever other reasons decide that you will increase the gas limit and let the contract pay for itself but then you have
to take extra care of verifying that the message came from The Trusted source that will not exploit this ability so some times you may you know decide that this is unauthenticated message but you will do a couple of checks make sure that your gas cost will be limited now to the second category of costs which is rent so rent is simply defined as a cost of a single bit of data that the contract stores per unit of time which is a second so it's really defined in a very granular manner per bit and per second
uh but it's not charged on a basis uh of each second instead we know that the contract does not change its state in between transactions so what happens instead uh nothing happens to a contract in between transactions and then when a new transaction begins this is where storage phase that we talked about previously kicks in where we take all of the amount of time that the contract existed since the previous transaction and multiply this by the size of the storage uh occupied by the contract and then we compute the amount of like what I mean
by we I mean the whole network computes the amount of rent um that the contract owes to the network for this amount of time and charges it from the balance of the contract and you may notice if you use a wallet that if you haven't used a wallet for uh several days then the first transaction that you send has slightly higher fee than the next one this is because your wallet was idle for a week or two and some noticeable amount of rent accumulated that was charged when you did this transaction and then next transaction
happens maybe a minute later and uh has negligible amount of rent and so you will see the difference and fees that may seem random but it's actually the rent that was charged for for all the idle time of the contract and finally the third category is a number of fees for importing and creating outgo messages and uh there are various fees that are um charged per message per bite uh with very various prices and uh also this applies to the update update of the storage of the contract so this comes to play in the action
phase when your contract creates the outgoing messages and specifies new state for itself and uh these are typically quite low fees because there's not you know much of much data uh transmitted between the contracts uh but this is a third category that you as a contract designer should take care of so let's talk about a couple of pitfalls and considerations in the design of smart contracts around gas and rent payments first of all you obviously don't want your contract to run out of gas limit in the ordinary valid transactions and you don't want your contract
to run out of rent because then it will be fro fren and gets stuck until it's um refilled with coins um so how to uh make sure that your contract you know exists first of all anyone in the network can send ton coins to any contract to refill their balance and so if you have a decentralized app that has um a shared user base and is not having any particular operator then any user could you know make this contract leave further by by just topping up its balance and sometimes in the logic of your contract
you can encode um a portion of the funds that are transferred in the messages to refill its own balance uh secondly uh if you put the cost of the guess um and and execution on the sender then uh you may not always be able to guarantee some specific cost of execution for various reasons but but what you could guarantee is some kind of upper bound so this means that the sender would attach some amount of coins that exceeds the necessary amount uh charged by the network for the gas and the rest of the coins would
otherwise be deployed and deposited on the uh contracts balance so to make it more usable uh there's a pattern in um design of the contracts where uh the contracts send excess coins as a reply message uh to the address that the sender specifies so it could be back to the sender or to some other wallet so for instance if you are transferring Tokens The Token transfer is operated through additional messages and you have to attach some amount of tone coins to this message to make sure to cover the gas costs and you typically want to
put a little bit more just to make sure that you know it succeeds but then uh there will be a separate additional message that sends all the unused amount of coins back to your wallet uh this is a pattern that people design in the systems um uh on t uh to make sure that the users attach uh enough coins to avoid failures but at the same time don't overpay unnecessarily for the fees and finally one more consideration is uh regarding bounded execution of the contracts strive to design your contracts to be of a constant cost
in terms of storage and in terms of computation because this way your rent and your gas costs could be more predictable if you have a variable length uh data structure that grows for instance with every transaction then uh the costs of operating in this contract are not predictable neither to your users nor to the contract uh author and this makes it very easy to uh slip into Stakes where contract runs out of money and may even enter inconsistent State uh so the best way to avoid these situations and avoid the complexity of dealing with it
is to design your contracts to be of a limited uh size and limited cost of execution
