# Multi‑Region Infrastructure **URL:** \ **Category:** Community Grants\ **Created:** [July 5, 2026, 5:51pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556 "2026-07-05T17:51:09Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 5, 2026, 5:51pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/1 "2026-07-05T17:51:09Z")
Hello Everyone, My name is Perryn Gordon, I am an information technologist focused on developing, deploying and sustaining secure cloud solutions. I am interested in submitting a grant proposal to implement multi-region highly-available Zebra and Lightwallet infrastructure. I’d like to validate that using this template [RFP - Zcash Lightwalletd Infrastructure Development and Maintenance](https://forum.zcashcommunity.com/t/rfp-zcash-lightwalletd-infrastructure-development-and-maintenance/47080) is still the best way to develop a successful proposal, or if there is something newer I should be looking at. I would be grateful for any advice anyone might have for my process leading up to submitting an infrastructure proposal. I am encouraged by the excitement, creativity, and depth of engagement I’ve seen reading through various topics here. I am looking forward to becoming a helpful member of this community. ---
**Author:** ![ZKZeek](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zkzeek/32/46012_2.png) [@ZKZeek](https://forum.zcashcommunity.com/u/ZKZeek)\ **Post date:** [July 10, 2026, 10:33pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/2 "2026-07-10T22:33:36Z")
Running lightwalletd across multiple regions is exactly the reliability work wallets have been missing. When a wallet fails over between regions, does one operator end up seeing that user’s whole request pattern, or does the design keep each region’s view partial? ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 11, 2026, 3:02am UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/3 "2026-07-11T03:02:30Z")
Hi ZKZeek, Thanks for the question! The infrastructure design that has been whomped up thus far is using Cloudflare to frontend all user requests to the nearest node, all of the nodes being under my operator “zinfra.xyz”, this kind of visibility being the same as if this were a single-node system, until Cloudflare routes to a different node due to the closest being not healthy/available, and so then spreading some of the pattern between nodes, albeit under the same operator. This single-operator exposure is mitigated by configuring Cloudflare to mask user’s info , so there is nothing to use as original identity/finger printing information or any session like data coming through from Cloudflare, and consequently nothing to corelate in the session data between nodes either. I am looking to provide a means of ongoing and real-time verification that the Cloudflare implementation feeding these nodes is always set so that no user data ever comes through. Please let me know if that answers your question, if that sounds good like a good approach, and/or if I can clarify anything. Please do correct my understanding and/or ask for any particular design desires, the input is very much appreciated. ---
**Author:** ![ZKZeek](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zkzeek/32/46012_2.png) [@ZKZeek](https://forum.zcashcommunity.com/u/ZKZeek)\ **Post date:** [July 12, 2026, 10:51am UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/4 "2026-07-12T10:51:13Z")
Can someone outside verify that config independently, or does it come down to trusting zinfra to attest its own setup? ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 12, 2026, 8:08pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/5 "2026-07-12T20:08:20Z")
I think the best way would be for independent verification; ill look into setting it up so that designated community security auditors would have admin access to this and would get notified for any configuration changes. ---
**Author:** ![ZKZeek](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zkzeek/32/46012_2.png) [@ZKZeek](https://forum.zcashcommunity.com/u/ZKZeek)\ **Post date:** [July 14, 2026, 9:07pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/6 "2026-07-14T21:07:10Z")
Could that config instead be exposed as a public endpoint any user or wallet reads directly, so trust does not concentrate in the auditor set either? Giving auditors change alerts is a real step up from zinfra attesting its own setup. ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 16, 2026, 6:15am UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/7 "2026-07-16T06:15:39Z")
ZKZeek thanks for the thoughtful questions. I think it may be feasible to implement both a public endpoint and auditor access. My proxying the CloudFlare config would have its own trust issues, and having the CloudFlare config be accessible directly would need to be a feature that CloudFlare provides; with some continued discussion and discovery we will figure out solution details for this. ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 16, 2026, 6:32am UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/8 "2026-07-16T06:32:44Z")
Maybe as part of development we provide a tool for auditors to use to independently proxy this information to the public since as auditors they would have the access privileges to do so. This is still an auditor centric solution, but i’m thinking that having the auditors retain a level of independence from each other means many of them providing this information could provide a foundation for the information being trustworthy. ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 17, 2026, 12:34am UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/9 "2026-07-17T00:34:45Z")
Logs from CloudFlare show Zinfra is being sent sanitized/proxied user information, looks like these logs can be sent from CloudFlare directly to an immutable store that is publicly available. The signed hash bit of it would be icing on the cake if it can be implemented like as presented below: from copilot : ## **Cloudflare Logpush + Cloudflare R2 + Cloudflare Signed Hashes** Cloudflare can push: - logs - metadata - signatures - checksums into R2. This gives you: - Cloudflare‑generated hash - Immutable object storage - Publicly verifiable logs - Zero involvement from the infra provider - Zero opportunity for tampering ---
**Author:** ![ZKZeek](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zkzeek/32/46012_2.png) [@ZKZeek](https://forum.zcashcommunity.com/u/ZKZeek)\ **Post date:** [July 17, 2026, 1:10pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/10 "2026-07-17T13:10:58Z")
Would the tool make their outputs directly comparable so a mismatch is obvious, or would a reader be left reconciling them by hand? ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 17, 2026, 10:17pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/11 "2026-07-17T22:17:12Z")
The first idea was to create a tool that designated folks with a key to Zinfra’s CloudFlare account could use to continually scrape the CloudFlare configuration page to see that it is and always stays configured to make the user’s real information anonymous to the Zinfra platform. Presumably we’d also be able to enable notifications to the group whenever this configuration changes. When an auditor scrapes the configuration and it is set to hide user info then the tool reports green, if that setting is not set to hide the user info then the tool returns red, I am thinking that this would eliminate the need for the auditors to do any kind of reconciliation between themselves. The second idea is to skip the scraping tool altogether and just have CloudFlare continuously publish the logs to a publicly accessible place, the logs would be immutable and signed/hashed by CloudFlare. The logs show all the user info that is passed to Zinfra, and would be used for ongoing verification by anyone who wants to check it. There would be no tool provided here, I am thinking the most veracious results would come from an auditors own tooling, instead of something that Zinfra would provide that would then itself need to be constantly audited. Please let me know if you think either solution is in the ballpark. thanks !! ---
**Author:** ![ZKZeek](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zkzeek/32/46012_2.png) [@ZKZeek](https://forum.zcashcommunity.com/u/ZKZeek)\ **Post date:** [July 18, 2026, 1:56pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/12 "2026-07-18T13:56:32Z")
My one worry is that a public log of every request Zinfra sees could become a timing and volume signal an outside watcher reads even with identifiers stripped, so could the log format blunt that? Idea two is the stronger one to me, since it drops the tool that would itself need auditing. ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 19, 2026, 4:28pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/13 "2026-07-19T16:28:19Z")
Yes, it looks like CloudFlare’s log\_push contents and format are completely customizable. ---
**Author:** ![cavalla](https://avatars.discourse-cdn.com/v4/letter/c/9f8e36/32.png) [@cavalla](https://forum.zcashcommunity.com/u/cavalla)\ **Post date:** [July 23, 2026, 7:48pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/14 "2026-07-23T19:48:45Z")
will the designated community auditor be some real person or a technical feature powered by code? ---
**Author:** ![perryngordon](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/perryngordon/32/46257_2.png) [@perryngordon](https://forum.zcashcommunity.com/u/perryngordon)\ **Post date:** [July 23, 2026, 9:01pm UTC](https://forum.zcashcommunity.com/t/multi-region-infrastructure/56556/15 "2026-07-23T21:01:29Z")
For the first idea I was thinking a real person or group, who would have elevated access to CloudFlare to check that the config is set to pass anonymous data. The second idea would be immutable, signed public logs from CloudFlare that anyone could view and check that the data sent is anonymous, so designating people would not be necessary in this case.