Hey Arthur, the CellScript / CellFabric split reads much clearer now! I think that part is mostly resolved: CellFabric makes sense as a UTXO-generation / inter-protocol coordination surface, not as a new ledger or transaction-DAG L2.
One concrete positive is that the current CellScript code already supports some of the single-protocol side you describe. receipt is a first-class cell type, claim only accepts receipt values, and read_ref lowers through Source::CellDep. That already supports “compose around existing cells” without implying a new settlement layer.
This is the one part where I still want to hear your view. The repo already exposes per-action touches_shared, read_refs, verifier_obligations, and transaction_runtime_input_requirements, and cellc scheduler-plan can derive simple shared-state conflicts from that metadata. But that still reads to me as intra-module compiler metadata, not yet a standard inter-protocol conflict-key or verifier surface.
The same semantics_preserving_claim says stateful lowering is represented in metadata and asm but is “not yet a proved schema decoder/verifier”. Structured WitnessArgs / Source views are still planned for v0.14, and the ProofPlan audit surface with trigger/scope/coverage and builder_assumption reporting is still planned for v0.15.
So my current read is: the split is right, the single-protocol foundation is already in the code, and the cross-protocol conflict-key / verifier surface still sits on the roadmap.
I was wondering: How do you see token standards and the wider inter-protocol interface evolving from here? The small Token / MintAuthority base already in the repo makes that especially interesting to me.
Phroi