Request for node operators to extend tx time out

Assuming it will not negatively impact network security,
I’d like to ask node operators to modify their config.toml files, as mentioned by Assaf in the link below, to something between 1-3 minutes, if that will cut down on the number of time out errors on secretswap.

Could Enigma recommend a time out parameter and then provide instructions and support to the node operators on how make this change?

1 Like

I really like the way you think tech3 and hope we can attract more people like you to our ecosystem.

With some standardization of minimum fees and timeouts, it would also be something to consider using in our transaction flow.

  1. call the blockchain to get the current minimum fee
  2. build the transaction and get a transaction object to store the id on the server or save it locally to use later
  3. Check the status of the transaction in the event network connection is lost

Ideally we would want to know there is a minimum fee and that a transaction will eventually go through.

1 Like

There is a slight delay for this method, but you can see if you transaction went thru by pasting your account number into the search bar of Also on, you can look directly at the account of the contract that you called for the transaction.

For example, if you are on the secretswap app “swap” tab, this is the contract that is called:

Look for your account number in the transaction history.

It may not be necessary to call the network each time for minimum fees.

My current understanding of how to manually determine the minimum fee is to look at this contracts “transaction history”. Click “details” on a transaction and then look at the “Gas used”. In the case of this particular contract, the “gas used” tends to be around 930,000. This seems to be the absolute minimum for the contract not to fail and eat your fee. You can use that as a baseline, and most of the txs seem to be going thru with a “gas wanted” of 1,500,000.

It seems like a web interface that reports these “gas wanted” and “gas used” fee averages calculated from the transaction history would be enough.

I’m piecing this together, someone with more knowledge please correct my errors.

1 Like

A few things on this.

  1. The fee market is a free market. So it will likely never be standardized unless the network moves this to this being an on chain parameter
  2. The timings for all nodes should probably all be the same to avoid issues.
  3. Changing the timings used by nodes will impact the blocktime of the network.
  4. Anyone with different timings than default is someone who manually changed it.

If the timings need to be changed, it should be changed by default in the binary downloaded during a network upgrade.

1 Like

I agree with this, that the fee should remain a free market.

What is the current default setting for time out?

Is this a major issue, in your opinion?

If all the node operators are on board, this does seem to be the safest method.

It would actually make a lot of sense if the fees were an on chain perimeter. That way when/if the price increases a lot, the network can effectively lower fees to be common sense. If fees were all zero or very low, then it would be free or cheap to ddos the whole network. The tradeoff here is that the fees would be regulated, but only via vote.

Idk, but if someone has different than default then they manually changed it (i assume for a reason).

It depends what timings they mess with.

1 Like

I guess we’re getting off on another subject here but, do you mean the fee should be fixed? or capped? or set as a ratio of token price? what do you have in mind?

The best thing would probably be to have the minimum fee be an on chain parameter. Again, if the price goes way up (like 5x) and the min fees vals use stay the same as they are now, then most transaction fees would be high (they’d cost 5x more in usd value if the price does a 5x). This is the only reason why I say it could make a lot of sense to make this an on chain parameter.

On another note, this should be in a different section on the forums. Probably validators / secret nodes section.

Isn’t the minimum fee basically just the cost of the computation. Like the case of the contract I mentioned above, around 930,000? Anything less and the tx fails automatically.

Is this parameter that you are suggestng a fixed number or is it a formula/ratio?

The min fee for a tx is 1 line in the app.toml config file. Larger computations generally still need to pay more than the minimum. It’s just a minimum.

If the minimum fee is in the node code app.toml, isn’t it already an on-chain parameter? Or by “on-chain” you mean adjustable by voting?

Someone messaged me that this might be regarding a different timeout setting related to keplr so I probably don’t have enough context to comment on the original topic here.

I was talking about transaction time out related to the “swap” tab of secretswap.

I just talked with a keplr dev on their telegram and to paraphrase what he said, keplr just signs the transaction in secretswap, but the time out settings are set by the secretswap app.

Interesting. Ok. Sorry for commenting, It seems i was talking about different timings than the topic was actually about.

It’s no problem, I still learned a lot from the conversation. Thank you for replying.

None of the early game progress so far has involved creating and funding user wallets and so that may be a good place to start. Once that’s done we can begin to think about playing with any timing on the front-end. These things take a few months or even a year to finish the first time around.