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.
Related
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
I'm building a DeFi application on Ethereum, and I would like to implement the Deposit function. Everything works fine between ETH and a ERC20 token that I built, but I would like to add some tokens like aToken for AAVE or cTokens for Compound that the user will receive after a Deposit call.
So the question is: is it possible to add a function in my smart contract to create multiple tokens without creating a smart contract for each of them? If not, I have to create a different contract for each token I want to add in my app or there is a best method to do it?
Yes this is possible. You can transfer the tokens to the user's address after the Compound Protocol mint operation. This can be made generic using the ERC-20 transfer interface. Be sure to account the amounts users are due and beware of the reentrancy vulnerability.
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 want to create a smart contract which people can transfer tokens without ether in their wallet.
Suppose A want to transfer ERC20 tokens to B, but he does not have ether in his wallet.
Does third party C can send the transaction for A and therefore pay the gas? Is it possible to create a function in the contract for this usgae?
I have searched online for a soloution and could not find one.
This is a key issue of Ethereum dApp development, but also of tokens. Here is a very old thread on Ethereum Stack Exchange, and also this one.
There are 2 options with their pros and cons:
Use signatures
Every function in your smart contract must have signature parameter.
People who want to interact with the smart contract must sign the function parameters with their account's private key and send it to the smart contract owner (via any communication channel).
The owner then submits the parameters along with the signature to the blockchain, paying for gas. The signature guarantees that the message was approved by the user.
Refund used gas at the end of the transaction. A modifier refundGasCost can be used for this (see below).
But (1) is really hard to apply to token transfers where you just don't know who uses the token and (2) does not really address the issue.
There is a lot happening recently, there is this blog post about How to save your Ethereum Dapp users from paying gas for transactions, and since you ask about tokens, there is an ERC that suggests to Pay transfers in tokens instead of gas, in one transaction which would be nice if you have tokens but no ETH.
I hope this helps.
Exactly this case is already defined in the ERC20 standard. Its this function:
function transferFrom(address from, address to, uint tokens) public returns (bool success);
But before party C could use it and send tokens from A to B, A would have to approve C to do this via the following function, which is also defined in the ERC20 standard:
function approve(address spender, uint tokens) public returns (bool success);
No, in a standard ERC20 token contract, the token holder must initiate at least one transaction (to call transfer() or approve()), and a transaction must always be paid for by its initiator.
I am trying to write upgradable smart contract in ethereum. Can anyone give an example of upgradable smart contract in ethereum and accessing data.
To write an upgradable smart contract I suggest you do the following (works for me):
Create a storage contract on which you will store all your map and variables. Add a modifier to the functions changing state. This modifier should require that an address must be present in a specific map (let’s call it authorized) to change the state of map or variable. Place the owner’s address in that map.
Write a function to authorize external address on the storage contract
Deploy another contract containing the logic of your app.
Autorise the logic contract on the storage contract.
Upon upgrade of the logic, deny access to the storage contract from the logic contract, deploy your upgraded logic and link the new contract to the storage.
Tadaa you now have an upgradable set of smart contracts.
Smart Contract cannot be replaced, but you can create a smart contract proxy to be able to replace the calling of all new Smart Contract functions (previous smart contracts cannot be removed on the main network ethereum).
Complete explanation and examples can be seen Here
You can implement follow Proxy Pattern
Blog
https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357
Smart contract upgradability is a state of the art area. Currently, there are a few solutions, but each of them has its own pros and cons. Here are the solutions with examples:
https://consensys.github.io/smart-contract-best-practices/software_engineering/