Develop a universally adopted wrapped Toncoin (wTON)
afstonfi opened this issue · comments
Summary
We are developing a wrapped Toncoin (wTON) in a jetton format, which will serve as a universal intermediary for exchanging TON-based jettons (tokens) in any trading pairs on TON-based DEXs, and will be used in other TON-based applications.
Our next (and big) goal is not only to program a wTON smart contract, but to create the wTON everyone is happy with.
The benefits of a universally adopted wTON (compared to lots of different wTONs, which have been already created and/or will be created in the future) are as follows:
- Consensus of interested participants
- No financial risks for the end users (e.g. avoid other wTONs which might be scam ones)
- No ecosystem fragmentation
- A single standard API and a single standard set of features
Context
Implementation of a wrapped TON contract doesn't require a lot of effort. As a matter of fact, several implementations already exist. The problem is that numerous different wTONs created by different developers bare lots of risks:
- Financial risks: there is no guarantee that a particular wTON doesn't hold security vulnerabilities left deliberately or by mistake. Getting security audits and certifications of the same quality for all the many wTONs is unrealistic.
- Ecosystem fragmentation and no single API: this is a real problem for developers who are building products that will have to use a variety of wTONs. Imagine a wallet developer who wants to correctly display the total amount of wTON, including regular and all kinds of wrapped ones.
- No parity of features: each wTON will have its own unique set of features, which will lead to additional hassle with support.
The solution could be a standard, universally adopted, audited and certified wTON with a set of features that fits the needs of most developers. Of course, it won't prevent creating other wrapped TON contracts, but most likely developers will prefer to use a widely used, universally adopted and community-led wTON if there is one.
We have already implemented these features:
- Wrap/unwrap functionality
- Conformance to Fungible Token Standard TIP-74
Goals
To create wrapped Toncoin, which will serve as a universal intermediary for exchanging TON-based jettons (tokens) in any trading pairs on TON-based DEXs, and will be used in other TON-based applications.
Our next (and big) goal is not only to program a wTON smart contract, but to create the wTON everyone is happy with.
Deliverables
Source code which will include these features:
- Custom payload for minting/burning transactions.
- Support for query_id parameter similar to TEP-74.
- Better gas management via reserves which will allow not to use any hardcoded fees in the code.
Definition of Done
GitHub repository with the source code.
Reward
5000$ in TON equivalent
Hey guys!
I guess the idea to make a reference implementation of wTON smart-contracts is a good thing to do.
But as you already mentioned implementation of wrapped TON Jetton is not really a hard task.
At the same time building a standard on top of that is interesting task.
My opinion is that we should include creating a TEP to the deliverables. (You can take a look at SBT's TEP as an example)
Also i think price of 5000 Toncoins is too hight for this kind of work, i guess something aroud 2000 should be enough.
Dear all,
How about add TEP-89 to universal wTON standard contract?
The feature of TEP-89 is useful to DEX.
Because in DEX's view, if a contract receives a message from jetton-wallet contract,
TEP-89's feature make receiver contract to be convinced that this message is really from exact user.
Actually, our team already developed this contract and frontend.
Our wrapped ton contract code is uploaded at https://github.com/ozys-io/wrapped-ton
And official site is at https://wton.dev/
What we only want is that avoid ecosystem fragmentation.
@Naltox Thanks for the feedback! We definitely planned to go through TEP process as a part of this work and approved TEP is planned as a delivery.
@junmoDev I'm glad that you joined, since our primary goal is also avoiding ecosystem fragmentation.
We'd definitely like to support TEP-89. And there are few more features we'd like to be supported, for example ability to pass query_id and custom payload when minting/burning wTON. I suppose the final list of features should be defined within TEP framework to make sure that the interests of all parties are taken into consideration.
Hey guys,
Giving some kind of a new breath to this discussion.
So the main idea is that having a public implementation rather then a standard would build a higher trust score. So every DEX player would use the very same contract to wrap TON.
This would require a bit of discussion to make sure the public implementation satisfies every existing party (deDust, Ston.fi, Ozys and Mint.xyz) and also the security requirements.
I could run this initiative of gathering both the requirements and the implementation.
Please let me know what you think and then I would proceed organizing that thing to happen.
@markokhman Mark, thank you for the great offer! We definitely support it. We will be happy if you could run this initiative of finalising the WTON standard.
Approved!
@markokhman any rough deadline we can rely on ?
Super, thanks for your trust! @Hiyorimi
I've already started to organize the description of requirements, and will make sure a proper discussion with a TEP is going to be held.
I would roughly estimate this as 2 weeks together with implementation. If everything goes smoothly - it can be even faster. Hopefully, the discussion won't extend that deadline.
It might also take a few iterations, so I will publish drafts as they are ready.
Thanks @markokhman!
Our team(Ozys) would be satisfied if the implementation contains TEP-89.
And please let me know if there are anything that our team could support you.
@junmoDev thanks for your comment! Sure we are going to implement it with discoverable tokens standard requirements.
I'm preparing a TEP with all the specifications.
Just in case guys, I've created a TEP and started to elaborate the solution we're proposing.
ton-blockchain/TEPs#102
Publishing this as a draft. The work is in process and will be lot's of updates in upcoming days.
Please leave your comments.
I'm still against the idea of using a payload when burning. In my opinion, the wton implementation should be as same as possible to official standard jetton contracts. Adding a custom payload when burning is wrong, a dapp cannot know if the user want to receive wton or native ton
But we can specify it when initializing the chain of messages
This is still a bad approach since you are relying on a specific feature of a non-standard contract and this isnt modular, you dapp will always rely on this certain implementation and this makes no difference with using specific code to handle native ton.
In my opinion, contracts should work with standard and should be generic. So custom mint (wrap) is fine, unwrap is not.
Hi all,
In my opinion,
It is enough to make new wton to follow the interface of standard jetton, not implementation.
So I'm okay with using custom_payload field in implementation of new standard wton.
Because this field is mentioned at TEP-74.
But I'm against with add a new op-code in wton to implement special functionality.
Because I think the main reason that dApp developer need wrapped token in blockchain is that to handle native coin to same as other fungible tokens on that chain.
If we add new op, dApp developers should add special handling code in their contract for just wton token.
Hi all,
In my opinion,
It is enough to make new wton to follow the interface of standard jetton, not implementation. So I'm okay with using custom_payload field in implementation of new standard wton. Because this field is mentioned at TEP-74.
But I'm against with add a new op-code in wton to implement special functionality. Because I think the main reason that dApp developer need wrapped token in blockchain is that to handle native coin to same as other fungible tokens on that chain. If we add new op, dApp developers should add special handling code in their contract for just wton token.
Just in case guys, I've created a TEP and started to elaborate the solution we're proposing. ton-blockchain/TEPs#102
Publishing this as a draft. The work is in process and will be lot's of updates in upcoming days. Please leave your comments.
What about the progress?
Hey @Hiyorimi
After we've started to investigate what will be required changes for DEX developers - I decided to first draft the solution and see how two core ideas we have can be implemented in that interface.
The idea is indeed to make sure we have something that is tradable same as any other jettons, but is real representation of TON.
However, we want to also make it end-user friendly, especially for those who are not advanced users and the don't understand the essence of wTon.
So we make it backward-compatible, so any DEX developer could use it as normal Jetton, but those who want to provide the end user with ability to never deal with wTon - will use the extra commands and proper flow.
I'm close to finish the first draft and will publish it tomorrow, so we could continue the discussion with real subject of the draft solution.
Thanks.
Here is the resulting TEP pull request with source code of WTON:
https://github.com/markokhman/TEPs/blob/master/text/0000-wrapped-ton-standard.md
Changed reward to 2k ton as @Naltox mentioned
Hello guys, as we can see there was kind of a misunderstanding with the total amount of the reward, as it was initially set to 5000 TON, then it was adjusted to 2000 TON in comments, but not in the original footstep outline.
Maybe we can do it following way - let's keep the total reward amount as 5000 TON, but from our side:
- we will collect more feedback on the TEP from the community, also put required efforts to organize further discussions on the TEP Pull Request
- produce content like article on the process of WTON creation, guide and even video tutotrial on how to use WTON and it's most applicable usecases.
So we would add one more deliverable - the accepted TEP that describes the WTON implementation and the standard.
This way will be beneficial for all parties - community, footstep's sponsors and also the team who is working on WTON.
What do you think?
@markokhman sounds good! Can you specify new goals and rewards for completing them?
Hey @Gusarich
Yes, sorry for the late reply. Happy New Year for you!
So basically as suggested above, let's keep the same amount of the reward (5000 TON), but we update the deliverables list and deadline.
DELIVERABLES UPDATE:
Deliverables by 15 Jan:
- published video about WTON with core participants of it's creation, that will cover implementation approach and it's list of alternatives, in-depth overview of how WTON is implemented
- article guide/tutorial on using WTON and the usecases
- facilitate feedback and it's handling on the TEP's pull request, so the TEP once merged would have the community's approval
Final deliverable to unlock the footstep reward: The accepted TEP that describes the WTON implementation and the standard.
NOTICE: We are dependent on the amount of time that community will be reviewing the TEP, it's application guides and providing feedback. We will push to have enough publicity for the TEP to be merged by Jan 30, to provide two weeks period. This might extend slightly based on the community's requirement.
@markokhman, after talking in direct, the work will be continued and done. In this regard, there are several questions regarding implementation:
-
what are your milestones now?
-
what are the deadlines?
-
what's the new amount of reward?
@markokhman, any updates?
Hey guys, seems like there is not much interest in Wrapped TON from exchanges, as well as a loss of momentum for this initiative - we're going to close this issue for now.
The current state of delivery is the following:
Implemented source code: https://github.com/ton-community/wton-contract
TEP: ton-blockchain/TEPs#102