The Self-Custody & OpSec Hub

Community Hubs
1

Please give a short description of the topic/cause for your Community Hub

The Self-Custody & OpSec Hub is a community-led space focused on helping Ethereum users, developers, DAO contributors, and teams use wallets and smart contracts more safely. Through practical, vendor-neutral education, the hub will cover secure key management, transaction verification, token approvals, phishing and wallet-drainer risks, multisig, smart accounts, recovery planning, privacy, and operational security across the Ethereum ecosystem

What will you offer to the Devcon attendees?

We will offer Devcon attendees a community-led, vendor-neutral space to learn and practise self-custody and operational security within the Ethereum ecosystem. Through hands-on workshops, demonstrations, discussions, and walk-in clinics, participants will learn how to safely use Ethereum wallets and dApps, verify transactions, manage token approvals, recognise phishing and wallet-drainer risks, use multisig and smart accounts, improve privacy, and plan for secure recovery. The hub will also provide a space for Ethereum users, developers, DAO contributors, and security practitioners to share experiences and learn from one another.

Rough Program Outline

The hub will run across all four days of Devcon as a practical learning space focused on self-custody and operational security within the Ethereum ecosystem.

Day 1 — Ethereum Self-Custody Foundations
Understanding externally owned accounts, smart contract wallets, seed phrases, private keys, hardware wallets, and the security trade-offs between different Ethereum account models. Attendees will build a personal threat model based on loss, theft, phishing, coercion, device compromise, and recovery needs.

Day 2 — Safe Ethereum Transactions and dApp Interaction
Hands-on sessions on reading transaction prompts, verifying addresses and contract interactions, understanding token approvals, avoiding blind signing, identifying malicious signatures, and reducing exposure to phishing sites, wallet drainers, and compromised front ends.

Day 3 — Smart Accounts, Multisig and Recovery
Practical workshops on Safe and other smart-account models, multisig operational procedures, signer separation, access control, social and institutional recovery, inheritance planning, and designing custody systems without a single point of failure.

Day 4 — Ethereum Privacy, Treasury Security and Incident Response
Sessions on wallet separation, address reuse, metadata leakage, RPC and interface privacy, operational security for DAOs and protocol teams, treasury transaction procedures, emergency response, approval revocation, and recovery after a suspected compromise.

List the people who will organise, oversee and be responsible for the Community Hub

  • Bala & Santosh - Ethereum Wallet Security

  • AD - Smart Accounts and Multisig

  • Palash - Privacy and OpSec

  • Paco - Program Coordinator

List the equipment or production needs (see what’s possible in the RFP)

  • LED TV with HDMI connection for demonstrations

  • Two whiteboards for threat-modelling exercises

  • One worktable for wallet and backup demonstrations

  • Power outlets and extension boards for test devices

2

Good proposal, and I think there’s a natural pairing here: flagging a neighbouring hub application ( Devcon 8 India: Sovereign Infrastructure Hub ) rather than a competing one.

I’m posting an intention this week for a “Sovereign Infrastructure” hub, reframed from the “Node Operators” hub of previous editions. Short version: self-custody answered “not your keys, not your coins.” We’re aimed at its quieter twin: “not your node, not your data.” Light clients, node tooling on hardware people already own, and wallets that verify chain data rather than trust a provider for it.

Which puts us squarely alongside two things already in your scope.

Transaction verification: an attendee who has learned to read a transaction carefully is still reading a screen populated by an RPC endpoint they don’t control. The provider chooses what they’re shown. Same for checking token approvals through a block explorer — the check is only as honest as whoever served the page. Drainers and phishing are the attacker in your face; a filtered or lying data source is the quiet one, and it defeats a well-trained user rather than a careless one.

I’d happily co-run a session on that if it appeals: “what your wallet shows you, and who told it that” — practical, and it lands better with an audience already thinking about verification than with one that isn’t. We’ll have light client maintainers in the room who can show the difference live.

Otherwise: we’d send anyone asking “how do I know what my wallet is telling me is true” to you, and you’d have somewhere to send people who want to fix the data path. Happy to coordinate scheduling so we’re not drawing on the same audience at the same hour.

Good luck with the proposal!