Suppose that when the liquidity of an ERC20 token is added to the liquidity pool it generates some trigger for my contract to execute something.
Or suppose a wallet receives a token. This receipt IMMEDIATELY triggers my contract.
I tried to make a while function that reads balanceOf (which will be zero at the beginning) and stops when the balance of a wallet is different from zero . However, it seems that this method consumes a lot of gas and reaches the limit. Even though query is free, it seems that the network does not process it.
Any suggestions on how I can resolve this trigger issue?
Additional detail: the token or liquidity contract is from a third party and is already deployed on the mainnet.
I once asked myself the same question. impossible. You cannot let an contract wait. It needs to happen in on transaction/block. You can create a view function that checks if addressA got more tokenA than before and then create a python program that gets the response of the function and then triggers an event.
You cant let your contract wait like forever til something happens. the contract sees on end so you would end up paying unlimited gas, also your transaction would go til the person gets the token. And if your transaction was first he can't get it because your transcation need to proccess first but in order for it to procces you need him to get more tokens but in order for him to get tokens your transaction must procced.
See the problem?
I understand your clarification. At first I thought that since the queries are free of fees then it wouldn't be a problem to use this. However, when implementing the contract, a gas error appears.
On the other hand, when an address receives tokens it would trigger my contract, but if that address never received tokens, theoretically my contract would run infinitely. But in this case I would put a limit of a few minutes, for example.
I'm looking to do this through smart contracts on the blockchain because the processing is faster, as opposed to doing it with off-chain software.
Is there really no possibility to do it on the blockchain?
Due to the nature of blocks being mined, as Team_x said, you cannot have a contract running indefinitely, talkless of the possibly infinite gas fees involved. There will be a negligible speed difference if you set up an off-chain option like a python script constantly querying your contract for the liquidity pool balance and comparing it to a previously obtained value. If a change is observed, it can then trigger the function you've defined in the contract.
If i'm hearing you correctly, I would argue that it is possible. If the function that is called to deposit the token in the contract (that you do own), emits an event, then the ethersJS library allows you to place an event listener on a contract instance, assuming you have access to the contract ABI. The contract will emit an event, the block will be mined, and the callback for the event listener will then be invoked. You can then, in the callback to the event lister, have a script that instantiates a wallet that has write access to the contract that you do own, and invoke the function that you would like.
So contracts cannot react to any kind of external events. ( By external I don't only mean outside the blockchain, I mean outside the contract itself).
When you deposit a token to your contract (ContractA), you are just telling the Token contract (ContractB) to modify balances on its own records (which are internal to ContractB)
The way to make ContractA "react" to a token transfer is either by:
A: ContractA needs a function that "takes" the tokens from the "buyer" balance. (an approval tx has to be submitted by the "buyer" wallet e.g. contractB.approve(contractA.address, amount)). This is the buyer allowing a specific address to have control over a certain amount of tokens. This is the usual way token transactions are handled.
B: ContractB issuing a call to contractA to account for the balances. (this means you probably have to own the ContractB to implement the specific calls. There are token standards that implement callbacks to a random contract but there are some security risks to this way.
C: Having a web2.0 service or script monitoring the events to contractB and then calling cotnractA. I wouldn't advise this way unless you have some super-specific requirements for your implementation. This way will represent some expenses to you, centralization to your app, and non-trivial security risk.