How do I make a existing running erc20 to prevent some holders from transacting?
I am trying to do a staking feature. Can I write a new contract to control the existing erc20 contract?
Logic that would affect a token holder's ability to transfer (or have a party transferFrom on the holders behalf) must be written into the contract if you want token transfers to be halted within the contract itself. Therefore, if you already have a contract deployed you would have to deploy a new ERC20 contract that has the logic - if you want the staking mechanism to be within the same contract. Then you would have to transfer balances from the previous version of the contract to the newly deployed contract. While possible, it would incur a gas expense to replicate the contract state. You could have your token holders pay this gas cost by having some sort of mint or recover function that would read the old contract balance for an address, create the balance on the new contract, and then mark the balance as transferred.
Alternatively, to your second question, you could facilitate the staking with an additional contract that users would set an allowance to within the ERC20 contract. Then, users could interact with something like a stake function on this new staking contract. The staking contract would use the transferFrom ERC20 function to transfer tokens from the owner to the staking contract's address after incrementing the user's staked token amount within the staking contract. This would record the holder's staking "credit" and tie the tokens up by transferring their ownership to the staking contract. Users could then unstake which would decrement the user's staked token amount and transfer the tokens back from the staking contract's address to the token holder's address. This type of approach has more moving pieces but could be a more flexible step while developing the mechanism as you can deploy new versions of the staking contract without having to redeploy the ERC20 contract or transfer balances. Users would be able to transfer like normal throughout multiple versions of the staking contract and extracting tokens from previous versions of the staking contracts would be gas-efficient.
Related
I wanted to ask if its possible to have a USDT tokens (like the standard smart contract's balance in Ether) inside my smart contract, and if it was possible to than swap it with the Ether inside the smart contract's balance (if possible using Uniswap; swapping both from ETH to USDT and viceversa).
Thanks.
Yes, it is entirely possible to store ERC20 token in any contract, since the balance of ERC20 token is only defined as a mapping of mapping(address => uint256) in the ERC20 contract.
However, since transferring ERC20 requires either you as the owner or you having the approval to transfer, you will need to give yourself, or the address executing transactions, allowance to transfer the ERC20 "stored" in the contract address, or otherwise, the ERC20 token will be stuck inside the contract.
For the swapping part, you can look into the interfaces of Uniswap and have your smart contract call to Uniswap for the swap.
I would like to transfer ERC20 tokens from a wallet who don't own ETH to another wallet who own ETH and who can pay gas fee.
Do you know if it is possible to made a transfer of ERC20 tokens and to let the receiver wallet pay fees ?
TLDR: Not possible, unless the token contract explicitly allows it. Or unless the token holder is also the block producer.
Transaction fees are paid in ETH (or generally, native currency of the network - for example BNB on Binance Smart Chain, MATIC on Polygon, ...). So in most cases, you need to pay ETH to execute either the transfer() function if you want to send the tokens from your address, or the approve() function if you want someone else to transfer tokens from your address.
Very few token contracts implement delegated transfer mechanism on top of the ERC20 standard. There's currently no standardized way to perform a delegated transfer, so each contract might have a different implementation. The token holder uses their private key to sign a predetermined message saying how many tokens they want to transfer to which address. The message also usually contains a nonce or a timestamp to prevent signature replay attack. Token holder passes the message offchain to the transaction sender, and then the transaction sender executes a function of the token contract built specifically for delegated transfers (note that the transaction sender pays the fee to execute this function). The contract validates the signature, and performs the transfer. Again, most token contracts do not implement this mechanism.
One more exception from the rule is a block producer. When you create a new block, you can fill it with transactions not only from the mempool but also with your own transactions. You can build a transaction with 0 gas price, and then include it in the block that you're producing. This way you're also able to send tokens for free.
Learning Solidity along with token development.
I'm having a hard time understanding how tokens with multiple smart contracts interact with each other.
I've read through other tokens with multiple contracts on GitHub and reviewed contracts on OpenZeppelin but they all appear somewhat orphaned.
Let's say we developed a token that has a supply and tracks wallet address to amount using a map. The contract is released and is given an address. Admin or privilege methods are protected via owner address validation. Then we release a second contract that needs to make apply a fee for transactions.
How does the second (token transaction fees) contract interact with the data stored on the first (token contract)? Does the second contract need to also verify ownership?
Any contract on Ethereum can interact with any other contract by using Interfaces. You can call methods from the second contract on the first contract for an ERC20 token as below:
Define ERC20 Interface
interface ERC20 {
function balanceOf(address account) external view returns (uint256);
}
Use the interface and token contract address to call methods on the first contract:
ERC20(tokenContractAddress).balanceOf(0xabcd....);
The similar approach can be used for any contracts
Users can deposit on Binance, for example, various ERC20 tokens, but later then those tokens should be transferred to the Binance cold wallet(wallet used for withdrawing) how those tokens are transferred when the newly generated address doesn't contain any ether(for transferring contracts), it doesn't make any sense for me that Binance sends some ether for every newly generated address.
it doesn't make any sense for me that Binance sends some ether for every newly generated address.
That's exactly what they do. If you do happen to deposit ether, they will leave a little bit ~$5 or so in the address when moving the ether to their cold wallet to pay for future token transactions. If you transfer only tokens, they will transfer some ETH before moving it.
This question is a little conceptual, so hopefully this picture will help clear up my misunderstanding.
Image there is a crowdsale smart contract deployed on address 0x2. A User at address 0x01 buys a token.
Here is my understanding of what happens:
The crowdsale contract (# address: 0x2) accepts ether from the user account (# address: 0x1)
The crowdsale contract stores 0x1 as having purchased a token (important: this information is stored in the smart contract #address 0x2)
Now my Question: If 0x1 is a user account (and not a smart contract) there is no code at address 0x1. I thought a user account just consisted of an address + ether associated with the address, how can it also store the fact that 0x1 owns an ERC20 token? For example, I can login to MetaMask and (before clicking the "add token" option) MetaMask can see that I have a token... how is this possible?
Every ERC20 contract has the following function:
function balanceOf(address _owner) public view returns (uint256 balance) {
return balances[_owner];
}
Your wallet just calls this function from the known token contracts with your address. Since it's a view function it doesn't cost any gas.
I recon most ERC20 token get added rather quickly to a wallet like Metamask or MEW. But if your balance doesn't automatically show, you can add the contract address manually (in MEW at least, not sure about Metamask) and it will show up afterwards.
In solidity there are two ways to get the address of the person who sent the transaction
tx.origin
msg.sender
In your example, in the method inside ERC20 Token.sol, the value tx.origin will be 0x1 and msg.sender will be 0x2
So to answer your question, how does the ERC20 token know about 0x2 is: it depends on how the token contract is written and whether it uses tx.origin or msg.sender. I would imagine it uses msg.sender, because that is the more prevalent one.
If it does use msg.sender you can still make the crowdsale contract work by first buying the tokens and then immediatelly transfering the tokens from the crowdsale contract to the caller.
For more information, refer to What's the difference between 'msg.sender' and 'tx.origin'?
how can it also store the fact that 0x1 owns an ERC20 token?
Token transfers, or transfers in accounting in general, are kept in a ledger. In this case, the ledger is ERC-20 smart contract that internally keeps balances who owns and what in its balances mapping. Or, the smart contract manage the storage (EVM SSTORE instructions) where the records of ownership are kept.
Note that some other blockchains, like Telos and EOS (and mayne Solana) might be opposite and there the storage is maintained on the user account (user account has associated RAM and tables for any token user owns).