Closed gbalabasquer closed 3 years ago
clipper.chost
is 0 upon deployment. Should the deployer call clipper.upchost()
for each collateral with a clipDeploy
?
Note that
testchain
deployment is populating addresses for both DSValue (VAL
) and OSM (PIP
) for each collateral token in theaddresses.json
. Example:"ETH": "0xEddA486ddB7eaa8f9FEce8c682EFD40f535b3Ad5", "VAL_ETH": "0xb4c79daB8f259C7Aee6E5b2Aa729821864227e84", "PIP_ETH": "0xb4c79daB8f259C7Aee6E5b2Aa729821864227e84", "MCD_JOIN_ETH_A": "0x9119B5d8b735E4cEbaE7386AF6cD2B863c7d35A8", "MCD_FLIP_ETH_A": "0x0BD7632aF5F7020575e59E80ABbca739035Ac0EC",
Yes, this always worked this way when not deploying an osm
as it is the contract to get the value, but also the pip that uses the spotter. It might not be the best way and we might want to evaluate other options but that is out of scope of this PR.
clipper.chost
is 0 upon deployment. Should the deployer callclipper.upchost()
for each collateral with aclipDeploy
?
This is weird as upchost
is being called, after setting the mat
and dust
but still setting it to 0. I can see the tx was executed in the logs. Need to figure it out what is happening as if then I call manually upchost again, it just works as expected.
Wait, that's the reason, we don't care about mat
, but chop
. Need to move the code a few lines below, so upchost
will work. Doing it now.
@EdNoepel should be fixed now, it was great catch
Note that
testchain
deployment is populating addresses for both DSValue (VAL
) and OSM (PIP
) for each collateral token in theaddresses.json
. Example: