address update proposal #123

tolya-yanot · 2023-06-13T12:26:29Z

Proposal that will prevent the loss of user funds in case of erroneous sending

TON is a blockchain for massadoption, so we propose a number of guidelines and small changes in the address format,
so that even if the inexperienced user is inattentive and sends funds to the wrong place, the funds were not lost and bounced back to him in most cases.

This proposal describes changes that almost do not break backward compatibility. However, at the same time we can discuss other proposals, including more radical ones.

Examples of cases where a user can lose funds:

The user copied the address in the testnet service, but mistakenly interacts with it or sends coins to it from the mainnet wallet app.

Since there will be no such address in the mainnet, the wallet app will now set the non-bounceable mode and send coins that will remain at the destination address and will be lost
Let's imagine a smart contract for the sale of NFT (for example, belonging to some marketplace), after receiving Toncoins from the buyer, this contract sends NFT to the buyer and destroy itself, because its mission is completed.

However, the UI may not be updated immediately and another user may send Toncoins for purchase to this contract address. Since the contract will no longer exist, the wallet app will set non-bounceable mode and Toncoins will remain forever at the destination address and will be lost.

At the moment, most marketplaces bypass this by not destroying the sale smart contract.
The smart contract of the service (e.g. DEX) has not been deployed yet, but the user has already sent coins there, the wallet app will set non-bounceable mode and Toncoins will remain forever at the destination address and will be lost.

Suggested behaviour:

All TON apps and services must show addresses with a testnet flag set if they are on a testnet network.
All TON apps and services should reject addresses with a testnet flag set if they are on a mainnet network.
For example, mainnet wallets should not allow sending coins to a testnet address in any way.
User apps and services should only accept addresses in user-friendly format and not accept addresses in raw format.
All services must only display and accept urlsafe format, and not operate with non-urlsafe form.
All wallets should show non-bounceable addresses.
All other smart contracts should always show in bounceable form.
The creators of such smart contracts (for example, DEXes) must first deploy such smart contracts themselves in order for the bounceable form of the address to be applicable.
bounceable flag from address representation should now be taken as "force-bounceable".

When sending, wallets must accept this flag as follows:

if true - all messages to this address can ONLY be sent in bounceable mode, even if the destination contract has an uninitialized state.

if false - means that a non-bounceable message can be sent to the destination address.
The wallet app checks the destination address - if it has an uninitialized state, then it sends a non-bounceable message, otherwise it sends a bounceable message.

Since only wallets will use the non-bounceable form, it will also be possible to distinguish the wallet from the service smart contract using this flag.

Migration Plan

Since there are already many services and applications in the TON network, it makes sense to carry out the migration in stages:

All popular services must apply a testnet flag to the addresses on their testnet versions.
All popular wallets and services (such DEX'es or NFT marketplaces) must reject destination testnet addresses in mainnet.
All popular services must not display and accept "raw" address form and non-urlsafe form.
All popular wallets must show user's address in non-bounceable form.

This modifies only the leading and last characters of the address, while the body of the address remains the same.

However, changing the address may confuse some users, so advance warning and explanation in public channels is needed.
All popular exchanges and services must show deposit addresses in non-bounceable form.
All popular exchanges should not allow withdrawals to non-wallet addresses (to non-bounceable addresses).
After that all popular wallets must implement new bounceable flag algo.

Suggested behaviour of TON DNS:

The DNS recode scheme assumed a cap_is_wallet flag (which allow to send non-bounceable messages).

cap_method_seqno#5371 = SmcCapability;
cap_method_pubkey#71f4 = SmcCapability;
cap_is_wallet#2177 = SmcCapability;
cap_name#ff name:Text = SmcCapability;


cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;

dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
  cap_list:flags . 0?SmcCapList = DNSRecord;

However, this flag was not widely used and applied in practice.

Based on the fact that DNS names are mainly used for user wallets and to a much lesser extent for service addresses, we propose to introduce the flag

cap_only_bounceable

which will mean that non-bounceable message should never be sent to this address.

DNS records of addresses of existing services can be updated, because this is in the interests of the services themselves.

Suggested behaviour of TON Connect

TON Connect methods (such as sendTransaction) must accept a domain or address in user-friendly form as the destination address, and not accept the raw form.

A dapp that calls such a method either received this address from the user, or knows the type of smart contract (for example, it sends a transaction to the DEX smart contract, which means bounceable form).

tvorogme · 2023-06-13T12:52:09Z

I would vote to either wait for other options or take some time. I don't like that flags use the first bits of addresses and users don't have a single address option with which they could define their transactions in any service without buying a domain (although the rules for displaying domain instead of address are not defined).

Since only wallets will use the non-bounceable form

Probably still add explorers?

mr-tron · 2023-06-13T12:53:16Z

Suggested behaviour:
0. All libraries, services and wallets should support DNS. tolya.ton should be first class entity with same support level as EQCdqXGvONLwOr3zCNX5FjapflorB6ZsOdcdfLrjsDLt3Fy9.

Osasv · 2023-06-13T15:15:12Z

UQBtIj4QE6xT2gmUtfmT5xp9CDVOvCuIcj2w3bvRsZT_55Rk

BeyCoder · 2023-06-13T17:05:10Z

Suggested behaviour:
0. All libraries, services and wallets should support DNS. tolya.ton should be first class entity with same support level as EQCdqXGvONLwOr3zCNX5FjapflorB6ZsOdcdfLrjsDLt3Fy9.

up

oleganza · 2023-09-04T11:20:27Z

I agree with @mr-tron that TON.DNS support should be a requirement for all TON services.

Also I suggest rewriting a bit this TEP to put the migration plan up front and all the technical discussion below.

Plus, let's add some realistic deadline and prepare network-wide communication to make all the users familiar with the change, so they are not surprised when the addresses switch from EQ... to UQ... Those who look at the last 3-4 characters of the address will be surprised because the checksum will change. We need to make sure people don't feel like that may lose money if someone continues to use their old-style address.

mr-tron · 2023-09-04T15:41:59Z

we are already working on supporting dns as first class address form. tongo library implemented it today. ton-kotlin promised to do it in the nearest future. tonutils-go author promised to think how it can be done. I hope over libraries developers will join to our small initiative. You can contact me in telegram @subden for any questions.

Osasv · 2023-09-04T16:05:01Z

Alright

…

On Tue, Jun 13, 2023 at 1:05 PM Beybut Abdulragimov < ***@***.***> wrote: Suggested behaviour: 0. All libraries, services and wallets should support DNS. tolya.ton should be first class entity with same support level as EQCdqXGvONLwOr3zCNX5FjapflorB6ZsOdcdfLrjsDLt3Fy9. up — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A73LUSVVLRI4TRD6S4ERLJTXLCMVFANCNFSM6AAAAAAZEZCSKA> . You are receiving this because you commented.Message ID: ***@***.***>

Osasv · 2023-09-04T16:06:53Z

Okay I will contact you shortly

…

On Mon, Sep 4, 2023 at 11:42 AM Denis Subbotin ***@***.***> wrote: we are already working on supporting dns as first class address form. tongo library implemented it today. ton-kotlin promised to do it in the nearest future. tonutils-go author promised to think how it can be done. I hope over libraries developers will join to our small initiative. You can contact me in telegram @subden for any questions. — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A73LUSX7LKHG54QOF6XDTA3XYXZFDANCNFSM6AAAAAAZEZCSKA> . You are receiving this because you commented.Message ID: ***@***.***>

slavafomin · 2023-10-04T13:49:42Z

Hello!

All services must only display and accept urlsafe format, and not operate with non-urlsafe form.

@tolya-yanot could you please elaborate on what's wrong with accepting the url-unsafe format of the address (just for backward-compatibility purposes)?

slavafomin · 2023-10-04T15:41:30Z

@tolya-yanot

only wallets will use the non-bounceable form

…

All popular exchanges should not allow withdrawals to non-wallet addresses (to non-bounceable addresses).

There must be a mistake here. Shouldn't it be:

All popular exchanges should not allow withdrawals to non-wallet addresses (i.e. to bounceable addresses).

?

Alferid1 · 2024-05-24T19:51:39Z

How can i.merge ..?

Tamkin44 · 2024-06-06T14:56:04Z

UQBM8_B71xv91aBGx7qSdauVyU0SqlrMQ9Ctd7b2XJ9eUS0G

Tamkin44 · 2024-06-06T14:56:11Z

UQBM8_B71xv91aBGx7qSdauVyU0SqlrMQ9Ctd7b2XJ9eUS0G

Poer1008

Poer168

Malikgousi · 2024-06-28T20:14:06Z

New address

Rohan1363m · 2024-07-16T02:13:20Z

Hi is this true without knowing the account of a large amount of Coins and Tons Coins were withdrawn from notcoin the Tonkiper wallet
UQC6P_IPXqi0fVw2F7uknJIBRgVVyCHzxa88lddDSS1iw2S-

Rohan1363m · 2024-07-16T02:13:20Z

Hi is this true without knowing the account of a large amount of Loton Coins and Tons Coins were withdrawn from the Tonkiparm wallet Hi, is it true to withdraw a large amount of Knotcoin and Toon Coin from the Toonkiparm wallet without knowing the account? UQC6P_IPXqi0fVw2F7uknJIBRgVVyCHzxa88lddDSS1iw2S-

Yosofmb · 2024-07-16T02:18:59Z

Ymb1104202

…

---------- Forwarded message --------- فرستنده: Rohan1363m ***@***.***> ‪Date: سه‌شنبه ۱۶ ژوئیه ۲۰۲۴، ۵:۴۳‬ Subject: Re: [ton-blockchain/TEPs] address update proposal (PR #123) To: ton-blockchain/TEPs ***@***.***> Cc: Yosofmb ***@***.***>, Manual < ***@***.***> Hi is this true without knowing the account of a large amount of Loton Coins and Tons Coins were withdrawn from the Tonkiparm wallet Hi, is it true to withdraw a large amount of Knotcoin and Toon Coin from the Toonkiparm wallet without knowing the account? — Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJRX4GJH6P7LN4RBEJJA6E3ZMR6VPAVCNFSM6AAAAAAZEZCSKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRZHA3DSNZTGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Rohan1363m · 2024-07-16T04:29:34Z

I have updated it, but there is no news about Coinham and Ton-Coinham

Rohan1363m · 2024-07-18T15:52:47Z

I didn't send any currency to anyone, I don't even know what happened to my tokens.

Rohan1363m · 2024-07-19T03:42:53Z

Hi is this true without knowing the account of }xa88lddDSS1iw2S-

OKE66

EQD5mxRgCuRNLxKxeOjG6r14iSroLF5FtomPnet-sgP5xNJb

Lexa77Q · 2024-08-22T23:54:33Z

👍

OKE66

Alex UQC2RRBsgX-BPlrJjJgX2ZObVUlY0e67Fl0JGszCc5DcxBBT

Lexa77Q

I'm

OKE66

Alex

Danyalkasiri

Danyalkasiri · 2024-08-23T21:13:42Z

text/0002-address.md


-5) If destination is not `unitialized` then wallet app uses the bounceable/non-bounceable flag from the address representation for the `bounce` field of sending message.
+   The wallet app checks the destination address - if it has an `uninitialized` state, then it sends a non-bounceable message, otherwise it sends a bounceable message.

 ## Public keys


