An Honest On-Chain Verifier: What AttestedVerifier Actually Guarantees
A real STARK verifier in Solidity is a large undertaking. This project doesn't have one — and names the contract that stands in for it accordingly.
The contracts/ directory has four Solidity files: ProofOrchestrator.sol, IProofVerifier.sol, AttestedVerifier.sol, and UnimplementedStarkVerifier.sol. The last two are both real implementations of the same interface, and the names are the point: one reverts, honestly, because it doesn't check anything; the other checks something, but it isn't the STARK.
What UnimplementedStarkVerifier actually does
Exactly what its name says — every call reverts. It exists so ProofOrchestrator has a default verifier that fails closed rather than either not compiling or silently accepting anything, and so the honest state ("no real on-chain STARK verifier exists yet") is a compileable, testable fact rather than a gap that only shows up in documentation.
What AttestedVerifier actually does
It checks an ECDSA signature from one designated attester key over the claimed proof result — not the STARK proof itself. The actual trust chain is:
- A prover generates a real STARK proof and gives it to the attester.
- The attester verifies it off-chain, using the real cryptographic verifier (
zkvm-stark'sverify_program) — the same code path the CLI and HTTP server use. - If it checks out, the attester signs an attestation of the result.
- The on-chain contract checks the signature, not the proof.
So the actual security property is: the chain trusts one key to have told the truth about a real STARK verification that happened elsewhere. That's a meaningfully weaker guarantee than a real on-chain verifier, which would need no external trust at all — and it's exactly why the docs call this a "trust bridge," not "on-chain STARK verification."
What this is not pretending to be
This distinction only matters if it's checkable, so the test suite exercises the actual failure modes of a trust-bridge design specifically, not just the happy path:
test_onlyAttesterCanAttest— a non-attester's signature is rejectedtest_rejectsProofBytesThatDontMatchTheAttestation— the proof bytes have to match what was actually attested to, not just any bytestest_cannotDoubleFulfill,test_paysOutOnlyAfterAttestation— the payment side of the orchestrator only releases funds once, and only after a real attestation exists
What a real verifier would require
Making this trustless means porting FRI, Merkle proof verification, and the underlying field arithmetic into Solidity — or wrapping the STARK in a SNARK with an existing efficient EVM verifier, or targeting a chain/precompile that can check this proof system natively. Any of those is a genuine, large cryptographic engineering project on its own, not a follow-up PR. docs/ONCHAIN_VERIFIER.md lays out the specific paths and what each would need.
The actual claim this project makes today: off-chain STARK verification, on-chain attestation, with the attester's single key as the one named, documented, testable trust assumption. Not "on-chain STARK verification" — that phrase doesn't appear anywhere in this repo's own docs for a reason.