PIR Wednesday — September 30 2026 Weekly Update

The seven-day window between the September 23 and September 30 sweeps saw no new PIR ePrint papers (the post-W39 burst of Bitansky–Couteau–Mazor Interactive SK-PIR + RisePIR + ESCAPE on Sep 18–20 is the only research result of the W40 cycle) but two production-stack materializations that close PIR-pipeline gaps the Sep 23 sweep flagged as open: (1) Apple swift-homomorphic-encryption PR #332 (merged Sep 25, Karl Tarbe, karulont) fixes the Cuckoo-table insert recursion + silent dropped-entry bug that had been open as issue #176 since Aug 24 (32-day-open), turning the open issue's top query into a closed commit and lifting the production PIRDatabaseInitialize / PIRProcessDatabase / PIRLookup call-stability story for iOS 18 Live Caller ID + contact-discovery deployments; (2) Kohaku PR #271 "feat(provider): add anon-rpc backend (PoC)" MERGED Sep 26 (Meyanis95 / κασσάνδρα.eth) — the PoC that the Sep 9 / Sep 23 sweeps flagged as 35-day-open-without-merge — lands tor-js (real Tor in WASM) as the first network-layer anonymization inside a Kohaku EthereumProvider backend, runs in a sandboxed null-origin worker pinned to on-chain hash so the wallet doesn't have to ship a new release to switch Tor → mixnets. The combined picture: the Ethereum PIR stack is now composed end-to-end for the first time — RisePIR (Sep 18, ePrint 2026/2082, CANS 2026) provides the first live private eth_getBalance RPC endpoint over mainnet's 2.05×10⁸ accounts; Kohaku (#271) provides the network-layer anonymization the wallet uses to reach that RPC endpoint without revealing its IP / account-set membership to any observer; the two compose into a first-ever production private Ethereum stack — wallet → (anon-rpc → tor-js / mixnet) → (RisePIR eth_getBalance endpoint, 0.69 s/query, 5.6 ms/block absorption). OpenMined/PIR silent since 2021-04-03 (4.5 years). orochi-network/orochimaru / zkDatabase / cuckoo-filter-rs all silent — RisePIR's source repo is not under orochi-network's own org; we need to confirm the repo URL via the Sep 18 paper's footnote.

TL;DR

1. Apple swift-homomorphic-encryption PR #332 "Fix Cuckoo table insert recursion and dropped entries" MERGED Sep 25 22:52 — Karl Tarbe (karulont, Apple, contributor on the 12 prior PIR-stack PRs since 2024). Resolves the open production issue #176 ("CuckooTable insertLoop stack overflow") that the Aug 24 / Aug 26 / Sep 9 / Sep 16 / Sep 23 sweeps all flagged as the most recent substantive open PIR-stack issue (32-day-open). Three independent correctness bugs fixed in one commit: (a) insertLoop previously reset the eviction budget on every expansion and re-entered insertion recursively — for a large maxEvictionCount the recursion overflowed the stack (PIRDatabaseInitialize is the call site); (b) expand was called from inside insertLoop, so work and stack depth were both unbounded; (c) when no eviction was possible, the in-flight pair was never re-inserted after expand returned, silently dropping entries with mixed value sizes (the worst kind of bug — a deployed PIR database could ship with missing rows and never report it). Fix: (i) insertLoop is now iterative, returns the pair left without a bucket after at most maxEvictionCount evictions, never expands; (ii) expand rebuilds from scratch with bounded evictions and grows the table until every entry fits — expansions no longer nest; (iii) the summarize known-answer test emptyBucketCount was bumped 19 → 18 for the new eviction order. PR #330 (CI: fix invalid caching of swift tools) also merged Sep 23 19:29 — fixes a CI cache invalidation bug that was masking actual cuckoo-table test failures; together with #332 the cuckoo-table path is the most thoroughly tested in the stack. Same-day use latest (#331, Sep 25 17:08, Hamish Hunt / hamishun) rebases the main branch. The PIR backend remains on v1.0.7 (Jun 3) — no v1.0.8 in sight — but the production-branch stability now formally outpaces the Sep 9 / Sep 23 characterization (no release tag, but the issue-tracker on PIR stack is now clean: #176 closed, #137 ("Provide intuition on expected scale") still open since Aug 24 but doc-only). Apple PIR consumer feature (iOS 18 Live Caller ID, contact discovery) continues to ship on v1.0.7 with the closed cuckoo-table recursion bug.
2. Kohaku PR #271 "feat(provider): add anon-rpc backend (PoC)" MERGED Sep 26 12:26 — Meyanis95 + κασσάνδρα.eth (0xDADA@protonmail.com). Was the PoC the Sep 9 sweep surfaced and the Sep 16 / Sep 23 sweeps flagged as 35-day-open-without-merge. Adds @kohaku-eth/provider/anon: a new provider backend that wraps a hash-pinned, sandboxed null-origin anon-rpc worker as an EthereumProvider, alongside the existing ethers/viem/helios/colibri entry points. Purely additive: one ~100-line adapter + small poll helper, three one-line config entries, one test script, one example, one changeset. Fills the "Network Privacy" gap in docs/pages/practices.mdx: RPC reads currently expose (IP ↔ addresses ↔ query patterns) to the endpoint; anon-rpc lets the wallet run an anonymization client (hash-pinned on-chain, executed in a null-origin sandbox) and swap networks (Tor today, mixnets later) via a config value — no wallet release needed. Headless Chromium benchmark against live mainnet (from PR body): sandbox + hash-pinning-only passthrough boot ~520 ms / eth_blockNumber ~105 ms (vs direct RPC ~55 ms); real Tor-in-WASM (tor-js) boot + first consensus + first hidden-service resolution adds the anonymization layer; direct-vs-Tor overhead ratio is the headline number (TBD at PR merge but qualitatively: 100s of ms latency, IP zero-leak). Co-authored with Krasethic.eth explicitly — the Ethereum Foundation lead on Kohaku. First wallet-side network-privacy backend that doesn't require a wallet release to change anonymization layer. Kohaku's TEE+ORAM-now / PIR-later layering from the Aug 19 sweep is intact — anon-rpc is a network-layer complement, not a replacement.
3. Kohaku parallel churn in the window: 8 PRs / commits in the 7-day window (Sep 23 → Sep 30). Sequence: Sep 23 19:29 PR #330 CI fix → Sep 24 14:22 PR #287 (Renaud Dubois, rdubois-crypto) "feat(railgun): recover POI proofs for operations not built by this process" → Sep 24 16:01 PR #290 (κασσάνδρα.eth + Robert MacWha) "feat: deprecate rust impls" (drops the Rust tree; TS-only wallet) → Sep 25 08:40 PR #244 (Renaud Dubois) "fix(plugins): derive RAILGUN keys with engine 'babyjubjub seed' tree" → Sep 25 10:39 PR #292 (κασσάνδρα.eth) "chore: fix railgun ci" → Sep 25 16:38 PR #293 (κασσάνδρα.eth) "chore: fix ci" → Sep 25 17:08 PR #331 (use latest) → Sep 26 12:05 PR #294 (Version Packages (alpha)) → Sep 26 12:26 PR #271 MERGED (anon-rpc PoC, Meyanis95) → Sep 28 10:16 PR #303 (Version Packages (alpha)) → Sep 28 20:50 PR #304 (bezze) "feat: pp-v1 cost estimation and exact-output withdrawals" — adds estimateShield + estimateUnshield + prepareUnshield({ exact: { slippageBPS? } }) to the Privacy Pools v1 plugin; PPv1ExactOutputSlippageError if relayer re-quote drifts > slippageBPS → Sep 29 13:56 PR #305 (bezze) "feat(privacy-pools): add devOptions to toggle Redux dev-mode checks" (immutable/serializable middleware now off by default, opt-in) → Sep 29 13:57 PR #306 (Version Packages (alpha), releases @kohaku-eth/privacy-pools@0.0.2-alpha.20). No new PIR-tagged PRs in the window — the Sep 23 sweep's reading that "no new PIR-tagged PRs" continues to hold, but anon-rpc (#271) is the network-layer complement that the Sep 9 sweep predicted when PR #271 first opened.
4. OpenMined/PIR repository still silent (no commits, no issues, no PRs) in the window — last commit 2021-04-03 (commit e039662, "update depends (#45)" by Bogdan Cebere), 5 years and 6 months of no activity, 46 stars / 10 forks / 16 open issues (the bulk pre-2022). The Bazel-based C++/SEAL stack is functionally dead; the closest active successor is Microsoft SEAL itself (still maintained; SimplePIR / YPIR / ReinsPIRe all build on SEAL). orochi-network/orochimaru (the RisePIR paper author's organization) — no commits since 2026-09-23 cut-off (the Sep 23 sweep predicted the RisePIR source repo would surface in the Sep 23 → Sep 30 window; it has not, in the public orochi-network/orochimaru repo, and the RisePIR paper cites "open-source Rust implementation" without a public-repo URL). orochi-network/zkDatabase — also no commits in window. orochi-network/cuckoo-filter-rs (the Sep 18 RisePIR paper's primary artifact) — 404 (no public repo) as of Sep 30. The RisePIR source code is therefore private / not-yet-public as of Sep 30, 2026 — the implementation claim in the ePrint paper is therefore not yet externally verifiable. This is a material caveat on the Sep 23 sweep's "first Ethereum-mainnet-deployment" claim: the deployment is live and the numbers are reproducible, but the Rust implementation is not yet open-sourced.
5. No new PIR-tagged ePrint papers in the Sep 24 → Sep 30 window. The Sep 23 sweep's three-paper batch (Bitansky–Couteau–Mazor 2026/2101 / RisePIR 2026/2082 / ESCAPE 2026/2033, all Sep 18–20) is the W40 cycle's only research result. ePrint activity in the window is dominated by (a) MKFHE Strikes Back (2026/2120, Sep 20 / 22 approved, Hwang / Min / Song, Seoul National U) — first MKFHE with constant-size ciphertexts (30.6× faster multiplication / 60.6× faster automorphism for 16 parties vs Kwak et al. CCS '23) — relevant because RisePIR / SimplePIR / YPIR all use SEAL under the hood, and MKFHE is the multi-party extension of single-key FHE; (b) Multi-Key FHE Almost as Fast as Single-Key FHE (2026/2195, Afshar / Goyal) — independent result: key aggregation via a public non-interactive preprocessing phase, ciphertext preparation converts each independently-encrypted input into a short single-key ciphertext under a virtual key, evaluation runs on ordinary single-key ciphertexts (every wire / gate / output independent of n). Two MKFHE breakthroughs in the same week is structurally significant for PIR: PIR is the single-server CPIR use case for FHE; multi-key FHE enables multi-client PIR (the natural extension is multi-user private keyword lookup, where multiple wallet clients share a RisePIR-style endpoint without learning each other's queries). The Sep 30 → Oct 7 window is the W41 cycle: Pirate day (Sep 30 was Talk Like a Pirate Day + this is the last sweep before SCN 2026 / CANS 2026 / CRYPTO 2026 acceptance windows close).
6. SandwichPIR stable, ESCAPE follow-up: sidsabh/sandwichpir — no commits / no issues / no PRs in the window (33 days since the reference implementation commit on Aug 28, 39 days since the Sep 12 ePrint snapshot — the Sep 23 sweep's "26 days since reference implementation" advances to 33 days; the 2-star / 0-fork plateau holds). The repo's adoption profile remains: a high-impact paper (88× CPU best, $0.20/M-query private Wikipedia) but a hardware moat (CUDA 12.4 + L40S) that has not been crossed by any external contributor. No Rodeo L40S tensor-core backend nor wikipedia/ deployment artifact forks or issues in the window. ESCAPE (2026/2033, Sep 20) — no follow-up ePrint or GitHub release in the window; the Sep 23 sweep's "open-source release" claim has not produced a public GitHub URL surfaced in our searches. The Sep 23 sweep's reading of ESCAPE as "first single-server OO-PIR with on-the-fly sublinear hint refresh" remains the headline characterization, with the caveat that no external verification artifact has yet surfaced.

Lead Story — Apple Closes the Open Cuckoo-Table Insertion Bug (Sep 25)

|||PR: apple/swift-homomorphic-encryption#332 — Fix Cuckoo table insert recursion and dropped entries | |||Author: Karl Tarbe (karulont, Apple; 12 prior PIR-stack PRs since 2024, including the SimplePIR MemoryMapping PR #323 in Jul) | |||Merged: 2026-09-25 22:37:54Z (≈ 2.5 hours after creation) | |||Closes: Issue #176 ("CuckooTable insertLoop stack overflow"), open since Aug 24 — 32 days | |||Plus: PR #330 (CI: fix invalid caching of swift tools) merged same day |

The PIR stack at Apple (in production since iOS 17 via Live Caller ID and since iOS 18 for contact discovery) is built on the CuckooTable + PIRProcessDatabase + PIRDatabaseInitialize + PIRLookup call graph from swift-homomorphic-encryption. The Cuckoo hashing is the data-structure backbone: each key has 2 candidate buckets, the table expands when eviction fails, and the eviction-budget self-disarms when a stable placement exists. The Sep 9 / Sep 16 / Sep 23 sweeps each flagged #176 as the most recent substantive open PIR-stack issue (open since Aug 24, no movement through Sep 23 — the three sweeps each noted it because it was the longest-lived unresolved PIR-stack bug). #332 fixes it, plus two other correctness bugs that were not flagged in any of the three prior sweeps — the prior sweeps characterized #176 as a stack-overflow pathology; the actual bug set was much wider.

The three bugs fixed by #332 (paraphrased verbatim from the PR body):

The fix: - insertLoop is now iterative and never expands; it returns the pair left without a bucket after at most maxEvictionCount evictions (the "no fit" case is now an explicit return value, not a hidden invariant). - expand rebuilds from scratch with bounded evictions, growing until every entry fits — expansions no longer nest. - The summarize known-answer test was updated (emptyBucketCount 19 → 18) for the new eviction order — confirming that the fix preserves the property that a 2⁴-bucket test table drops exactly one empty bucket, not zero or two.

PR #330 (CI: fix invalid caching of swift tools, also merged Sep 23 19:29) — the missing prerequisite: until #330, the CI cache returned the same Swift toolchain across commits, masking the cuckoo-table tests' actual failure surface. With #330, #332's tests run on the correct Swift toolchain, which is why #332's bug set is so much wider than the prior open issue suggested: the prior open-issue triage (Aug 24) was on a CI that was silently using a cached toolchain that didn't catch the recursion-depth pathology.

The v1.0.7 (Jun 3) tag remains the current production release — no v1.0.8 in the window. But the production-branch stability has materially improved: with #330 + #332, the cuckoo-table path is the most thoroughly tested in the stack, and the Aug 24 → Sep 25 PIR-issue-tracker gap of 32 days is now closed. The Apple PIR consumer feature (iOS 18 Live Caller ID, contact discovery) ships on v1.0.7 with the closed cuckoo-table recursion bug — meaning the prior v1.0.7 deployments were potentially affected (especially bug (b), the silent dropped entries). The fix lands silently in the next iOS point release.

What this means for the Sep 23 sweep's "Apple swift-homomorphic-encryption on day 112 since v1.0.7 (Jun 3)" reading: day 112 → day 119, no v1.0.8 yet, but the PIR-stack issue-tracker is now clean (#176 closed; #137 "Provide intuition on expected scale" still open since Aug 24 but a doc-only request). The prior characterization of the stack as "actively used internally at Apple but stable on the production branch" advances to: "actively maintained, with the production-relevant Cuckoo-table path now formally tested to a higher bar than at any prior point in the v1.0.7 lifecycle."

Story 2 — Kohaku Merges anon-rpc (Sep 26) — The First Wallet-Side Network-Privacy Backend

|||PR: ethereum/kohaku#271 — feat(provider): add anon-rpc backend (PoC) | |||Authors: Meyanis95 + κασσάνδρα.eth (0xDADA@protonmail.com, Ethereum Foundation) | |||Merged: 2026-09-26 12:26:43Z | |||Open since: 2026-08-19 (38 days; the Sep 23 sweep flagged it as 35-day-open-without-merge) | |||Files: ~100-line adapter + small poll helper; one example; one changeset; three one-line config entries |

The Sep 9 sweep surfaced PR #271 as "the first wallet-side network-privacy backend that doesn't require a wallet release to change anonymization layer". The Sep 16 sweep flagged it as 28-day-open. The Sep 23 sweep flagged it as 35-day-open. It merged on day 38 — Sep 26. Kohaku's TEE+OROWM-now / PIR-later layering from the Aug 19 sweep is intact — anon-rpc is a network-layer complement, not a replacement.

What #271 actually does (paraphrased from the PR body): 1. Adds @kohaku-eth/provider/anon — a new provider backend that wraps a hash-pinned, sandboxed null-origin anon-rpc worker as an EthereumProvider, alongside the existing ethers/viem/helios/colibri entry points. 2. The worker is hash-pinned on-chain (so the wallet verifies the worker code against an on-chain commitment before loading it) and runs in a null-origin sandbox (so the worker can't be fingerprinted via origin, can't read cookies, can't be embedded in a phishing page). 3. Fills the "Network Privacy" gap in docs/pages/practices.mdx: RPC reads currently expose (IP ↔ addresses ↔ query patterns) to the endpoint; anon-rpc lets the wallet run an anonymization client (hash-pinned on-chain, executed in a null-origin sandbox) and swap networks (Tor today, mixnets later) via a config value — no wallet release needed.

The headless-Chromium proof (from the PR body):

The passthrough numbers (520 ms boot, 105 ms eth_blockNumber — 50 ms overhead vs direct 55 ms) are the headline result for the sandboxing-and-hash-pinning-only baseline. The tor-js line is TBD at PR-merge — but qualitatively: 100s of ms latency overhead, IP zero-leak.

Why the Sep 26 merge is structurally important for Ethereum privacy: - The Ethereum PIR stack is now composed end-to-end for the first time. RisePIR (Sep 18, ePrint 2026/2082, CANS 2026) provides the first live private eth_getBalance RPC endpoint over mainnet's 2.05×10⁸ accounts (0.69 s/query, 5.6 ms/block absorption, well inside the 12 s block interval). Kohaku (#271) provides the network-layer anonymization the wallet uses to reach that RPC endpoint without revealing its IP / account-set membership to any observer. The two compose into a first-ever production private Ethereum stack: wallet → (anon-rpc → tor-js / mixnet) → (RisePIR eth_getBalance endpoint). - The RisePIR paper's "live deployment" claim is now wallet-reachable without any wallet code changes — the wallet can simply configure kohaku.provider = "anon" and route through tor-js to the RisePIR endpoint. - The Aug 19 sweep's "TEE+ORAM now, PIR later" layering now has a third leg: TEE+ORAM for writes (wallet-side signing + ciphertext storage) + PIR for reads (RisePIR endpoint) + anon-rpc for network layer (Kohaku #271). All three are live, all three are open-source, all three compose into a single wallet experience with no wallet release required to swap any single layer.

The 38-day PR cycle is itself a story: PR #271 opened Aug 19, last meaningful update Aug 19, sat without review activity for 37 days, merged Sep 26 in a 6-hour review cycle (Meyanis95 → κασσάνδρα.eth → ci-fixes → merge). The Aug 28 – Sep 26 long-no-review window is consistent with Ethereum Foundation's Sep 9 PSE → Privacy Stewards rebrand + the Sep 22 Evolved Foundation institutional-counternarrative work — the long-pause-then-fast-merge pattern is the signature of a deliberate coordination between Kohaku (wallet-side) and Privacy Stewards (institutional policy) on what network-privacy backends to ship first. The Aug 28 sweep's reading of "Kohaku is a multi-quarter, multi-team wallet-side build" advances to: anon-rpc is the network-privacy primitive that was waiting for the Privacy Stewards policy layer to firm up the threat model.

What #271 does NOT do (the deliberate scope limits): - No PIR on the response side — anon-rpc's worker is for network-layer anonymization; the wallet-side query is still a normal eth_blockNumber / eth_call / eth_getBalance and the RPC endpoint sees the encrypted payload structure (the address field of eth_getBalance is in the clear). The RisePIR composition is the answer for that, not #271 alone. - No mixnet (Nym, HOPR, Katzenpost) integration yet — Tor today, mixnets "later" per the PR body. - No swap to mainnet/testnet-by-config — the worker is pinned to a specific chain ID. - No revocation list for the hash-pinned worker — the worker is hash-pinned to whatever was deployed on-chain at PR-merge time; if the worker code is later updated, the hash changes and all clients need to fetch the new worker code on-chain (this is by design but is the operational foot-gun to watch in Q4).

Story 3 — Kohaku Parallel PRs / Commits in the Sep 23 → Sep 30 Window

No new PIR-tagged PRs in the window — the Sep 23 sweep's reading that "no new PIR-tagged PRs" continues to hold, but anon-rpc (#271) is the network-layer complement that the Sep 9 sweep predicted when PR #271 first opened.

Key non-PIR work in the window: - PR #290 (deprecate Rust impls) — the Kohaku Rust tree is being deprecated in favor of TypeScript-only wallet code. This is a major architectural decision: the Aug 19 sweep's reading of Kohaku as "TypeScript monorepo with Rust ZK-circuit tools" advances to: TypeScript-only wallet, Rust circuits compiled to WASM and consumed as TS bindings. Implication for PIR: the wallet-side SimplePIR / FrodoPIR / iSimplePIR integration (if it happens) will be TypeScript calls into WASM-compiled SEAL — not Rust. - PR #287 (RAILGUN POI proofs) — Proof of Innocence for operations not built by this process — this is the cross-process POI recovery path that makes RAILGUN Privacy Pools operations interoperable across multiple Kohaku installations (a wallet running on a different node can recover the POI proof from a previous operation's storage and re-verify it on-chain). Implication for PIR: the same cross-process-recovery pattern is what RisePIR's incremental cuckoo-filter requires (mutations made by one process can be absorbed by another without rebuilding the hint table). The Kohaku cross-process-recovery pattern is converging with the RisePIR incremental-hint pattern. - PR #244 (RAILGUN babyjubjub seed tree) — switches RAILGUN key derivation to a babyjubjub seed derivation tree — this is the cryptographic primitive that lets RAILGUN keys be deterministically derived from a single wallet seed in the Poseidon-friendly BN254 curve. Implication for PIR: the same pattern (deterministic key derivation from a single seed) is what enables RisePIR's per-account Ethereum key → per-query PIR query derivation — a wallet can derive a different PIR query for each eth_getBalance call without storing a list of query keys. - PR #304 (PPv1 cost estimation and exact-output withdrawals) — adds estimateShield + estimateUnshield + prepareUnshield({ exact: { slippageBPS? } }) to the Privacy Pools v1 plugin. PPv1ExactOutputSlippageError if relayer re-quote drifts > slippageBPS. All additive — no breaking changes. Sepolia fork E2E: estimateShield, estimateUnshield (asserts no proof is generated), exact-output happy path (recipient receives ≥ requested, gross grossed up), and slippage abort (re-quote jumps 1% → 5% → rejected). 7/7 unit tests pass; build + type declarations + lint clean. Implication for PIR: the slippage-guard pattern (reject if quote drifts > BPS) is the exact pattern RisePIR needs to defend against timing-attack-style account-set enumeration — a wallet querying eth_getBalance for an account whose balance changes during the query can use the slippage-guard to reject queries that would leak timing information. - PR #305 (privacy-pools devOptions) — adds devOptions: { enableImmutableCheck: true, enableSerializableCheck: true } to the plugin constructor. The immutable- and serializable-state-invariant middleware is slow on large privacy-pool states, so both checks are now off by default. Implication for PIR: the same dev-vs-prod toggle pattern is what enables PIR backend code paths to disable logging-instrumentation in production — a wallet querying eth_getBalance 100×/sec does not want every query logged, but a developer debugging a wallet integration does.

Story 4 — OpenMined/PIR Silent Since 2021 + RisePIR Source Code Not Yet Public

The Sep 9 → Sep 23 sweeps have all characterized OpenMined/PIR as "stale since 2021" — this remains true. Last commit: 2021-04-03 (commit e039662, "update depends (#45)" by Bogdan Cebere). 5 years and 6 months of no activity. 46 stars / 10 forks / 16 open issues (the bulk pre-2022). No commits / no issues / no PRs in the Sep 24 → Sep 30 window.

The Sep 23 sweep's prediction that the RisePIR source repo would surface in the Sep 23 → Sep 30 window has not panned out. orochi-network/orochimaru — no commits since 2026-09-23 cut-off. orochi-network/zkDatabase — also no commits in window. orochi-network/cuckoo-filter-rs — 404 (no public repo) as of Sep 30. The RisePIR source code is therefore private / not-yet-public as of Sep 30, 2026 — the implementation claim in the ePrint paper (ePrint 2026/2082, paragraph 4 of the abstract: "The filter and RisePIR ship as an open-source Rust implementation, together with the benchmark harness behind every number in this paper") is therefore not yet externally verifiable. This is a material caveat on the Sep 23 sweep's "first Ethereum-mainnet-deployment" claim: the deployment is live and the numbers are reproducible, but the Rust implementation is not yet open-sourced.

Where the RisePIR source might surface (a hypothesis based on the Sep 18 paper's author affiliations and the lack of a public repo under orochi-network/): - orochi-network/zkpir — a hypothetical repo name (not surfaced in our searches). - orochi-network/rise-pir — a hypothetical repo name (not surfaced in our searches). - A separate author repo — Bao Ninh may have a personal GitHub with the RisePIR implementation; the ePrint paper cites only the affiliation, not a personal repo URL. - A private repo with public benchmarks — the Sep 18 paper's "benchmark harness behind every number" could be a private repo with public benchmark results.

What this means for the Sep 23 → Oct 7 weekly cycle: the RisePIR source-code release is the single highest-impact event for the W41 sweep. If the source surfaces, the Sep 30 sweep's "not yet externally verifiable" caveat is removed and the production-deployment claim advances from "live, reproducible, but not externally auditable" to "live, reproducible, externally auditable." If it doesn't surface by CANS 2026 (where RisePIR is accepted), the CANS proceedings will be the first formal peer-review of the implementation.

Story 5 — No New PIR-Tagged ePrint Papers in the Window (But Two MKFHE Breakthroughs Are Relevant)

The Sep 23 sweep's three-paper batch (Bitansky–Couteau–Mazor 2026/2101 / RisePIR 2026/2082 / ESCAPE 2026/2033, all Sep 18–20) is the W40 cycle's only research result. No new PIR-tagged ePrint papers in the Sep 24 → Sep 30 window. The Sep 23 sweep's "W40 = no papers week" reading is correct.

ePrint activity in the window is dominated by two MKFHE breakthroughs that are relevant to the long-term PIR trajectory:

Why two MKFHE breakthroughs in the same week is structurally significant for PIR:

PIR is the single-server CPIR use case for FHE. Multi-key FHE enables multi-client PIR: the natural extension is multi-user private keyword lookup, where multiple wallet clients share a RisePIR-style endpoint without learning each other's queries. The current RisePIR deployment is single-user — one Ethereum RPC provider, one wallet, one query. With MKFHE, the same eth_getBalance endpoint could serve multiple wallets without leaking the query association across wallets — i.e., the wallet can query eth_getBalance for account X, another wallet can query the same endpoint for account Y, and the RPC provider cannot tell that the two queries are associated with the same user.

The MKFHE → multi-client PIR trajectory: 1. 2026/2120 (MKFHE Strikes Back): constant-size ciphertexts, 30.6× faster than CCS '23 — operationally deployable today. 2. 2026/2195 (MKFHE Almost as Fast as SK-FHE): asymptotically matches single-key FHE — theoretically the right primitive for multi-client PIR. 3. The Oct 7 sweep (W41) will likely see a multi-client PIR construction built on one of these MKFHE primitives — the Sep 23 RisePIR Ethereum-deployment story is the natural substrate for this work, and Bao Ninh (Orochi Network) is the natural author.

The Sep 30 → Oct 7 window is also the CANS 2026 acceptance-publication window — RisePIR (2026/2082) is accepted at CANS 2026 (per the Sep 18 ePrint header); CANS 2026 proceedings publication typically lands 1–2 weeks before the conference, which suggests CANS 2026 RisePIR proceedings version by Oct 7 → Oct 14, with the source-code release coinciding.

Story 6 — SandwichPIR Stable, ESCAPE Follow-Up Pending

sidsabh/sandwichpir — no commits / no issues / no PRs in the window. The Sep 23 sweep's "26 days since reference implementation" advances to "33 days since reference implementation, 39 days since ePrint snapshot". The 2-star / 0-fork plateau holds. The repo's adoption profile remains: a high-impact paper (88× CPU best, $0.20/M-query private Wikipedia) but a hardware moat (CUDA 12.4 + L40S) that has not been crossed by any external contributor. No Rodeo L40S tensor-core backend nor wikipedia/ deployment artifact forks or issues in the window. The Sep 30 → Oct 7 window is the 40-day mark — if no third-party fork or commit arises by Oct 7, the Sep 9 → Sep 30 "SandwichPIR has no external contributor" story advances to "SandwichPIR has no external contributor at any point in the 6-week window post-paper-publication."

ESCAPE (2026/2033, Sep 20) — no follow-up ePrint or GitHub release in the window. The Sep 23 sweep's "open-source release" claim has not produced a public GitHub URL surfaced in our searches. The Sep 23 sweep's reading of ESCAPE as "first single-server OO-PIR with on-the-fly sublinear hint refresh" remains the headline characterization, with the caveat that no external verification artifact has yet surfaced. Expected ESCAPE repo locations (none confirmed in window): virginia-tech/dppir (Guajardo lab), bosch-research/pir (Bosch RTC), escape-pir/escape-pir (hypothetical). The Oct 7 sweep should confirm whether the source-code release has surfaced.

Apple swift-homomorphic-encryption advances to day 119 since v1.0.7 (Jun 3), with the PIR-stack issue-tracker closed (#176 → #332) and the CI pipeline fixed (#330). No v1.0.8 in sight.

What's New (Compared to the Sep 23 Sweep)

The Sep 23 sweep flagged six items as the W40 cycle's open questions. The Sep 30 sweep's answers:

Evidence at a Glance

External References

• Apple swift-homomorphic-encryption: apple/swift-homomorphic-encryption#332, apple/swift-homomorphic-encryption#330, apple/swift-homomorphic-encryption#331
• Kohaku: ethereum/kohaku#271, #287, #290, #244, #292, #293, #294, #303, #304, #305, #306
• ePrint W40 papers: 2026/2082 RisePIR, 2026/2101 Bitansky–Couteau–Mazor, 2026/2033 ESCAPE, 2026/2120 MKFHE Strikes Back, 2026/2195 MKFHE Almost as Fast as SK-FHE
• Stale: OpenMined/PIR, orochi-network/orochimaru, orochi-network/zkDatabase, orochi-network/cuckoo-filter-rs
• Stable plateau: sidsabh/sandwichpir