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
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: