PSP-30: Augmented ERC20s

[hskang9]

Nice. it is grateful we have a person who is interested in.

[xgreenx]

@hskang9 If you don't support all functions from the asset-pallet it means that you will not emit events on the pallet level. You can implement transfer via mint and burn, but in that case, you miss directly transfer event on pallet level, instead you will emit Mint and Burn. The same with approving of the transfer.

[hskang9]

This is just absurd to hear. Precompiles can still emit pallet events and transfer event can be supported.

[hskang9]

Also, @xgreenx you are getting totally wrong idea about the proposal. The proposal is for unwrapping/wrapping an asset that can be connected with each apis, not having a control of asset pallet in the evm. Read the proposal before making a point.

[xgreenx]

Also, @xgreenx you are getting totally wrong idea about the proposal. The proposal is for unwrapping/wrapping an asset that can be connected with each apis, not having a control of asset pallet in the evm. Read the proposal before making a point.

Okay. Let me try to describe what I understood from that PSP, what I propose, and you will correct me=)

You want to create and deploy one simple contract, which you called "entry point contract". That contract should create a wrapper contract for some token and you called that wrapper - "augmentor contract".

EntryPointContract contains only one method:

createAugment(token) returns (address augmentor) {
    require(msg.sender == IERC20(token).owner(), "ACCESS_INVALID"); // <- So it requires that `Erc20` contract should implement `Ownable`. But it is not implemented for each `Erc20`.
    ...
}

The flow for some token is next: 1) The owner of some token should call EntryPointContract.createAugment(addressOfHisToken). That will generate a new augmentor contract. 2) Any user who wants to wrap his tokens from Erc20 into pallet-asset should find(somehow) an augmentor address, approve tokens for AugmentorContract and then call AugmentorContract.augment(tokenAmount). 3) After that the user will be able to send his new tokens in pallet-asset to someone via XCM.

My point was:

• Why do we need EntryPointContract? Because everyone will know how to find a wrapper for some token. Everyone can ask EntryPointContract. That is a good idea=) + All wrappers will have the same codebase.
• Why Erc20 should be Ownable? Because the owner of Erc20 should be the owner of tokens in pallet-asset? I think tokens in pallet-asset should not have an owner so we can remove that restriction.
• Why AugmentorContract contains only augment(amount) and decrease(amount)? I don't see at the moment why, so if you can describe that will be cool=)

I expect that AugmentorContract is an Erc20 wrapper like here. Where depositFor is your augment and withdrawTo is your decrease.

That wrapper can be implemented via pallet-asset. It means that you store information on the pallet-asset level and do transfers also on that level.

[hskang9]

First of all, your points are now different from your previous quote. You do not even care what you said before. Answers to your points:

• EntryPointContract is Solidity's factory design using create2. EntryPointContract is the contract which makes an AugmentorContract for each erc20 to be mapped to an augmented to pallet-asset data.
• For this, I made permission for project or token owner to create augmented erc20, but as I see weth contracts permissionlessly made in etherscan, I think owner access requirement is unnecessary.
• There are only two functions because they are the only functions proposed. Read the proposal before why it only contains those two functions. It is just ignorant to say that you do not understand before even thoroughly reading the proposal. Elaborate yourself on questions regarding the functions after reading it.

Still, @xgreenx you do not understand the proposal, because you just throw random quotes about it. AugmentorContract is where evm provides token primitives to pallet-contract so that they can use it as pallet-asset data. If you want to discuss about contract-pallet's implementation or comparison, talk in other proposals. This page is to discuss the information in the proposal, not discussing your preference on this proposal. What you have to correct yourself is the topic that you engage with this page and overall attitude towards other proposers. You just don't have any integrity to participate in the discussion.

[xgreenx]

First of all, your points are now different from your previous quote. You do not even care what you said before.

I said next:

@hskang9 If you don't support all functions from the asset-pallet it means that you will not emit events on the pallet level. You can implement transfer via mint and burn, but in that case, you miss directly transfer event on pallet level, instead you will emit Mint and Burn. The same with approving of the transfer.

