diff --git a/docs/kusama-grant/README.md b/docs/kusama-grant/README.md
new file mode 100644
index 0000000..5c34cba
--- /dev/null
+++ b/docs/kusama-grant/README.md
@@ -0,0 +1,9 @@
+# Kusama Grant Documentation Index
+
+This directory tracks delivery evidence for Kusama grant milestones.
+
+## Milestones
+
+- Milestone 1 - DKIM Registry on Testnet: [zk-email-verify `packages/contracts/docs/kusama-grant/milestone-1`](https://github.com/zkemail/zk-email-verify/blob/kusama-grant/packages/contracts/docs/kusama-grant/milestone-1/README.md)
+- Milestone 2 - ZK Verifier Contract Tooling: [sdk-images `circom/docs/kusama-grant/milestone-2`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-2/README.md)
+- Milestone 3 - Verification Pipeline + SDK & Frontend: [sdk-images `circom/docs/kusama-grant/milestone-3`](./milestone-3/README.md)
diff --git a/docs/kusama-grant/milestone-3/05_frontend_integration_and_documentation.md b/docs/kusama-grant/milestone-3/05_frontend_integration_and_documentation.md
new file mode 100644
index 0000000..f5b59cd
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/05_frontend_integration_and_documentation.md
@@ -0,0 +1,40 @@
+# 05 - Frontend Integration & Documentation
+
+Milestone 3 frontend integration: the registry frontend supports target chain selection for new blueprints and lets users verify Circom proofs on-chain against the deployed verifier contract.
+
+## Implementation Notes
+
+### Chain selection
+
+- **UI component:** [`src/app/create/[id]/createBlueprintSteps/EmailDetails.tsx`](../../../src/app/create/%5Bid%5D/createBlueprintSteps/EmailDetails.tsx) adds a `Target Chain` `<Select>` to **Step 3 (Optional Details)** of the blueprint creation wizard, with three options: Base Sepolia (`84532`), Ethereum Sepolia (`11155111`), and Paseo Testnet / Polkadot (`420420417`).
+- **Store:** [`src/app/create/[id]/store.ts`](../../../src/app/create/%5Bid%5D/store.ts) initializes `verifierContract.chain` to `84532` (Base Sepolia); the component falls back to the same default when unset. The selected chain is used downstream by the compilation pipeline when deploying the Solidity verifier contract.
+- Covered by [`tests/kusama/targetChainSelector.ts`](../../../tests/kusama/targetChainSelector.ts): confirms Paseo is both an available option and genuinely selected on the real `kusama_grant_paseo_e2e` blueprint. Runs in CI on every push (see Demonstration below).
+
+### On-chain verification UI
+
+- A **"Verify On-Chain"** button appears in two places: the proof list row ([`src/app/[id]/ProofRow.tsx`](../../../src/app/%5Bid%5D/ProofRow.tsx), `onVerifyOnChain` / `isVerifyingOnChainLoading`) and the proof detail page ([`src/app/[id]/proofs/[proofId]/page.tsx`](../../../src/app/%5Bid%5D/proofs/%5BproofId%5D/page.tsx), same pattern).
+- Rendered only when a browser wallet (`window.ethereum`) is detected, the blueprint has a `verifierContract.address` set, and the proof is Circom-based (not Noir); disabled while the proof is still `InProgress`.
+- Calls `blueprint.verifyProofOnChain(proof)` from `@zk-email/sdk` and shows a toast with the result.
+- Covered by [`tests/kusama/verifyProofOnChain.ts`](../../../tests/kusama/verifyProofOnChain.ts) (real proof, asserts success) and [`tests/kusama/verifyTamperedProofOnChain.ts`](../../../tests/kusama/verifyTamperedProofOnChain.ts) (same real proof, corrupted in-flight, asserts failure). Runs in CI on every push (see Demonstration below).
+
+### Dynamic block explorer links
+
+- [`src/app/[id]/proofs/[proofId]/page.tsx`](../../../src/app/%5Bid%5D/proofs/%5BproofId%5D/page.tsx) builds the verifier contract address link from an `EXPLORER_MAP` keyed by chain ID: `84532` → `sepolia.basescan.org`, `11155111` → `sepolia.etherscan.io`, `420420417` → `blockscout-testnet.polkadot.io`. Falls back to `#` if the chain is unrecognized or no address is set.
+- Also covered by [`tests/kusama/verifyProofOnChain.ts`](../../../tests/kusama/verifyProofOnChain.ts), which asserts the rendered link resolves to Blockscout specifically for this Paseo-targeted blueprint.
+
+## Demonstration
+
+```bash
+bunx playwright test tests/kusama/
+```
+
+Four real, end-to-end Playwright tests under [`tests/kusama/`](../../../tests/kusama/), all against [`zkemailverify/kusama_grant_paseo_e2e`](https://registry-staging.onrender.com/e94e7f93-7575-4e26-a147-de894b19ce3e/versions) (blueprint `e94e7f93-7575-4e26-a147-de894b19ce3e`), compiled and deployed to Paseo through the current pipeline:
+
+| Test | Exercises |
+| --- | --- |
+| [`targetChainSelector.ts`](../../../tests/kusama/targetChainSelector.ts) | Target Chain dropdown offers, and this blueprint has selected, Paseo Testnet (Polkadot). |
+| [`generateProof.ts`](../../../tests/kusama/generateProof.ts) | Fresh remote proof generation end to end (email upload through "View Proof"). |
+| [`verifyProofOnChain.ts`](../../../tests/kusama/verifyProofOnChain.ts) | Real "Verify On-Chain" button click against the deployed verifier ([`manifest.json#L20`](./manifest.json#L20)), asserting the explorer link resolves to Blockscout/Paseo specifically and that verification succeeds. |
+| [`verifyTamperedProofOnChain.ts`](../../../tests/kusama/verifyTamperedProofOnChain.ts) | Same real proof, corrupted in-flight via route interception (the persisted proof is never touched), asserting the failure toast through the actual button. Added after a curator-reported bug (`blueprint.verifyProofOnChain` discarding the standalone call's result, fixed in [zk-email-sdk-js#104](https://github.com/zkemail/zk-email-sdk-js/pull/104)) - this test failed against `@zk-email/sdk@3.0.0-nightly.34` and passes against `3.0.0-nightly.36`, confirmed by real CI runs on both. |
+
+Runs automatically in CI on every push to `staging`/`main` via [`.github/workflows/playwright.yml`](../../../.github/workflows/playwright.yml). Example passing `test` job, with all four tests including the tampered-proof case: [`manifest.json#L11-L14`](./manifest.json#L11-L14). For the current state of the branch, see the [Actions tab](https://github.com/zkemail/registry/actions/workflows/playwright.yml?query=branch%3Astaging).
diff --git a/docs/kusama-grant/milestone-3/06_public_howto.md b/docs/kusama-grant/milestone-3/06_public_howto.md
new file mode 100644
index 0000000..131ddb4
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/06_public_howto.md
@@ -0,0 +1,51 @@
+# 06 - Public How-To: Creating a Blueprint and Verifying On-Chain on Paseo
+
+Step-by-step walkthrough of the deliverable 5 golden path in the registry frontend: create a blueprint targeting Paseo, upload an email, generate a proof, and verify it both locally and on-chain, using only the UI.
+
+## 1) Create a blueprint
+
+Click **Create Blueprint** and fill in the pattern details: a name, description, etc.
+
+![Pattern Details step](./assets/01-create-blueprint-step1.png)
+
+On the next step, choose which fields to extract. Quick header extraction toggles (Subject, To field, Sender email, Sender domain, Timestamp) auto-write the regexes for you - each one can be marked Public or Private.
+
+![Extract Fields step](./assets/02-create-blueprint-step2-1.png)
+
+Scrolling down shows the generated regex for each field, an editable Max Length, and a live test against the sample email. Once it reads "All tests passed. Ready to compile", move on.
+
+![Regex definition and test results](./assets/03-create-blueprint-step2-2.png)
+
+On the final step, set **Target Chain** to **Paseo Testnet (Polkadot)** then click **Submit Blueprint**.
+
+![Optional Details step with Paseo selected](./assets/04-create-blueprint-step3.png)
+
+## 2) Wait for compilation
+
+Compilation happens server-side: the circuit is compiled, a Solidity verifier is generated, and it's deployed to Paseo. Depending on complexity, this can take more than an hour - the blueprint's status badge reads **In Progress** in the meantime, with an option to cancel.
+
+![Compilation in progress](./assets/05-compilation-in-progress.png)
+
+Once the badge reads **Compiled**, the blueprint is ready to generate proofs against.
+
+## 3) Upload an email and generate a proof
+
+On the blueprint page, upload an `.eml` file matching the sender domain (or connect Gmail).
+
+![Connect emails step](./assets/06-generate-proof-step1.png)
+
+Select the email to prove and press **Remote Proving**.
+
+![Select emails step](./assets/07-generate-proof-step2.png)
+
+## 4) Verify the proof
+
+Once generation finishes, the proof row shows its outputs, a validity checkmark, a button to download the proof, and both a **Verify** and a **Verify On-Chain** button. **Verify** checks the proof locally in the browser. **Verify On-Chain** calls the deployed verifier contract's view function on Paseo and reports the result of verification:
+
+![Proof verified successfully on chain](./assets/08-verify-on-chain-success.png)
+
+## 5) Find the deployed contract address
+
+Open the proof's detail page to see the full generated proof, its public outputs, and the **Verifier Address** - the deployed contract on Paseo that `Verify On-Chain` calls. The address links out to the block explorer for independent inspection. The proof can also be downloaded from this page.
+
+![Proof details page with verifier address](./assets/09-proof-details.png)
diff --git a/docs/kusama-grant/milestone-3/07_bytecode_verification.md b/docs/kusama-grant/milestone-3/07_bytecode_verification.md
new file mode 100644
index 0000000..70d57a7
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/07_bytecode_verification.md
@@ -0,0 +1,140 @@
+# 07 - Bytecode Verification
+
+Verifier contracts are generated and deployed dynamically per blueprint by the registry's compilation pipeline, so there's no single fixed contract to point at like milestone 1's `DKIMRegistry`. This walks through reproducing the deployed bytecode for a specific blueprint's verifier contract from its downloadable circuit bundle, and comparing it against what's actually on-chain.
+
+## Deployment Manifest
+
+| Field | Value |
+| --- | --- |
+| Blueprint | [`zkemailverify/kusama_grant_paseo_e2e`](https://registry-staging.onrender.com/e94e7f93-7575-4e26-a147-de894b19ce3e/versions) (`e94e7f93-7575-4e26-a147-de894b19ce3e`) |
+| Contract | `ZKEmailVerifier` |
+| Network | Polkadot Hub Testnet (Paseo Testnet), chain ID `420420417` |
+| Address | [`0x72616B78d29d0cccBfEec1bf00E108885286D2f3`](https://blockscout-testnet.polkadot.io/address/0x72616B78d29d0cccBfEec1bf00E108885286D2f3) |
+| `resolc` version | `0.5.0` (pinned in the bundle's `hardhat.config.ts`) |
+| `solc` version | `0.8.30` |
+| Optimizer | enabled, `runs = 10000` |
+| PVM bytecode magic | `0x50564d0000` (`"PVM\0"` prefix - confirms genuine PolkaVM/RISC-V bytecode, not EVM) |
+| Runtime bytecode hash (keccak256) | `0x5655a9fe87e1a1bd736b117c89a181c71f7985a682f419e3396574165a37ef55` |
+
+## Download the circuit bundle
+
+Every compiled blueprint has a downloadable `circuit.zip` containing the contract source, its `hardhat.config.ts`, and a `package.json` with the exact build script used to compile it:
+
+[`https://registry-staging.onrender.com/e94e7f93-7575-4e26-a147-de894b19ce3e/download`](https://registry-staging.onrender.com/e94e7f93-7575-4e26-a147-de894b19ce3e/download)
+
+`circuit.zip` is listed under "Downloads for Server Side Circom". Unzip it - the `contracts/` directory is a self-contained Hardhat project.
+
+## Reproducible Command Flow
+
+From the unzipped bundle's `contracts/` directory:
+
+```bash
+yarn install
+yarn build
+```
+
+## Verification
+
+- Source-code verification is **not currently possible for PolkaVM deployments.** The contract is `resolc`-compiled to PolkaVM/RISC-V bytecode; the Blockscout explorer's verification API and `@nomicfoundation/hardhat-verify` both only support EVM `solc`/Vyper bytecode, and `@parity/hardhat-polkadot` does not yet provide a resolc-aware verify task. This is a PolkaVM tooling gap, not a deployment issue.
+- The contract is still fully visible on [Blockscout](https://blockscout-testnet.polkadot.io) (address, PolkaVM bytecode, transactions) and is exercisable via its read methods.
+
+## Bytecode Provenance
+
+Because automated source verification is not yet available for PolkaVM, provenance is established by comparing the locally compiled runtime bytecode against the on-chain code.
+
+| Source | keccak256 |
+| --- | --- |
+| Locally compiled (`hh-artifacts/src/ZKEmailVerifier.sol/ZKEmailVerifier.json`) | `0x5655a9fe87e1a1bd736b117c89a181c71f7985a682f419e3396574165a37ef55` |
+| On-chain (`0x72616B78d29d0cccBfEec1bf00E108885286D2f3`) | `0x5655a9fe87e1a1bd736b117c89a181c71f7985a682f419e3396574165a37ef55` |
+
+The two hashes are identical: the deployed contract is exactly this bundle's source, compiled with the compiler settings in its own `hardhat.config.ts`. Reproduced independently twice from a clean unzip, both times matching.
+
+### Reproduce
+
+```bash
+# on-chain runtime-bytecode hash
+cast code 0x72616B78d29d0cccBfEec1bf00E108885286D2f3 \
+  --rpc-url https://services.polkadothub-rpc.com/testnet | cast keccak
+
+# locally compiled runtime-bytecode hash (from the unzipped bundle's contracts/ directory,
+# after yarn install && yarn build)
+jq -r '.bytecode' hh-artifacts/src/ZKEmailVerifier.sol/ZKEmailVerifier.json | cast keccak
+
+# PVM bytecode magic (first bytes should read 0x50564d00, "PVM\0")
+cast code 0x72616B78d29d0cccBfEec1bf00E108885286D2f3 \
+  --rpc-url https://services.polkadothub-rpc.com/testnet | cut -c1-12
+```
+
+## Groth16Verifier Provenance
+
+The wrapper's `GROTH16_VERIFIER()` is immutable and readable on-chain, so the address it points
+to (and that contract's own bytecode) can be verified with the same method used above for the
+wrapper itself, rather than just asserted.
+
+| Field | Value |
+| --- | --- |
+| Contract | `Groth16Verifier` |
+| Address (read from the wrapper's own `GROTH16_VERIFIER()`, not just asserted) | [`0xDfbcfE9D3C6ecdc0d614Ff671b5A3fd73E6d3DBC`](https://blockscout-testnet.polkadot.io/address/0xDfbcfE9D3C6ecdc0d614Ff671b5A3fd73E6d3DBC) |
+| Source | `src/Groth16Verifier.sol` in the same `circuit.zip` bundle, same `hardhat.config.ts` (`resolc` `0.5.0`, `solc` `0.8.30`, optimizer `runs = 10000`) |
+| PVM bytecode magic | `0x50564d0000` |
+| Runtime bytecode hash (keccak256) | `0xc1d5f187d0d06a9a5a31f2254299fd0f3190efe19086e7192b3c3af430f586ee` |
+
+Locally compiled and on-chain hashes are identical: the deployed Groth16Verifier is exactly this
+bundle's source, same compiler settings, same provenance chain as the wrapper.
+
+### Reproduce
+
+```bash
+# read the verifier address directly off the deployed wrapper, rather than trusting a stated address
+cast call 0x72616B78d29d0cccBfEec1bf00E108885286D2f3 "GROTH16_VERIFIER()(address)" \
+  --rpc-url https://services.polkadothub-rpc.com/testnet
+
+# on-chain runtime-bytecode hash of that address
+cast code 0xDfbcfE9D3C6ecdc0d614Ff671b5A3fd73E6d3DBC \
+  --rpc-url https://services.polkadothub-rpc.com/testnet | cast keccak
+
+# locally compiled runtime-bytecode hash (same unzipped bundle as above)
+jq -r '.bytecode' hh-artifacts/src/Groth16Verifier.sol/Groth16Verifier.json | cast keccak
+
+# PVM bytecode magic
+cast code 0xDfbcfE9D3C6ecdc0d614Ff671b5A3fd73E6d3DBC \
+  --rpc-url https://services.polkadothub-rpc.com/testnet | cut -c1-12
+```
+
+## Full Provenance Summary
+
+Everything above in one place: the `sdk-images` commit that generated this blueprint's contracts,
+the downloadable artifacts that came out of it, and the two deployed contracts' runtime bytecode.
+Compiler settings aren't re-stated here beyond what's already above - they're read directly from
+the bundle's own `hardhat.config.ts`, not something separate to prove.
+
+| Field | Value |
+| --- | --- |
+| Blueprint compile timestamp | `2026-08-03T17:40:26Z` (the blueprint's own `updated_at`, readable via the API - see Reproduce below) |
+| sdk-images generator commit | [`a6e5c43`](https://github.com/zkemail/sdk-images/commit/a6e5c43) ("test(circom): generator-regression test + fixture README fix (#70)"), confirmed unchanged on `staging` between 2026-07-27 and the compile timestamp above |
+| `circuit.zip` hash (sha256) | `edc4a3b89b7699911c2b402fdf0a64ac3a1091b240c70420534bb4bec9f40592` |
+| `circuit.zkey` hash (sha256) | `e8358bbc0c70db9f3d76ed92473dcf6c1e8de5b8a3e1fb2ea7f13778a75c34fe` (from `circuit_zkey.zip`; the separate `circuit.zkey.gz` asset for this blueprint is a 43-byte stub, not the real file) |
+| Wrapper (`ZKEmailVerifier`) runtime bytecode hash | `0x5655a9fe87e1a1bd736b117c89a181c71f7985a682f419e3396574165a37ef55` |
+| Groth16Verifier runtime bytecode hash | `0xc1d5f187d0d06a9a5a31f2254299fd0f3190efe19086e7192b3c3af430f586ee` |
+| Compiler settings | see the [Deployment Manifest](#deployment-manifest) above - `resolc 0.5.0`, `solc 0.8.30`, optimizer `runs = 10000`, all read from the bundle's own `hardhat.config.ts` |
+
+### Reproduce
+
+```bash
+# circuit.zip hash
+shasum -a 256 circuit.zip
+
+# zkey hash (from the zip bundle, not the separate .gz asset)
+unzip circuit_zkey.zip -d zkey_unzipped
+shasum -a 256 zkey_unzipped/circuit.zkey
+
+# blueprint compile timestamp, straight from the API (updated_at)
+curl -s https://staging-conductor.zk.email/blueprint/e94e7f93-7575-4e26-a147-de894b19ce3e \
+  | jq -r '.updated_at.seconds' | xargs -I{} date -u -r {} "+%Y-%m-%dT%H:%M:%SZ"
+
+# generator commit: confirm nothing touched the contract generator between a6e5c43
+# and the blueprint's compile time
+git log a6e5c43..origin/staging --oneline --before="2026-08-03T17:40:26Z" \
+  -- circom/src/contract.rs circom/templates/ circom/src/main.rs
+# (empty output confirms a6e5c43 was still the live generator state)
+```
diff --git a/docs/kusama-grant/milestone-3/08_revocation_demo.md b/docs/kusama-grant/milestone-3/08_revocation_demo.md
new file mode 100644
index 0000000..1821060
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/08_revocation_demo.md
@@ -0,0 +1,93 @@
+# 08 - DKIM Revocation Demo
+
+Additional evidence added in response to curator review, not itself a milestone deliverable.
+Demonstrates the same real proof succeeding while its DKIM key is valid in the milestone 1
+registry, then failing after that exact key is revoked, using four real on-chain transactions
+against the real deployed contracts. No new proof was generated - the existing real proof used
+throughout this milestone's evidence is reused unchanged; only the registry's key-hash state
+changes.
+
+## Why revoke and re-register, rather than use a separate test domain
+
+The deployed wrapper's domain check is a compile-time constant, not a runtime parameter:
+
+```solidity
+bytes32 public constant DOMAIN_HASH = keccak256(bytes("x.com"));
+```
+
+(`contracts/src/ZKEmailVerifier.sol` in the blueprint's `circuit.zip`, see
+[`07_bytecode_verification.md`](./07_bytecode_verification.md).) This specific deployed wrapper
+([`manifest.json#L20`](./manifest.json#L20)) can only ever check x.com - a different domain
+would need an entirely new blueprint and a fresh contract deployment. Revoking and immediately
+re-registering the same key on the existing real registry demonstrates the actual revocation
+state transition against the real deployed contracts, with a minimal window (a few seconds
+between the revoke and restore transactions) and no lasting effect: the key is confirmed valid
+again immediately after.
+
+## Why this differs from the existing bit-flip negative control
+
+`ZKEmailVerifier.verify` checks three distinct conditions, each with its own error:
+
+```solidity
+if (publicInputs.length != PUBLIC_INPUTS_LENGTH) revert InvalidPublicInputsLength(...);
+if (!DKIM_REGISTRY.isKeyHashValid(DOMAIN_HASH, publicInputs[PUBLIC_KEY_HASH_OFFSET])) revert InvalidPublicKey();
+if (!GROTH16_VERIFIER.verifyProof(pA, pB, pC, pubSignals)) revert InvalidProof();
+```
+
+The existing negative control (milestone 2's `06_e2e_demo.md`) flips a bit in `publicInputs[0]`,
+which is the key-hash slot itself - so it also reverts with `InvalidPublicKey()`, but for a
+fabricated hash that was never registered. That proves the wrapper checks the registry at all.
+It doesn't prove a hash that *was* valid stops working the moment the registry revokes it -
+the actual registry state transition. This demo isolates that specific case: the proof and its
+public inputs never change, only `DKIM_REGISTRY`'s stored state does.
+
+## Sequence
+
+Proof used throughout (unchanged): [`fece17c3-f3ed-4833-bbf9-eccdf530d474`](https://registry-staging.onrender.com/e94e7f93-7575-4e26-a147-de894b19ce3e/proofs/fece17c3-f3ed-4833-bbf9-eccdf530d474) (the same proof exercised by `zk-email-sdk-js`'s CI integration test). `domainHash = keccak256("x.com")` = `0xbbcc9f0af825b951a41a390086b09f7d8b4c4434d5315255b2ab6ffee1e8c781`; `keyHash` (`publicInputs[0]` of this proof) = `0x0462b6e208f3552371d7c7d2fbeb31691e5f789b9e5f0bdfaa68a6a84f01d9aa`.
+
+| # | Call | Tx | Block | Status | Result |
+| --- | --- | --- | --- | --- | --- |
+| 0 | `isKeyHashValid(domainHash, keyHash)` (read, before) | - | - | - | `true` |
+| 1 | `revokeDKIMPublicKeyHash(domainHash, keyHash)` on the M1 registry | [`0x384c1540...74562`](https://blockscout-testnet.polkadot.io/tx/0x384c1540afaaf6782c5cff3bad71cd05854bd2f422246e8acf2f7cd42af74562) | `12697891` | Success | Emits `KeyHashRevoked(domainHash)` |
+| 2 | `verify(proof, publicInputs)` on the wrapper, same proof, sent as a transaction | [`0xea3d710d...c8e5c5`](https://blockscout-testnet.polkadot.io/tx/0xea3d710de2c21f6792d084262d6f65d5376d1cfb0e8ac3dafd6e62df42c8e5c5) | `12697893` | **Failed** | Reverts with `InvalidPublicKey()` (selector `0xa2d0fee8`) - confirmed by replaying the same call against block `12697892`, where `isKeyHashValid` independently reads `false` |
+| 3 | `setDKIMPublicKeyHash(domainHash, keyHash)` on the M1 registry - restores it | [`0xde60c1ec...cb41f14`](https://blockscout-testnet.polkadot.io/tx/0xde60c1eca66d5caa295b885fb83a12023f49ef44a148d84d551ef49e4cb41f14) | `12697894` | Success | Emits `KeyHashRegistered(domainHash, keyHash)` |
+| 4 | `verify(proof, publicInputs)` on the wrapper, same proof again | [`0x77fb1ffd...f5c8de422`](https://blockscout-testnet.polkadot.io/tx/0x77fb1ffde5f93a74038cc639bed5f4880c0e0d2d4c76401afb58bdcf5c8de422) | `12697896` | Success | Same unchanged proof verifies again, confirming only the registry state determined the outcome |
+| 5 | `isKeyHashValid(domainHash, keyHash)` (read, after) | - | - | - | `true` |
+
+### Reproduce
+
+From the M1 registry owner account (`0x9401296121FC9B78F84fc856B1F8dC88f4415B2e`):
+
+```bash
+RPC_URL=https://services.polkadothub-rpc.com/testnet
+REGISTRY=0xD9e492f8104Ec730AF47A1A5C0cEAf94C89Da8EE
+WRAPPER=0x72616B78d29d0cccBfEec1bf00E108885286D2f3
+DOMAIN_HASH=$(cast keccak "x.com")
+KEY_HASH=0x0462b6e208f3552371d7c7d2fbeb31691e5f789b9e5f0bdfaa68a6a84f01d9aa
+
+# proof and public inputs for fece17c3-f3ed-4833-bbf9-eccdf530d474, ABI-encoded the same way
+# verifyProofOnChain does (see 04_sdk_on_chain_verification.md)
+PROOF_BYTES=0x...
+PUBLIC_INPUTS="[...]"
+
+cast call $REGISTRY "isKeyHashValid(bytes32,bytes32)(bool)" "$DOMAIN_HASH" "$KEY_HASH" --rpc-url $RPC_URL
+
+cast send $REGISTRY "revokeDKIMPublicKeyHash(bytes32,bytes32)" "$DOMAIN_HASH" "$KEY_HASH" \
+  --rpc-url $RPC_URL --private-key "$PRIVATE_KEY"
+
+cast send $WRAPPER "verify(bytes,bytes32[])" "$PROOF_BYTES" "$PUBLIC_INPUTS" \
+  --rpc-url $RPC_URL --private-key "$PRIVATE_KEY" --gas-limit 500000
+
+cast send $REGISTRY "setDKIMPublicKeyHash(bytes32,bytes32)" "$DOMAIN_HASH" "$KEY_HASH" \
+  --rpc-url $RPC_URL --private-key "$PRIVATE_KEY"
+
+cast send $WRAPPER "verify(bytes,bytes32[])" "$PROOF_BYTES" "$PUBLIC_INPUTS" \
+  --rpc-url $RPC_URL --private-key "$PRIVATE_KEY"
+
+cast call $REGISTRY "isKeyHashValid(bytes32,bytes32)(bool)" "$DOMAIN_HASH" "$KEY_HASH" --rpc-url $RPC_URL
+
+# to independently confirm the revert reason at any time, replay the call against the
+# block where the key was revoked:
+cast call $WRAPPER "verify(bytes,bytes32[])" "$PROOF_BYTES" "$PUBLIC_INPUTS" \
+  --rpc-url $RPC_URL --block 12697892
+```
diff --git a/docs/kusama-grant/milestone-3/README.md b/docs/kusama-grant/milestone-3/README.md
new file mode 100644
index 0000000..ffd4824
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/README.md
@@ -0,0 +1,31 @@
+# Milestone 3 - Verification Pipeline + SDK & Frontend
+
+Primary Goal: extend the Circom pipeline, SDK, and registry frontend to support automated PolkaVM verifier contract generation and deployment, and end-to-end on-chain proof verification.
+
+This milestone spans five deliverables across three repositories: sdk-images (1-3), zk-email-sdk-js (4), and registry (5).
+
+## Deliverables
+
+| # | Name | Description | Deliverable | What was done / Proof |
+| --- | --- | --- | --- | --- |
+| 1 | Circom Pipeline Integration | Modify the existing Circom pipeline to integrate the new contracts project structure and support PolkaVM deployments. | Updated Circom pipeline capable of generating verifier contracts with Paseo testnet deployment. | Pipeline orchestration in `main.rs` renders templates, exports the verifier, deploys via Ignition using `payload.chain_id` (including Polkadot Hub testnet `420420417`), and persists the address to the database. **Proof:** [`01_circom_pipeline_integration.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/01_circom_pipeline_integration.md). |
+| 2 | Proof Formatting and Wrapper Integration Layer | Implement proof formatting, serialization, and integration logic to ensure compatibility between Circom-generated proofs and the verifier wrapper contracts, enabling seamless on-chain verification. | Proof formatting and integration layer enabling compatibility between Circom-generated proofs and on-chain verifier contracts. | Templated `ZKEmailVerifier` wrapper decodes Groth16 proofs and public inputs; the wrapper/verifier Solidity itself is rendered from `ContractData` (signal size, public-key-hash offset) via `create_zkemail_verifier_and_interface_at_paths`, gated on the DKIM key hash. **Proof:** [`02_proof_formatting_and_wrapper_integration.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/02_proof_formatting_and_wrapper_integration.md). |
+| 3 | Blueprint Deployment System | Extend the blueprint system to support configurable target chains and automate contract generation and deployment for new blueprints. | Blueprint pipeline supporting automatic contract generation and deployment. | Chain id from the blueprint payload selects the Ignition network; the deployed verifier address is read back from Ignition's output and persisted to the blueprint record. **Proof:** [`03_blueprint_deployment_system.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/03_blueprint_deployment_system.md). |
+| 4 | SDK On-Chain Verification | Integrate on-chain proof verification into the SDK using the generic verifier interface defined in Milestone 2. | SDK functionality enabling on-chain proof verification via deployed verifier contracts | `verifyProofOnChain` supports Ethereum Sepolia, Base Sepolia, and Paseo Testnet (Polkadot) against the `IZKEmailVerifier` ABI, viem-encoded. Published to npm and consumed by the registry frontend. **Proof:** [`04_sdk_on_chain_verification.md`](https://github.com/zkemail/zk-email-sdk-js/blob/kusama-grant/docs/kusama-grant/milestone-3/04_sdk_on_chain_verification.md). |
+| 5 | Frontend Integration & Documentation | Update the registry frontend to support target chain selection and enable on-chain proof verification. Include documentation with public how-tos. | Updated frontend supporting Paseo Assethub target and documentation with usage instructions | Chain selector added to blueprint creation, a "Verify On-Chain" button on the proof list and detail pages, and chain-aware block explorer links. **Proof:** [`05_frontend_integration_and_documentation.md`](./05_frontend_integration_and_documentation.md), [`06_public_howto.md`](./06_public_howto.md), [`07_bytecode_verification.md`](./07_bytecode_verification.md). |
+
+## Evidence Index
+
+- [`01_circom_pipeline_integration.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/01_circom_pipeline_integration.md) - sdk-images
+- [`02_proof_formatting_and_wrapper_integration.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/02_proof_formatting_and_wrapper_integration.md) - sdk-images
+- [`03_blueprint_deployment_system.md`](https://github.com/zkemail/sdk-images/blob/kusama-grant/circom/docs/kusama-grant/milestone-3/03_blueprint_deployment_system.md) - sdk-images
+- [`04_sdk_on_chain_verification.md`](https://github.com/zkemail/zk-email-sdk-js/blob/kusama-grant/docs/kusama-grant/milestone-3/04_sdk_on_chain_verification.md) - zk-email-sdk-js
+- [`05_public_howto.md`](https://github.com/zkemail/zk-email-sdk-js/blob/kusama-grant/docs/kusama-grant/milestone-3/05_public_howto.md) - zk-email-sdk-js
+- [`05_frontend_integration_and_documentation.md`](./05_frontend_integration_and_documentation.md) - registry
+- [`06_public_howto.md`](./06_public_howto.md) - registry
+- [`07_bytecode_verification.md`](./07_bytecode_verification.md) - registry
+- [`08_revocation_demo.md`](./08_revocation_demo.md) - registry - additional evidence added in response to curator review, not itself a milestone deliverable
+
+## Summary
+
+The Circom pipeline generates templated wrappers and zkey-derived `Groth16Verifier` contracts and deploys them via Hardhat Ignition (sdk-images); the SDK's `verifyProofOnChain` calls the deployed verifier through a generic `IZKEmailVerifier` interface (zk-email-sdk-js); the registry frontend lets users select a target chain, generate proofs, and verify them on-chain through the UI (registry).
diff --git a/docs/kusama-grant/milestone-3/assets/01-create-blueprint-step1.png b/docs/kusama-grant/milestone-3/assets/01-create-blueprint-step1.png
new file mode 100644
index 0000000..5c59915
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/01-create-blueprint-step1.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/02-create-blueprint-step2-1.png b/docs/kusama-grant/milestone-3/assets/02-create-blueprint-step2-1.png
new file mode 100644
index 0000000..b2d10a4
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/02-create-blueprint-step2-1.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/03-create-blueprint-step2-2.png b/docs/kusama-grant/milestone-3/assets/03-create-blueprint-step2-2.png
new file mode 100644
index 0000000..de22d52
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/03-create-blueprint-step2-2.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/04-create-blueprint-step3.png b/docs/kusama-grant/milestone-3/assets/04-create-blueprint-step3.png
new file mode 100644
index 0000000..f0f877b
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/04-create-blueprint-step3.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/05-compilation-in-progress.png b/docs/kusama-grant/milestone-3/assets/05-compilation-in-progress.png
new file mode 100644
index 0000000..47da4f2
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/05-compilation-in-progress.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/06-generate-proof-step1.png b/docs/kusama-grant/milestone-3/assets/06-generate-proof-step1.png
new file mode 100644
index 0000000..731a3d9
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/06-generate-proof-step1.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/07-generate-proof-step2.png b/docs/kusama-grant/milestone-3/assets/07-generate-proof-step2.png
new file mode 100644
index 0000000..bdc7cd6
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/07-generate-proof-step2.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/08-verify-on-chain-success.png b/docs/kusama-grant/milestone-3/assets/08-verify-on-chain-success.png
new file mode 100644
index 0000000..af9dfdf
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/08-verify-on-chain-success.png differ
diff --git a/docs/kusama-grant/milestone-3/assets/09-proof-details.png b/docs/kusama-grant/milestone-3/assets/09-proof-details.png
new file mode 100644
index 0000000..b7d9c80
Binary files /dev/null and b/docs/kusama-grant/milestone-3/assets/09-proof-details.png differ
diff --git a/docs/kusama-grant/milestone-3/manifest.json b/docs/kusama-grant/milestone-3/manifest.json
new file mode 100644
index 0000000..cdcafd3
--- /dev/null
+++ b/docs/kusama-grant/milestone-3/manifest.json
@@ -0,0 +1,33 @@
+{
+  "repo": "registry",
+  "updated_at": "2026-08-26T20:00:00Z",
+  "branch": "staging",
+  "commit_sha": "9b12918be73817e4a79033d2bc67d0a85f203de9",
+  "dependency": {
+    "package": "@zk-email/sdk",
+    "version": "3.0.0-nightly.36"
+  },
+  "ci": {
+    "playwright.yml": {
+      "job": "test",
+      "run_url": "https://github.com/zkemail/registry/actions/runs/33000352081/job/98280253814",
+      "date": "2026-08-26"
+    }
+  },
+  "reference_blueprint": {
+    "id": "e94e7f93-7575-4e26-a147-de894b19ce3e",
+    "verifier_contract_chain": 420420417,
+    "verifier_contract_address": "0x72616B78d29d0cccBfEec1bf00E108885286D2f3",
+    "groth16_verifier_address": "0xDfbcfE9D3C6ecdc0d614Ff671b5A3fd73E6d3DBC",
+    "verifier_deployment_tx": "0x2de5759fc470311c6ef5be16855fbaee095725c3f3fb671fc31da422300d344e",
+    "proof_verify_tx": "0xb866a4b151dfba6838ba31275afc5dbc9e45b16918f1c6a69fab1d7592364934"
+  },
+  "revocation_demo": {
+    "domain_hash": "0xbbcc9f0af825b951a41a390086b09f7d8b4c4434d5315255b2ab6ffee1e8c781",
+    "key_hash": "0x0462b6e208f3552371d7c7d2fbeb31691e5f789b9e5f0bdfaa68a6a84f01d9aa",
+    "revoke_tx": "0x384c1540afaaf6782c5cff3bad71cd05854bd2f422246e8acf2f7cd42af74562",
+    "failed_verify_tx": "0xea3d710de2c21f6792d084262d6f65d5376d1cfb0e8ac3dafd6e62df42c8e5c5",
+    "restore_tx": "0xde60c1eca66d5caa295b885fb83a12023f49ef44a148d84d551ef49e4cb41f14",
+    "succeeding_verify_tx": "0x77fb1ffde5f93a74038cc639bed5f4880c0e0d2d4c76401afb58bdcf5c8de422"
+  }
+}