Maverick Verifies Matvecs Without Taxing the Server

Maverick's new primitive verifies a delegated matrix-vector multiplication with information-theoretic soundness, no trusted setup, and, in the authors' words, virtually no server overhead. To their knowledge it is the first protocol for matvec delegation with those properties together.

Two of those properties do more work than the third. Information-theoretic soundness means the guarantee does not weaken against a server with more compute than you assumed, so there is no security parameter to tune for correctness and no hardness assumption a future algorithm could break. No trusted setup means there is no separate ceremony whose output everyone has to trust before the protocol is safe to use. "Virtually no server overhead" is the empirical claim, and it is the one that has to hold up on a benchmark.

Matvec is where the paper points, on the grounds that it is a dominant operation in LLMs. That is as far as the argument goes in the abstract: pick a common operation, hand it to a server that has more compute than the client.

The verification primitive is meant to be combined with LPN-based pseudorandom masking to provide input privacy. That is the paper's own description of how the two halves fit. How a masked vector gets checked, and what the client and server exchange, the abstract does not say.

Existing privacy and verification protocols for this setting often impose substantial server overhead or introduce additional trust assumptions, per the paper. Maverick claims neither. The overhead number is the one to watch: if checking a matvec costs the server more than the matvec itself, the economics do not work regardless of how good the privacy is.

Verification here is information-theoretic. The check on the server's arithmetic holds regardless of what the server computes, and does not rest on a hardness assumption. Privacy does. Input privacy comes from LPN-based pseudorandom masking, and LPN, learning parity with noise, is a hardness assumption. A title promising "private and verifiable" is bundling a very strong property with a weaker one, and at least this paper says which is which.

The numbers, on Qwen3-4B, measured in tokens per second against running the model locally:

At one client thread with masks generated on the fly, delegation buys 17x. Precompute the masks and it buys 45x. Drop privacy and ask only for verification and you get 44x, essentially the same as precomputed masks. So mask generation is where the client's time goes, and once it is out of the picture, privacy costs little on top of verification. Moving to four client threads drops all three columns to 13x, 18x and 17x, and the abstract does not explain why.

Every ratio there is net of the client's own masking and verification work.

The 45x assumes the client can generate masks ahead of the multiplication, outside the latency-critical path. Verification-only at 44x is the third column, and it is the posture for a case where you trust the server with your inputs but not with its arithmetic.

The second set of measurements is client-side microbenchmarks with simulated network delay, run once server computation is no longer the bottleneck, across client thread counts of one to eight. They report ranges rather than single figures: 12x-20x, 34x-135x and 38x-157x for the same three configurations. I would want the per-configuration breakdown before reading much into the width of those.

The prototype points to a third option for anyone on a 4B-ish open model: delegate the matvec to a bigger machine and keep both correctness and input privacy. Until now, a privacy-sensitive workload on a 4B-ish model meant either local inference on whatever CPU you have, or sending inputs to a provider. The cost of the new option lands on the client, and it is bounded by a machine you already own rather than a GPU you don't.

The abstract also names efficient batch verification as part of the primitive. Batching is what would keep verification affordable across a long generation rather than a single multiplication, and a generation is a long run of these multiplications, so the question is whether the check stays cheap when it runs hundreds of times. The reported figures are aggregate throughput, not a per-token breakdown, so there is no way to see how the cost amortises as a sequence gets longer.

Three things I would want before believing the headline number. The abstract reports ratios and no absolute tokens per second, so a 44x gain could be three tokens per second or thirty, and nothing here distinguishes those. The evaluation is one 4B model on a CPU server, so nothing says the overheads behave the same at larger hidden dimensions or on GPU hardware. And the LPN parameters are not in the abstract, which means the strength of the privacy claim, as opposed to the verification claim, is not checkable from what is quoted here. The verification result is the one I would take at face value, because information-theoretic soundness has no parameter to get wrong. The rest is a benchmark from the authors until someone reproduces it.