Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(connext): request collateral for order amount #1885

Merged
merged 1 commit into from
Sep 24, 2020

Conversation

sangaman
Copy link
Collaborator

@sangaman sangaman commented Sep 10, 2020

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.

  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.

Note that this PR does not remove the collateralization that happens after depositing/opening a channel. I figure that can be done in a separate PR, but we may want to reconsider instead. One thing that occurred to me while working on this is that if we only issue market orders, the collateralization may never happen since it's based on requesting a fixed amount based on the price and quantity of orders we place. However, market orders don't have a price and therefore don't have a specific amount of collateral for us to request. Maybe there's a cleaner solution for dealing with this without requesting collateral after opening a channel, but I haven't thought of it yet.

@sangaman sangaman requested review from a user, kilrau and raladev September 10, 2020 07:39
@sangaman sangaman self-assigned this Sep 10, 2020
@kilrau
Copy link
Contributor

kilrau commented Sep 10, 2020

Does this also expose the connext remote balance in tradinglimits?

@sangaman
Copy link
Collaborator Author

Does this also expose the connext remote balance in tradinglimits?

Yes, trading limits should now return the actual collateral available for receiving payments, as opposed to a max number like it used to.

@kilrau
Copy link
Contributor

kilrau commented Sep 10, 2020

Here the discussion about adding a 3% buffer: #1845 (comment) . If you agree on adding it, let's do it @sangaman

@sangaman
Copy link
Collaborator Author

I updated this PR to remove collateral requests upon depositing funds to a channel and to use the best available price for market orders for purposes of calculating inbound/outbound amounts. I also added a 5% buffer to the amount of collateral requested, up from the 3% originally discussed to better handle the cases with market orders since we optimistically calculate the entire order based off the best available price.

@raladev
Copy link
Contributor

raladev commented Sep 14, 2020

  • collateralization does not work - buy 0.5 ETH/BTC 0.1 1. I see coll request and response in connext client and in logs of xud, but there is no node balance amount for ETH after response.

Screenshot from 2020-09-14 14-23-39
Screenshot from 2020-09-14 14-23-26
Screenshot from 2020-09-14 14-22-19
Screenshot from 2020-09-14 14-22-16

  • also im not sure why i saw collateralization only for first buy request. For second and third there is no collateral request in connext logs
simnet > buy 0.5 ETH/BTC 0.1 1
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
simnet > buy 0.5 ETH/BTC 0.1 1
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
simnet > buy 0.5 ETH/BTC 0.1 1
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
  • also it would be good add info about collateral - why is it required? because this flow misrepresent first impression.

Copy link
Contributor

@raladev raladev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For me it works for limit orders:

➜  xud git:(collateral-on-order) ✗ ./bin/xucli buy 0.01 ETH/BTC 0.01
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
➜  xud git:(collateral-on-order) ✗ ./bin/xucli buy 0.01 ETH/BTC 0.01
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
➜  xud git:(collateral-on-order) ✗ ./bin/xucli buy 0.01 ETH/BTC 0.01
matched 0.01 ETH @ 0.01 with peer FlightMillion order 5ce90f90-f691-11ea-af6a-b103d10b44b2, attempting swap...
successfully swapped 0.01 ETH with peer order 5ce90f90-f691-11ea-af6a-b103d10b44b2

lib/connextclient/ConnextClient.ts Outdated Show resolved Hide resolved
lib/connextclient/ConnextClient.ts Show resolved Hide resolved
@ghost
Copy link

ghost commented Sep 14, 2020

@raladev

also im not sure why i saw collateralization only for first buy request. For second and third there is no collateral request in connext logs

