Hey everyone,
I’d like to start a discussion around architectural patterns for building decentralized protocols that are both secure and upgradeable. It feels like most teams eventually run into this tension: systems need to evolve, but every upgrade path introduces new risks and complexity.
We’ve seen a range of approaches in the wild, from proxy-based contracts to more modular designs where core logic is intentionally kept minimal and extended via replaceable components. Each pattern seems to trade off different things, whether it’s auditability, governance overhead, or the blast radius of a mistake. What looks clean in early development can become fragile once real value and adversarial pressure enter the system.
I’m particularly interested in how teams decide where to draw boundaries between “immutable” and “upgradeable” parts of a protocol. How much logic should live in a core that never changes, and how much flexibility should be pushed to the edges? There’s also the human side of this: upgrade mechanisms often rely on governance, multisigs, or emergency controls, which themselves become attack or failure points.
If anyone has experience designing or maintaining upgradeable protocols, it would be great to hear what patterns held up over time. What assumptions turned out to be wrong, and what would you do differently if you were starting from scratch today?