pull down to refresh
Fair question — two different things are bundled in that paper, and you're right to separate them.
The part that matters here is the technical one: the readiness standard and the chain-split math. That stands on its own, no law required.
"Legal" is the other half, for a different audience. It asks a narrow thing: if a handful of people push a consensus change that splits the chain and wipes out value — after ignoring every red flag to do it — does existing law already have something to say about that? Negligence, fiduciary duty, that kind of analysis. It's not "code is law," and it's not a call to go sue developers. It's mapping what existing law would probably already say if an activation went badly and people lost money — so the exposure is visible before anyone acts, not after.
I kept that half deliberately out of the scorecard. A readiness test shouldn't carry liability theory — it should just tell you whether a change is ready.
Ha — but the whole point is the gavel should never strike. That half's about staying out of court, not dragging Bitcoin into one.
No disagreement — that's where the paper starts, not something it missed. Tulip Trading already put developers in front of the England & Wales Court of Appeal, and the court said both claims — fiduciary duty and negligence — were strong enough to go to trial. The case itself later fell apart, but the door it opened is still open: courts will hear these claims against developers.
Which is exactly why process matters. If a court can look, the question becomes what it finds when it does. A change that clears a careful, documented process gives a negligence claim very little to grab. A change that rushes past red flags writes the plaintiff's brief for them. The framework is the difference between those two.
I'm curious why you call this a "legal framework." What does legal mean in this context?