# Commitments

> Every committed column is opened with Mercury, a multilinear commitment over KZG with a constant-size opening. What it costs, how a shard batches all its columns into one opening, and how recursion defers the pairing.

Every column Apogee commits is a multilinear polynomial, a table of `2^n` evaluations over the boolean cube. Every one of them is committed and opened with **Mercury** (Eagen and Gabizon, ePrint 2025/385), finished by the batched KZG opening of BDFG20 (Boneh, Drake, Fisch and Gabizon, ePrint 2020/081). The specification pins what the papers leave open and adds two things: a batch of many columns at one point, and a deferred form that the recursion tree folds.

## The commitment

A Mercury commitment is exactly the KZG commitment of the evaluation table read as coefficients: one multi-scalar multiplication over the first `n` powers of the ceremony's `τ`, one G1 point, 64 bytes. There is no second scheme behind it. Two properties follow and the rest of the system uses both:

- **It is linear.** The commitment of `Σ ρ^i·f_i` is `Σ ρ^i·cm_i`, which is what lets many columns share one opening.
- **Zero coefficients add nothing.** A column extended by zero rows keeps its commitment, so the generic lookup table's three commitments serve every height that holds the table, and they are a constant of the ceremony.

Columns are committed at their integer width: a bit, byte, halfword or word column goes through an MSM over `u32` scalars, recoded from 32 bits instead of 254, which keeps committing a trace cheap.

## The opening

Mercury splits an opening point `u` of `s = 2t` variables into halves, folds the polynomial by a challenge `α`, and proves the two inner products that remain with a symmetrized witness, finishing with one batched KZG opening at three points. The proof is **eight G1 points and six field elements: 704 bytes**, for every size. Hence one requirement: the number of variables must be even, which is why every height on the menu is an even power of two.

The verifier does `O(t)` field operations, MSMs of ten and two points, and **one pairing check of two pairs**. Both relations it checks are written as `e(A, [1]_2) = e(B, [x]_2)`, so both G2 arguments are constants of the setup and the verifier does no G2 arithmetic at all. That shape is also what lets recursion postpone the pairing instead of computing it.

## A shard's columns, one opening

The GKR pass ends with every committed column of a shard claimed at the same point `u`. So nothing needs a claim-merging sumcheck: the opening batches all of them. A challenge `ρ`, drawn after every commitment and every claimed value, weights column `i` by `ρ^i`; the prover opens `Σ ρ^i·f_i` once, and the verifier forms `Σ ρ^i·cm_i` by a `k`-point MSM. A false claim survives with probability at most `(k − 1)/|Fr|`.

The columns in the batch come from three places, in a fixed order that is part of what is proved: the memory columns' commitments from the statement, the witness columns' from the shard proof, and the setup columns' from the verifying key. Taking the setup commitments from the key is what makes the opening bind the decoded tables and the image the program identity commits.

## Deferred verification

A deferred check runs everything but the pairing and keeps the relation's terms as twelve `(side, scalar, point)` entries. Recursion uses exactly this: each node of the tree computes a shard's twelve scalars in its own arithmetic, weights them by fresh challenges, and adds them into one running pair of points `(A, B)`. Every shard's opening in the whole tree folds into one claim `e(A, [1]_2) = e(B, [x]_2)`, which only the contract on Ethereum finally checks. [Recursion and settlement](https://apogee.gweb3networks.com/docs/architecture/recursion) shows the fold.

## Measured

On an 18-core Apple M5 Pro:

| Operation | Time |
| --- | --- |
| Commit a `2^22` column | 1.30 s |
| Open a `2^22` column | 2.89 s |
| 16 columns of `2^20`, opened as one batch | 1.01 s, verified in 4.8 ms |
| The same 16 opened one by one | 9.79 s, verified in 62 ms |

## Security

Knowledge soundness holds in the algebraic group model under q-DLOG, with Fiat–Shamir over the Poseidon2 transcript in the random-oracle model, and an SRS whose `τ` nobody knows. The statistical terms, Schwartz–Zippel over the challenges, stay below `2^−220` for every instance in use, so the security level is BN254's, about 100 bits. Nothing is hiding and nothing is blinded: Apogee v1.0.0 is not zero-knowledge.

The SRS is the PSE perpetual powers of tau, contribution 80, sound while one contributor was honest. Its file is decoded and every point checked to lie on its curve and in the right subgroup; nothing proves that a file is that ceremony's, which is why a verifier compares the SRS digest with the ceremony's from its own channel.

The specification: [Mercury](https://apogee.gweb3networks.com/docs/auditors/spec/mercury), [The structured reference string](https://apogee.gweb3networks.com/docs/auditors/spec/srs).