Jetton migrations (for discoverable jettons and future standard upgrades)

[shaharyakir]

Summary

Provide a migration path for jettons to new contracts.

Context

TEP-89 introduced discoverable jetton minters.
This means that previously deployed jettons are not discoverable and have to deploy an auxiliary contract for adding such capability.
We suggest to support a migration path such that non-discoverable jettons can be migrated to a new (discoverable) minter.

Such a migration solution will also serve further extensions to the jetton protocol in the future.

Suggested Flow

A migration contract will be deployed such that it is linked to a certain minter contract.
Holders of the outdated jetton can send their jettons to the migration contract and receive new jettons instead.

Goals

Come up with a full solution to the migration path, including a contract interface & implementation as well as a UI.

Deliverables

• A PR to jetton.live with UI operating the migration (https://github.com/ton-defi-org/jetton-deployer-webclient)
• Documentation stating out the solution logic. Attack vectors should be specified and resolved.
• TL-B schemas for operations and storage
• Github repo with contract (latest stable func version using latest syntax)
• Full tests (typescript, sandbox)
• Full blueprint-style contract wrapper
• Code for deploying the contract (typescript)

Technical instructions

• Compiles under func 0.4.1
• Uses latest syntax: consts, include and pragma directives
• Opcodes are CRC32 hashes
• Gas-efficient
• 100% Test coverage (using sandbox)

Definition of Done

The contract is deployable and provides a migration path between minters

Reward

5000$ in TON equivalent paid out by these milestones:

• 20% - complete detailed solution documentation specifying logic, interfaces and TL-B schemes.
• 40% - contract implementation with tests, deployment code
• 40% - PR for UI

This grant is funded by Orbs as part of its ecosystem grant program.

[shaharyakir]

@Hiyorimi can we get this approved please? thank you!

[Hiyorimi]

@Hiyorimi can we get this approved please? thank you!
Sure thank you!

[Hiyorimi]

@shaharyakir is there anyone we can assign yet?

[shaharyakir]

Not yet

[deioann]

Hi @Hiyorimi, @shaharyakir! I think I and @deivana can take on this task.
But we have some questions:

• Will the task remain relevant if we're ready to start within ~5-7 days?
• Can we use Fift instead of typescript and tvm-contract-executor?
• Code of "new jettons" should be provided by the developer who initializes the migration contract or should it be static? Given that jetton contracts can have unique logic the first option seems more logical.
• Does it matter which organization and which repository on github the project will be developed in?

[shaharyakir]

• Will the task remain relevant if we're ready to start within ~5-7 days? Yes
• Can we use Fift instead of typescript and tvm-contract-executor? Unfortunately not
• Code of "new jettons" should be provided by the developer who initializes the migration contract or should it be static? Given that jetton contracts can have unique logic the first option seems more logical. The first option, yes. Mostly because this grant is about supporting future (hence unknown) versions of the the jetton contract
• Does it matter which organization and which repository on github the project will be developed in? No, as long as it's MIT license and we can fork it, it doesn't matter

[deioann]

@shaharyakir thanks! Okay, it's no problem for us to use a stack consisting of typescript and tvm-contract-executor. Is licensing smart contracts in TON under MIT possible? The TON smart contracts on FunC are usually linked with stdlib.fc, which is distributed under GPL license.

[shaharyakir]

Thanks for raising that, let me clarify this point and return with an answer

[deioann]

Thanks for raising that, let me clarify this point and return with an answer

I think there is no problem to license smart contracts under the GPL. You are just as free to do an open source fork.

[shaharyakir]

From our reading of the stdlib.fc LGPL license, the TON smart contracts would be considered a "work that uses the library" that is linked to the library. According to section 6, it is allowed to distribute this type of work under terms that you choose. So the smart contract as a whole can be licensed under MIT, as long as the other things written in Section 6 of the license are followed for the part that is GPL.

[deioann]

@shaharyakir ok, got it. Can you assign me and @deivana to this task?

[Hiyorimi]

@Gusarich can you help please?

[Gusarich]

@deioann sure! Assigned you. But I cant assign @deivana because he didn't write anything in this issue (github works like that)

[deivana]

@Gusarich I'm here and confirm my ability to take part in this task.

[shaharyakir]

@Gusarich The team let us know they will not complete the task. Let's remove the assignees,

For anyone looking - this is up for grabs.

[Gusarich]

I think there can be some troubles with such migration contract in case if Jetton-wallet has some specific logic for transfers (Jetton burning for example)

@shaharyakir are you sure we really need such way for migrations? What's the problem with the default auxiliary contract?

[shaharyakir]

Can you specify the problematic scenario?

The current auxiliary contract solves the discoverability issue, but future extensions to the jetton protocol may require further such contracts which can become cumbersome to manage.

[Gusarich]

@shaharyakir I thought about the scenario with auto-burning jettons. There may be some jetton that, for example, burns 0.1% on each transfer as a "fee". In this case, user who wants to migrate their jettons to new version will lose some value because of these two transfers. But anyway, in 99% cases this migration contract will be a good approach.

I'd like to take up on this footstep, what do you think? I also have a few suggestions about this footstep's deliverables:

• It'll be better to use newer FunC versions instead of 0.2.0 which is specified in this Footstep
• It'll be better to use the Sandbox instead of ton-contract-executor

[shaharyakir]

Nice point, but I agree about the 99%.
I've updated the description per your suggestions, please go ahead and take this.

[Gusarich]

I'm working on this Footstep in repository:

• https://github.com/Gusarich/jetton-migration

First milestone is completed. I'll implement the contracts soon.

[Gusarich]

Contracts & Wrappers are implemented.
Covering them with tests now (there are a few tests already done).

[Gusarich]

2nd Milestone is completed!
I'll start working on the UI soon

[Gusarich]

Sorry for the long delay, I've been quite busy.
I'm actively working on the UI part of this Footstep in my fork:

• https://github.com/Gusarich/minter

I'll finish it soon.

[Gusarich]

I've opened the PR to the UI repository:

• Jetton Migrations interface ton-blockchain/minter#183

All functions are working as intended and it only requires a few minor fixes in visuals. I'll finish it in 2-3 days.

[delovoyhomie]

@shaharyakir, can you tell me approximately when the Pull Request will be merged?

[delovoyhomie]

@shaharyakir, I appeal to you to clarify the situation and elucidate why the Pull Request cannot be merged, as the progress of this Bounty appears to be halted.

[shaharyakir]

I will look into it tomorrow

[shaharyakir]

@delovoyhomie we were stalled on e2e testing due to an unexpected result, where we weren't able to migrate jettons.
I will redo the e2e test this week (it takes some time because we need to investigate the failure), and once we're certain the flow works we'll be able to merge.

[shaharyakir]

Update - waiting for @Gusarich to investigate the code and issue a fix after a 2nd attempt at e2e testing.