Request to refresh datacap allowance after pathway address modification
Opened this issue · 9 comments
I requested to modify the pathway address for CoinSummer Labs and MinerDAO, and now they are both correct.
The new address has no datacap allowance, and the old address should have its datacap allowance removed.
CoinSummer Labs
Previous address: f26btyj7einvdsg2n2sq34tcdvvspzk6yld6grftq
New address: f23q74wvk6zq2dfopfe4wbt2tal2fkwicexcqui5q
MinerDAO
Previous address: f2uib6cqjmos6ir4ajx4aqt4pbglrrsd7w6ubovki
New address: f2gelosrtlc7iciehlytdrz2dqsakgadtuclp4eli
The initial allocated datacap of both are 5PiB.
Confirmed via SLACK DMs that the ledger is no longer in possession - need a new Multisig (and not just an additional signer)
Hello @maxvint
Checking records and Filfox and it looks like the Governance team created the two previous f2 msigs (https://filfox.info/en/address/f26btyj7einvdsg2n2sq34tcdvvspzk6yld6grftq & https://filfox.info/en/address/f2uib6cqjmos6ir4ajx4aqt4pbglrrsd7w6ubovki). Therefore, we still have a signer and threshold of 1, so we could add a new signer and remove an old address.
In this case, we would prefer to update these f2 msigs with the new f1 address that you want, rather than involving the RKH (which will require more time) to remove the DataCap from the f2 and create new DataCap at the new f2 addresses you provided.
I can go ahead and add the two f1 addresses you have inside the f2 addresses you provided, and remove the old f1 addresses. After that, if you would like, you have the ability to remove our Governance team f1 address from inside the msig, but know that we wouldn't be able to make future changes like this if you remove that address. Another flag, you are requesting the same f1 address for both of these pathways. This should be fine, since the tracking will happen based on the f2 pathway address, but generally it is better to create new unique signer addresses, to help partition these allocators.
CoinSummer Labs 1060
- Previous address: f26btyj7einvdsg2n2sq34tcdvvspzk6yld6grftq
- Previous f1 (remove): f1gn6jq55uyx5eir2a7isc6t63fq7lmhrcpgdo2wy
- New f1 (add, from provided f2 above): f1bv4fwfmiuww25jhwqvtjsjofxu77iyhqac4j6qy
MinerDAO 1065
- Previous address: f2uib6cqjmos6ir4ajx4aqt4pbglrrsd7w6ubovki
- Previous f1 (remove): f17w2vhqlyyzxkuayiavfkc6jxr4adonvuw3tfefq
- New f1 (add, from provided f2 above): f1bv4fwfmiuww25jhwqvtjsjofxu77iyhqac4j6qy
Please confirm if you would like me to edit the existing f2 msigs, so that we do not have to make any changes to the DataCap.
Hello @galen-mcandrew
Thank you so much. I confirm the solution you provided above.
CoinSummer add: https://filfox.info/en/message/bafy2bzaceb7ih3xtsaas6gagnvc6jqts7m7qfu7sthstkcfejelsv45ibkbyq?t=4
MinerDAO add: https://filfox.info/en/message/bafy2bzacebv4eudbopd3ddslq55hrgps354o4zgnr3edgydqnzgozz244bwnu?t=4
@maxvint please review, the new f1 address has been added to the above f2 addresses
@Kevin-FF-USA please verify the allocator JSON files for 1060 & 1065 have been updated with this new f1 signer
I have confirmed that the new f1 address has been added, and the JSON file for https://github.com/filecoin-project/Allocator-Registry/blob/main/Allocators/1060.json and https://github.com/filecoin-project/Allocator-Registry/blob/main/Allocators/1065.json have also been updated.
However, the Allocator’s DataCap balance is 0B when I sign an application. An error alert appears saying, “Amount is bigger than the allowance.”
Could you please check the details and help identify what might have gone wrong?
Hey Max,
Just wanted to keep you updated. Working on getting this corrected. When there is a new change like this to an existing pathway, it requires merging of the past records. Should have this up shortly. Thanks for your patience and keeping us updated.
Hey @Kevin-FF-USA
I have been waiting for a long time, and several clients have reached out for datacap approval but have been unable to proceed due to this issue. Could you please prioritize and resolve this at your earliest convenience? I would really appreciate your help.
Checking the JSON files and it appears that the recorded f2 addresses were changed in June. This caused a problem, because just editing the JSON with a different f2 address does not move the DataCap.
The original f2 addresses (f26btyj7einvdsg2n2sq34tcdvvspzk6yld6grftq & f2uib6cqjmos6ir4ajx4aqt4pbglrrsd7w6ubovki) still have 5PiB of DataCap, and have the correct signers on-chain (f1bv4fwfmiuww25jhwqvtjsjofxu77iyhqac4j6qy).
I have opened and merged 2 PRs to revert these JSON files back to the correct f2 address (#359 & #358). The tooling should now check that on-chain f2 and allow for the DataCap to be awarded to your clients. Please try again and let us know!
Hey @Kevin-FF-USA @galen-mcandrew 👋
Great news - I've tested everything and it's all working perfectly now! The DataCap balance is showing correctly and applications are processing smoothly. This is exactly what we needed.
Really appreciate you both taking the time to fix this issue. Your help made a huge difference for us and our clients.
Thanks again for the great support! 🙌