Could we split offer and rollover parameters in maker API?

[luckysori]

When working on #2859, I immediately built on the assumption that the offer parameters will be updated frequently. This is why I originally chose to consider the fees expired if a minute had passed since they were set in the daemon.

Whilst this makes sense for the offer parameters because the prices change very frequently, the funding rates behave differently. We expect them to change once every 8 hours.

I bring this up now because I have been told that it would be a good idea to allow the caller of the maker's HTTP API to configure the time-to-live of these rollover parameters, instead of defining a constant in maker. I could just add a timestamp or a duration which only applies to parts of CfdNewOfferParamsRequest, but that doesn't strike me as good API design.

A time-to-live that applies to all of these parameters doesn't make sense, because they should have different times-to-live.

[klochowicz]

Yes, we could - we even considered doing it when we did the libp2p refactor, but as to my knowledge we kept them together as it was considered too little gain at that point.

on the very basic TTL level I can definitely agree that "offer params" and "rollover params" should have different TTL.

are there any overlapping fields that would need to end up in both params?

[luckysori]

are there any overlapping fields that would need to end up in both params?

It depends if we want CfdNewOfferParamsRequest to provide enough information by itself to create an offer. If so then the funding rates and the transaction fee rate would still need to be included. I see several options:

1. Live with the duplication.
2. Ensure that all fields are orthogonal and require that we have up-to-date offer parameters, funding rates and transaction fee rate in order to create offers. Only the last two would be needed to roll over.

If we went for 2, I think the transaction fee rate would not belong in either object and would have to stand by itself. Which is not necessarily a bad thing, because it is a value that changes at a completely different frequency than the others.

---

There is a third option that might be cleaner, but it would result in changing the order protocol: we could opt to only introduce the funding rate when rolling over, opting to charge no fees until the first rollover occurs. But this has (tiny) financial implications and I have no idea if we actually want to do this.