I was trying to direct you on the idea that it is better to support all functions from pallet-asset instead of only mint and burn. Because if you do a transfer of wrapped tokens on Solidity level, you will not emit the Transfer event on the pallet-asset level. So for me, everything fits right=)

About points:

• I know how it works. The question: why do we need that? Do you want to force all users to use that factory? If yes, then I'm okay with that, but it means that the developer can't customize the code of the augmented contract(someone maybe wants to has own implementation with some features).
• Cool, so we can remove that restriction from PSP=)
• I've read the proposal, many times, it is why I'm asking you to describe that more=) Why are only two functions proposed? (maybe we can't use other functions from the pallet-asset or we have other problems. Could you describe that please?) Why AugmentorContract doesn't support all functions from Erc20 + these two functions?

Still, @xgreenx you do not understand the proposal, because you just throw random quotes about it. AugmentorContract is where evm provides token primitives to pallet-contract so that they can use it as pallet-asset data. If you want to discuss about contract-pallet's implementation or comparison, talk in other proposals. This page is to discuss the information in the proposal, not discussing your preference on this proposal. What you have to correct yourself is the topic that you engage with this page and overall attitude towards other proposers. You just don't have any integrity to participate in the discussion.

Okay=) Let's first check that I'm correctly understanding which problem are you trying to solve. Motivation in PSP:

Augmented ERC20s propose a wrapper method to bring ethereum token primitives into xcm-compatible asset class.

I see the problem: How to teleport tokens from the Erc20 contract on Solidity level to pallet-asset level? If those tokens are available on the pallet-asset level, we easy can transfer them via XCM message.

If my understanding of the problem is right, let's continue the discussion, if not, then could you describe it in more clearly please=)

[hskang9]

Answers to points:

