Skip to content

Commit

Permalink
Staging (#811)
Browse files Browse the repository at this point in the history 
* remove content

* New translations overview.md (Chinese Simplified)

* New translations translation-style-guide.md (Chinese Simplified)

* Mandarin localization (#63)

* New translations cell-boc.mdx (Chinese Simplified)

* New translations as-contributor.md (Korean)

* New translations as-maintainer.md (Korean)

* New translations readme.mdx (Korean)

* New translations guidelines.md (Korean)

* New translations schemes-guidelines.mdx (Korean)

* New translations guidelines.md (Korean)

* New translations guidelines.md (Japanese)

* New translations principles-of-a-good-tutorial.md (Korean)

* New translations sample-tutorial.md (Korean)

* New translations readme.md (Korean)

* New translations contribution-rules.md (Korean)

* New translations maintainers.md (Korean)

* New translations participate.md (Korean)

* New translations mining.md (Korean)

* remove engines

* update dropdown menu

* fix import

* add translation of sidebar

---------

Co-authored-by: TonSquare <147710825+TonSquare@users.noreply.github.com>

* New translations how-it-works.md (Chinese Simplified)

* New translations how-to-contribute.md (Chinese Simplified)

* format fix

* Update to mytonctrl2 links in FullNode

* Add tip on how to use testnet config in Full Node

* Add tip about status fast in testnet

* Refactor

* Add link for testnet dump for archive node

* update default lang array

* New translations pow-givers.md (Korean)

* New translations sharding-lifecycle.mdx (Korean)

* fix header (#68)

* fix translation header

* Fix number of outgoing messages

* Remove duplicated

* Add tlb-parsers.md & Add tlb-codegen & fix link

* Separate parsers and tl-b generator

* add backend example for ton proof

* New translations send-transactions-from-highload.md (Chinese Simplified)

* New translations shards.mdx (Korean)

* New translations auditors.mdx (Korean)

* New translations outsource.mdx (Korean)

* New translations adnl.md (Korean)

* New translations getblock-ton-api.md (Korean)

* New translations overview.md (Chinese Simplified)

* New translations how-to-contribute.md (Chinese Simplified)

* cut_warining

* Stepik corrections

Added RU and CHN links as well as replaced EN -> CHN in CHN pages

* Update academy-overview.md

* Add AWS instance description

* ecosystem_messages_layout_init

* ecosystem_messages_layuot_2

Correction sidebars,js

* ecosystem-messages-layout_3

Scheme files added

* ecosystem-messages-layout_4

Cookbook update

* chrore: add info about gasless transactions

* Add information about node setup timings

* Revert "ecosystem-messages-layout_4"

This reverts commit c33a788.

* ecosystem_messages_layout_4

Cookbook Update according new schemes

* cookbook_schemes_update

Added dark scheme

* Cookbook_update

Deleting old scheme

* Cookbook_update_3

Deleting old schemes

* Update jetton_transfer_dark.svg

* Fix non latin symbol

* Scheme_Visio_added

* Update archive-node.md

update archive node requirements

* Update enable-liteserver-node.md

update liteserver requirements

* sidebar_fix

* Delete public proxy and C++ compile page

- participate/web3/sites-and-proxy
- public proxy

* Delete public proxy and C++ instruction

- participate/web3/sites-and-proxy
- public proxy
amend

* Revert "Delete public proxy and C++ instruction"

This reverts commit 4adc61a.

* tons_sites_for_apps_page_added

* Updated after review

* cut_jetton_text

Cut the jetton - as Standard operation text from the Cookbook.

* Update how-to-run-ton-site.md

* Update how-to-run-ton-site.md

* Revert wallet.md typo fix

* Add error of wrong user usage for nodes

* docs(cookbook): update Go address parsing example

* feat: ton connect tg bot integration archived

* Update single-nominator.mdx (#710)

* Update single-nominator.mdx (#711)

* collectiong_minging_fix

Transfer fixes from PR, which got stuck because of merge conflicts.

https://github.com/ton-community/ton-docs/pull/664/files

* 🐛 Fix link in doc (#685)

* Add some explanation for effective stake (#687)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* feat: Add tonconnect vue sdk link (#688)

* add tonconnect vue sdk link

* fix typo

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: infinityspectra <149141428+infinityspectra@users.noreply.github.com>

* feat: upd wallets switch testnet info (#694)

Co-authored-by: igor <i.verhusha@pixelplex.io>

* Add Error parsing dependencies to troubleshooting (#695)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>
Co-authored-by: AlexG <39581753+reveloper@users.noreply.github.com>

* Fix typo in mode 0 of send_raw_message (#699)

This is a non-trivial typo as developer most likely refer to mode 0 to understand how token transfer works

* Update how-to-run-ton-site.md (#700)

* update ton connect docs, add video (#701)

Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Update cookbook.md date->data (#703)

* Update messages.md (#706)

Fixed Send a regular message

* fix_node_troubleshooting

added lost snippet related to Version problem

* update troubleshooting (#712)

* update_ton_connect_button

* remove mytonctrl2 branch mentions (#714)

* Scheme update 2 (#707)

* Ecosystem_schemes_layout_5

Try to change font replacement

* Ecosystem_scheme_png_update

* Ecosystem_sheme_png_2

* Update nodes-troubleshooting.md

* SAP list update

SAP list updated according current status of auditors on Ecosystem.

* added contributors wall

* single-nominator-fix

* wallet-guidelines-cut-oudated-link

* Added info run docker (#611)

* add info run in docker

* change docker repository mytonctrl

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Update docs/participate/run-nodes/run-docker.md

Co-authored-by: Dr. Awesome Doge <doge@ton.org>

---------

Co-authored-by: Sergey Andreev <s.andreev@pixelplex.io>
Co-authored-by: AlexG <39581753+reveloper@users.noreply.github.com>
Co-authored-by: Dr. Awesome Doge <doge@ton.org>

* Fixed code for selling nft on getgems (#691)

* fixed code for selling nft on getgems

* fix first mistake with nanoTon

* added suggestions that tokens come in different decimals

---------

Co-authored-by: vityooook <vityooook@gmail.com>

* feat: add high-load wallet v3 to wallet tutorial (#715)

* Update difference-of-blockchains.md (#716)

The previous link is broken, fix with ton.org pdf

* Add transaction and messages hashes examples (#718)

Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Added message modes cookbook (#724)

Co-authored-by: Vladislav Kokosh <v.kokosh@pixelplex.io>

* Update data about archive node sync timings (#720)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* add Japanese content document translation (#743)

* Transaction outcome description (#708)

* Transaction outcome

Definition of success and some TVM details.

* Upd transaction outcome

* Update message-delivery-guarantees.mdx

* Update tvm-overview.mdx

* Update auditors.mdx

* Additional changes to Msg & Tx page (#744)

* Transaction outcome

Definition of success and some TVM details.

* Upd transaction outcome

* Update message-delivery-guarantees.mdx

* Update tvm-overview.mdx

* Update message-delivery-guarantees.mdx

* Added an example of how to send a transaction with Wallet V5 (#721)

Co-authored-by: Vladislav Kokosh <v.kokosh@pixelplex.io>

* Added actual link to wallet v5 (#725)

Co-authored-by: Vladislav Kokosh <v.kokosh@pixelplex.io>

* feat: upd mytonwallet switch testnet info (#726)

Co-authored-by: igor <i.verhusha@pixelplex.io>

* fix bridge.ton.org link (#727)

and open external links in new page

* Add status output explanation (#728)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>
Co-authored-by: Full-Hat <68519677+Full-Hat@users.noreply.github.com>

* Add information about api keys (#730)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* supplement Korean translation (#731)

Co-authored-by: lotteam003 <lotteam003@proton.me>

* Adding Tatum under RPC Nodes provider (#745)

Adding Tatum under RPC Nodes provider as Tatum provides TON RPC Nodes and whole infrastructure to run Web3 Apps.

* Fix for buttons at academy page (#747)

* Transaction outcome

Definition of success and some TVM details.

* Upd transaction outcome

* Update message-delivery-guarantees.mdx

* Update tvm-overview.mdx

* Update message-delivery-guarantees.mdx

* Update academy-overview.md

Button

* add i18n ja translation (#732)

Co-authored-by: lotteam003 <lotteam003@proton.me>

* Mytonctrl installer (#733)

* Add information about disabling storing archive blocks

* Add explanation to mytonctrl installer section

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* Add information about configs (#734)

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* change link to tonapi rates documentarion (#735)

* Examples (#736)

* Update examples & add -t flag explanation

* Complete examples

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* Fix footer & add guideline (#739)

* fix & udpate footer

* update guides

* complete add footer guide

* update branch doc

* specify function

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* improve transaction processing (#741)

Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Add vue section (#738)

* add vue section

* cut numbers from header

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

* Add testnet.dton.io (#750)

* Add tonpy to TLB parsers and codegen (#749)

* fix jetton sample (#742)

#637

Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* remove numbers (#751)

* Update node-types.md (#748)

* Added tonutils SDK to the Python SDKs section (#740)

* update_bridge_example_link

* Add -c flag explanation in liteserver test node (#670)

* Add -c flag explanation in liteserver test node

* Update links to mytonctrl master

* Update examples & add -t flag explanation

* Add -c flag explanation in liteserver test node

* Update links to mytonctrl master

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* Add .NET ton_proof demo (#723)

* Add information about api keys (#729)

* Add information about api keys

* Remove info about tariffs

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* added translation (#752)

* Update analysis link (#674)

* Update analysis link

* Fix link

* Add eth 2.0 info

* Remove Eth 1.0 & update ton name

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* node-commands_added

* Fixed cases with 16 flag in modes cookbook (#754)

Co-authored-by: Vladislav Kokosh <v.kokosh@pixelplex.io>

* Docu update on MacOS installation and docker image with MyTonCtrl 2.0 (#755)

* update ton installation on MacOS

* update docker with MyTonCtrl 2.0 docu

---------

Co-authored-by: neodiX <neodix42@ton.org>

* cut-ecosystem-sap

* Update governance.md

* lite-client-naming

* Update sign.mdx (#760)

added convenient check if proof valid

* nodes_documentation_fine_update (#762)

* nodes_documentation_fine_update

* added_wallet_deployment_for_each_shard

* added_mintless_jettons

* beauty_fixes

* beauty_fixes_2

* build_fix

* fix_node_reqierements

* node_reqierement_fix.mdx

* fix_node_reqierements_2

* fix_node_reqierements_3

* wallet_v5_caution_cut

* feat: clarified jetton errors information (#771)

Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Add Chainstack as node & indexer provider (#774)

* Update_node_reqierements

* feat: add nodes video (#779)

* Fix transfer example for V5R1 wallet (#778)

https://github.com/ton-blockchain/wallet-contract-v5/blob/88557ebc33047a95207f6e47ac8aadb102dff744/contracts/wallet_v5.fc#L82

Transfer will fail without IGNORE_ERRORS flag with 137 exit code

* feat: add examples with assets sdk for message builders (#667)

* feat: add examples with assets sdk for message builders

* improve assets-sdk examples

* add info about Jetton and NFT Contracts

* feat: add cells information

---------

Co-authored-by: “mlikhar” <m.likhtar@pixelplex.io>
Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Add OP Codes to the docs (#763)

* Transaction outcome

Definition of success and some TVM details.

* Upd transaction outcome

* Update message-delivery-guarantees.mdx

* Update tvm-overview.mdx

* Update message-delivery-guarantees.mdx

* Update academy-overview.md

Button

* op code update

Added known op codes

* Update contracts.md

* Update contracts.md

* Added DEX opcodes

StonFi&DeDust

* Update contracts.md

* add secure guidelines for nodes (#766)

Co-authored-by: AlexG <39581753+reveloper@users.noreply.github.com>

* feat: update Prism.js definitions of Tact and FunC for syntax highlighting (#768)

* feat(prism): update Tact from 1.2.0 to 1.5.0

* feat(prism): update and enhance FunC from 0.2.0 to 0.4.4

* Check ef (#773)

* check_ef description

* update check_ef description & update status info

* update check_ef description (add links to configs)

* update check_ef description (fix typos)

---------

Co-authored-by: Full-Hat <nikita3131228@gmail.com>

* Minor corrections (#780)

* Transaction outcome

Definition of success and some TVM details.

* Upd transaction outcome

* Update message-delivery-guarantees.mdx

* Update tvm-overview.mdx

* Update message-delivery-guarantees.mdx

* Update academy-overview.md

Button

* op code update

Added known op codes

* Update contracts.md

* Update contracts.md

* Added DEX opcodes

StonFi&DeDust

* Update contracts.md

* Add serokell

* Refatored page about node types (#769)

* Update cookbook.md (#777)

Fixed

* React doc wrappers (#673)

* improve react doc

* chore: add wrappers examples for react doc

* add more info about react

* add info about contract deploy

* remove protocol pages from doc, improve react doc

---------

Co-authored-by: “mlikhar” <m.likhtar@pixelplex.io>
Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>

* Update custom-overlays.md

* shard-optimization-guidelines-added

* fix_address_format.mdx

* rework documentation with guidelines in first iterartion

* feat: update docusaurus version

* feat: divide sidebars

* feat: divide sidebars

* add husky and cspell for grammar check

* fix docs/develop/howto/step-by-step.mdx

* fix some spelling

* fix: fix husky

* feat: reorganize learn sidebar

* nodes section renewal

* refactor TON Node Command-Line Flags

* feat: extract navbar

* feat: update navbar

* aws_node_req_update.mdx

* Update full-node.mdx

* Update full-node.mdx

* feat: add contribute link

* add redirect script

* Add smart contracts specs (#6)

* refactor wallets page

* fix highload ref

---------

Co-authored-by: Gleb Karavatski <g.karavatski@pixelplex.io>

* feat: improve difference in the naming

* feat: improve concepts

* feat: remove web3 from upper bar

* feat: move wallets

* feat: rename mytonctrl

* feat: add guidelines

* feat: fix assets

* fix: fix move script

* feat: move page

* feat: move page

* feat: move page

* feat: move concepts files

* feat: move part of guidelines

* feat: add dapps guidelines

* feat: move guidelines

* feat: move part of docs

* feat: move part of docs

* feat: move part of docs

* feat: move part of docs

* feat: move part of docs

* feat: move part of docs

* feat: move part of docs

* feat: move contribute

* feat: remove absent pages and setup redirects

* feat: link part of pages

* feat: link part of pages

* feat: link part of pages

* feat: link part of pages

* feat: link part of pages

* feat: link part of pages

* feat: link part of pages

* feat: remove search

* devide nominator pools article into docs + guidelines

* add docs/guidelines reflinks

* feat: proof read

* update footer

* fix doc build

---------

Co-authored-by: sansx <646924078@qq.com>
Co-authored-by: TonSquare <147710825+TonSquare@users.noreply.github.com>
Co-authored-by: sansx <xiathxth@gmail.com>
Co-authored-by: Full-Hat <nikita3131228@gmail.com>
Co-authored-by: “mlikhar” <m.likhtar@pixelplex.io>
Co-authored-by: AlexG <39581753+reveloper@users.noreply.github.com>
Co-authored-by: Antonoff <35700168+memearchivarius@users.noreply.github.com>
Co-authored-by: p.nazarychev <pavel.nazarychev@copper.co>
Co-authored-by: Airam G <169088121+AiramGol@users.noreply.github.com>
Co-authored-by: Vladislav Kokosh <v.kokosh@pixelplex.io>
Co-authored-by: Oleg Baranov <xssnick8@gmail.com>
Co-authored-by: Anthony Tsivarev <tsivarev.a@gmail.com>
Co-authored-by: omahs <73983677+omahs@users.noreply.github.com>
Co-authored-by: 70sh1 <70sh1@proton.me>
Co-authored-by: igor <i.verhusha@pixelplex.io>
Co-authored-by: Maksim Kurbatov <94808996+yungwine@users.noreply.github.com>
Co-authored-by: Ginta <775650117@qq.com>
Co-authored-by: PixelPlex Dev team <10460630+pixelplex@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: infinityspectra <149141428+infinityspectra@users.noreply.github.com>
Co-authored-by: NakeyJakey <jimip6c12@gmail.com>
Co-authored-by: Aliaksandr Bahdanau <a.bahdanau@pixelplex.io>
Co-authored-by: Devin <studyzy@gmail.com>
Co-authored-by: Duginets Nikita <duginetsn98@gmail.com>
Co-authored-by: Roman <krutovoyroman@gmail.com>
Co-authored-by: Sergey Andreev <s.andreev@pixelplex.io>
Co-authored-by: Dr. Awesome Doge <doge@ton.org>
Co-authored-by: Victor <129557549+vityooook@users.noreply.github.com>
Co-authored-by: vityooook <vityooook@gmail.com>
Co-authored-by: aSpite <45543119+aSpite@users.noreply.github.com>
Co-authored-by: zhangchitc <95238503+zhangchitc@users.noreply.github.com>
Co-authored-by: SilentPine <SilentPine@proton.me>
Co-authored-by: spookyahell <9724215+spookyahell@users.noreply.github.com>
Co-authored-by: Full-Hat <68519677+Full-Hat@users.noreply.github.com>
Co-authored-by: lotteam003 <Kafkaesqt@proton.me>
Co-authored-by: lotteam003 <lotteam003@proton.me>
Co-authored-by: blockchaingirl1407 <142514003+blockchaingirl1407@users.noreply.github.com>
Co-authored-by: Moiseev Ilya <ilya@mois.pro>
Co-authored-by: Andrey Tvorozhkov <tvorog@tvorog.me>
Co-authored-by: Artem <79601745+Sovenok-Hacker@users.noreply.github.com>
Co-authored-by: Shon Ness <78713403+nessshon@users.noreply.github.com>
Co-authored-by: Alexander <Seviant88@gmail.com>
Co-authored-by: StarryHazex <StarryHaze@proton.me>
Co-authored-by: neodix42 <namlem@gmail.com>
Co-authored-by: neodiX <neodix42@ton.org>
Co-authored-by: EmelyanenkoK <emelyanenko.kirill@gmail.com>
Co-authored-by: JeanClaude (JC) <Jeanclaude.aoun@hotmail.com>
Co-authored-by: Ake <10195782+akegaviar@users.noreply.github.com>
Co-authored-by: Aliaksandr Bahdanau <122269567+a-bahdanau@users.noreply.github.com>
Co-authored-by: Max Voloshinskii <me@voloshinskii.com>
Co-authored-by: Novus Nota <68142933+novusnota@users.noreply.github.com>
Co-authored-by: Pavel Nazarychev <73617204+fmira21@users.noreply.github.com>
Co-authored-by: yycceth <zhichunqi93@gmail.com>
Co-authored-by: Gleb Karavatski <g.karavatski@pixelplex.io>
  • Loading branch information
@gleb498 @sansx
@TonSquare @Full-Hat @mlikhtar @reveloper @memearchivarius @fmira21 @AiramGol @vkokosh @xssnick @tsivarev @omahs @70sh1 @IVerhusha @yungwine @mar-heaven @pixelplex @github-actions @infinityspectra @Jimsparkle @a-bahdanau @studyzy @glcanvas @SwiftAdviser @awesome-doge @vityooook @aSpite @zhangchitc @SilentPine @spookyahell @lotteam003 @blockchaingirl1407 @mois-ilya @tvorogme @Sovenok-Hacker @nessshon @WinoGarcia @StarryHazex @neodix42 @EmelyanenkoK @Jeanclaudeaoun @akegaviar @voloshinskii @novusnota @yycceth @gkaravatski
55 people authored Oct 28, 2024
1 parent ab84624 commit 3eb4d4c
Show file tree
Hide file tree
Showing 3 changed files with 225 additions and 5 deletions.
2 changes: 1 addition & 1 deletion docs/v3/documentation/tvm/tvm-overview.mdx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ RU
When some event happens on the account in one of the TON chains, it causes a **transaction**. The most common event is the "arrival of some message", but generally speaking there could be `tick-tock`, `merge`, `split` and other events.

Each transaction consists of up to 5 phases:
1. **Storage phase** - in this phase, storage fees accumulated by the contract due to the occupation of some space in the chain state are calculated. Read more in [Storage Fees](/v3/documentation/smart-contracts/transaction-fees/fees#storage-fee).
1. **Storage phase** - in this phase, storage fees accumulated by the contract due to the occupation of some space in the chain state are calculated. Read more in [Storage Fees](/v3/documentation/smart-contracts/transaction-fees/fees-low-level#storage-fee).
2. **Credit phase** - in this phase, the balance of the contract with respect to a (possible) incoming message value and collected storage fee are calculated.
3. **Compute phase** - in this phase, TVM is executing the contract (see below) and the result of the contract execution is an aggregation of `exit_code`, `actions` (serialized list of actions), `gas_details`, `new_storage` and some others.
4. **Action phase** - if the compute phase was successful, in this phase, `actions` from the compute phase are processed. In particular, actions may include sending messages, updating the smart contract code, updating the libraries, etc. Note that some actions may fail during processing (for instance, if we try to send message with more TON than the contract has), in that case the whole transaction may revert or this action may be skipped (it depends on the mode of the actions, in other words, the contract may send a `send-or-revert` or `try-send-if-no-ignore` type of message).
Expand Down
224 changes: 224 additions & 0 deletions docs/v3/learn/addresses.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,224 @@
# Smart Contract Addresses

This section will describe the specifics of smart contract addresses on TON Blockchain. It will also explain how actors are synonymous with smart contracts on TON.

## Everything is a Smart Contract

On TON, smart contracts are built using the [Actor model](/learn/overviews/ton-blockchain#single-actor). In fact, actors in TON are technically represented as smart contracts. This means that even your wallet is a simple actor (and a smart contract).

Typically, actors process incoming messages, change their internal state, and generate outbound messages as a result. That's why every actor (i.e., smart contract) on TON Blockchain must have an address, so it is able to receive messages from other actors.

:::info EVM EXPERIENCE
On the Ethereum Virtual Machine (EVM), addresses are completely separate from smart contracts. Feel free to learn more about the differences by reading our article ["Six unique aspects of TON Blockchain that will surprise Solidity developers"](https://blog.ton.org/six-unique-aspects-of-ton-blockchain-that-will-surprise-solidity-developers) by Tal Kol.
:::

## Address of Smart Contract

Smart contract addresses operating on TON typically consist of two main components:

* **(workchain_id)**: denotes the workchain ID (a signed 32-bit integer)

* **(account_id)** denotes the address of the account (64-512 bits, depending on the workchain)

In the raw address overview section of this documentation, we'll discuss how **(workchain_id, account_id)** pairs present themselves.

### Workchain ID and Account ID

#### Workchain ID

[As we've seen before](/learn/overviews/ton-blockchain#workchain-blockchain-with-your-own-rules), it is possible to create as many as `2^32` workchains operating on TON Blockchain. We also noted how 32-bit prefix smart contract addresses identify and are linked to smart contract addresses within different workchains. This allows smart contracts to send and receive messages to and from different workchains on TON Blockchain.

Nowadays, only the Masterchain (workchain_id=-1) and occasionally the basic workchain (workchain_id=0) are running in TON Blockchain.

Both of them have 256-bit addresses, therefore, we assume that the workchain_id is either 0 or -1, and the address within the workchain is precisely 256 bits.

#### Account ID

All account IDs on TON make use of 256-bit addresses on the Masterchain and Basechain (or basic workchain).

In fact, Account ID’s **(account_id)** defined as hash functions for smart contract objects (particular, the SHA-256). Every smart contract operating on TON Blockchain stores two main components. These include:

1. _Compiled code_. Logic of the smart contract compiled in the form of bytecode.
2. _Initial state_. The contract's values at the moment of its deployment on-chain.


Finally, to accurately derive the contract's address, it is necessary to calculate the hash corresponding to the pair **(Initial code, Initial state)** object. At this time, we won't take a deep dive into how the [TVM](/learn/tvm-instructions/tvm-overview) works, but it's important to understand that account IDs on TON are determined using this formula:
:
**account_id = hash(initial code, initial state)**

In time, throughout this documentation, we'll dive deeper into the technical specifications and overview of the TVM and TL-B scheme. Now that we are familiar with the generation of the **account_id** and their interaction with smart contract addresses on TON, let’s explain Raw and User-Friendly addresses.

## Addresses state

Each address can be in one of possible states:

- `nonexist` - there were no accepted transactions on this address, so it doesn't have any data (or the contract was deleted). We can say that initially all 2<sup>256</sup> address are in this state.
- `uninit` - address has some data, which contains balance and meta info. At this state address doesn't have any smart contract code/persistent data yet. An address enters this state, for example, when it was nonexist and some other address sent some tokens to it.
- `active` - address has smart contract code, persistent data and balance. At this state it can perform some logic during the transaction and change its persistent data. An address enters this state when it was `uninit` and there was an incoming message with state_init param (note, that to be able to deploy this address, hash of `state_init` and `code` must be equal to address).
- `frozen` - address cannot perform any operations, this state contains only two hashes of the previous state (code and state cells respectively). When an address's storage charge exceeds its balance, it goes into this state. To unfreeze it, you can send an internal message with `state_init` and `code` which store the hashes described earlier and some Toncoin. It can be difficult to recover it, so you should not allow this situation. There is a project to unfreeze the address, which you can find [here](https://unfreezer.ton.org/).

## Raw and User-Friendly Addresses

After providing a brief overview of how smart contract addresses on TON leverage workchains and account IDs (for the Masterchain and Basechain specifically), it is important to understand that these addresses are expressed in two main formats:

* **Raw addresses**: Original full representation of smart contract addresses.
* **User-friendly addresses**: User-friendly addresses are an enhanced format of raw address that employ better security and ease of use.

Below, we’ll explain more about the differences between these two address types and dive deeper into why user-friendly addresses are used on TON.

### Raw address

Raw smart contract addresses consist of a workchain ID and account ID *(workchain_id, account_id)* and are displayed in the following format:

* [decimal workchain_id\]:[64 hexadecimal digits with account_id\]


Provided below, is an example of a raw smart contract address using a workchain ID and account ID together (expressed as **workchain_id** and **account_id**):

`-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260`

Notice the `-1` at the start of the address string, which denotes a _workchain_id_ that belongs to the Masterchain.

:::note
Uppercase letters (such as 'A', ‘B’, ‘C’, ‘D’ etc.) may be used in address strings instead of their lower-case counterparts (such as 'a', ‘b’, ’c’ 'd' etc.).
:::

#### Issues With Raw Addresses

Using the Raw Address form presents two main issues:

1. When using the raw address format, it's not possible to verify addresses to eliminate errors prior to sending a transaction.
This means that if you accidentally add or remove characters in the address string prior to sending the transaction, your transaction will be sent to the wrong destination, resulting in loss of funds.
2. When using the raw address format, it's impossible to add special flags like those used when sending transactions that employ user-friendly addresses.
To help you better understand this concept, we’ll explain which flags can be used below.

### User-Friendly Address

User-friendly addresses were developed to secure and simplify the experience for TON users who share addresses on the internet (for example, on public messaging platforms or via their email service providers), as well as in the real world.

#### User-Friendly Address Structure

User-friendly addresses are made up of 36 bytes in total and are obtained by generating the following components in order:

1. _[flags - 1 byte]_ — Flags that are pinned to addresses change the way smart contracts react to the received message.
Flags types that employ the user-friendly address format include:

- isBounceable. Denotes a bounceable or non-bounceable address type. (_0x11_ for "bounceable", _0x51_ for "non-bounceable")
- isTestnetOnly. Denotes an address type used for testnet purposes only. Addresses beginning with _0x80_ should not be accepted by software running on the production network
- isUrlSafe. Denotes a deprecated flag that is defined as URL-safe for an address. All addresses are then considered URL-safe.
2. _\[workchain_id - 1 byte]_ — The workchain ID (_workchain_id_) is defined by a signed 8-bit integer _workchain_id_.
(_0x00_ for the BaseChain, _0xff_ for the MasterChain)
3. _\[account_id - 32 byte]_ — The account ID is made up of a ([big-endian](https://www.freecodecamp.org/news/what-is-endianness-big-endian-vs-little-endian/)) 256-bit address in the workchain.
4. _\[address verification - 2 bytes]_ — In user-friendly addresses, address verification is composed of a CRC16-CCITT signature from the previous 34 bytes. ([Example](https://github.com/andreypfau/ton-kotlin/blob/ce9595ec9e2ad0eb311351c8a270ef1bd2f4363e/ton-kotlin-crypto/common/src/crc32.kt))
In fact, the idea pertaining to verification for user-friendly addresses is quite similar to the [Luhn algorithm](https://en.wikipedia.org/wiki/Luhn_algorithm), which is used on all credit cards to prevent users from entering non-existing card numbers by mistake.

The addition of these 4 main components means that: `1 + 1 + 32 + 2 = 36` bytes in total (per user-friendly address).

To generate a user-friendly address, the developer must encode all 36 bytes using either:
- _base64_ (i.e., with digits, upper and lowercase Latin letters, '/' and '+')
- _base64url_ (with '_' and '-' instead of '/' and '+')

After this process is complete, the generation of a user-friendly address with a length of 48 non-spaced characters is finalized.

:::info DNS ADDRESS FLAGS
On TON, DNS addresses such as mywallet.ton are sometimes used instead of raw and user-friendly addresses. In fact, DNS addresses are made up of user-friendly addresses and include all the required flags that allow developers to access all the flags from the DNS record within the TON domain.
:::

#### User-Friendly Address Encoding Examples

For example, the "test giver" smart contract (a special smart contract residing in the testnet masterchain that sends 2 test tokens to anyone who requests them) makes use of the following raw address:

`-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260`

The above "test giver" raw address must be converted into the user-friendly address form. This is obtained using either the base64 or base64url forms (that we introduced previously) as follows:

* `kf/8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15+KsQHFLbKSMiYIny` (base64)
* `kf_8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15-KsQHFLbKSMiYIny` (base64url)

:::info
Notice that both forms (_base64_ and _base64url_) are valid and must be accepted!
:::

#### Bounceable vs Non-Bounceable Addresses

The core idea behind the bounceable address flag is sender's funds security.

For example, if the destination smart contract does not exist, or if some issue happens during the transaction, the message will be "bounced" back to the sender and constitute the remainder of the original value of the transaction (minus all transfer and gas fees). This ensures the sender doesn't lose their funds that were sent by accident to an address that cannot accept the transaction.

In relation to bounceable addresses specifically:

1. The **bounceable=false** flag generally means the receiver is a wallet.
2. The **bounceable=true** flag typically denotes a custom smart contract with its own application logic (for example, a DEX). In this example, non-bounceable messages should not be sent because of security reasons.

Feel free to read more on this topic in our documentation to gain a better understanding of [non-bounceable messages](/develop/smart-contracts/guidelines/non-bouncable-messages).

#### Armored base64 Representations

Additional binary data related to TON Blockchain employs similar "armored" base64 user-friendly address representations. These differentiate from one another depending on the first 4 characters of their byte tag. For example, 256-bit Ed25519 public keys are represented by first creating a 36-byte sequence using the below process in order:

- A single byte tag using the _0x3E_ format denotes a public key
- A single byte tag using the _0xE6_ format denotes a Ed25519 public key
- 32 bytes containing the standard binary representation of the Ed25519 public key
- 2 bytes containing the big-endian representation of CRC16-CCITT of the previous 34 bytes


The resulting 36-byte sequence is converted into a 48-character base64 or base64url string in the standard fashion. For example, the Ed25519 public key `E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D` (usually represented by a sequence of 32 bytes such as: `0xE3, 0x9E, ..., 0x7D`) presents itself through the "armored" representation as follows:

`Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2`


### Converting User-Friendly Addresses and Raw Addresses

The simplest way to convert user-friendly and raw addresses is to use one of several TON APIs and other tools, including:

* [ton.org/address](https://ton.org/address)
* [dton.io API method](https://dton.io/api/address/0:867ac2b47d1955de6c8e23f57994fad507ea3bcfe2a7d76ff38f29ec46729627)
* [toncenter API methods in mainnet](https://toncenter.com/api/v2/#/accounts/pack_address_packAddress_get)
* [toncenter API methods in testnet](https://testnet.toncenter.com/api/v2/#/accounts/pack_address_packAddress_get)

Additionally, there are two ways to convert user-friendly and raw addresses for wallets using JavaScript:

* [Convert address from/to user-friendly or raw form using ton.js](https://github.com/ton-org/ton-core/blob/main/src/address/Address.spec.ts)
* [Convert address from/to user-friendly or raw form using tonweb](https://github.com/toncenter/tonweb/tree/master/src/utils#address-class)

It's also possible to make use of similar mechanisms using [SDKs](/develop/dapps/apis/sdk).

### Address Examples

Learn more examples on TON Addresses in the [TON Cookbook](/develop/dapps/cookbook#working-with-contracts-addresses).

## Possible problems

When interacting with the TON blockchain, it's crucial to understand the implications of transferring TON coins to `uninit` wallet addresses. This section outlines the various scenarios and their outcomes to provide clarity on how such transactions are handled.

### What happens when you transfer Toncoin to an uninit address?

#### Transaction with `state_init` included

If you include the `state_init` (which consists of the wallet or smart contract's code and data) with your transaction. The smart contract is deployed first using the provided `state_init`. After deployment, the incoming message is processed, similar to sending to an already initialized account.

#### Transaction without `state_init` and `bounce` flag set

The message cannot be delivered to the `uninit` smart contract, and it will be bounced back to the sender. After deducting the consumed gas fees, the remaining amount is returned to the sender's address.

#### Transaction without `state_init` and `bounce` flag unset

The message cannot be delivered, but it will not bounce back to the sender. Instead, the sent amount will be credited to the receiving address, increasing its balance even though the wallet is not yet initialized. They will be stored there until the address holder deploys a smart wallet contract and then they can access the balance.

#### How to do it right

The best way to deploy a wallet is to send some TON to its address (which is not yet initialized) with the `bounce` flag cleared. After this step, the owner can deploy and initialize the wallet using funds at the current uninitialized address. This step usually occurs on the first wallet operation.

### The TON blockchain implements protection against erroneous transactions

In the TON blockchain, standard wallets and apps automatically manage the complexities of transactions to uninitialized addresses by using bounceable and non-bounceable address, which are described [here](#bounceable-vs-non-bounceable-addresses). It is common practice for wallets, when sending coins to non-initialized addresses, to send coins to both bounceable and non-bounceable addresses without return.

If there is a need to quickly get an address in bounceable/non-bounceable form this can be done [here](https://ton.org/address/).

### Responsibility for custom products

If you are developing a custom product on the TON blockchain, it is essential to implement similar checks and logic:

Ensure your application verifies whether the recipient address is initialized before sending funds.
Based on the address state, use bounceable addresses for user smart contracts with custom application logic to ensure funds are returned. Use non-bounceable addresses for wallets.

4 changes: 0 additions & 4 deletions redirects/redirects.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -791,10 +791,6 @@
"from": "/develop/smart-contracts/fee-calculation",
"to": "/v3/guidelines/smart-contracts/fee-calculation"
},
{
"from": "/develop/smart-contracts/testing",
"to": "/v3/guidelines/smart-contracts/testing"
},
{
"from": "/develop/smart-contracts/testing/writing-test-examples",
"to": "/v3/guidelines/smart-contracts/testing/writing-test-examples"
Expand Down

0 comments on commit 3eb4d4c

Please sign in to comment.