Merge pull request #35 from howardpen9/patch-1

README.md

@@ -13,7 +13,7 @@ Each state has the contract code and data.
 The contract data can be complex, but developers typically provide [get-methods](https://ton.org/docs/develop/func/functions#specifiers) in the contract, which can be executed to retrieve the necessary data.
 The TON has standard contracts (such as [TEP-62](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md), [TEP-74](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md)), and they have predefined get-method names. 
 Therefore, you can attempt to match accounts found in the network to these standards by checking the presence of the get-methods.
-Contract standards also specify [TL-B constructor tags](https://ton.org/docs/learn/overviews/tl-b-language#constructors) (or operation ids) for each acceptable message to contract, defined as the first 32 bits of the parsed message payload cell.
+Contract standards also specify [TL-B constructor tags](https://docs.ton.org/develop/data-formats/tl-b-language#constructors) (or operation ids) for each acceptable message to contract, defined as the first 32 bits of the parsed message payload cell.
 So you if you know standard of a given contract, you can determine the type of message to it (for example, NFT item transfer) by parsing the first 32 bits of message body. 
 
 Anton allows you to define the contract interface in just one JSON schema.