• You do not understand developers can add suggestions and customize the code in a proposal which suggests an open-source code.
• yes
• You are still saying the wrong thing and try to prove your cognitive skills with only number of reading. Two functions are only needed to turn erc20 to pallet-assets and vice versa. all the other functions are handled from each runtime api(e.g. IERC20().transfer from ethers.js, pallet_asset.transfer(asset_id, to, amount) from polkadot.js). I already said that the proposal is where evm provides token primitives to pallet-contract so that they can use it as pallet-asset data. Read again. The proposal is about to use both sides's functionalities without having to control pallet-asset in evm side. You can't read and think that two of them(controling pallet-asset with evm vs. adding augmentor between erc20 and pallet-asset's asset). This is where you are wrong. You can always improve on this if possible, but this proposal is about taking the step of changing data.

Teleporting is not the right term to describe, and it is just a term used in science fictions. Please elaborate with more detailed words without ignorance. The proposal is for making open-source algorithms with standard that is used in software, not for describing vague idea from yours. Contract keeps the erc20 then generate pallet-asset asset data. then it can go opposite way by burning it then giving back the erc20. Read the proposal again without your subjective way of understanding. Try to understand how Wrapped Ether works as referred in the proposal.

As the proposal is in discussion phase, it needs details that could describe the workflow of the proposal so I answer questions on how function is built, but I don't accept why more function is needed when each module has its own apis and the proposal only wraps/unwraps the data between them, because there are already apis(functions to make you understand) that is compatible with each data. I do not feel worth to describe clarification when you just talk a different topic on controlling pallet-asset via evm. I suggest proposing this in a separate standard as the topic here is different. I will just ignore your opinion on this and work on implementation. I personally do not want to keep revealing your reading skills in public. I do not feel worth to talk with you as you do not think on code level, and just thinking how to teleport in arbitrary way without comparisons. Software works more delicate than that.

[xgreenx]

You are still saying the wrong thing and try to prove your cognitive skills

I'm only trying to improve that proposal. So the problem is right, thanks for confirmation, we can continue discussion=)

The proposal is about to use both sides's functionalities without having to control pallet-asset in evm side. You can't read and think that two of them(controling pallet-asset with evm vs. adding augmentor between erc20 and pallet-asset's asset).

But in your case adding augmentor between erc20 and pallet-asset's asset - is a partial controlling pallet-asset with evm. You use pallet-asset.mint and pallet-asset.burn.

Try to understand how Wrapped Ether works as referred in the proposal.

It is what I'm exactly expecting from that PSP! Thanks that you said it by self=) Wrapped Ether(WETH) is a Erc20 contract. It is why I think AugmentorContract should be Erc20 contract and it is why I mentioned ERC20Wrapper early.

Let's define some terminology for the next chapter:

• AugmentorContractV1 - is AugmentorContract defined in this proposal. It contains only two proposed methods - partial controlling pallet-asset with evm.
• AugmentorContractV2 - is AugmentorContract that has full controlling pallet-asset with evm. It is fully Erc20 compatible.
• Erc20Token - is a token created by some owner. For example, it can be USDC.

If AugmentorContractV2 is fully compatible toErc20(supports all methods) then we don't need to adapt an application to do a convert between Erc20Token and AugmentorContractV1. It doesn't change the flow for users and it can be used later as a main representation of the token. If the parachain provides pallet-asset functionality then better to migrate all tokens to use that functionality. Because it enables native support of XCM, multisig and etc. The same AugmentorContractV2 contract can be used to create Erc20 wrapper around tokens from pallet-asset(In that proposal you only touched how to wrap Erc20 -> pallet-asset. It allows to do the same in reverse order). It allows having the same API in both directions of wrapping and simplifies future integration with applications.

With AugmentorContractV1 we introduce a new entity like AugmentorContract. It makes the flow harder because it requires a conversion between AugmentorContractV1 and Erc20Token. It requires rewriting of existed applications to use that flow. And that means that we will have a different API to do wrapping of Erc20 -> pallet-asset and pallet-asset -> Erc20.

So the question is the same: Why AugmentorContractV1 is not AugmentorContractV2?=) If we can't implement AugmentorContractV2 let's discuss here why. Maybe we will find a solution.

Try to understand how Wrapped Ether works as referred in the proposal.

BTW, you didn't refer to Wrapped Ether in the proposal. It is time to fix that=)

[hskang9]

Stop putting '=)' in sentences. It is unprofessional, and does not show that you have engagement for conversation.

[xgreenx]

Stop putting '=)' in sentences. It is unprofessional, and does not show that you have engagement for conversation.

I'm fully interested in that conversation because we plan to implement AugmentorContractV2 with ink on contract-pallet. I'm just trying to emphasize positive intentions. Because it seems to me that the conversation has a negative tone. But okay, let's continue without them.

[hskang9]

I know that you are improving the proposal from first and second item, and I am willing to support that and change it, which is what the proposal is for. However, you need another proposal on controlling pallet-asset in evm. For feedbacks, now you are suggesting without complaints. This is great way to start a productive conversation regarding augmentor contract.

You are still saying the wrong thing and try to prove your cognitive skills

I'm only trying to improve that proposal. So the problem is right, thanks for confirmation, we can continue discussion=)

The proposal is about to use both sides's functionalities without having to control pallet-asset in evm side. You can't read and think that two of them(controling pallet-asset with evm vs. adding augmentor between erc20 and pallet-asset's asset).

But in your case adding augmentor between erc20 and pallet-asset's asset - is a partial controlling pallet-asset with evm. You use pallet-asset.mint and pallet-asset.burn.

Try to understand how Wrapped Ether works as referred in the proposal.

It is what I'm exactly expecting from that PSP! Thanks that you said it by self=) Wrapped Ether(WETH) is a Erc20 contract. It is why I think AugmentorContract should be Erc20 contract and it is why I mentioned ERC20Wrapper early.

Let's define some terminology for the next chapter:

• AugmentorContractV1 - is AugmentorContract defined in this proposal. It contains only two proposed methods - partial controlling pallet-asset with evm.
• AugmentorContractV2 - is AugmentorContract that has full controlling pallet-asset with evm. It is fully Erc20 compatible.
• Erc20Token - is a token created by some owner. For example, it can be USDC.

If AugmentorContractV2 is fully compatible toErc20(supports all methods) then we don't need to adapt an application to do a convert between Erc20Token and AugmentorContractV1. It doesn't change the flow for users and it can be used later as a main representation of the token. If the parachain provides pallet-asset functionality then better to migrate all tokens to use that functionality. Because it enables native support of XCM, multisig and etc. The same AugmentorContractV2 contract can be used to create Erc20 wrapper around tokens from pallet-asset(In that proposal you only touched how to wrap Erc20 -> pallet-asset. It allows to do the same in reverse order). It allows having the same API in both directions of wrapping and simplifies future integration with applications.

With AugmentorContractV1 we introduce a new entity like AugmentorContract. It makes the flow harder because it requires a conversion between AugmentorContractV1 and Erc20Token. It requires rewriting of existed applications to use that flow. And that means that we will have a different API to do wrapping of Erc20 -> pallet-asset and pallet-asset -> Erc20.

So the question is the same: Why AugmentorContractV1 is not AugmentorContractV2?=) If we can't implement AugmentorContractV2 let's discuss here why. Maybe we will find a solution.

Try to understand how Wrapped Ether works as referred in the proposal.

BTW, you didn't refer to Wrapped Ether in the proposal. It is time to fix that=)

[hskang9]

From the suggestion, I am interested in AugmentorV2Contract as well. It is great that my proposal is now scaling with other people's help.

[hskang9]

However, your question "Why AugmentorContractV1 is not AugmentorContractV2?" is just an logical error. AugmentorContractV2 is AugmentorContractV1 as a superset from your texts. Stop trolling LOL

[xgreenx]

However, you need another proposal on controlling pallet-asset in evm.

Do you mean the proposal about: 1) the implementation of Erc20 via pallet-asset? 2) support of pallet-asset's methods in pallet-evm to use them in Solidity? (you called that "evm precompiled module")

