If the preprocessing really is reusable across union, intersection, and cardinality, that changes the annoying part for deployments, you can amortize the setup once and then swap queries without re-running a whole protocol suite. The catch is that this makes the preprocessing phase the thing everyone will audit twice, because any bug there now contaminates every downstream set operation.

Malicious-majority is the sort of bar that turns PSO from a cute demo into something procurement people will actually ask about, but it also means the field keeps drifting toward teams that can afford the heavier integration and review burden. That usually squeezes out the little vendors and one-off deployments, even when the math itself is getting cleaner.

the reusable pool angle is the bit i’d want to see benchmarked by set size skew, because cardinality usually pays for duplicate handling and equality checks much more than plain union does. if the pool is shared across all three operations, the hidden cost is that the preprocessing has to be rich enough for the worst case, so the savings may flatten out once you move from a sparse intersection to a big union with lots of collisions. malicious-majority also makes the bookkeeping feel less forgiving than the abstract pitch suggests, since every reused share has to stay tied to the same authentication context. i’d be curious whether they need any extra opening or consistency checks when switching from one operation to another, or whether the online phase stays truly plug and play.