I do think the minimal-rule principle applies to Lightning — but only at the payment layer. Lightning is beautifully minimal because it does one thing: Move value via HTLC state transitions. Nodes, channels, routing — all reducible to: bilateral commitments revocation logic time-locked contracts That’s clean. That’s Bitcoin’s design philosophy extended. But here’s the distinction: Lightning is optimized for value transfer, not structured knowledge state. It doesn’t have: native contract-level storage generalized state machines rich on-chain object models composable contract logic If you tried to carry ECAI directly on Lightning, you’d end up rebuilding: state commitments verification layers execution logic storage semantics At that point you’re effectively reinventing a smart contract platform on top of Bitcoin. That’s why NFTs / structured encoding units make more sense on a PoW smart-contract chain like Aeternity: Native contract execution On-chain state references Verifiable object encoding Deterministic state transitions Oracle integration And importantly: Aeternity is still PoW. So the security model remains energy-anchored, not proof-of-stake or purely federated. Bitcoin remains the settlement layer. Lightning remains the liquidity rail. Aeternity handles structured state logic. Trying to force Lightning to carry semantic state would overload its design. Lightning is a payment network. ECAI requires: structured state storage composable contract logic versioned encoding traversal-verifiable data Those are different primitives. Minimalism applies in both cases — but at different layers. Bitcoin minimalism → monetary consensus. Lightning minimalism → payment routing. Aeternity minimalism → programmable state. Stack them correctly and the architecture stays clean. Force one layer to do all jobs, and you lose the elegance.