If 1, then I think it should be part of that proposal. Because it describes the implementation of AugmentorContract. If 2, then how did you plan to use pallet-asset.createAsset, pallet-asset.mint and pallet-asset.burn?

However, your question "Why AugmentorContractV1 is not AugmentorContractV2?" is just an logical error. AugmentorContractV2 is AugmentorContractV1 as a superset from your texts. Stop trolling LOL

It was a reinterpretation of my initial question "Why AugmentorContract contains only augment(amount) and decrease(amount)?" by new terminology.

[hskang9]

I don't care for your AugmentorV2Contract design, and you can always suggest a new proposal, but I do not have your design for your imaginery augmentor contract. Submit it in another proposal, when you have the code with examples.

[hskang9]

Anyway, moving on with the current confirmed design. I feel no need to hear from you until you have AugmentorV2Contract.

[hskang9]

However, you need another proposal on controlling pallet-asset in evm.

Do you mean the proposal about:

1. the implementation of Erc20 via pallet-asset?
2. support of pallet-asset's methods in pallet-evm to use them in Solidity? (you called that "evm precompiled module")

If 1, then I think it should be part of that proposal. Because it describes the implementation of AugmentorContract. If 2, then how did you plan to use pallet-asset.createAsset, pallet-asset.mint and pallet-asset.burn?

However, your question "Why AugmentorContractV1 is not AugmentorContractV2?" is just an logical error. AugmentorContractV2 is AugmentorContractV1 as a superset from your texts. Stop trolling LOL

It was a reinterpretation of my initial question "Why AugmentorContract contains only augment(amount) and decrease(amount)?" by new terminology.

This is the question that I want to ask, how? and where? in V2? proposal does not support that.

[hskang9]

