Outsource a computation and you face a quiet question: how do you know the server actually computed the right answer rather than a cheap, plausible-looking wrong one? Re-running the computation yourself defeats the purpose of outsourcing it. Verifiable computation is the cryptographic answer — the server returns the result plus a short proof that the result is correct, and checking the proof is far cheaper than redoing the work.

Lagrange Labs landed two related grants in 2025 in this space. US12368596B2, “Systems and methods for cryptography” (July 22, 2025), and US12400019B1, “Systems and methods for cryptographically verifying queries” (August 26, 2025). The inventor team includes Papamanthou and Srinivasan, names tied to serious academic work on verifiable computation and authenticated data structures.

“Methods and systems are provided for cryptographically verifying SQL queries. The method comprises: computing a succinct digest for a table stored in a database; receiving a query in structured query language (SQL) for querying data in the table; decomposing the query into one or more basic queries;…”— U.S. Patent No. 12,400,019 source

The query-verification grant's claim is a clean, end-to-end pipeline, and each stage is a deliberate design choice. Claim 1 begins by “computing a succinct digest for a table stored in a database,” receives an SQL query, then “decomposing the query into one or more basic queries, wherein each… comprises a verifiable SQL operator from a library of verifiable SQL operators, and wherein the verifiable SQL operator is a Succinct Non-interactive Argument of Knowledge (SNARK) proof for a statement involving a succinct digest of a table.” It then computes “one proof per basic query in parallel and in a distributed fashion,” and verifies the whole query “by verifying the previously computed proofs in parallel, and checking for consistency of their public statements, according to the previously executed query decomposition.” So the architecture decomposes a complex SQL query into a library of pre-built verifiable operators, proves each independently and concurrently, and stitches the operator proofs together by checking that their public inputs and outputs line up.

The dependent claims name the cryptographic substrate. Claim 2 makes the digest “a collision resistant representation of the table,” and claims 3 and 4 give two concrete constructions: a “Merkle tree” or an “order-agnostic hash function” — the latter notable because it lets the digest be insensitive to row ordering. Claim 5 has the digest “encode metadata related to an attribute name of the table or an indexing of the table,” so the proof can bind to schema, not just raw rows. The succinctness guarantees are claimed explicitly and separately: claim 8 says the proof size depends on “a number of the one or more basic queries,” while claim 9 — re-asserted as its own independent claim in claim 22 — says the proof size is “not dependent on a size of the table.” That table-size-independence is the entire economic argument for the system: you can verify a query against a billion-row table with a proof whose size is governed by the query's structure, not the data's volume.

Claim 10 supplies the scaling mechanism, and it is specific: computing and verifying the proofs “comprises using Map/Reduce circuits for Reckle trees.” That is the distributed-proving engine behind “in parallel and in a distributed fashion” — a Map/Reduce decomposition over a Reckle-tree structure, which is exactly the kind of construction needed to prove queries over very large tables without a single prover doing all the work serially. The companion grant, US12368596B2, carries the more general cryptography claims, and its CPC tags (H04L 9/3236 for hash-based mechanisms, H04L 9/50 for blockchain) versus the data-protection tags on the query grant show the deliberate split: a general primitive grant and a specific application grant.

The query-verification framing is the practically interesting one. Imagine a database where you do not run the server but still need to trust its answers — a blockchain state query, an outsourced analytics result. The patent claims producing a proof that a returned query result is exactly what the underlying data implies, so a light client can verify correctness without holding or scanning the whole dataset. The decomposition-into-verifiable-operators design is what makes arbitrary SQL tractable: rather than building one monolithic circuit per query, the system composes proofs from a fixed library of operators and proves consistency at the seams.

These proofs are succinct and rest on the SNARK machinery named directly in claim 1 — short proofs that are fast to verify regardless of how large the underlying computation was. The value is the asymmetry the claims encode: expensive to prove (a proof per basic query, computed in a distributed Map/Reduce), trivial to check (verify in parallel, with proof size independent of table size).

Per the desk's rules: these are issued grants (one B2, one B1), not applications, and they claim systems and methods, not shipped products — though Lagrange's work on verifiable computation for blockchain and data is the obvious context. The pairing of a general cryptography grant with a specific query-verification grant is a typical build-the-core-then-apply-it pattern.

For the reader watching the zero-knowledge frontier, query verifiability is where the abstract SNARK machinery meets a concrete, marketable need: in a world of outsourced and decentralized computation, being able to prove an answer is correct — cheaply, succinctly, without re-execution — is foundational. These grants stake out that ground, down to the digest construction, the operator library, and the table-size-independent proof.