The BLUEPRINT_TYPE_HASH
is not properly encoded according to EIP-712 standard and will lead to integration issues when EIP compliant signers try to access various blueprint requisition functions.
In LibTractor.sol, the BLUEPRINT_TYPE_HASH
is declared. Important to notice the encoding of bytes operatorData
as its third parameter.
This is incorrect as the BLUEPRINT_TYPE_HASH
exists as an EIP-712 hash of the Blueprint struct, and the third parameter is the bytes32[] operatorPasteInstrs
which is of a significantly different type to the parameter encoded in the type hash.
As a result, when the blueprint hash is calculated, the returned has will be incorrect due to the use of incorrect typehashes and users/integrations that use "correct" typehashes that match the parameters of these functions will end up generating different signatures, causing them to revert when called.
The hash is not EIP-712 compliant, hence transactions implementing EIP-712 signatures correctly will revert as their on-chain counterpart will be different.
It is being used in the verifyRequisition
modifier in the TractorFacet.sol, which is used when publishing, cancelling and executing a tractor blueprint. Since this is basically the entire function of TractorFacet.sol, not being able to perform this makes the contract completely almost unusable, hence the high severity.
Manual Review
Recommend changing the BLUEPRINT_TYPE_HASH
to this.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.