Let me simplify the solution for you as you have hard times understanding what you are doing. Make another proposal. Stop being scared of releasing new ideas. Stop trying to take the credit of what others worked by putting your vague and unspecified ideas.

[hskang9]

If you release your contract about it in a new proposal, I will review, even though I do not know when it will come.

[hskang9]

Also, one criticism about your V2 design is that it is not compatible to existing erc20 transfer. pallet-asset must need an asset identifier to send an asset, and you just do not understand that will bring a bunch of incompatibility in existing ethereum infrastructure. You haven't even started to think about your design. I am sorry that you are too afraid to get your thoughts reviewed by the others. There is a reason why even wrapped ether was developed when weth contract can support all the ethereum native functions, because it does not work with its existing infrastructure. I am sorry that you do not figure this out all by yourself when you claim yourself your understanding. I hope to see your proposals though =)

[xgreenx]

This is the question that I want to ask, how? and where? in V2? proposal does not support that.

Could you clarify what you want to ask, please? If it is 2, my question was related to AugmentorContractV1. Where do you plan to take the implementation of pallet-asset.createAsset, pallet-asset.mint and pallet-asset.burn?

Anyway, moving on with the current confirmed design. I feel no need to hear from you until you have AugmentorV2Contract.

Let me simplify the solution for you as you have hard times understanding what you are doing. Make another proposal. Stop being scared of releasing new ideas. Stop trying to take the credit of what others worked by putting your vague and unspecified ideas.

If you release your contract about it in a new proposal, I will review, even though I do not know when it will come.

I don't plan to work on it. It is your proposal.

That PSP is in the state Call for Feedback(it is not yet, but it will be). I'm leaving my feedback. If we vote for the acceptance of that PSP withAugmentorContractV1 I will reject it. Because we can implement that with AugmentorContractV2 and it will be better for the community.

Also, one criticism about your V2 design is that it is not compatible to existing erc20 transfer. pallet-asset must need an asset identifier to send an asset, and you just do not understand that will bring a bunch of incompatibility in existing ethereum infrastructure. You haven't even started to think about your design. I am sorry that you are too afraid to get your thoughts reviewed by the others. There is a reason why even wrapped ether was developed when weth contract can support all the ethereum functions. I am sorry that you do not figure this out all by yourself. I hope to see your proposals though =)

AugmentorContract knows identifier of the token because it should be specified during creation of the asset in pallet-asset.

Update: Sorry, it is already in state Call for Feedback, missed that moment.

[hskang9]

You still don't understand. AugmentorV2 contract design has not been released yet, and you threaten a proposer with voting right. This is just total nonsense in my opinion. You did not respect the proposer with the weird gesture, and now you are throwing a proposal because your undesigned idea is challenged with thorough manner. This is just a corruption happening in Polkadot ecosystem with one person threatening a proposal will not pass with vote, because AugmentorV2 will be better. You are just refusing the virtue "less trust, more truth"

[hskang9]

@Noc2 who takes a vote for this, and do you think @xgreenx threatening for voting is right for overall ecosystem? and how is this even possible with one person saying that the standard can be refused because the upcoming standard will be better, without any specifications?

[xgreenx]

because your undesigned idea is challenged with thorough manner

I'm ready to discuss how it can be implemented, but you don't want to do that.

@Noc2 who takes a vote for this, and do you think @xgreenx threatening for voting is right for overall ecosystem?

I'm not threatening you... I only described my thought that this proposal can be better and I will vote for accepting of AugmentorContractV2 otherwise I will vote for rejecting.

@Noc2 is one of the owners of that repository and he approved that for a draft because it is part of the workflow. He also may vote for accepting or rejecting when that proposal will be nominated to Accepted state. And he will make a final decision and that decision should be based on the votes of the community.

[hskang9]

because your undesigned idea is challenged with thorough manner

I'm ready to discuss how it can be implemented, but you don't want to do that.

@xgreenx I told you to make another proposal on this, and focus on functions for now.

@Noc2 who takes a vote for this, and do you think @xgreenx threatening for voting is right for overall ecosystem?

I'm not threatening you... I only described my thought that this proposal can be better and I will vote for accepting of AugmentorContractV2 otherwise I will vote for rejecting.

I accept the contract. make another proposal, and stop saying V2 is V1 without throughly explaining the contract when the function should be different by specifying asset id on transfer. This is just obvious plagiarism. so I will specify the contract as V1. Let's wait for V2.

@Noc2 is one of the owners of that repository and he approved that for a draft because it is part of the workflow. He also may vote for accepting or rejecting when that proposal will be nominated to Accepted state. And he will make a final decision and that decision should be based on the votes of the community.

Ok

[xgreenx]

I told you to make another proposal on this, and focus on functions for now.

I don't plan to implement that at the moment because it is at the end of the roadmap. But we can discuss with you of how V2 can be implemented in that proposal and you will implement that.

I can only put pseudocode here to be more clear:

contract AugmentorContractV2 is IERC20, IERC20Metadata {
    // It is identifier of the token. It can be placed manually or generated based on the address of this contract.
    // It is bytes32 like an example, but is hould be compatible with T::AssetId from `pallet-asset`
    bytes32 private _identifier;

    constructor(bytes32 memory identifier_, string memory name_, string memory symbol_) {
        _identifier = identifier_;
        pallet_asset.create(_identifier, address(this) /* owner */);
        // set metadata
        pallet_asset.set(_identifier, address(this), name_, symbol_, 18 /* decimals */);
    }

    function name() public view virtual override returns (string memory) {
        return pallet_asset.name(_identifier);
    }

    function totalSupply() public view virtual override returns (uint256) {
        return pallet_asset.total_issuance(_identifier);
    }

    function balanceOf(address account) public view virtual override returns (uint256) {
        return pallet_asset.balance(_identifier, account);
    }

    function allowance(address owner, address delegate) public view virtual override returns (uint256) {
        return pallet_asset.allowance(_identifier, owner, delegate);
    }

    function approve(address delegate, uint256 amount) public virtual override returns (bool) {
        // `pallet-asset` requires verification of owner(that it is signed).
        // Implementation of `pallet-asset.approve` in `pallet-evm` should check that `owner` is msg.sender or this.
        // Otherwise it should reject transaction.
        emit Approval(_msgSender(), delegate, amount);
        return pallet_asset.approve(_identifier, _msgSender() /* owner */, delegate, amount);
    }

    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        // `pallet-asset` requires verification of source(that it is signed).
        // Implementation of `pallet-asset.transfer` in `pallet-evm` should check that `source` is msg.sender or this.
        // Otherwise it should reject transaction.

        emit Transfer(_msgSender(), recipient, amount);
        return pallet_asset.transfer(_identifier, _msgSender() /* source */, recipient /* destination */, amount, true /* keep alive? */);
    }

    function transferFrom(
        address delegate,
        address dest,
        uint256 amount
    ) public virtual override returns (bool) {
        // `pallet-asset` requires verification of owner(that it is signed).
        // Implementation of `pallet-asset.transfer_from` in `pallet-evm` should check that `owner` is msg.sender or this.
        // Otherwise it should reject transaction.

        emit Transfer(delegate, recipient, amount);
        return pallet_asset.transfer_from(_identifier, _msgSender() /* owner */, delegate, dest, amount);
    }

    function _mint(address account, uint256 amount) internal virtual {
        emit Transfer(address(0), account, amount);
        pallet_asset.mint_into(_identifier, account, amount);
    }

    function _burn(address account, uint256 amount) internal virtual {
        emit Transfer(account, address(0), amount);
        pallet_asset.burn_from(_identifier, account, amount);
    }

    // I think `depositFor` is better naming
    function augment(uint256 amount) internal virtual {
        // Here you check that you get tokens and then you call `_mint`
        ...
    }

    // I think `withdrawTo ` is better naming(transfer them back)
    function decrease(uint256 amount) internal virtual {
        // You call `_burn` and unlock tokens
        ...
    }
}

[hskang9]

V2 is different from V1. Please stop trolling. You still do not understand ERC20 is using evm-native functions when the AugmentorContractV2 is only interacting with pallet-asset. As I told you, this proposal design is about providing a wrapper between each runtime, not having a control of an wasm runtime with evm. I think I already told you 5 times. This is not compatible with ERC20's mint function. V2 cannot be better, because it is totally different. V1 is the algorithm for converting ERC20 to pallet-asset data, but V2 is just a pallet-asset token with ERC20 api. I do not see any reference on conversion of it. You are just arbitrarily adding functions in the existing works and call that as a better contract when existing functions were supposed to interact with evm runtime in a parachain. Stop plagiarizing other people's work. It is such a shame that you have a name for an organization so called "OpenZeppelin of Polkadot" but yet you try so hard to plagiarize other people's work and ask one to implement it with vote threat even when you do not even contribute to the wrapper or showed any works of trial. You are supposed to lead implementation and design in the ecosystem, but you are doing opposite, depreciating other proposer's work with mocking gesture[=)] and include the code without permission by claiming that you are better without any firm comparison. Stop being delusional and come up with a legit design with fundamentals. Stop including my proposal to your work(V2) without reference, backward compatibility, nor mocking comments.

[hskang9]

and If I see functions not implemented as pseudocode and have any similar my proposal's design without the reference in this repo, I will go through footsteps for legal procedure of copyright laws, media, and any other platforms to reveal your case.

[hskang9]

@xgreenx I am warning you. I am now sick of your excuses.

[xgreenx]

As I told you, this proposal design is about providing a wrapper between each runtime, not having a control of an wasm runtime with evm.

Could you elaborate more on "each runtime", please? Do you mean runtime of substrate node - pallet-evm. Or something more?

Let's return to the beginning and move step by step to solve everything. In the proposal you have "An evm precompile module is provided with three functions". Who provides that EVM precompiled module?

If you plan to implement that during that proposal, then: 1) How createAsset(name, symbol, decimal) creates the token in pallet-asset without identifier? 2) How does the mint(account, amount) method have access to the entry point's mapping(address -> address) augmentors;?

[xgreenx]

@hskang9 Regarding your thoughts that are not related to the PSP. Please be calm. I'm not threatening you. I don't ask you re-work the PSP to use AugmentorContractV2. I'm not planning to create another PSP at the moment to resolve the problem. AugmentorContractV2 is only an example of how the problem can be resolved in another way(more general in my opinion). I'm only asking you(you don't need to answer these questions now, let's answer on previous. We will move step by step to get answer):

• Why do you prefer AugmentorContractV1 instead of AugmentorContractV2? If you think that AugmentorContractV2 can't be implemented, then let's discuss why it can't be implemented.
• Maybe AugmentorContractV2 doesn't resolve some cases which can be resolved with AugmentorContractV1. Then please describe: What kind of problem is not possible to resolve with AugmentorContractV2?

I mentioned my voting for rejection only to highlight that if you don't want to answer questions(because it is wasting your time), then okay, I will vote for rejection. And as you mentioned before, other people can vote for acceptance if everything is clear for them.

[hskang9]

If you plan to implement that during that proposal, then:

How createAsset(name, symbol, decimal) creates the token in pallet-asset without identifier?

Ok for this, I suppose the api call createAsset function with the id incrementing by one. If there is an asset id registry in overall polkadot ecosystem with Statemint, the contract will adjust to it. I think this can be discussed once Substrate runtime dex projects(e.g. Acala, HydraDx) sets up the table for substrate native assets.

How does the mint(account, amount) method have access to the entry point's mapping(address -> address) augmentors;?

Read the proposal. The mint(account, amount) function you describe is in precompile rust code. The augmentor contract which supports augment and decrease functions should have the access to the precompile function.

