ERC-721: How to determine which Tokens an Address Own - ethereum

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.

Related

Detect ETH transfer which made by smart contract

I need to analyze blocks and txs to find if there is a transfer ETH to address from my list. When some user makes a direct transfer it is clear, I can check to parameter of the transaction. But sometimes users execute smart contracts which transfer ETH to address from my list, in this case to is the address of the smart contract, so I can't match it with my list. Is there a way to handle such cases?
If you mean something like an "internal tx" of a forwarding contract like this example. Which does a value call (address.call()()). Then there is no way of knowing the final destination with tracing the transaction. Alternatively some contracts could emit an event or in the case of forwarding contracts, you could read the 'parentAddress' set during contract init.
Etherscan parses the trace for you so you can see those internal transfers afaik (see example above).

Transfer ERC20 token without ETH

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.

airdrop and lock tokens for specific time

I want to airdrop and presale my won token
so in the next step I want to lock them until my IDO data come
and unlock in this time 30% of user wallet balances
and next month 50 %
what is the best way to do this
If you want your token to be sent to users when certain date comes automatically without backend or any users or you doing the transactions, it is not possible. Blockchain operations cannot be executed without calling a transaction using scripts by user or backend.
You can write the following airdrop contract to achieve desired result:
Users send stable coins to your airdrop contract. Addresses of these users should be stored in some place. You can store addresses and amounts of token buyers automatically (in arrays on the blockchain - address[] buyers, uint256[] amounts).
If you want users to click on button on website to receive available amount of tokens, your airdrop contract should have a method to send right amount of your token to caller if the caller sent stable coins before. This method should check, if msg.sender is in buyers (check in array can be expensive, you can create a buyers map only for this check) and if airdrop date has come (you can save timestamps in seconds in some array and check if any date has come via comparison with block.timestamp). If both requirements are met, contract sends tokens from your balance (transferFrom) or from its balance (transfer) following the exchange rate.
If you want send the transaction by yourself to give all tokens to buyers, you can make the method, which can be called only by you (Ownable will be very helpful). Inside this method, contract goes through buyers array and send amount[buyerIndex]*exchangeRate to each of them. This method doesn't require users to click on any buttons, but can be very expensive in gas and hence for you.

Multiple ERC20 tokens in a DeFi platform

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.

Can an ethereum smart contract address hold many types of tokens?

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?".