Let’s make this clear: Arch is not an L2. The label gets thrown around because people see our custom execution model, and assume a familiar category. But categories only help when they reflect how a system actually works. Calling Arch an L2 only creates confusion about what the architecture is doing. L2s require that users bridge or wrap their assets in order to access greater programmability. They maintain a separate state machine that only syncs back to Bitcoin, if ever, when transactions are posted back as post commitments or proofs on the base layer. Their transactions aren’t dependent at all on what is happening on the Bitcoin base layer, since their execution and validator lives entirely elsewhere. The ArchVM works differently. ・The same validators that approve the transactions within the ArchVM also have proportional key shares within Arch’s FROST + ROAST cryptography on Bitcoin. ・State changes are reflected accordingly, with a real-time mempool indexer and a DAG (Directed Acyclic Graph) that keeps track of the state transitions on arch and the corresponding asset transfers on Bitcoin to ensure they remain atomic. ・Its rollback/reapply method ensures state consistency, allowing Arch to give applications a pre-confirmation, allowing users to break away from the user experience issues that come with Bitcoin’s slow block times. That’s how Arch can bring financial logic to UTXO-based assets on Bitcoin, keeping actions taken within our suite of apps and aligning them at every stage with the base layer. Developers can coordinate activity, enforce rules, and build onchain applications without introducing wrapped assets, bridging models, or security assumptions that force users to move their assets elsewhere. It’s a model unlike anything Bitcoin has ever seen… and unlocking a form of Bitcoin programmability that has never been feasible until now.

See how Arch keeps execution within Bitcoin’s trust boundaries: