Use cases
Built for systems
that prove state.
StateSync-GKR lets the keeper of a ledger prove one fact about one record to anyone who trusts the ledger's published fingerprint: that the record is there, that it is not, or that it changed correctly. Its core also proves other computations written as layered circuits, through a frontend you build.
Where it fits
From regulated assets
to custom circuits.
Wherever one system keeps records and another has to check them without trusting the first, StateSync-GKR supplies the proof.
Registers, eligibility and restrictions
Tokenized securities depend on registers that say who may hold an asset, who may not, and what each holder owns. StateSync-GKR proves each fact against a published root, so a counterparty checks one entry and its path instead of receiving the whole register.
StateSync-GKR began as the proof engine of Oraclizer's oracle state machine, which is designed to keep the state of tokenized assets synchronized across ledgers.
State commitments that move often
Rollups, application chains and synchronization layers commit state roots continuously. When that state lives in the engine's sparse Merkle tree, prepared circuits and independent parallel proofs suit that rhythm: the setup is paid once and every proof stays tied to its own request.
Authenticated lookups and updates
A key-value store or registry can return a proof with each answer: present, absent, or updated from one value to another. The client checks it against a root it already trusts instead of trusting the server.
Your circuit on a tested core
The sumcheck and GKR core does not depend on the sparse-Merkle frontend. Computations built from layered arithmetic, such as the matrix products inside machine-learning inference or batch checks over data, can be written as layered circuits and proved by the same core through a frontend you supply.
What it proves
Four kinds of proof.
A registry, an exchange or a chain publishes a short fingerprint of its whole ledger, called the state root. With StateSync-GKR it proves one fact about one record to anyone who trusts that fingerprint, by sending the record and its path instead of the ledger. The fourth kind runs the same engine on computations of your own.
Show that a record is on the ledger.
Proves that a specific record is stored, exactly as written, under the published state root.
A fund administrator shows a regulator that an investor is on its eligibility register, without sending the register.
A custodian shows that a holding exists before a corporate action is applied.
Show that a record is not on the ledger.
Proves that nothing is stored under an identifier, whether it was never written or was deleted.
An exchange shows a partner that an account is not on its restricted list.
A registry shows that an identifier is still free before it is issued.
Show that one record changed correctly.
Proves that exactly one record went from its old value to its new one, on the same path, and that the published root moved with it.
After a transfer settles, the registry shows both counterparties that only that holding changed.
A registry shows that an entry changed status after an approval.
Prove a computation of your own.
Runs the same sumcheck and GKR core on other computations written as layered arithmetic circuits, through a frontend you build.
A data service shows that a total was computed correctly from committed inputs.
A model provider shows that a layer of matrix arithmetic was evaluated correctly.
Why it fits repeated state proofs
What the measurements mean for a deployment.
Each figure comes from its own controlled run of StateSync-GKR. They describe separate benefits and are not combined into one overall multiplier.
Try it on your own state.
Run the quickstart, then follow the guide for the operation your system needs.