StateSync-GKR v1.2.0 is out. Measured next to v1.1.0 on the same 192-core server, same day: 3,300 requests a second, each proved and verified within 1 s, up from 1,150. At 1,000 a second, 99% of requests now finish within 34 ms, down from 440. oraclizer.io/ss-gkr/performa… StateSync-GKR is the prover inside @Oraclizer's state sync: every change that crosses between a chain and the off-chain world gets its first proof here. At this speed that proof lands in milliseconds, the clock trading runs on, instead of waiting for an end-of-day reconciliation. That brings Oraclizer a real step closer to its purpose.

ERC-TRUST from @Oraclizer runs regulatory actions on security tokens: six typed actions, fail-closed, one receipt each. It builds on ERC-8319, which I co-authored with @robviglione and @DanSpuller, and our proofs ran on tools from @certora and @rv_inc. github.com/Oraclizer/erc-tru… ERC-7943 built in, ERC-3643 plugs in. Dan wrote ERC-8319's policy principles, and ERC-TRUST lives by them: a technical capability is not a legal obligation, the chain carries out decisions made through due process and never makes them, and compliance stays modular, so no market is forced into another's rules. Certora's Prover checked our rules that the ERC-3643 adapter can never claim Full and that its receipts carry the token's real restriction state. With Runtime Verification's KEVM and Kontrol, we proved on the compiled bytecode that raw freeze and forced-transfer calls stay closed, that failures and non-raising freezes leave state untouched, and that LIQUIDATE moves exactly its amount and ends with its receipt. Thank you, Rob and Dan, and the Certora and Runtime Verification teams.

While building StateSync-GKR at @Oraclizer, three questions kept coming back. How far can we take it? Is there a better way? Why not prove the prover itself? So we built our own engine and took it all the way. Less memory, more speed, machine-checked.

A state oracle asks another ledger the same questions: is this record there, is it gone, did it change correctly. Last December we showed why GKR fits this work. Over ten months at @Oraclizer we built the StateSync-GKR prover around those questions. research.oraclizer.io/states…

We've put the StateSync-GKR design, measured results and developer docs together here: oraclizer.io/ss-gkr/ The Rust engine, Isabelle models and reproduction tools are on GitHub: github.com/Oraclizer/statesy…

StateSync-GKR is a reusable, high-performance Rust proof engine for computations and ledger updates. Both papers are on arXiv. Machine-checked models and conditional Rust verifier refinement under explicit assumptions. Thanks @muellerberndt for the challenge-generation review and claim corrections. Proud to share these controlled results: 89.46x lower peak RAM vs our dense reference and up to 23.68x faster prepared same-proof verification vs table wiring. The engine paper includes 300+ benchmark graphs. Targeting Springer for the formal paper and Wiley's Software: Practice and Experience for the engine paper. Engine: arxiv.org/abs/2610.14849 Formal: arxiv.org/abs/2610.05335

TRUST 1.2 is underway. We have just completed the hardest Native FREEZE proof. A TrustToken can now guarantee that a regulatory freeze executes exactly as intended and that an invalid command leaves the asset untouched. “Guarantee” is not a word anyone gets to use lightly. We back it with public, independently verifiable mathematics. To our knowledge, ERC-TRUST is the first Ethereum standards proposal built to turn financial-grade regulatory execution into a mathematical guarantee. This work was built with Veri by Oraclizer. The repository update containing the latest Native FREEZE result is coming soon.

Euler lost $197M to one function that skipped a check every other path ran. It was audited. Euler v2 came back formally verified. We built the first Ethereum standard to go through formal verification and refinement, for tokenized securities. New on ethresearch: ethresear.ch/t/can-we-verify…

3) You keep what you already run. It is an ordinary ERC-20, so custody and wallets do not need to change. It fully implements the ERC-7943 interface for fungible real-world assets. An existing ERC-3643 issuance partially interoperates through an adapter, once it is locked down.