Why do you prefer AugmentorContractV1 instead of AugmentorContractV2? If you think that AugmentorContractV2 can't be implemented, then let's discuss why it can't be implemented.

Read the previous messages. You haven't even described how V2 works. you cannot ask for preference when you don't even have specification. AugmentorContractV2 can't be implemented because it is just in your imagination without specification.

Maybe AugmentorContractV2 doesn't resolve some cases which can be resolved with AugmentorContractV1. Then please describe: What kind of problem is not possible to resolve with AugmentorContractV2?

What kind of problem is not possible to resolve with your unspecified imaginery contract so called AugmentorContractV2?

I really do not have time to talk about your contracts that are not even in your roadmap without comparison with backward compatibility when it is AugmentorContractV2. Also, what more can I say that you are just threatening with vote without even thoroughly describing your idea by when voting is supposed to be secret in all democratic government? From your saying on vote, you can express a lot about yourself in democracy and how you manage the power. You are not respecting freedom of speech and ownership of one's intellectual property. You are abusing your position of the vote to influence other community members, because you are cognitively challenged to force your unspecified addition. I will protect my freedom to keep the proposal and deliver codes while you are trying to add your name without responsibilities and capabilities of understanding and maintaining them. There is no rest for the wicked.

[xgreenx]

Ok for this, I suppose the api call createAsset function with the id incrementing by one. If there is an asset id registry in overall polkadot ecosystem with Statemint, the contract will adjust to it. I think this can be discussed once Substrate runtime dex projects(e.g. Acala, HydraDx) sets up the table for substrate native assets.

I think it is an important part and you need to highlight that in PSP. How do you plan to resolve conflicts(the identifier of the token is used)? Maybe it is better if the caller of createAugment provides the identifier?

Read the proposal. The mint(account, amount) function you describe is in precompile rust code. The augmentor contract which supports augment and decrease functions should have the access to the precompile function.

Okay, so mapping(address -> address) augmentors; should be public. I think also better to highlight that. How does the mint(account, amount) method know the identifier of the token that should be minted? Maybe you also need to have additional mapping for that? Like mapping(address -> address) public augmentor_to_asset_id;

Read the previous messages. You haven't even described how V2 works. you cannot ask for preference when you don't even have specification. AugmentorContractV2 can't be implemented because it is just in your imagination without specification.

AugmentorContractV2 is a AugmentorContractV1 + methods from Erc20. You can check available methods(and their description) of Erc20 in eip-20(it is a specification for these methods). Under the hood, these methods can be implemented via pallet-asset(pallet-asset is Erc20 compatible, the methods have the same naming and description but different signatures). As you've planned to implement methods mint and burn, you can use the same pattern during implementation for transfer, balance_of, and other methods.

What kind of problem is not possible to resolve with your unspecified imaginery contract so called AugmentorContractV2?

In that proposal you try to resolve the next problem: How to move tokens from Erc20 into pallet-asset?

AugmentorContractV2 and AugmentorContractV1 resolve that problem. Here I described the cons and pros of each solution. But maybe AugmentorContractV2 doesn't cover some cases covered by AugmentorContractV1?

[xgreenx]

BTW, @hskang9 if the EVM precompile module is already implemented(or partially implemented) then you can refer to it and I will find answers to some of my questions there to not waste your time answering them.

[hskang9]

I think inplementing the precompile first is needed before making you understand in text as you feel the hardship understanding how the data is managed.

[xgreenx]

I think inplementing the precompile first is needed before making you understand in text as you feel the hardship understanding how the data is managed.

If it is not implemented, then let's continue with questions from that comment.

[hskang9]

Yes you cannot understand after repeating same answers. I will finish implementation.

[xgreenx]

Yes you cannot understand after repeating same answers. I will finish implementation.

I asked new questions, but okay. Let's keep that proposal in the Draft state until the end of the implementation and end of the discussion.

[hskang9]

You are asking same questions with variation with text, and you cannot give any idea about your V2 contract without reference of my work, because you are plagiarizing other's idea without shame.