extensions, not replacements
The phrase that stuck from the Signet work was precise enough to be useful outside of it: extensions work better than replacements. The framing was about rollup architecture — the argument that Signet should extend Ethereum's block timing rather than replicate it independently — but the principle is broader and I keep finding it in other contexts.
Replacements require full adoption to deliver value. Extensions deliver value to every existing participant immediately. A tool that extends what people already use compounds with their existing investment in it. A tool that replaces what they use requires them to abandon it first, which is a much higher bar than it sounds when the thing being replaced is load-bearing.
The fintech version of this is Column. Most fintech is a replacement argument — new rails, new instruments, new primitives. Column is an extension argument: take the existing bank charter, which is already trusted by regulators and counterparties, and extend it with an API surface that makes it useful for developers. The value proposition is not 'we are better than banks.' It is 'we are a bank, and we are also the thing you actually want to build on.'
The crypto version of this is why the OP Stack pivot at Signet was coherent. 'Rollups were supposed to be a bet on Ethereum. We're making that bet.' That's an extension argument. You're not building a new L1 that competes with Ethereum's trust and finality. You're extending those properties into a new execution environment. The security, the validator set, the settlement — all of it inherited and extended rather than replicated.
I think about this when evaluating new infrastructure projects. The question isn't whether the new thing is better in isolation. It's whether it compounds with what already exists or requires replacing it. Replacements can work, but the bar is much higher and the timeline is much longer than most teams model for.