text/0002-address.md

S5GBV4VFFSVSW6VVFYBEAEVTNYCM6ZVP

Danyalkasiri · 2024-08-23T21:15:36Z

_
تکراری از #_

Nopandi1101

cap_method_seqno#5371 = SmcCapability;
cap_method_pubkey#71f4 = SmcCapability;
cap_is_wallet#2177 = SmcCapability;
cap_name#ff name:Text = SmcCapability;

cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;

dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
cap_list:flags . 0?SmcCapList = DNSRecord;

Nopandi1101

UQC53Sk3lkCm0E7kSejCsBk8z9f_Yf4ndp-MNNUjRhG5O0KV

text/0002-address.md

Nopandi1101

0xF1CA31083E0c073779C8D5ACA3F1bB3b4CBB558B

OKE66

0002-address.md

Nopandi1101

cap_method_seqno#5371 = SmcCapability;
cap_method_pubkey#71f4 = SmcCapability;
cap_is_wallet#2177 = SmcCapability;
cap_name#ff name:Text = SmcCapability;

cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;

dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
cap_list:flags . 0?SmcCapList = DNSRecord;

Euomen888

Nice

address update proposal

1b1729e

romanzaycev mentioned this pull request Oct 11, 2023

Address reform support olifanton/interop#3

Closed

