Closed walkjivefly closed 2 years ago
Overall, it looks good. I built
eth-payment-processor
locally on my VPS4 from thefeature-SYS
branch, then called therequest_project
from my home computer to VPS4. This is the response I got:Here are my concerns/requests:
- I checked the
amount_tier{1,2}_sys
values returned and they do indeed correspond to the USD values I had set in mysources.yaml
config. +1partying_facetada However, I'm thinking we should probably change the name of those field toamount_tier{1,2}_wsys
just to minimize the chances some bozo will try to send actual SYS instead of wSYS for payment.- I don't see a
payment_nevm_address
field in the response. How will clients know where to send their wSYS?- I'm assuming the
amount_tier{1,2}_sysblock
fields are null simply because the sysBLOCK token doesn't exist yet, and those fields will be populated with real values once it does exists? How will you get price info for sysBLOCK if there is no sysBLOCK Liquidity Pool (LP) on Pegasys? Maybe for now you could assume sysBLOCK value is the same as aaBLOCK value...? It's probably a reasonable assumption for now, since the only way to acquire sysBLOCK initially will be to bridge BLOCK => sysBLOCK on multichain. Therefore, the price of sysBLOCK will be closely tied to the price of BLOCK until someone sets up an LP on Pegasys. (And the price of aaBLOCK seems to reflect the actual price of BLOCK as well as anything.) Ooo... just realized getting aaBLOCK value isn't going to work unless the host supports AVAX chain... Hmm...thinking
Strange! using curl I see
blockops@ops1:~/src/exrproxy-env/cli$ curl $OPS1/xrs/projects -X POST -H "Content-Type: application/json" -d '{"id":,"method":"request_project","params":[]}'|jq .
{
"result": {
"api_key": "NXy6CyfepaiWCj9qTIrHKOXTzctLfizqpWz_2FBDP7o",
"expiry_time": "2022-06-20 13:15:20 EST",
"payment_amount_tier1_aablock": null,
"payment_amount_tier1_ablock": null,
"payment_amount_tier1_eth": null,
"payment_amount_tier1_sys": 7.447292,
"payment_amount_tier1_sysblock": 32.586908,
"payment_amount_tier2_aablock": null,
"payment_amount_tier2_ablock": null,
"payment_amount_tier2_eth": null,
"payment_amount_tier2_sys": 37.236459,
"payment_amount_tier2_sysblock": 162.934539,
"payment_avax_address": null,
"payment_eth_address": null,
"payment_sys_address": "0xed44d1b478799C3A890F3C6537182Bd0887BC3Cc",
"project_id": "cd42e894-824c-4d33-ba9d-97ca0f82b2a1"
}
}
and using projects.py I get
blockops@ops1:~/src/exrproxy-env/cli$ ./projects.py --host=172.31.15.214 --new
Enterprise XRouter Environment Projects CLI
Project
name f690384b-39ff-477f-8d25-5a976dae1eb6
api_key e0PrVcr8pt9gDyuhLpFo_aTLfBTyLVIQ_pDp0OJLmMY
api_token_count 6000000
used_api_tokens 0
archive_mode None
expires None
active False
Payment
id 59
pending True
eth_token
eth_address
eth_privkey
avax_token
avax_address
avax_privkey
tier1_expected_amount -1.0
tier2_expected_amount -1.0
tier1_expected_amount_ablock -1.0
tier2_expected_amount_ablock -1.0
tier1_expected_amount_aablock -1.0
tier2_expected_amount_aablock -1.0
tx_hash
amount None
amount_ablock 0.0
amount_aablock 0.0
start_time 06/20/2022, 12:12:26
project f690384b-39ff-477f-8d25-5a976dae1eb6
nevm_token e0b20c9ff1da639d978828dc27d028e75a9987d572f3cbc208306490a753545d
nevm_address 0x0384c68C16783D5877fb802Bd5c07E1c5A9955A1
nevm_privkey 0xd633abb95291ffb6e1f9002f4a57391443230242d006b3ce2951537d571dcb24
tier1_expected_amount_sysblock 32.586908
tier2_expected_amount_sysblock 162.934539
tier1_expected_amount_sys 7.447292
tier2_expected_amount_sys 37.236459
amount_sysblock 0.0
amount_sys 0.0
Must be your turn to be the weirdness magnet!
Oh, silly me! You need exrproxy from branch feature-SYS as well.
Improvement! The response I get now from a call to
request_project
looks like this:Looking better! sys name changed to wsys... Thanks! nevm address now returned... great! The only thing that concerns me is the high quantity of sysblock requested for payment. I'm assuming this is just a reflection of the fact that sysblock doesn't actually exist yet, and therefore there is obviously no sysblock liquidity pool yet on Pegasys, which means it's impossible to get meaningful price data for sysblock?
It's using PSYS (the Pegasys governance token) as a proxy for sysBLOCK. This way I can test the functionality and when sysBLOCK is available just change the contract address. I think there will be one more push to close out the cosmetic wrinkles and then it's ready for deployment and for Pegasys to test with. Same with the exrproxy-env, exrproxy and xquery feature-SYS branches.
Would be great if you could confirm ETH/aBLOCK/aaBLOCK payments work as expected @ConanMishler....
It should be merged together with
Adds payment in WSYS and PSYS (temporarily used as a proxy for sysBLOCK which will hopefully be implemented soon (TM) by Multichain).
Initially this is expected to be used by Pegasys DEX, and later by other dApps on SYS NEVM.