I was checking the OCR2Base.sol file in the CCIP repo and was wondering what the i_uniqueReports variable stands for. Especially, why would it change the transmit() function such that the expected number of signatures changes:

uint256 expectedNumSignatures;
if (i_uniqueReports) {
  expectedNumSignatures = (configInfo.n + configInfo.f) / 2 + 1;
} else {
  expectedNumSignatures = configInfo.f + 1;
if (rs.length != expectedNumSignatures) revert WrongNumberOfSignatures();
if (rs.length != ss.length) revert SignaturesOutOfRegistration();

I have taken a look at their older OCR PDF, but I don't see anything that may resemble this.

You can see the shared excerpt in the following link at line 219: https://github.com/smartcontractkit/ccip/blob/ccip-develop/contracts/src/v0.8/ccip/ocr/OCR2Base.sol

Thank you very much in advance!

1 Answer 1


It is important to understand that Smart Contracts verify signatures on-chain, which can be costly. The more signatures, the higher the cost, so we should have as few signatures as possible. A report is considered valid if it has f+1 signatures, which means that at least one of the f+1 signers is correct. Remember that f is the maximum number of potentially malicious oracles. This may be enough for some use cases.

However, there is a scenario where the current leader of OCR report generation can be malicious and force a subset of oracles to create report r, while another subset creates report r'. Since f+1 oracles sign both reports, they are considered valid but not unique. As a result, one transmitter might transmit report r while another might transmit report r'.

We use the uniqueReports flag to avoid this scenario, which forces each report to be signed by 2f+1 oracles. This ensures that it is impossible to have two different subsets of oracles that sign different reports. Since we only have 3f+1 oracles in total, the two sets would intersect at least once with a correct oracle that would not sign both r and r'. This property is known as the quorum intersection.

By setting the uniqueReports flag, a transmitter can only ever transmit a unique report. However, even with f+1 signatures, we can depend on the blockchain to choose which report to finalize first among r and r'. This may be acceptable for some use cases but not for others.

OCR3 combines the best of both worlds, as it only requires f+1 signatures to be verified on-chain but always produces unique reports. This is achieved by decoupling consensus on unique reports from gathering signatures on the reports.

  • Thank you for the clarity! May I ask then, what would be some use cases in which it would be considered less problematic not to have unique reports? Also, where could I find info as detailed as your answer for OCR2 and OCR3? I can't find much beyond Youtube conference videos and these are a bit too superficial.
    – PensoGlide
    Commented Dec 13, 2023 at 12:01
  • A note for a future reader: 2f + 1 arises as the minimum condition that satisfies n >= 3f, in the sense that ((configInfo.n + configInfo.f) / 2 + 1) >= 2f + 1
    – PensoGlide
    Commented Dec 13, 2023 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.