This is an intention post and a call for collaborators. I’m convening this topic rather than proposing to run it single-handed: the framing, the argument and the introductions are here, and I’m looking for an operating team to build it with — particularly India-based organisers. See Team for exactly what’s committed and what isn’t.
Summary of Proposal
A hands-on space for running your own connection to Ethereum. Self-custody answered “not your keys, not your coins.” This hub tackles its unsolved twin — “not your node, not your data.” Bring the device you already carry, and leave with your own wallet reading Ethereum through software you run, with no provider in the path.
Motivation and Rationale
The problem is invisible and nearly universal. Almost every Ethereum user reaches the network through a third-party RPC endpoint: a company that sees every question they ask and chooses what to answer. People who have carefully self-custodied their keys still hand their entire view of the chain to an intermediary, and mostly don’t know they’re doing it.
The EF Mandate names this directly. Section VI, point 4:
There are already many places across the Ethereum protocol and application layer - block building, RPC servers, entities attesting to aspects of digital identity - where intermediaries exist. This state of affairs carries serious risks: one or more intermediaries may become dominant chokepoints, impose their special interests, censor users, enforce arbitrary participation rules, or extract value.
And sets the standard:
In particular, we ensure the presence of a “zero option”: for every affordance that has an intermediated path, any intermediary-free path that is possible must be built and must remain credible and accessible.
For RPC, that intermediary-free path is thinner than the ecosystem assumes. The Portal Network was meant to provide it; its reference client, Trin, is now explicitly unmaintained. Light client work more broadly has a habit of falling off roadmaps — as recently as May 2026, Lodestar’s light client and prover packages were moved out of the flagship monorepo into a separate repository. Good work exists, in Nimbus, Helios, Lodestar and elsewhere, and much of it is genuinely usable today. But it is maintained by very few people, it is largely invisible to the users who would benefit most, and nobody is currently accountable for the layer as a whole.
That gap is the reason for this hub. The tooling has quietly become real; almost nobody knows, and the people maintaining it are working without much company.
And there is a reason it hasn’t landed, which two of our participants arrived at independently. Steffen Kux (Colibri) puts it as weight: light clients in their many versions have not succeeded because they remain too heavy for mobile and web — slower, more data to sync, more to store — which is why Colibri is stateless, “as simple as RPC but trustless by cryptographic proofs.” Dirk Jäckel (Myotis) hit the same wall from the other side: a node app on a phone has to drop its peers when idle or it drains the battery, and a wallet talking to it has no way to know it is addressing a sleeping node. Same conclusion from opposite directions — the model of “run a node beside your wallet” does not survive contact with a phone. What survives is verification you embed. That is a finding worth a room, and it is not the story the ecosystem currently tells itself about light clients.
How it enhances the attendee experience. Most Devcon content is watched. This is installed. An attendee walks in depending on someone else’s node and walks out not depending on it, on the device already in their bag. That is a rare thing to be able to offer, and it is memorable precisely because it changes something the attendee owns.
The measure of success is the wallet, not the app. Nobody wants a light client. People want their wallet to stop trusting a company. So the clinic does not end when software is installed — it ends when an attendee’s own wallet shows their own balance, resolves a name, or sends a transaction, with the verification happening on their machine and no provider anywhere in the path. The light client is plumbing they should barely see. We say this plainly because the maintainer of one of these clients said it to us first: a node app whose main screen is a debug view is not, by itself, a benefit to anyone.
On phones the answer is different, and it has just started working. A standalone node app on Android has to drop its peer connections when idle or it eats the battery — and a wallet talking to it over local RPC has no way to know it is addressing a sleeping node. The fix is not a better standalone app. It is the light client living inside the wallet, where the host app knows about lifecycle and can tell the user “reconnecting, give it a moment.”
That is no longer theoretical. A build of an existing open-source Android wallet with a light client compiled into the same process — no socket, no local RPC — now proves a balance on-device against its own verification, and has signed and broadcast a transaction with no fallback provider present in the build at all. Cold start to a usable node is about a minute, during which the wallet tells you what it is doing rather than failing silently. It is early: it needs a recent Android, it is memory-hungry, and it has not been tested in anger. We are not promising it as a finished product. But it means the mobile track is a working session with wallet developers standing next to something that runs, rather than a discussion of something that might.
Why a hub, and not a talk or a workshop. A talk can explain that light clients exist. It cannot get software onto a stranger’s laptop. Installs fail in specific, individual ways — a Gatekeeper prompt, a firewall, an unfamiliar package manager, a network that filters UDP. Each one takes a few minutes of one-to-one attention from someone who knows the software. That is a support desk staffed over four days, not a session. It is also why the format has to be persistent: people try, hit a wall, wander off to a talk, and come back. A hub lets them come back.
How it complements Devcon 8 India. The Self-Custody & OpSec Hub is this hub’s twin, and the pairing is exact: they serve the people who hold keys safely, we cover the other half of the same user’s sovereignty — not the key path, but the data path. An attendee who has learned to read a transaction carefully is still reading a screen populated by an endpoint they don’t control, and the same is true of checking approvals through a block explorer. We have offered them a joint session on that, and would cross-refer attendees either way.
How it supports builders. Light client and node-software maintainers get something they almost never have: a queue of real users installing their software on unfamiliar hardware, in front of them, failing in ways no CI catches. That feedback loop is the single most valuable thing this hub produces, and it runs in both directions.
Have we organized a hub before? This hub is a reframing of the Node Operators Hub, which Jonathan Meyer ran at previous editions. He isn’t able to host this year and has been generous with his input on the reframing. What we carry forward: the hardware showcase, the walk-in support desk, the daily-theme structure. What we change: the centre of gravity moves from staking to end-user access. Solo staking is well served by EthStaker and others, whereas the mass-market user who should have a sovereignty-preserving connection to Ethereum is unrepresented. Staking remains welcome, with emphasis on resource-constrained hardware and distributed validator technology.
I have not run a Community Hub myself, which is a large part of why this is posted as a convening call rather than a finished plan. Jonathan is advising on what the format actually demands, and I would rather recruit people who have done it than discover the gap in November.
Implementation
Production requirements:
- Wired ethernet at the demo tables — the single most important item. Everything demonstrated here is peer-to-peer: discovery protocols need outbound UDP, and libp2p needs sustained TCP connections. Conference wifi that filters UDP or applies aggressive NAT will break live light-client demos in a way that misrepresents the technology and teaches attendees the wrong lesson. Wired uplink with unrestricted outbound traffic is what makes this hub demonstrable rather than theoretical. We are flagging this early as a hard dependency rather than a preference, and we will test against hostile network conditions before the event either way. Two of the demos make this concrete rather than abstract. The live A/V chain needs a sustained 3–6 Mbps uplink — modest, but sustained and outbound, which is the direction venue wifi handles worst. The bare-metal provisioning demo speaks EFI_TCP4 over a built-in wired NIC and needs DHCP: no wifi, no captive portal, no proxy, or it cannot boot at all.
- 4–6 tables with power, for hardware and laptop installs
- Three screens — two side by side for the media day’s live-versus-storage comparison, one for workshops and walkthroughs
- Audio out to a small speaker or headphones, for generated-caption playback
- Microphone/PA for roundtables if the space is open-plan
- Mains power for 3–4 low-draw single-board machines running continuously
What we will source ourselves: demonstration hardware brought by participating projects (single-board computers and phones for the showcase), printed quick-start guides, and testnet funds for attendees doing hands-on setup. Attendees install on their own laptops, so we are not asking for or providing loaner machines.
Programming
Possible speakers and topics
Marked honestly: confirmed, interested, or invited-and-awaiting-reply. We would rather show you the real state than a wish list presented as a line-up.
- OFFERED — “Your wallet, reading Ethereum through software you run” (Dirk Jäckel, Myotis). One or two runs of a practical workshop: get it onto your laptop, point your own wallet at it, and watch queries answered from your machine instead of a provider’s. Offered, not confirmed — he maintains the project unfunded and cannot currently afford to attend. A ticket from the organiser allocation would resolve it.
- CONFIRMED — Colibri Stateless (Steffen Kux and team, corpus-core). One or more workshops on integrating a stateless verifier into an application, plus a session on Pragmatic Adaptive Privacy: your reads leak who you are and what you intend to do, to RPC providers and indexers, before any transaction is ever broadcast. PAP treats that as two separate problems — who observes your requests, and what your requests reveal — and lets a developer pick a level for each. It is the half of sovereignty that running your own node alone does not fix.
- What does sovereignty actually cost you? The session this hub is built around. Not “which of these is best”, but a spectrum, priced honestly, with the people who built each point on it:
- A full node — the BuidlGuidl Client runs a real execution and consensus pair on your own hardware. You verify everything and depend on nobody. Its own README states the price: a 2TB NVMe and 32GB of RAM.
- A light client — Myotis fetches and verifies for itself over devp2p and libp2p, on the laptop or phone you already own. Still no server in the path, at a fraction of the hardware. The cost is that it must run a peer-to-peer stack, which rules out a browser, and deep history is harder.
- A stateless verifier — Colibri splits proving from verifying: a prover assembles a self-contained proof and a thin verifier in portable C checks it anywhere, including in a browser and offline. The server can no longer lie to you, but someone still has to run one.
Colibri and Myotis rest on the same cryptography — sync-committee BLS signatures and Merkle proofs against verified roots — and differ on who assembles the proof, not on how it is checked. Attendees should leave knowing which point on that spectrum fits their machine and their tolerance for depending on someone.
Two axes the hardware numbers miss, and both belong in the same session:
Ownership versus verification. These are different kinds of answer, not different sizes of the same one. You can own the thing you ask — a Raspberry Pi Zero 2 W on your own network, holding the RPC tunnels so nothing else in the house has to, is real and costs almost nothing. Or you can verify what you are told, in which case there is nothing to own, because you check the headers yourself. The cheap row on the table is not a smaller version of the expensive one.
The supply chain you inherit. Count the organisations that must cooperate before a node runs at all: laptop firmware, an operating system vendor, their package mirrors, a container registry, a language package index, the code host, the toolchain. None of them are accountable to the operator, and each can be compelled, acquired, or simply fold. We apply one standard of custody to funds and an entirely different one to the software guarding them. An audit of a single ordinary laptop, before any Ethereum software is installed, found five distinct companies in the path.
This matters more here than it would elsewhere. If the honest answer to “how do I use Ethereum without an intermediary” is always “buy a home server”, sovereignty stays a wealthy person’s hobby. Establishing how far down the cost curve it can be pushed, in front of an audience for whom that question is not academic, is the most useful thing this hub could do.
- CONFIRMED — Lodestar (Matthew Keil, engineering manager at ChainSafe). Joining the maintenance panel below, and the right person for it: he ran the process and knows the reasoning. Attending with the Lodestar team, self-funded.
- Running your own RPC — the implementations compared. Attendees try the different verified-RPC options on their own laptops, side by side. Nimbus (verified proxy) and Helios invited alongside those already in. The point is the capability, not any one project; attendees should leave knowing which fits their machine and their tolerance for rough edges.
- Who maintains the light client layer? — the panel this hub most wants to get right, and the line-up has genuine tension in it: a well-resourced team that moved its light client out of the monorepo and can say why (Matthew Keil, Lodestar), a company that concluded the architecture itself was the problem and rebuilt it stateless (Steffen Kux, Colibri), and an unfunded solo maintainer still doing it the hard way (Dirk Jäckel, Myotis). Nimbus and Helios invited. Not “light clients are good,” but: what does maintaining this actually cost, why does it keep getting deprioritised, and what would it take for the layer to have anyone accountable for it?
- Wallet developers — a working session on embedding a light client as a data access layer: lifecycle, battery, and what a wallet needs from the node it carries. Open invitation to any Android or iOS wallet team at Devcon.
- INTERESTED — Freedom Browser. Meinhard will be in Mumbai and the team are up for participating; sessions to be shaped together.
- NeoMist — sovereignty-preserving end-user tooling. Invited, awaiting reply.
- Full nodes on constrained hardware. Ethereum on ARM were invited and can’t come — they have no funding for travel and are maintaining the project in their spare time. That answer is itself part of this hub’s subject matter, and we would rather report it than quietly drop the topic. Invitations continue to others working on approachable self-hosting.
- Hands-off provisioning — a machine on a table with an empty disk, fetching its kernel and root filesystem from public peer-to-peer storage by hash, verifying every byte, and starting an Ethereum node, identically provisioned from a signed manifest with no manual configuration. This runs today, unattended, dozens of cycles a night. It does not make the hardware cheaper; it removes most of the organisations between an operator and a running node, and it makes attempting one disposable — wipe the disk and start again costs nothing, which in practice is a bigger barrier than the disk. Note for scheduling: roughly ten to thirteen minutes from power-on, so it is a demo left looping rather than gathered around.
- Connecting a wallet to a dapp without a cloud. WalletConnect is another intermediary almost nobody counts. There is early work replacing it with peer-to-peer signalling over untrusted relays, which would close the last obvious gap in a fully self-hosted path from user to application. Very early, and included here as a thread rather than a promise.
- SSV — distributed validator technology, on the argument that participation shouldn’t require one big reliable machine. Invited, awaiting reply. (Obol were invited and can’t make Mumbai this year.)
- The Portal gap — an open roundtable on what replaces Portal, and who maintains it
- India-based node operators and mobile developers — actively seeking, see Audience
Sample program (9:00–18:00, four days)
Two days are led by partner communities taking the floor end to end; two are ours. Every day keeps unstructured clinic time, because installs need support hours more than they need sessions.
| Day 1 — Access | Day 2 — Mobile & wallets | Day 3 — Sovereign Media | Day 4 — Open day | |
|---|---|---|---|---|
| 09:30 | Welcome, orientation | Welcome, orientation | Welcome, orientation | Doors open, networking |
| 10:00 | Talk: not your node, not your data | Working session: light clients inside wallets | What does it cost to publish without a platform? | Short slots, participant-led |
| 11:00 | Install clinic | Install clinic | Publish something, then remove the publisher | Open space |
| 13:00 | Lunch / open hours | Lunch / open hours | Open clinic / integrations | Lunch / open hours |
| 14:00 | Workshop: your wallet on your own node | Panel: who maintains the light client layer? | Live A/V chain: platform-free streaming in practice | Short slots + group discussion |
| 15:30 | Install clinic + hardware showcase | Install clinic + hardware showcase | Open clinic continues | Rump session |
| 16:00 | — | — | What breaks first? Pragmatic shortcut or unacceptable control point | — |
| 17:00 | Open roundtable | Open roundtable | From protocols to a usable stack | Closing + where to continue |
Day 3 — Sovereign Media Infrastructure. Proposed as a full-day takeover by the Swarm Foundation, who would handle its programming, guests and workshops. A draft programme is already written, and it is built on the hub’s own question one layer up: what does it cost to publish and stream without a platform? It opens with an inventory of what publishing actually depends on — an account, a CDN, a storage provider, their terms — and what removing each costs in bandwidth, persistence, latency, fees and effort. It then makes that experiential: attendees publish a file, then watch what survives when the publisher, the frontend and the service all disappear.
The centre of gravity is a live A/V chain shown end to end — camera, captioning, peer-to-peer delivery and storage, playback — with the centralised and decentralised delivery paths running side by side so the audience can see them differ. We intend to demonstrate this rather than promise it; it is real but not yet robust.
The session we are most pleased about is one nobody had to offer. This year a decentralised storage network set out to carry Devcon’s own livestream — twenty stages, four days, a real concurrency target. It designed the system, and then declined to run it.
Not because it failed a test. Because the only way to be confident in time would have been to scale up centralised gateways in front of the network to absorb the traffic — and that, in their words, “would recreate a centralized delivery layer in front of Swarm rather than solve the underlying problem.” They would rather spend the same effort on the architecture that doesn’t need the crutch: direct delivery through in-browser nodes, tested with real audiences over the coming months. Their judgement was that Devcon is not the place to find out live.
That is the hub’s entire argument, made at cost, by people who had every incentive to take the win and announce it. It is also an honest account of where this actually stands: the real test depends on people running nodes, most people don’t, and the in-browser client cannot yet carry that load at that scale. We would rather have that in a room than another architecture diagram.
It also sets the tone we want for the whole hub. This is not server-free, and saying otherwise would be false. Every server in the path is one you chose, pay directly and can replace — no account, no terms of service, nobody who can switch it off. Platform-free is the achievable claim, it is the more interesting one, and it is the one that survives a load test.
The day closes by turning that failure boundary into a research agenda — which parts of a decentralised media stack are solved, which are merely possible, and which remain bad user experience — and feeds into the final day’s discussion.
Day 4 — Open day. Deliberately not talks-at-people. A long open start, short participant-led slots interleaved with group discussion, and a rump session to close. The subject is the one the whole hub circles: how to undo the cloud, and where the balance sits between self-hosting on hardware you own and leaning on decentralised networks with real economic incentives. The format is borrowed from an existing series that has run this way since 2022 and works; we are in conversation about whether that community wants to take the day formally, and will say so here if they do. Placed last by design — it is when a conference is at its most useful and least scheduled.
Programming is intended as a collaborative effort across participating communities. The clinic blocks are the backbone on days one and two; the partner days set their own rhythm.
Alignment with Devcon’s focus
The hub is about Ethereum’s core properties as a lived experience rather than a slide. Censorship resistance and privacy are abstract until you see that your wallet’s balance query goes to a company that logs it — and then see the same query answered by software on your own machine, verified against a sync-committee signature. Every project featured is open source. Several are maintained by one or two unpaid people, which is itself part of the story worth telling honestly.
Audience
Who it’s for. Anyone who uses Ethereum and hasn’t thought about where their data comes from — deliberately the broadest possible audience, not only operators. Secondarily: existing node operators, wallet developers who could embed a light client, and the maintainers of that software.
No assumed expertise. The entry-level path is “bring your laptop, we’ll help you install something,” and it needs no prior knowledge. The advanced path is protocol-level and runs in the same room, which is the point.
Why this matters particularly in India. India is mobile-first at a scale that makes the usual desktop-centric assumptions about running infrastructure fail. If sovereignty requires a home server, it is a hobby for the wealthy. If it fits on the phone someone already owns and tolerates intermittent connectivity and metered data, it is available to hundreds of millions of people.
That is not yet where the software is, and we would rather say so here than discover it on stage. The mobile path runs through wallets embedding a light client rather than users installing a separate node app, and the constraints — battery, backgrounding, metered data — bite hardest exactly where the need is greatest. Devcon 8 India is the right room in which to work on that, in front of the developers and users best placed to say what it would take.
Connecting with India’s Ethereum and open-source community. The organising team is currently based outside India, and we regard that as a gap to close before the event, not a detail to manage. Concretely, we intend to:
- Recruit India-based co-hosts and bring them into the organising team, with the forum thread kept active as the recruiting channel
- Invite India-based node operators and mobile developers as speakers rather than only as attendees
If you organise in India and any of this resonates, this is the most useful reply this thread could get.
Team
Being straight about where this stands: the topic has a convenor, not yet a full organising team. That is what this post is for.
Committed:
- Chris Hobcroft — independent, convenor. TG @chrishobcroft. I’ll bring the framing and the argument, the introductions across light-client and node-software projects, the programme design, and hands-on time during the event. What I am not offering is to run a four-day hub single-handed — that takes people who have done it before, and doing it badly would serve the topic worse than not doing it.
- Dirk Jäckel — maintainer of Myotis, an independent sync-committee light client for desktop, CLI, Android and iOS. Has offered one or two workshops on getting a wallet reading Ethereum through a light client you run. Brings direct, current knowledge of what breaks when a light client meets real hardware and real networks, including the parts that don’t work yet — he is also the person who told us the standalone app is not yet fit for non-technical users, which is why this proposal is written the way it is. Not confirmed: he maintains the project unfunded and cannot currently afford to attend. If the hub is accepted, a ticket from the organiser allocation resolves it.
- Steffen Kux and the Colibri team (corpus-core) — co-hosting. Colibri Stateless is an MIT-licensed prover/verifier for cryptographically verified Ethereum RPC, portable C with bindings for mobile, browser and embedded targets. Running an integration workshop and a session on Pragmatic Adaptive Privacy — the observation that your reads leak who you are and what you intend before any transaction is broadcast — plus a seat on the maintenance panel. Headcount and floor hours being confirmed.
- Matthew Keil (ChainSafe, engineering manager on Lodestar) — joining the maintenance panel, and has agreed to give the honest account of why Lodestar moved its light client and prover out of the monorepo. Attending with the Lodestar team, self-funded.
- The Swarm Foundation — proposing to take one full day as Sovereign Media Infrastructure, handling its programming, guests and workshops. A draft programme is written. They have also half-committed people to the floor for that day — at least one developer for technical help and one person for hospitality — with confirmation expected once the team has settled who owns what. That is the first offer of floor time anyone has made, and it is the kind of commitment a hub actually runs on.
- The final day’s open session — convened by Chris, drawing on an unconference series he co-organises. Whether that community takes the day under its own name is still being discussed; the format runs either way.
- Jonathan Meyer — advising on continuity with previous editions and on what the format actually demands.
Sought — this is the ask:
- An operating lead or co-hosting organisation, ideally one that has run a hub or a community space before, to own the floor across the four days. Previous editions of this hub were run by organisations (EthStaker, Dappnode, Ethereum on ARM, SEED Org) rather than individuals, and that is the right model.
- India-based co-hosts, both for the operational reasons above and because a hub about sovereign access to Ethereum in India should be shaped by people who live with those constraints. Currently our most significant gap.
- Participating projects and maintainers — light clients, node tooling, privacy-preserving end-user software.
- Wallet developers, particularly Android and iOS, for the mobile working session.
If you are interested in any of these, reply here — that is what this thread is for.
Practical note: hub organisers receive an allocation of Devcon tickets to distribute among contributors. Co-hosts and participating maintainers would be covered from that allocation, so taking part need not mean paying your own way in.
Why convene it at all? Because nobody else has, none of the twenty-odd hub topics proposed so far covers this ground, the hub that came closest is not returning, and the underlying problem is getting worse rather than better. I would rather post an honest half-team and find the other half in public than let the topic go unrepresented at Devcon.
Neutrality. This is a prompt worth answering carefully, because the organising team includes the maintainer of one of the projects the hub would feature.
- Nobody is selling anything from this floor. Several participants are companies or foundations — Lodestar is ChainSafe, Colibri is corpus-core — and that is normal and welcome. We are not going to pretend a room of open-source maintainers is a room of unaffiliated volunteers. What we commit to is narrower and keepable: no organisation buys a place here, no session is sold, and no project is featured because of who funds it. The same applies to any organisation that joins the organising team.
- The hub is about a capability, not a product. The comparison sessions deliberately span independent implementations rather than showcasing one, and we are still inviting more. If an attendee leaves running someone else’s client, the hub has succeeded exactly as much.
- Structurally: any project featured must be open source, and any organiser with an affiliation to a featured project will say so plainly when presenting it. We would rather state affiliations out loud than pretend to a neutrality nobody has.
- We will not accept sponsorship for hub content or placement, and there is no paying to present.
Connection to the communities served. The node operator community through the previous Node Operators Hub and its organisers; the light client maintainer community through direct work with the implementations; the end-user community that this hub is ultimately for is the one we are least connected to and most want to reach, which is why the India recruitment above matters.
Languages. English only from the current organisers, with German available through one participant. This is a real limitation for an event in India and we are not going to dress it up: the hub’s language coverage depends entirely on the co-hosts we recruit between now and November, which is one of the main reasons we are recruiting them.
Proposed for RFP-13: Devcon 8 India Community Hubs — as an intention and a call for collaborators. If you have run a Community Hub before, if you organise in India, if you maintain a light client or node tooling, or if you have tried to run a node on a phone and given up: please reply. The topic needs a team more than it needs another draft.