You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The payment process, the way we regard it now, should contain a parameter which will affect how many percents
a recommended gas price, fetched from the blockchain service provider, should be increased by in order to achieve maintaining a high rate of passes in our transactions. This way they will have as much gas that will work even after that short delay between the PaymentAdjuster's analysis, then possibly a conversation with the Neighborhood, the run adjustment of the adjustment machinery, and the actual payment stage.
Another concern to mitigate by this parameter lies in the batch structure of our RPC request. Given the possibility of processing multiple payments at once, we don't want to open up an opportunity for any of those to fail because that would mean all transactions after this one would fail too, if nothing else, just for the reason of their suddenly invalid nonces.
This parameter will come hard-coded with #GH-711 first. This card should take care of all the standard places where a configurable parameter meets the user's interface and bring it into the DB, that means the another row in the config table. When the BlockchainAgent is being constructed this value should be read from the database.
The text was updated successfully, but these errors were encountered:
The payment process, the way we regard it now, should contain a parameter which will affect how many percents
a recommended gas price, fetched from the blockchain service provider, should be increased by in order to achieve maintaining a high rate of passes in our transactions. This way they will have as much gas that will work even after that short delay between the PaymentAdjuster's analysis, then possibly a conversation with the Neighborhood, the run adjustment of the adjustment machinery, and the actual payment stage.
Another concern to mitigate by this parameter lies in the batch structure of our RPC request. Given the possibility of processing multiple payments at once, we don't want to open up an opportunity for any of those to fail because that would mean all transactions after this one would fail too, if nothing else, just for the reason of their suddenly invalid nonces.
This parameter will come hard-coded with #GH-711 first. This card should take care of all the standard places where a configurable parameter meets the user's interface and bring it into the DB, that means the another row in the config table. When the BlockchainAgent is being constructed this value should be read from the database.
The text was updated successfully, but these errors were encountered: