Context
A protocol client needed to execute a workflow on a public blockchain without exposing all of the data used to determine the result. The public chain still had to provide a shared settlement record and allow independent verification that the permitted rules had been followed. The design question was therefore not whether the system could be private in the abstract, but which facts could remain private while the chain retained enough evidence to accept a state transition.
Zero-knowledge proofs were a candidate mechanism, but selecting a proof system did not answer the protocol question. The system also needed a statement definition, witness lifecycle, public inputs, data commitments, proving boundary, verification path, settlement semantics, and a clear account of who or what remained trusted.
Challenge
Confidential execution creates tension between privacy, verifiability, cost, and finality. Making the proof statement broader can hide more information or establish a stronger claim, but it can also increase proving complexity and verification cost. Moving work offchain can preserve scarce onchain compute, but it introduces liveness and operational dependencies. Publishing additional commitments can improve auditability while creating linkability or metadata leakage.
The client needed a design that distinguished public claims from private data. A verifier should learn that the transition satisfied the protocol rules, not the private inputs used to satisfy them. At the same time, the chain needed enough public state to prevent replay, bind the proof to the intended context, and settle the result only once.
Benchmarking was essential because theoretical feasibility could hide an impractical workflow. Proof generation affected user or operator latency. Verification consumed transaction resources. Public-input size affected serialization and account access. Settlement could fail even after a valid proof was generated if state changed before submission. Trust assumptions around setup, proving software, data availability, and client-side execution also needed to be visible.
Approach
We started by writing the claim in plain language. For each candidate transition, we specified what the public chain needed to know, what could remain private, and what invalid behavior the proof had to exclude. This avoided building a circuit around implementation details before the security statement was agreed.
The statement was then decomposed into constraints, public inputs, private witness data, commitments, and state bindings. Domain separation and replay resistance were treated as protocol requirements. The settlement instruction checked that the proof referred to the current state and the intended action, so a valid proof from one context could not authorize another.
We compared proof approaches against the workload rather than assuming one family was universally best. The analysis considered proving environment, verification support, setup assumptions, artifact lifecycle, expected statement evolution, and the division between client, service, and chain. Compute and account constraints on Solana shaped how verification and settlement could be packaged.
The benchmark plan measured the complete path. Representative workloads covered the expected statement shapes and edge cases. The method separated proof construction, artifact handling, verification, and settlement so a bottleneck could be attributed correctly. Runs used controlled environments and recorded the software and hardware context needed for comparison. Failure cases included invalid witnesses, stale state, malformed public inputs, replay attempts, and resource pressure.
Privacy and trust boundaries
The design did not present privacy as absolute anonymity. Public timing, transaction submission, fees, account interaction, and committed state can reveal metadata even when witness values remain hidden. The privacy review therefore documented what an observer could still infer and how repeated actions might become linkable.
Trust assumptions were similarly explicit. A proof can establish that a statement is true under a circuit and verification key; it does not guarantee the privacy of a compromised client, the availability of an offchain prover, or the correctness of data before it becomes part of the statement. Operational controls and review procedures were mapped to those remaining assumptions.
Outcome
The architecture specifies an explicit public claim, private-data boundary, proof and settlement flow, and trust model. The design can be evaluated against both protocol security and practical execution constraints, not treated as inherently private because it uses zero knowledge.
Benchmarking measures cost and feasibility across proving, verification, and settlement as a complete system. The tradeoffs between statement scope and architecture become reviewable before production implementation. Confidential measurements and parameters are deliberately not reported here.
What this demonstrates
Applied ZK work joins cryptographic statement design with protocol architecture, performance engineering, and operational threat modeling. Matariki's method is to define the claim and trust boundary first, then use benchmarks to test whether the complete workflow is viable in its intended execution environment.
Confidentiality
This study excludes the client identity, private statement details, witness data, proof parameters, measurements, deployment configuration, and operational procedures. It does not imply absolute anonymity.