In my integration tests curiously multi-contributor contracts were failing until I realised that we were using msg.sender as the operator which is incorrect in the multi-contributor flow.
When you have a multi-contributor contract, that calls addBLSPublicKey on the rewards contract on the operator's behalf. This means that msg.sender is set to the multi-contribution contract. Then, in addBLSPublicKey we'd use the msg.sender to validateProofOfPossession but also emit a NewServiceNodeV2 log with the contract address.
This is incorrect and would prevent the operator from being able to exit the node. It'd also fail checks in core where it expects the 1st contributor to be the operator. The fix here is to correctly use msg.sender for transferring the stake and the 1st contributor as the operator for the SN metadata.
Thanks, have squashed the bugs back to the base commit (and fixed the syntax error in the unchecked section). Added an additional commit to fix the C++ tests since we got it working anyway, was a small fix.
In my integration tests curiously multi-contributor contracts were failing until I realised that we were using
msg.sender
as the operator which is incorrect in the multi-contributor flow.When you have a multi-contributor contract, that calls
addBLSPublicKey
on the rewards contract on the operator's behalf. This means thatmsg.sender
is set to the multi-contribution contract. Then, inaddBLSPublicKey
we'd use themsg.sender
tovalidateProofOfPossession
but also emit aNewServiceNodeV2
log with the contract address.This is incorrect and would prevent the operator from being able to exit the node. It'd also fail checks in core where it expects the 1st contributor to be the operator. The fix here is to correctly use
msg.sender
for transferring the stake and the 1st contributor as the operator for the SN metadata.