This is intentional to avoid over collateralizing the channel (we'll wait for the first collateralization to finish before attempting new ones).

@ghost
Copy link

ghost commented Sep 14, 2020

@sangaman could you also please rebase this against master?

@kilrau kilrau mentioned this pull request Sep 14, 2020
@raladev
Copy link
Contributor

raladev commented Sep 14, 2020

  • collateralization does not work - buy 0.5 ETH/BTC 0.1 1. I see coll request and response in connext client and in logs of xud, but there is no node balance amount for ETH after response.

checked one more time, same result.
Also checked for buy 5 ETH/BTC 0.1 1 same result too

@kilrau
Copy link
Contributor

kilrau commented Sep 14, 2020

Logs would be helpful I guess

@kilrau kilrau closed this Sep 14, 2020
@kilrau kilrau reopened this Sep 14, 2020
@raladev
Copy link
Contributor

raladev commented Sep 14, 2020

Logs would be helpful I guess

first comment contains xud and connext logs on screens

@sangaman
Copy link
Collaborator Author

  • collateralization does not work - buy 0.5 ETH/BTC 0.1 1. I see coll request and response in connext client and in logs of xud, but there is no node balance amount for ETH after response.

checked one more time, same result.
Also checked for buy 5 ETH/BTC 0.1 1 same result too

Does the collateral request ever complete for you? Based on the behavior and the logs, my best guess is that Connext is just taking a very long time to grant the collateral, longer than your testing period. I'd wonder if the same testing setup would succeed in placing an order ~hours later.

If xud is making the call and connext is receiving it, I'm not sure what else we can do from our end. I'm not too familiar with the process for requesting collateral from the connext node so maybe @erkarl will have more ideas here.

@ghost
Copy link

ghost commented Sep 15, 2020

Does the collateral request ever complete for you? Based on the behavior and the logs, my best guess is that Connext is just taking a very long time to grant the collateral, longer than your testing period. I'd wonder if the same testing setup would succeed in placing an order ~hours later.

In the screenshot above we can see that the connext client returned a response: https://user-images.githubusercontent.com/29906866/93080784-eeca8b00-f696-11ea-9a85-13a2a9318ab7.png

@ghost
Copy link

ghost commented Sep 15, 2020

I also managed to reproduce this on simnet:

➜  xud git:(collateral-on-order) ✗ ./bin/xucli buy 5 ETH/BTC 0.003
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute

Looking at connext client logs the collateralization request DID return (almost immediately), but nodeFreeBalanceOffChain did not increase.

[1600164359999] INFO  (2468344 on arbuntu): received request
    url: "/request-collateral"
    id: 367
    reqId: 367
[1600164360000] INFO  (2468344 on arbuntu): Getting client for publicIdentifier: indra5wdhrzMgR3DHrLJLBy726GDdS4DxCsns89UR9vTXWrkknQsubJ
2020-09-15T10:06:00.125Z [NodeApiClient] Node responded to indra5wdhrzMgR3DHrLJLBy726GDdS4DxCsns89UR9vTXWrkknQsubJ.indra6WRA6HQQTDQD1FC3KmdbpePijdcgLTqAdi2xy2Q2HqNeGn4cBh.1337.channel.request-collateral request in 124 ms
[1600164360126] INFO  (2468344 on arbuntu): request completed
    url: "/request-collateral"
    statusCode: 200
    reqId: 367

@sangaman
Copy link
Collaborator Author

Meant to post here that I'd rebased this branch and added tests for checking inbound capacity.

@ghost
Copy link

ghost commented Sep 15, 2020

@raladev so the issue was the the node needed to be configured to allow higher collateralization amounts. ETH collateralizations on simnet should now allow up to 55 ETH.

@sangaman
Copy link
Collaborator Author

@raladev so the issue was the the node needed to be configured to allow higher collateralization amounts. ETH collateralizations on simnet should now allow up to 55 ETH.

This makes a lot of sense, thanks for figuring it out.

@sangaman
Copy link
Collaborator Author

Evidently I had misunderstood how collateral requests work - I thought we were requesting the amount of additional collateral that we wanted when in fact we want to request the total collateral we want (including any existing collateral). I updated the PR to request the total amount of collateral we want, so in your tests above it should be 0.315 ETH which is 0.3 + 5%. I also updated the tests to account for this, including a case where we still expect to request the full amount of collateral needed + 5% even when we already have some existing collateral.

@raladev
Copy link
Contributor

raladev commented Sep 22, 2020

  • collateral for openchannel does not work now for USDT and for ETH. Not sure why it worked yesterday.
335f901a64c0c6indra_node2020-09-22T10:01:26.409Z [ChannelService] Rebalancing target for 0x0000000000000000000000000000000000000000 on 1337: {
Sep 22 13:01:335f901a64c0c6indra_node  "assetId": "0x0000000000000000000000000000000000000000",
Sep 22 13:01:335f901a64c0c6indra_node  "channels": [],
Sep 22 13:01:335f901a64c0c6indra_node  "id": 0,
Sep 22 13:01:335f901a64c0c6indra_node  "collateralizeThreshold": "0",
Sep 22 13:01:335f901a64c0c6indra_node  "target":           "100000000000000000",
Sep 22 13:01:335f901a64c0c6indra_node  "reclaimThreshold": "55000000000000000000"
Sep 22 13:01:335f901a64c0c6indra_node}
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.411Z [CF-GetFreeBalanceState] Executing with params: {"multisigAddress":"0x3Fe7..fED0","assetId":"0x0000..0000"}
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.413Z [CF-RpcRouter] Processed chan_getFreeBalanceState method in 2 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.414Z [ChannelService] Free balance 10000000 is less than or equal to upper reclaim bound: 55000000000000000000
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.415Z [ChannelService] Rebalance finished for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz on chain 1337, assetId: 0x0000000000000000000000000000000000000000
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.666Z [LockService] Releasing lock for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0 after 2147 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.668Z [LockService] Releasing lock for 0x7da6fd7573fda9c6478a66b87110283aae892b2371f8e9981b75b19b5b87e076 after 2146 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.669Z [LockService] Done releasing lock for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.670Z [MessagingInterface] Responded to indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz.indra6WRA6HQQTDQD1FC3KmdbpePijdcgLTqAdi2xy2Q2HqNeGn4cBh.1337.lock.release.0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0 in 4 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.672Z [LockService] Done releasing lock for 0x7da6fd7573fda9c6478a66b87110283aae892b2371f8e9981b75b19b5b87e076
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.673Z [MessagingInterface] Responded to indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz.indra6WRA6HQQTDQD1FC3KmdbpePijdcgLTqAdi2xy2Q2HqNeGn4cBh.1337.lock.release.0x7da6fd7573fda9c6478a66b87110283aae892b2371f8e9981b75b19b5b87e076 in 5 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.864Z [LockService] Acquiring lock for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0 (TTL: 21000 ms)
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.867Z [LockService] Acquired lock for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0 (value 15a413fdf606a1d7820274e178b0fa9b) after waiting 1 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.868Z [MessagingInterface] Responded to indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz.indra6WRA6HQQTDQD1FC3KmdbpePijdcgLTqAdi2xy2Q2HqNeGn4cBh.1337.lock.acquire.0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0 in 4 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.879Z [ChannelService] Rebalance type COLLATERALIZE for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz asset 0x0000000000000000000000000000000000000000 started on chain 1337 for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.881Z [CF-GetAppInstances] Executing with params: {"multisigAddress":"0x3Fe7..fED0"}
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.883Z [CF-GetAppInstances] Before execution complete in 2 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.885Z [CF-RpcRouter] Processed chan_getAppInstances method in 4 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.886Z [ChannelService] getDataFromRebalancingService for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz asset 0x0000000000000000000000000000000000000000 start
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.887Z [ChannelService] Rebalancing service URL not configured for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.893Z [ChannelService] Rebalancing target for 0x0000000000000000000000000000000000000000 on 1337: {
Sep 22 13:01:335f901a64c0c6indra_node  "assetId": "0x0000000000000000000000000000000000000000",
Sep 22 13:01:335f901a64c0c6indra_node  "channels": [],
Sep 22 13:01:335f901a64c0c6indra_node  "id": 0,
Sep 22 13:01:335f901a64c0c6indra_node  "collateralizeThreshold": "0",
Sep 22 13:01:335f901a64c0c6indra_node  "target": "100000000000000000",
Sep 22 13:01:335f901a64c0c6indra_node  "reclaimThreshold": "55000000000000000000"
Sep 22 13:01:335f901a64c0c6indra_node}
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.896Z [CF-GetFreeBalanceState] Executing with params: {"multisigAddress":"0x3Fe7..fED0","assetId":"0x0000..0000"}
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.898Z [CF-RpcRouter] Processed chan_getFreeBalanceState method in 2 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.899Z [ChannelService] Free balance 10000000 is greater than or equal to lower collateralization bound: 10000000
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.900Z [ChannelService] Rebalance finished for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz on chain 1337, assetId: 0x0000000000000000000000000000000000000000
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:26.901Z [MessagingInterface] Responded to indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz.indra6WRA6HQQTDQD1FC3KmdbpePijdcgLTqAdi2xy2Q2HqNeGn4cBh.1337.channel.request-collateral in 46 ms
Sep 22 13:01:335f901a64c0c6indra_node2020-09-22T10:01:28.435Z [CF-ProposeProtocol] [0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0] Response started
  • 0.21*1.05= 0.2205 (all is fine for that order); 0.23*1.05=0.2415 but xud requests 0.32 instead of that. Also after that i placed 10 eth order, but collateral amount was correct (10*1.05 =10.5)
simnet > buy 0.21 ETH/BTC 0.1
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
simnet > buy 0.23 ETH/BTC 0.1
2 UNKNOWN: channel collateralization in progress, please try again in ~1 minute
22/09/2020 10:11:05.850 collateral of 0 for ETH is insufficient for order amount 21000000
22/09/2020 10:11:05.851  sending request to /request-collateral: {"assetId":"0x0000000000000000000000000000000000000000","amount":"220500000000000000"}
22/09/2020 10:11:05.851 call /xudrpc.Xud/PlaceOrder errored with code 2: channel collateralization in progress, please try again in ~1 minute

22/09/2020 10:20:41.473: collateral of 22050000 for ETH is insufficient for order amount 23000000
22/09/2020 10:20:41.473: sending request to /request-collateral: {"assetId":"0x0000000000000000000000000000000000000000","amount":"320500000000000000"}
22/09/2020 10:20:41.473: call /xudrpc.Xud/PlaceOrder errored with code 2: channel collateralization in progress, please try again in ~1 minute
22/09/2020 10:20:42.399: sending request to /balance/0x0000000000000000000000000000000000000000
22/09/2020 10:20:42.401: sending request to /balance/0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4

22/09/2020 10:37:40.010: collateral of 32050000 for ETH is insufficient for order amount 1000000000
22/09/2020 10:37:40.010: sending request to /request-collateral: {"assetId":"0x0000000000000000000000000000000000000000","amount":"10500000000000000000"}
22/09/2020 10:37:40.011: call /xudrpc.Xud/PlaceOrder errored with code 2: channel collateralization in progress, please try again in ~1 minute

  • something wrong with USDT profile on simnet, i can get only 100 USDT as collateral amount.
2/09/2020 11:32:37.005 [CONNEXT] debug: collateral of 10000000000 for USDT is insufficient for order amount 40000000000
22/09/2020 11:32:37.005 [CONNEXT] trace: sending request to /request-collateral: {"assetId":"0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4","amount":"420000000"}
22/09/2020 11:32:37.006 [RPC] error: call /xudrpc.Xud/PlaceOrder errored with code 2: channel collateralization in progress, please try again in ~1 minute
22/09/2020 11:32:37.156 [CONNEXT] trace: sending request to /balance/0x0000000000000000000000000000000000000000
22/09/2020 11:32:37.158 [CONNEXT] trace: sending request to /balance/0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4
22/09/2020 11:32:37.703 [CONNEXT] trace: new inbound capacity (collateral) for ETH of 550000000
22/09/2020 11:32:37.727 [CONNEXT] trace: new inbound capacity (collateral) for USDT of 10000000000

Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.346Z [ChannelService] getDataFromRebalancingService for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz asset 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4 start
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.347Z [ChannelService] Rebalancing service URL not configured for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.447Z [ChannelService] Token has 6 decimals, converting rebalance targets
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.449Z [ChannelService] Rebalancing target for 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4 on 1337: {
Sep 22 14:18:135f901a64c0c6indra_node  "assetId": "0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4",
Sep 22 14:18:135f901a64c0c6indra_node  "channels": [],
Sep 22 14:18:135f901a64c0c6indra_node  "id": 0,
Sep 22 14:18:135f901a64c0c6indra_node  "collateralizeThreshold": "5000000",
Sep 22 14:18:135f901a64c0c6indra_node  "target": "20000000",
Sep 22 14:18:135f901a64c0c6indra_node  "reclaimThreshold": "100000000"
Sep 22 14:18:135f901a64c0c6indra_node}
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.449Z [CF-GetFreeBalanceState] Executing with params: {"multisigAddress":"0x3Fe7..fED0","assetId":"0x292B..91d4"}
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.449Z [ChannelService] Converted rebalance targets: {
Sep 22 14:18:135f901a64c0c6indra_node  "assetId": "0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4",
Sep 22 14:18:135f901a64c0c6indra_node  "channels": [],
Sep 22 14:18:135f901a64c0c6indra_node  "id": 0,
Sep 22 14:18:135f901a64c0c6indra_node  "collateralizeThreshold": "5000000",
Sep 22 14:18:135f901a64c0c6indra_node  "target": "20000000",
Sep 22 14:18:135f901a64c0c6indra_node  "reclaimThreshold": "100000000"
Sep 22 14:18:135f901a64c0c6indra_node}
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.453Z [CF-GetFreeBalanceState] Before execution complete in 4 ms
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.454Z [CF-RpcRouter] Processed chan_getFreeBalanceState method in 5 ms
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.454Z [ChannelService] Free balance 100000000 is less than or equal to upper reclaim bound: 100000000
Sep 22 14:18:135f901a64c0c6indra_node2020-09-22T11:18:13.454Z [ChannelService] Rebalance finished for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz on chain 1337, assetId: 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.363Z [ChannelService] Rebalance type COLLATERALIZE for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz asset 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4 started on chain 1337 for 0x3Fe7Bf55F8fe2B094778B61299Ba0e46A72ffED0
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.366Z [CF-GetAppInstances] Executing with params: {"multisigAddress":"0x3Fe7..fED0"}
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.381Z [CF-GetAppInstances] Before execution complete in 15 ms
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.383Z [CF-RpcRouter] Processed chan_getAppInstances method in 17 ms
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.384Z [ChannelService] getDataFromRebalancingService for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz asset 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4 start
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.385Z [ChannelService] Rebalancing service URL not configured for indra7EB88ypa5nkA9ZTAjsgiyCXxhTb4SXsChNGQrxzjdZqGT3zamz
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.490Z [ChannelService] Token has 6 decimals, converting rebalance targets
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.493Z [ChannelService] Converted rebalance targets: {
Sep 22 14:21:365f901a64c0c6indra_node  "assetId": "0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4",
Sep 22 14:21:365f901a64c0c6indra_node  "channels": [],
Sep 22 14:21:365f901a64c0c6indra_node  "id": 0,
Sep 22 14:21:365f901a64c0c6indra_node  "collateralizeThreshold": "5000000",
Sep 22 14:21:365f901a64c0c6indra_node  "target": "20000000",
Sep 22 14:21:365f901a64c0c6indra_node  "reclaimThreshold": "100000000"
Sep 22 14:21:365f901a64c0c6indra_node}
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.498Z [ChannelService] Rebalancing target for 0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4 on 1337: {
Sep 22 14:21:365f901a64c0c6indra_node  "assetId": "0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4",
Sep 22 14:21:365f901a64c0c6indra_node  "channels": [],
Sep 22 14:21:365f901a64c0c6indra_node  "id": 0,
Sep 22 14:21:365f901a64c0c6indra_node  "collateralizeThreshold": "5000000",
Sep 22 14:21:365f901a64c0c6indra_node  "target": "20000000",
Sep 22 14:21:365f901a64c0c6indra_node  "reclaimThreshold": "100000000"
Sep 22 14:21:365f901a64c0c6indra_node}
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.500Z [CF-GetFreeBalanceState] Executing with params: {"multisigAddress":"0x3Fe7..fED0","assetId":"0x292B..91d4"}
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.503Z [CF-GetFreeBalanceState] Before execution complete in 3 ms
Sep 22 14:21:365f901a64c0c6indra_node2020-09-22T11:21:36.505Z [CF-RpcRouter] Processed chan_getFreeBalanceState method in 5 ms
  • collateral logs stil contains different unit precision
22/09/2020 11:17:53.080 [CONNEXT] trace: sending request to /request-collateral: {"assetId":"0x292Ba2F10dbFB8925A209d3AdF09C2D2b1f491d4","amount":"100000000"}
22/09/2020 11:18:22.584 [CONNEXT] trace: new inbound capacity (collateral) for USDT of 10000000000
  • need to think about trading limits because of collateral max amount - it blocks order placing for bigger amounts.

Copy link
Contributor

@raladev raladev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Above

@sangaman
Copy link
Collaborator Author

I needed to make some changes for the collateral request upon opening channels to go with requesting full collateral instead of incremental amounts. I just pushed that so it should work.

[ ] 0.211.05= 0.2205 (all is fine for that order); 0.231.05=0.2415 but xud requests 0.32 instead of that. Also after that i placed 10 eth order, but collateral amount was correct (10*1.05 =10.5)

This is because of the minimum collateral request size. The minimum is 0.1 for ETH so when we already have 0.2205, we jump up to to 0.3205 for the next request (rather than 0.2415). That's so that we don't wind up making lots of small collateral requests. Is that also how you understand it @kilrau?

@kilrau
Copy link
Contributor

kilrau commented Sep 22, 2020

Yup, correct.

@raladev
Copy link
Contributor

raladev commented Sep 22, 2020

  • no collaterization process for market orders on LND/CONNEXT pair (Connext/LND pair works fine). Same for one side of connext/connext pair (only buy works correctly)
    message (55).txt
    Screenshot from 2020-09-22 19-57-58

@sangaman
Copy link
Collaborator Author

@raladev Thanks again for detecting that issue. I wasn't correctly identifying market orders by their price (which, the way we do it, isn't undefined within the placeOrder method but is rather 0 for sell orders and infinity for buy orders). I fixed that and also added some tests to verify that placeOrder is correctly calculating inbound and outbound amounts for the order. That goes along with the other set of tests that verify ConnextClient is requesting the right amount of collateral (once we've calculated the correct amounts).

@sangaman
Copy link
Collaborator Author

Rebased to get latest USDT/DAI contract info.

raladev
raladev previously approved these changes Sep 24, 2020
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.
@sangaman
Copy link
Collaborator Author

I updated the PR to add the INSUFFICIENT_COLLATERAL error to the list of errors that return the failed precondition grpc error code as per Karl's suggestion.

@sangaman sangaman requested a review from a user September 24, 2020 13:46
@sangaman sangaman merged commit 0ac95fe into master Sep 24, 2020
@sangaman sangaman deleted the collateral-on-order branch September 24, 2020 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Request connext collateral based on order amount
3 participants