Is it possible to provision a contract with Wei that can be used to pay the gas for future method invocations?
After creating the contract with Wei, I would like to reduce the price to invoke a method.
Related
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.
I understand msg.value represents how much wei the sender sent. But how does a contract use it?
In the example of a vending machine, the contract checks to ensure enough msg.value is present to cover the cupcakes ordered, but there's no code that actually deducts the wei.
Example:
https://ethereum.org/en/developers/docs/smart-contracts/#a-digital-vending-machine
I do see some info about buyer and seller.transfer() here:
https://docs.soliditylang.org/en/v0.8.15/solidity-by-example.html#safe-remote-purchase
A contract has no need for deducting to receive ETH or msg.value. The sender will determine ETH payment amount.
ETH receiving contract only need payable modifier to indicate that it can receive ETH. We can say it is like a vending machine in the way that the contract cannot determine how much it will receive, but you can refund by transferring the exceeding ETH back to the sender.
Unlike ERC20 which works differently, it does needs to be approved and deducted for the general contract purchase function.
Read more:
https://stackoverflow.com/a/71883390/2017851
https://medium.com/coinmonks/solidity-transfer-vs-send-vs-call-function-64c92cfc878a
https://cryptomarketpool.com/reentrancy-attack-in-a-solidity-smart-contract/
Typically, this code is paired with a dapp front-end for the user to operate, so if you are a developer who wants to send ETH when calling a contract, I recommend doing this
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
I have an Eth contract, called the controller, which is used to:
Generate new eth deposit addresses, one for each user, which is
an eth contract as well.
Sweep these deposit contracts when a user deposits eth or erc20 token to them. The funds end up in another central eth account.
A number of erc20 tokens seem to work perfectly, but USDT deposit transactions get reverted: https://etherscan.io/address/0x3cd5a0dc36a8f22011193f2a03910aa8260e64db
Without the original source code for these contracts (although I have the JSON ABI), it is hard to say:
Why it fails for USDT.
If these actually can support USDT, or what it would involve to do so.
If anyone can point in the right direction, it will be appreciated!
Controller contract:
0xEb818C6a48cCd60A8078aaa20997cC3CB2538C9E
Another contract involved linked to controller, called defaultSweeper:
0x8e7ABAF1316A0edB985e494F572Fdf148e8a7E93
EDIT:
It seems that USDT contract is missing some erc20 methods. Like transfer See: https://erc20-verifier.openzeppelin.com/ Why is this?
Tether contract was deployed before the ERC20 standard was finalized. Some functions don't follow the specs, for example transfer should return a boolean and it doesn't.
Recent versions of solc will check the returned data size is correct (since 0.5 I think).
My guess is that your contract was compiled with a recent version of solidity and it uses the standard ERC20 interface. And it fails because Tether returns nothing and it is expecting a bool value.
There isn't much you can do. Either Tether should upgrade its contract or the controller contract has to be modified to do not check the contract size. See SafeERC20 from OpenZepplin, they implemented a wrapper around ERC20 that allows interfacing with tokens that are not compliant with the standard.
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.