0

I currently have a working ERC-20 contract for a small group that I am in. I would like to make a new contract that mints or sends a 0 value token without liquidity similar to a rewards token that has defined parameters; Qty token to send is equal to X in reference to the other token quantity specified. I am familiar with reflection/taxation contracts, but I am unsure how to add a 0 value token from a contract to match parameters on the users transaction on token A. Supply would be controlled so not a concern for minting/burning.

I have thought about how this would be done with the minter/parser contract, again just not quite sure how to match parameters. If there was a way to add this to the original contract being a 0 value token it would pull from I would be interested in how that would be done. Any help would be greatly appreciated.

I tend to not explain things clear enough, so if 50 tokens are sent of token A, I would like to send 50 tokens of 0 value of token B in another contract.

1 Answer 1

0

Are you creating both token A and token B, just token B, or neither? It sounds to me like you're creating both of them?

Correct me if I'm wrong here, but to sum up it sounds like you're creating contracts for ERC20 tokenA and ERC20 tokenB, and whenever an amount of tokenA is transferred, you want the same amount of tokenB to be transferred to the same address?

If so you can simply give tokenA mint privileges over tokenB and add the following line to tokenA's transfer(sender, recipient, amount) function:

tokenB.mint(recipient, amount);
12
  • Yes that is correct, I am creating Token A and Token B. I have created Token A already and it is deployed, working etc. I do not mind having to do the contract again for Token A, so that is no issue. So essentially add that to Token A, allow it mint privileges over Token B, a function to set and define what Token B is (if not hard coded), then set the amount equal to Token A to be deployed correct?
    – jitzu76
    Commented Jan 21, 2022 at 15:09
  • The ratio/percentage for tokenB minted could then be further defined in another identifier I am assuming?
    – jitzu76
    Commented Jan 21, 2022 at 15:19
  • Yeah that's one way to do it, it has its pros and cons. Not knowing more about what you're trying to do it's hard to say that would be the best way--you'd never be able to unseparate tokenA and tokenB, and it would be forever be more gas expensive to transfer tokenA. But yeah this way would work.
    – Meriadoc
    Commented Jan 21, 2022 at 17:15
  • Great thank you! Essentially I am trying to just send "Proof of Activity" in a X:1 ratio of the native token that will remain with the user throughout their participation. Would another ERC type reduce gas fees? Or another way to call the mint?
    – jitzu76
    Commented Jan 21, 2022 at 20:16
  • I wouldn't even use an ERC20 in that case; I'd add it to the first ERC20 and just have the 1 contract. You can just have a mapping of address => uint inside the native token that is incremented each time the token is transferred. ERC20 has a lot of functionality that will make incrementing and deploying much more expensive if you never plan on letting users transfer this proof of activity. If they should be able to transfer it though, ERC20 is fine.
    – Meriadoc
    Commented Jan 21, 2022 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.