PSP-22: Fungible Token standard (WASM ERC20) adoption process #25
Conversation
|
Great work. Patract also second this proposal. |
|
Maybe FYI: paritytech/substrate#9757, low-level traits to expose ERC-20-like information about assets in Substrate's |
|
Hello there, During the last two months, we contacted every team & project that will benefit from this PSP. All of them agreed on the content as well as the urge to have such standards. I want to thank everyone who took the time to participate in building this standard with us! We are ready to merge the PR |
|
Hello @xgreenx did you try to wrap |
|
If Should I propose another way of token standard that is compatible with interoperability? =) |
Hi, yes, it can be implemented with a combination of |
I want to hear an answer for this =) |
I think you should edit your proposal for support =) |
Answer on what?=) Could you specify your question, please?
For support of what? If you mean support of |
|
@Noc2 I vote for reconsideration of proposal on wasm ERC20. When Statemint is connected to Polkadot ecosystem, I think |
How is it limiting The developer of the contract may specify on the contract level the logic of how to mint/burn tokens in the It doesn't limit the |
|
PSP22 interface limits |
|
Why are you not adding other |
Could you describe which other functions do we need to support during cross-contract communication, please?
All public functions mentioned in that comment are supported in that PSP.
The interface contains only methods used during cross-contract communication. Methods like |
|
To add points:
|
|
I do not plan to add V2 contract over this and would like to hear your plans first so that I can help according to your design. |
If someone created We don't need a separate logic that will register these wrappers. They are self-sufficient.
If
If you see how we can improve the |
|
Sorry, I’m currently on vacation and haven’t read the complete discussion. I just want to add that ideally asset balances should be held in pallet_assets in the future and not in contract storage as far as I know. |
It is exactly what we plan to do!=) Everything will be stored in the |
|
Current agnostic interface does not specify pallet-assets layer support. If you think that all assets in smart contract balance state should be in pallet-asset layer, I think you at least need asset id allocated in your contract state to identify balance state in pallet-assets layer. |
|
Also, I think you also need to add a balanceOf function and specify how an asset balance is retrieved in pallet-asset layer. Will the asset identifier be global across parachains? Or has its own identifier per each parachain? |
Using a smart contract is all about composability. Also using pallet-assets gives the asset balance to be used as gas fee. It still brings much better composability with feeless architecture. |
|
PSP22 has the compatible interface of using all contract assets in the ecosystem, and it would be great if pallet asset layer support is specified in order to be future proof and provide interoperability. |
It is why that PSP is agnostic=) We don't need to specify that.
Don't go to extremes=) But let's rephrase to: Everything information related to the token will be stored in the pallet-asset layer.
We don't need to specify it, because it is nuances of implementation, not interface.
The creator of the wrapper should specify the asset id during the instantiation of the contract. How to select asset id? If you don't need cross-chain compatibility, then the id should be unique only for parachain. If you want the support of cross-chain compatibility(XCM, for example), then you should use the id from the Statemint parachain.
In the case of a smart contract, the user pays by native token of the parachain that executes that contract.
We plan to implement During 7th milestone we will provide an implementation of that chain extension and will create a PSP with detailed description of the flow and implementation. |
|
Agnostic interface does not support details in pallet-asset layer compatibility, but I see your quote that it will operate with pallet-asset layer. Maybe it is better to have a separate proposal if you persist on defining interface here for now.
Wrapper standard is missing. Any ideas for adding this proposal?
This is not true in feeless architecture where runtime module can adjust weights and paying asset with the code. Check Karura for example.
The problem is in compatibility, not feasibility. Current proposal has unspecified interface for one possibility where asset identifiers are different in each parachain. I think there should be more than one interface related with pallet-asset layer for resolving different asset identifiers in the 7th milestone. Do you also think that more generic term to describe PSP22 is needed as it definitely has more features which is not from token? I do think the term “wasm ERC20” is effective, but the term may considered different as feeless architecture starts to take place in polkadot ecosystem. |
I said that
The wrapper is an implementation of
Could you elaborate more on that, please? Maybe you can provide the link in the documentation of Karura.
That proposal is not about the compatibility of fungible tokens between different parachains. That proposal is about the definition of the functionality of fungible token across contracts layer of the one parachain. The interface is agnostic to the implementation. But implementation can use
That affects the instantiation process of the wrapper contract. It is part of workflow and part of
"WASM ERC20" is mentioned in the name of the pull request to highlight that it is an adaptation of |
What if your implementation of PSP22 uses account-balance state within a contract? That is PSP22, but it is not an implementation of PSP22 via pallet-asset. PSP22 provides a unified way to operate fungible assets in smart contract, but it is still an ambiguous standard that currently provides confusion in the contract ecosystem when it comes to pallet-asset related interface and state. Do you have a wrapper standard to connect each PSP22 with different state architecture? Wrapper can be needed for PSP22 without pallet-asset state if they want to be integrated with xcmp standard. Otherwise, the token’s presence is limited to its deployed parachain even when native xcm support is available. This should be necessary if you plan to ship the codes in production before 7th milestone for backward compatibility. |
Both contracts are |
|
I agree wrapper should not be included in PSP22, but it needs a standard to lower the contract development barrier. However, it is clear PSP22 interfaces are affected if |
The OpenBrush will provide the implementation of
We also thought about that. And I agree, that maybe some contracts want to know is that Later(when XCM and flow for cross-chains communication will be ready) we will create a discussion(maybe a proposal) with our thoughts about that question and we hope that the community will help us to identify: do they need that extension or not and the list of methods that should be in that extension.
Maybe you can provide an idea of the contract that can face the problem? In the future that can be a good base for discussion about the extension=) |
So you confirm that the interface is not thoroughly considered for interoperability between parachains. In a dex where it supports multiple PSP22s in multiple parachains, A dex needs to know how a token is stored in a user's unit of an account. As PSP22s does not display asset id, A dex does not know how an input token is stored in a user's account. In addition, an asset without designated identifier between parachains can create double-spending attack as contract address does not differentiate tokens anymore. another PSP22 can claim to be existing PSP22 in a different parachain even with the different contract address, because the interface does not care its identification between parachains at all. By having a so-called agnostic or arbitrary interface can bring up irresponsibility and security attacks. It would be interesting to see if PSP22 turns out to be fraudulent by its design because anyone can identify other tokens as same in different chains because the interface claims to be agnostic without on-chain comparison. |
I confirmed, that someone maybe want to know the information about the realization of the contract. For example, you are asking about that feature now=)
First of all, you can't create truly cross-parachain DEX on smart contracts. Because it still is a transfer of tokens in In most cases DEX on the smart contracts is AMM. It contains pools of liquidity for some tokens. If tokens from that pool are malicious, nobody will use that. You always can create a pair to trade/swap/exchange fake tokens. Maybe you have another example or you can find an issue with that? |
Yes you can with wrapped assets from different chains and xcmp. Check market solutions out there and try not to isolate yourself, and the transaction involves transfers of tokens in different
Do you know how AMM works? Are you seriously saying that dex is not cross-contract communication when it needs to transfer output token to the sender using swap? what kind of codebase are you referring to for a dex?
Oh so a UI has to wait for an event to check if a contract address is pointing to an asset id that user is looking for in Statemint when the asset data may reside in other parachain's pallet-asset. This is really efficient way to check, isn't it? When a DEX can keep a default token list where listing projects claim their token on Github and then verify before making a pair(or let scammers make rug pull pair) through its interface, don't you think it is better working this way as this is the way how most DEXes work? It would be so interesting for dex team to just trust the project team to list their tokens because they claim they connected to a certain asset id but have no way to check in the contract.
You just isolate yourself in your own code and defy all those wrapped assets and bridge solutions, even xcmp. I cannot convince you to think until you try to realize your situation.
Then why does xcm have error message? Why was XCM made in the first place? |
Could you be more constructive and less aggressive, please?=) Could you provide the link to the documentation of the solution that provides multi-chain liquidity (that means that the price of the pair is based on the combined liquidity of pairs from several parachain. Tha is fully cross-chain DEX)? I only know about solutions that allow transfer tokens between parachains. But it is not fully cross-chain DEX, because you do a swap of tokens in the scope of one parachain, and after, you transfer those tokens to another parachain(I mentioned that kind of solutions in my previous message).
You misunderstood me. You and I are talking in that message about not trusted implementation of fungible tokens and that it can affect the DEX to cause security issues. DEX doesn't check is that trusted
UI doesn't wait for events... UI is using some indexer to get data(for example you can check the solution in Ethereum - Graph Node). It is way how most DApps UI works. DEX can keep that information, the DEXs team decides the flow of pair creation. But if DEXs team manages that list, that means that this solution is not permissionless. Could you provide an example of the DEX that does an audit of the created pair? Uniswap and Suchiswap allow everyone to create any pair without audit.
Did you check how XCM is propagated to the destination parachain? The message should be sent to |
So you expect dapp developers run graph node that is not realized yet just for getting information about a contract? This is just harder than EVM smart contract development. What is the advantage of using wasm then when compared to evm with precompiles on native related functionalities? You are just leveraging previous works without even considering why it appeared, whether the infrastructure exists, and the technical costs to build it. It is just unbelievable that you put a step in this smart contract standard in Polkadot to be "just another smart contract" with "just another" existing UI infrastructure that has not been appeared instead of solving how to make builders develop and contribute to Polkadot's native codebase. You are just making ripoffs without even considering thoroughly about previous works. |
Hey there!
to all stakeholders of the ERC20 like standard, in the WASM ecosystem. Creating PR to have a space for the discussion of this standard.
At this point in time standard has already passed Draft state and was merged in
Call for Feedbackstatus.Acceptedis the next stage.The Supercolony team will be leading the process of adoption. We are going to involve every meaningful stakeholder we know so that this standard is built fully and nothing is missed. We will update this PR with any change that will be agreed upon here or in any other channel.
@Noc2 @alxs @cmichi @athei guys thanks for your support so far! Will continue to expect it going further.
Please do invite WASM ERC20 stakeholders to that space!