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
In a VLS policy, there's a hard fee rate cap of 25000 sat/kw. Feerate spikes currently make the greenlight client unusable. Especially if longer periods of high onchain fee rates will come back, having a hardcoded chainfee limit inside the client will break all clients. Since clients will usually have a slow upgrade path, this situation is undesirable.
It makes sense to have some limit inside the signer, to ensure it is not signing anything undesirable. But if chainfees are high, there's not much you can do about that, and signing would be the right thing to do.
Some options:
Inject a fee rate source (like mempool.space) in VLS, so it can validate the chainfee rate is sane
Ignore fee rates when the chain fee will be paid by the remote peer
Remove the hard cap
The text was updated successfully, but these errors were encountered:
In a VLS policy, there's a hard fee rate cap of 25000 sat/kw. Feerate spikes currently make the greenlight client unusable. Especially if longer periods of high onchain fee rates will come back, having a hardcoded chainfee limit inside the client will break all clients. Since clients will usually have a slow upgrade path, this situation is undesirable.
It makes sense to have some limit inside the signer, to ensure it is not signing anything undesirable. But if chainfees are high, there's not much you can do about that, and signing would be the right thing to do.
Some options:
The text was updated successfully, but these errors were encountered: