If there are multiple domains resolving to the same wallet address, by watching the transactions of that wallet would it be possible to differentiate the transactions towards a domain or another?
Example:
My address 0x516F381d6C94110CDE63F3266B779065525096e6 resolves to primary.eth. 0x516F381d6C94110CDE63F3266B779065525096e6 (same address) also resolves secondary.eth and tertiary.eth.
If a user sends some ETH to secondary.eth, the ETH will reach 0x516F381d6C94110CDE63F3266B779065525096e6.
By monitor the transactions occurred on 0x516F381d6C94110CDE63F3266B779065525096e6 is it possible to know that this user has sent the ETH to secondary.eth, instead of primary.eth or tertiary.eth?
Related
I am learning node JS developing a crypto currency exchanger as a homework project where user can deposit ERC-20 token and Ethereum. I am generating unique ethereum deposit address for every user, where they can deposit ERC-20 token and ethereum. but after sometime I want to move the received ethereum and ERC-20 token to another address (cold wallet).
If someone only send ERC-20 token to the address and no etherum, then how I'll get ethereum to pay as gas fee to transfer the received ERC-20 token to cold wallet?
If suppose, I am first paying etherum (for gas fee) from cold address to the user address, and then using that etherum to transfer received ERC-20 token, will it work at mass level ? means if 10000 users do the same thing at the same time, will not it create a problem ? or is there any better solution for this?
If there's no eth in that account, you can't take the ERC-20 token out.
Transfer some eth to the address and then get ERC-20 token out is the only way. The problem is how to save the gas as far as you can.
You can write a batch transfer contract to send eth to several hundred addresses in one go (the ceiling is determined by block gas limit), batch transfer saves gas. Then you can collect the ERC-20 tokens.
Of course, you can charge your user for compensation.
I know that an ethereum funds address can hold many types of tokens. If the address is a contract address, can it also hold many types of tokens? or it can only hold the token it defines?
In other words, is it true that any address in ethereum can:
have at most one smart contract attached to it. This allows other users to locate this smart contract.
have arbitrary types of tokens attached to it. The address here allows other smart contract to keep track of the balance this address owns.
^ Is this correct? Thanks.
Both your assumptions are correct.
I'll just clear out the fact that it's not the "owner" address holding the tokens per se. The information which address owns how many tokens (or which tokens, in case of NFTs) is stored on each token contract. Also, blockchain explorers (such as EtherScan or BscScan) aggregate this data in their off-chain databases, so it's easier to search on their site.
Example:
Contract 0x123 (token ABC) holds the information that Address A owns 1 ABC token.
Contract 0x456 (token DEF) holds the information that Address A owns 2 DEF tokens.
A blockchain explorer has all this info aggregated in their off-chain DB, so that users can simply filter "all tokens by Address A" and they don't have to keep querying all token contracts asking "How many of your tokens does Address A own?".
If you are using the ERC-721 standard, what is the prefer method determining which tokens the address owns in a DAPP.
Currently I'm request all the Transfer Events for an address and basically sorting them into transfer in and transfer out, and then using that to determine which tokens the user owns.
Is there a simpler way I missed.
Transfer events may be emitted also by contracts that are not ERC-721 tokens, or some noname tokens that you might not be interested in.
The actual token ownership is stored in the tokens contracts (and not the DAPP contract).
So your current approach is pretty much as straightforward as it can get, if you want to automatically keep track of all tokens that the address currently owns (and some false positives as well).
Note: This is also similar to the approach of Etherscan, which listens to all Transfer event logs and if the sender contract is listed in their database of tokens, they use the event log data to update balances of the sender and recipient.
If you're willing/able to create and maintain a list of tokens that you want to follow, I'd recommend a simpler approach:
Define the list of followed token contract addresses (e.g. ECF or RARI)
For each of these token contracts, call balanceOf(<your_dapp_address>) that returns amount of tokens that the <your_dapp_address> currently owns.
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.
So from my understanding when creating a contract the two variables that are used in determining what the address of the contract will be are the msg.sender and the nonce value. So if I create two contracts in the same transaction such as I did with this code https://ropsten.etherscan.io/address/0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e#code
Why did it generate two contracts at two different addresses, what I though would happen is that they would generate at the same address and the one would simply overwrite the other or something like that.
You're understanding of the contract address determined by the address of the message creator and the nonce is correct. However, in the example you posted, msg.sender is the address of the Test contract.
These are the steps that occured:
You initiated the transaction to deploy Test from your external account (0x98081ce968e5643c15de9c024de96b18be8e5ace). According to the transaction information, the nonce of the account at that time was 639.
This resulted in the Test contract having an address of 0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e.
During the deployment of Test, the constructor then creates two new contracts through "internal transactions". Divert is deployed from the contract address at 0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e with nonce=1. OverRide is deployed from the same address with nonce=2.
You can view the details of the internal transaction here.