At the moment, availability certificates must contain a majority of signatures, while the Orderers module has no signatures in the PBFT good case (only for the view change). This means that if the adversary controls n/3 or more replicas, it can cause a disagreement (double-spend, triple-spend, ..., n/3-fold-spend even) at the cost of not finding any replica guilty of a disagreement (and the disagreement will not even be detected necessarily).

Also, the availability certificate is generated just by checking the validity of its metadata and including the multisigcollector ID (mscid), so no fraudproof can be generated (multiple certificates can be generated with the same mscid, both in the current implementation that generates multiple certificates for one slot and in the previous one as the mscid was the same for all slots of the same ISS segment.

This is not an issue for the Orderers code under the assumption of f<t, but it is an issue when applied to subnets with collateral and with slashing to deter disagreements (as the rational adversary will never be deterred from causing a disagreement).

The solution would imply one of the following:

a) Improving accountability of the availability certificate by:
1- Having each availability certificate include a new certificateID that is monotonically increasing for all certificates sharing the same mscid,
2- Explicitly requiring a specific number of certificates per slot (suboptimal)
3- Verifying that proposals match their intended slot with mscid and ceritificateIDs before sending a prepare message.
b) Adding signatures to PBFT , and adding a broadcast of a vector of signatures to support fraudproofs. Not sure that view change should not need to suffer certain changes too to ensure fraudproofs there as well.
c) Adding an extra round at the end of orderers, as an optional pluggable module that adds 2 reliable broadcasts at the end of ISS. In the first broadcast, all replicas broadcast a signature of their local decision and second they broadcast a strongQuorum() number of signatures they heard from. (O(n^3) bit complexity). This can be reduced to O(n^2) bit complexity (same as consensus) in the common case with a fallback to O(n^3) in the case of a disagreement with threshold signatures. (see follow-up comment for more details).

I would go with c), as a) only works if adding a synchronization step between availability and ordering modules (which we do not want for performance), and b) requires modifying the orderers code to add signatures (which we may not always want in all applications). Going with c) allows adding detecting disagreements and generating fraudproofs as a module that can be easily plugged in to support accountability/ BFT forensics in any consensus protocol (and thus add support for collateral/slashing in subnets if wanted).

The other nice thing about c) is that it is optimal in communication complexity, resilient-optimal for f<strongQuorum() (not assuming anything on clients-code, otherwise f<n can be achieved), and that it can be plugged in any other consensus protocol module to provide accountability and fraudproofs on it. The drawback is that it can increase latency compared to b), but nothing that we cannot later improve specifically on b) if need be.