Using git's workflow as an analogy for [delta] 's @deltadotnetwork >>> >>> >>> git commit -m "delta workflow" >>> >>> Let’s assume there’s a project whose master branch [account state] lives in a monorepo [single state]. A developer [server as domain operator] writes code [operator orders and executes user transactions], resulting in code changes [state diffs]. Alternatively, some devs like to work in groups [decentralized network as a domain operator] and come up with code changes after they have reached consensus. Subsequently, they create a branch and push these code changes to it [submit SDL; SDL is included in the state as a result]. Once they are ready [have produced a proof for the submitted SDL], they open a PR [submit SDL proof]. The code reviewers [validators] review the changes [verify the submitted proof]. If approved, the code changes receive the required number of approvals per branch protection rules [at least quorum-many validators attest to the proof’s validity]. As a result, the code changes are merged into the codebase [diffs included in the SDL are applied to the account state]. Moreover, let’s assume that, for this repo, merge conflicts must be prevented [double-spending risk must be eliminated]. Thus, each file [vaults registered under the same domain] can only be modified by a single dev [can only spend through their associated domain]. This is [delta].