Request connext collateral based on order amount #1845
Comments
|
connext/indra#1405 (comment) + connext/rest-api-client#89 should get us all we need. Connext moved fast, and a PR for connext/indra#1405 is already up: connext/indra#1406 props to @rhlsthrm |
What if instead of putting it on hold we fail the
Hmm, replace order could also need additional collateral if the price changes. |
That would also work. Easier from an implementation perspective I guess (even though there would be a new check against "collateralization already in progress, don't re-request").
If the price changes and consequently amount exceeds remote balance. What we can do is, request 3% more from the node to account for that. |
Yep, some buffer would probably be nice to have. The scenario I was thinking of was when the user deposits additional funds to BTC/LTC channels/CEX. In that case the logic would be the same as regular |
kilrau
changed the title
|
@sangaman any thoughts/ideas? |
|
Reiterating @raladev 's question about this on yesterday's call: do we still ask the node to automatically collateralize a fixed % of the amount (boltz-style) on Thinking about this again, I think it's better to solely rely on order amounts to request collateral from the connext node. This is simply much more precise and the node's capital is used more efficiently. User's might deposit funds into a connext channel and never use it in an order or at least not for a long period of time. In that caes the nodes capital remains unused. And in the moment it is used for an order, chances are high that the needed collateral amount for the order is be larger than what the node collateralized (fixed %) before. Connext channels give us this flexibility, so we should use it. That means in particular, I suggest xud not to request and collateral based on |
I agree with this logic. Failing rather than waiting if the collateral/remote balance isn't sufficient, particularly since delaying an order isn't great UX given that prices may be changing and the order may no longer be desirable after collateral is there.
I think I'd be OK with this, but then would we expect that the first order that receives via Connext will always fail due to needing to wait for collateralization? Maybe it can be optional when using |
No, that's precisely what we would want to prevent here, at least failing as in "swap timeout failing". In the moment the first order receiving connext is placed, xud requests collateralization for the required amount. Question is if we fail the order on CLI level (@erkarl s suggestion) in that case or put it on hold in the background and automatically add it to the order book once the collateralization is through. The latter is much better from user perpective, but would be more complicated to implement I guess. For example we'd need a timer to fail the order, if collateralization is taking longer than X minutes, because then it might be undesirable for the user that the order goes through. |
Yes, I was referring to the order being rejected upon being submitted due to lack of collateral, not due to failing a swap. I'm not sure whether adding the order on a delay is better tho as I mentioned above since a user might only want the order to be good for a few seconds, particularly in the case of market orders. |
I'm strongly of the opinion that we shouldn't automatically place the order in the orderbook once the collateralization completes. My desired flow would be: |
|
Or alternatively the behaviour that @kilrau suggests would be behind a flag: |
Ok I see that. Let's go with Karl's suggestion. Regarding wording/structure of output I suggest: |
ghost
mentioned this issue
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is no longer requested upon depositing funds to a Connext channel, instead it is only requested upon placing orders. Closes #1845.
may we add some flag to autoplace order after collateralization? (replacing is annoying) @kilrau @erkarl |
We discussed before that this can be dangerous because the market may move significantly within the time the collateralization takes. As an optional flag this can be useful though (for people who understand the consequences). Other opinions? |
Yeap, i am talking about optional flag with false value as default (no autoplacement as default). |
|
I think I'd be ok with it, let's see what @erkarl and @sangaman think |
I'm also OK with an optional flag that enables this functionality. This can be done outside of this PR as a follow-up. |
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is no longer requested upon depositing funds to a Connext channel, instead it is only requested upon placing orders. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the missing capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
This adds a check when a new order is receiving tokens via connext that ensures we have sufficient collateral from the connext node to fulfill the order. If not, we fail the order request and request the additional collateral necessary. This involves the following changes: 1. The Connext client now tracks the inbound node collateral for each currency and refreshes this value every time it queries for channel balances and every time a collateral request completes. 2. Before placing a new order that is receiving Connext tokens we check the inbound amount against the available collateral for that currency. In the case of market orders, we use the best available matching price in the order book to calculate inbound & outbound amounts. 3. If the collateral is insufficient, the order will be rejected and a collateral request will be performed for the necessary capacity plus a 5% buffer. 4. Any other collateral checks while we're awaiting a response for a collateral request will not perform an additional collateral request so as to prevent duplicate calls. 5. Traders may repeat their order request and it will be accepted once sufficient collateral to complete the trade is acquired. 6. Collateral is only requested upon depositing funds to a Connext channel according to hardcoded collateral request minimums per currency. There are also several hardcoded collateral request minimums. If the capacity shortage is smaller than these minimums, the minimum amount will be requested instead. Closes #1845.
As discussed before, we should request channel collateralization (remote balance) from the connext node ahead of (swap) time to avoid on-the-fly collateralization.
How it could work:
placeOrderxudcheckstradinglimits/balanceendpoint to see if remote balance is thereDepending on:
connext/rest-api-client#89 -> PR: connext/rest-api-client#90
connext/indra#1405 (comment) -> PR: connext/indra#1406
The text was updated successfully, but these errors were encountered: