Pre-Collateralization (try to avoid "on-the-fly" collateralization)

[kilrau]

Is your feature request related to a problem? Please describe.
Apart from the technical issues that we had with "on-the-fly" collateralization, we don't believe it is a good long-term approach since it relies on getting a transaction into the next block. There are times where the chain will be highly congested and latest then this approach will fail or result in very high gas costs.

Describe the solution you'd like
Allocate collateral to a channel with a client based on certain parameters. In times when gas prices are low (below a certain threshold or e.g. moving average).

• how much fees the sender/receiver paid to have
• how much was paid for liquidity fee (see RFC: Node Fee Policy #1139)
• transfer history (e.g. most transfers going from node -> client , x transfers per time)
• I bet we can come up with some more, but the basic trade-off I see is "opportunity costs for capital locked" vs. "next block gas price"

Exposing this as API and letting an external service take care (#802) is great, are you guys also planning to implement this service yourself (#796 suggests so)?

[ArjunBhuptani]

Exposing this as API and letting an external service take care (#802) is great, are you guys also planning to implement this service yourself (#796 suggests so)?

Yep, we're planning to implement this ourselves. Right now collateralization has 3 tiers of "prioritization", along with an automated override for larger transfers. Every time an application is uninstalled, the node will look up a profile for a given channel and rebalance based on the following logic:

1. The node will check to see if an externally-provided profile is available via the Collateral Management Service you mentioned above in [tracker] Collateral Management Service #802. We have yet to finish setting this up, but this will be a plug in API configured on setup that gets access via an auth key served from the node. This service is closed source for now, but will intelligently analyze a channel's behavioral data to optimize on the tradeoff between collateral cost vs gas cost of rebalancing.
2. If not, the node will check to see if an internally-provided profile is available. Setting up an internally-provided profile can be done using an admin auth key from the node and calling an addProfile nats endpoint.
3. If nothing else is available, the rebalancing logic will default to the node's base collateralization schema found in config.service.ts

In all cases, if a transfer that is greater than collateral volume comes through, the node will attempt to collateralize it "just in time".

[ArjunBhuptani]

Gonna tag prioritization on this as a wontfix just because there isn't an action item yet beyond whats in the other issues, but happy to continue a long form discussion here.

[kilrau]

Great to see that most of it is already in the works. Thanks!

• how much fees the sender/receiver paid to have

• how much was paid for liduiditiy fee (see RFC: Node Fee Policy #1139)

• transfer history (e.g. most transfers going from node -> client , x transfers per time)

• I bet we can come up with some more, but the basic trade-off I see is "opportunity costs for capital locked" vs. "next block gas price"

Maybe we can make this an issue about defining metrics for the collateralization profile? Can you link me to the current state of profiles (or describe) so I can see how it looks like?

[kilrau]

Closing here in favor of #1405