rustarians.com / workshop
Live age verification workshop for software teams

Build an age verifier that checks 18+ without seeing a birth date.

Your team builds the proof in Rust and halo2, breaks a circuit that accepts the wrong witness, then maps the issuer, client proof and verifier to a real app. By the end they can explain what the proof says and what it still does not solve.

Build this with my team Join the next open session
3 hours live Rust + halo2 closed team session product boundary review

On the video I run the final verifier on examples that pass and fail in MockProver, then do a full run that actually generates a proof.

Adam

I write Rust, work with ZK in production and have been in blockchain since 2016. I first showed this age-proof pipeline at Rustmeet Kraków. People asked for the code, so I turned it into a workshop where the team builds it.

The system

The verifier gets one answer: over 18 or not.

The birth year stays private. The circuit checks the signed input, computes the age and exposes only the answer needed by the service.

  • InputA birth year signed by the issuer.
  • CircuitSignature verification, age calculation and range checks.
  • OutputA proof and the public claim the verifier is expected to check.
Trusted issuer signs age data, an iOS or Android app creates a local proof, the browser sends the proof to the verifier, and the verifier returns valid or invalid.
The workshop uses one concrete path: issuer, local proof, verifier and public result.
Real workshop code

The team sees what passes and what fails.

This is the constraint and a shortened output from the workshop repo. The correct witness passes. A forged signature and an underage input fail. The final step generates and verifies a KZG proof.

src/bin/step5.rsage constraint
let age_w = gate_chip.sub(ctx, current_year_w, birth_year_w);
let diff_lo = gate_chip.sub(ctx, age_w, min_w);
let diff_hi = gate_chip.sub(ctx, max_w, age_w);

range.range_check(ctx, diff_lo, 8);
range.range_check(ctx, diff_hi, 8);
$ cargo run --release --bin s5verified output
correct signature, birth_year=2001
MockProver: all constraints satisfied

forged signature, s + 1
MockProver FAILED

birth_year=2020, age=6
MockProver FAILED

KZG proof: 13312 bytes
Verification: ok
The 3 hours

The session runs from the repo to the app flow.

  1. 01 Setup and repo

    Open the code, check the moving parts and run the verifier path locally.

  2. 02 Age claim

    Turn a private birth year into one public answer: over 18 or not.

  3. 03 Valid and bad cases

    Run the correct witness, a forged signature and an underage case to see what fails where.

  4. 04 Broken circuit review

    Find the missing constraint that lets a proof accept the wrong witness, then fix it.

  5. 05 App flow

    Place the issuer, local proof, verifier and public inputs in a web, iOS or Android flow.

Closed workshop for teams

Run it with the engineers who will evaluate or integrate ZK.

The age verifier is the shared code for the session. Your team builds it, runs the bad cases and finishes by placing the issuer, proof generation, verifier and trust boundary in the context of your product.

This format fits teams looking at identity, signed attributes, selective disclosure, a ZK vendor or an internal prototype.

What we cover

  • A closed live session for your engineers
  • The working age proof and broken circuit review
  • Questions while the code is running
  • The trust boundary in your own product
After the session

Your team can run the proof again and explain what it checks.

They can

  • Run the proof and the invalid cases locally.
  • Explain what stays private and what the verifier sees.
  • Spot one common missing-constraint bug.
  • Ask what is signed, what is public and what is actually verified.
  • See what still has to be built before production.

Who it is for

  • Software engineers who are comfortable reading Rust.
  • No previous halo2 experience required.
  • No math, blockchain or security background required.
  • Not a passive webinar and not a production identity SDK.
Adam
Who runs it

Adam

I write Rust, have been in blockchain since 2016 and work with ZK in production. I also mentor developers who want to understand halo2 beyond copied snippets and generated explanations.

I first ran this pipeline as a live Rustmeet Kraków talk. The workshop keeps the same approach: run the code, break it, then discuss what the proof is actually checking.

“Adam has an incredible mix of mathematical/cryptography and smart contract/software engineering knowledge.”

LinkedIn recommendation, architecture director

“The ZK Course helped me break through the wall of ZK moon math and complex terminology.”

Rust developer, 1:1 mentee
Choose the format

Run it with your team or join the next open session.

Closed team workshop

Your engineers, your questions and a final discussion around your product.

Scope, date and price agreed for the team
Build this with my team

Open session

For individual developers. The next date is not scheduled yet.

€175/person, recording and materials included
Build it in the next open session
FAQ

Before you book it

Does the team need previous ZK or halo2 experience?

No. The engineers need to be comfortable reading Rust. I explain the math only where it is needed to understand the constraint and the proof.

What do we need to build along live?

Rust, cargo and the editor you normally use. Setup instructions are provided before the session.

Where does this fit in a real app?

An issuer signs an attribute, the user creates a proof locally, and the app or backend verifies the proof and public inputs. Production still needs key management, revocation, UX and privacy review.

Is this a production-ready identity product?

No. The workshop gives the team a working proof and the technical model needed to evaluate an implementation. It is not a ready-made identity SDK.

What is included in the open session?

The live 3-hour workshop, recording, workshop code and materials. Access lasts 12 months after the session.

Can we use the code afterwards?

You can use, reuse and build on it in your own projects. Keep the workshop code itself off public repositories.