t3pot mentioned this pull request Oct 19, 2023

New address format UQ vs. old format EQ ton-blockchain/locker-contract#7

Open

inozemtsev-roman mentioned this pull request Nov 3, 2023

Migration flag EQ-UQ TEPs 123 TON-NFT/custon#1

Open

ARRO88BLAZIN approved these changes Jun 2, 2024

View reviewed changes

Nikolay211 approved these changes Jun 15, 2024

View reviewed changes

Poer1008 reviewed Jun 28, 2024

View reviewed changes

shyrybovich222 mentioned this pull request Jul 18, 2024

I have updated it, but there is no news about Coinham and Ton-Coinham Uniswap/token-lists#690

Open

shyrybovich222 mentioned this pull request Jul 26, 2024

New address #178

Closed

address update proposal #123

Are you sure you want to change the base?

address update proposal #123

Conversation

tolya-yanot commented Jun 13, 2023

Proposal that will prevent the loss of user funds in case of erroneous sending

Migration Plan

Suggested behaviour of TON DNS:

Suggested behaviour of TON Connect

tvorogme commented Jun 13, 2023 • edited Loading

mr-tron commented Jun 13, 2023

Osasv commented Jun 13, 2023

BeyCoder commented Jun 13, 2023

oleganza commented Sep 4, 2023 • edited Loading

mr-tron commented Sep 4, 2023

Osasv commented Sep 4, 2023 via email

Osasv commented Sep 4, 2023 via email

slavafomin commented Oct 4, 2023

slavafomin commented Oct 4, 2023 • edited Loading

Alferid1 commented May 24, 2024

Tamkin44 commented Jun 6, 2024

Tamkin44 commented Jun 6, 2024

Poer1008 left a comment

Choose a reason for hiding this comment

Malikgousi commented Jun 28, 2024

Rohan1363m commented Jul 16, 2024 • edited Loading

Rohan1363m commented Jul 16, 2024 • edited Loading

Yosofmb commented Jul 16, 2024 via email

Rohan1363m commented Jul 16, 2024

Rohan1363m commented Jul 18, 2024

Rohan1363m commented Jul 19, 2024 • edited Loading

OKE66 left a comment • edited Loading

Choose a reason for hiding this comment

Lexa77Q commented Aug 22, 2024

OKE66 left a comment

Choose a reason for hiding this comment

Lexa77Q left a comment

Choose a reason for hiding this comment

OKE66 left a comment

Choose a reason for hiding this comment

Danyalkasiri left a comment

Choose a reason for hiding this comment

Danyalkasiri Aug 23, 2024

Choose a reason for hiding this comment

OKE66 Sep 22, 2024

Choose a reason for hiding this comment

ebe1707 Oct 17, 2024

Choose a reason for hiding this comment

Danyalkasiri Oct 18, 2024

Choose a reason for hiding this comment

Danyalkasiri commented Aug 23, 2024

Nopandi1101 left a comment

Choose a reason for hiding this comment

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

Nopandi1101 left a comment

Choose a reason for hiding this comment

This comment was marked as spam.

Nopandi1101 left a comment

Choose a reason for hiding this comment

OKE66 left a comment

Choose a reason for hiding this comment

This comment was marked as spam.

Nopandi1101 left a comment

Choose a reason for hiding this comment

This comment was marked as spam.

This comment was marked as off-topic.

This comment was marked as outdated.

This comment was marked as spam.

Euomen888 left a comment

Choose a reason for hiding this comment

This comment was marked as spam.

tvorogme commented Jun 13, 2023 •

edited

Loading

oleganza commented Sep 4, 2023 •

edited

Loading

slavafomin commented Oct 4, 2023 •

edited

Loading

Rohan1363m commented Jul 16, 2024 •

edited

Loading

Rohan1363m commented Jul 16, 2024 •

edited

Loading

Rohan1363m commented Jul 19, 2024 •

edited

Loading

OKE66 left a comment •

edited

Loading