State Without a Landlord: An Architecture Proposal for Peer-to-Peer Replication of Durable Workflow State

1.1 What durable execution actually is

• Code plus an append-only journal determines workflow state, and deterministic replay lets any party holding both reconstruct it and become executor.Source: §1.1 · p. 3

1.2 Where the journal lives today

• Provider-hosted journals make in-flight runs hard to migrate and bound workflow availability by the reachability of one journal store.Source: §1.2 · p. 3
• A host’s ledger remains authoritative for multi-party workflows, exposing them to censorship, tampering, outages, and rent extraction.Source: §1.2 · pp. 3–4

1.3 The agentic forcing function

• Agentic workflows are long-lived, adversarial-by-default, and dynamically composed, motivating jointly held, independently verifiable, executor-portable state.Source: §1.3 · p. 4

1.4 Related work

• The proposed composition couples authenticated logs with deterministic-replay execution and fenced writer succession, a combination the paper says its P2P predecessors do not provide.Source: §1.4 · p. 5

2.1 Hypercore, briefly

• Hypercore uses signed, Merkle-protected append-only logs that peers can sparsely replicate and verify, with built-in detection of equivocation.Source: §2.1 · p. 5

2.2 The mapping

• Signed Merkle-tree states add block authentication to journals that otherwise lack an integrity story.Source: §2.2 · p. 5
• Hypercore’s one-keypair-one-writer model matches durable execution’s rule that exactly one executor advances a run, enforcing the invariant cryptographically.Source: §2.2 · p. 6
• Deterministic workflow replay and Autobase deterministic apply share the contract that the same linearized inputs produce the same state view.Source: §2.2 · p. 6

2.3 Why BitTorrent and the Pear stack

• The design keeps small, live journals in a coordination plane and sends large, immutable payloads through a content-addressed distribution plane joined by hash references.Source: §2.3 · p. 6

• Signatures and Merkle proofs authenticate authorship and log integrity, but do not establish that recorded effects occurred.Source: §3 · p. 7
• Under T1 crash-only faults, the architecture aims to preserve state given surviving replicas, permit authorized peers to resume, and detect divergence at resumption seams.Source: §3 · p. 7
• Under T2, the design provides evidence such as fork proofs and breach claims rather than preventing misbehavior; recorded outcomes remain unverified without external attestation.Source: §3 · p. 7
• T3 guarantees exclude malicious indexer majorities, Sybil floods, global traffic analysis, and partition-controlling adversaries; hardening is future work.Source: §3 · pp. 7–8
• Liveness assumes mostly bounded message delays and clock skew, while timing violations should cause delay or recoverable duplication rather than state corruption; external effects rely on idempotency, safe re-query, or surfaced uncertainty.Source: §3 · p. 8

4 Architecture: The P2P World

• Workflow SDK’s World is the sanctioned seam: the same workflow code can use Local, hosted Vercel, Kubernetes, or the proposed P2P World.The P2P World resolves storage, queuing, and authentication to swarm primitives.Source: §4 · p. 8

4.2 Anatomy of a step

• A step’s small signed fact travels separately from its bulk payload on the distribution plane, and both propagate to peers with a stake.Source: §4.2 · p. 9

4.3 Data model

• The run identity is the genesis epoch core’s public key, while each epoch core key grants append authority for that epoch; branch identity does not determine succession.The design distinguishes stable epoch identity from branch identity when making safety decisions.Source: §4.3 · pp. 9–10

4.4 The World interface: a hypothesis, sketched

• The World-interface promise is a hypothesis: workflow source may remain unchanged, but the SDK, compiler output, and execution engine require extensions.The paper says atomic multi-entity updates and deployment affinity still need design work.Source: §4.4 · p. 12
• A sleeping workflow’s wake time becomes replicated journal state, so interested peers can observe it and initiate resumption instead of relying on a centralized scheduler.The authors describe the resulting wake-up arrangement as an incentive structure, not a guarantee.Source: §4.4 · p. 13

4.5 The notarized resume flow

• A peer resuming a crashed run fetches and verifies the journal and pinned code, obtains quorum-finalized succession, replays through transcript and intent checks, then appends in a fresh epoch.The authors say this flow needs no exclusive liveness-critical custodian, but does not establish the truth of recorded outcomes.Source: §4.5 · p. 14

• The journal is the source of truth, while the executor is only a cache; giving the running process authority the journal lacks would regress to landlordism.Source: §5 · p. 15
• Coordination facts travel on Hypercores and bulk bytes on BitTorrent v2, while keys enforce one writer per run and fork proofs expose violations.Source: §5 · p. 15
• Deterministic replay makes state a function of the log, while signatures and Merkle proofs authenticate the log rather than the truth of recorded effects.Source: §5 · p. 15
• Availability follows participant interest only as a heuristic: replication does not guarantee an online, reachable, credentialed executor when needed.The design uses wake paths, failover sets, and contracted custody to address this gap.Source: §5 · p. 15
• Runs pin code and engine versions by content address, human-readable names remain advisory, and payload secrets are encrypted before entering either replicated plane.Source: §5 · p. 15
• Centralized services may accelerate the open substrate without owning it, and trust needs must be met by checkable evidence or stateless, replaceable roles.Source: §5 · p. 15

Coordination and finality

• Autobase linearizes respondent cores through an eventually consistent causal DAG, so a majority-signed view checkpoint—not the ordering mechanism itself—establishes finality.Before finality, events may reorder; a Byzantine indexer majority can finalize a bad view, an out-of-scope T3 adversary.Source: §6 · pp. 15–16

Hooks

• A hook names authorized respondent keys and its Autobase identity; respondents sign their own contributions, and the deterministic outcome drives action only at finality.The same apply function derives the hook outcome for the executor and verifiers.Source: §6 · p. 16

Execution boundary

• If ACME’s standby is in the failover set, resuming the run executes the requesting organization’s step code on ACME infrastructure.The paper identifies step-ownership discipline as the proposed way to close this gap.Source: §6 · p. 16

Composed patterns

• Hooks support cross-organization approval chains and agent-to-agent contracting without hosting another party’s assent or requiring a trusted intermediary.The proposed patterns include staged commitments, encrypted escrowed outputs released on counterpart signatures, and evidence-backed disputes.Source: §6 · p. 16

Coordination channel

• Participants use the coordination Autobase to record challenges and co-signatures when a silent executor cannot record its own liveness failure.The channel also supports checkpoint co-signing and the eviction process.Source: §6 · p. 17

Design cost

• Autobase apply functions must be deterministic and tolerate reordering before checkpoints, a discipline the paper compares to existing orchestrator-code practice.The paper says this reuses rather than adds a mental model for durable-workflow authors.Source: §6 · p. 17

7.1 The transcript commitment and the next-intent record

• A transcript commitment pairs a fold-derived transcript hash with an engine-derived next-intent record, because the hash alone cannot test what the resumer is about to do.The next intent records the upcoming command’s kind, call site, call index, and argument hash.Source: §7 · p. 17, §7.1 · p. 17
• Before its first append, a resumer checks both the transcript fold and its replay-derived next intent, failing before action if either comparison diverges.The two gates catch transcript-decoding or schema divergence and an engine that would issue a different next call despite matching the transcript.Source: §7.1 · p. 17
• After the last commitment, each intent-bearing suffix entry is checked against replay; failover is allowed only when the suffix validates, while pinned-engine replay is a recovery attempt, not a guarantee.Ambient nondeterminism can still make the pinned build diverge, in which case the run halts with a bug report.Source: §7.1 · pp. 18–19
• Commitments and fork proofs provide signed evidence when an executor later acts inconsistently, but they establish neither honesty nor whether recorded outputs reflect reality.The checks establish shared transcript decoding and folding and agreement on the next call, not continuation agreement beyond that boundary.Source: §7.1 · pp. 17–19

7.2 Checkpoints and pruning: verification is not resumption

• A verification snapshot is sufficient to verify a suffix but not resume; a replay capsule preserves settled operations and replay inputs needed to reconstruct them.The snapshot is O(active work), while the capsule is O(settled operations); pruning bounds verification cost by active work, but failover cost remains proportional to the capsule.Source: §7.2 · p. 19
• Before signing a checkpoint, each honest co-signer must authenticate the prefix, independently derive the snapshot and capsule, replay through them, verify next intent, and sign a certificate binding the results.The obligation is normative; merely byte-verifying executor-supplied capsule bytes is insufficient.Source: §7.2 · pp. 19–20
• Only a finalized checkpoint licenses pruning; verification replicas retain snapshot plus suffix, failover replicas also retain the capsule, and archival replicas retain genesis history.The snapshot carries active state needed for resumption, and checkpoint certificates authenticate the material used to bootstrap fresh verification or failover peers.Source: §7.2 · p. 20

7.3 Checkpoints as receipts for the transcript, not the world

• A finalized checkpoint is a portable, quorum-attested receipt that a bundle folded over a history reaches a state and next intent, not a receipt that the recorded effects happened.Object hashes, quorum signatures, and chain linkage are independently verifiable; snapshot–capsule semantic consistency is quorum-attested and independently re-derivable only while history remains unpruned.Source: §7.3 · p. 21

8.1 Epoch cores: fencing by construction

• Each run is a chain of single-writer epoch cores, and a finalized epoch.open carrying a closure certificate fences the old writer at the finalized length.On a fork, closure selects the last common ancestor if no acknowledgment certificate covers later entries; otherwise it preserves the certified branch, leaving later entries as evidence and effects as possibly-fired orphans. The predecessor’s key can still sign, but those writes cannot extend the run.Source: §8.1 · pp. 21–23, §8 · p. 21

8.2 Closing an epoch: voluntary handoff and safety eviction

• Voluntary handoff closes the epoch cooperatively; a self-authenticating fork proof triggers safety eviction without a challenge period, subject to coordination finality.The successor rotates the KEK and performs the two-gate check; eviction does not determine whether recorded outcomes were true.Source: §8.2 · p. 24

8.3 Liveness eviction under partial synchrony

• A timeout certificate uses quorum-signed observations from independent indexers to authorize closure, but attests non-response rather than proving executor failure.Each indexer measures its own elapsed window from first observing the challenge; a healthy executor can still be falsely evicted under partition, so the design bounds rather than eliminates false eviction.Source: §8.3 · pp. 25, 27
• A successor readiness declaration establishes agreement with public values, not possession of history or ability to replay; an optional challenge can attest possession of a sampled plaintext range.Even the challenge does not prove future liveness; under T2 the default declaration filters nothing.Source: §8.3 · pp. 25–26

8.4 Durability certificates and the finality quorum

• Failover-survivable acknowledgments require valid certificates finalized in coordination; closure must preserve the highest certified prefix on its branch, while local and replica acknowledgments offer weaker protection.Certificate signer rules and thresholds make conflicting certified branches impossible under the stated signer model; survivable acknowledgment costs a coordination-finality round-trip, and effect-bearing steps default to it.Source: §8.4 · pp. 28–29
• Indexer reconfiguration proceeds jointly: the currently valid configuration authorizes a joint transition, whose jointly certified barrier activates the new configuration.Joint certificates meet the relevant thresholds in both sets; after the barrier, certificates use the new configuration alone.Source: §8.4 · pp. 28–29

8.5 The lifecycle invariants

• The lifecycle invariants require unique succession and history, preservation of survivable acknowledgments, and fencing before any external effect is initiated.The reducer enforces succession and history through finalized closures; effect ordering requires the executor’s epoch to be the finalized head and the intent durable under its declared acknowledgment policy.Source: §8.5 · p. 29

8.6 The half-fired step: external effects at the seam

• At the epoch seam, at-least-once execution can repeat an effect if the executor crashes after firing it but before step.end is durable.The proposed discipline is intent, durability, keyed firing, then outcome, using deterministic idempotency to manage retries.Source: §8.6 · p. 30
• A successor finding step.begin without step.end can retry with the same idempotency key, letting an idempotent or deduplicating target return the original outcome [P].The key derives from (runId, seq, attempt), not executor-local state.Source: §8.6 · p. 30
• Without target idempotency or safe re-query, the manifest requires a reconciler before retry or at-most-once handling that surfaces a seam crash as step.error.Capability gateways use a bounded recent-key dedupe window that also serves as their fencing check.Source: §8.6 · p. 30
• Exactly-once external effects do not exist in any World [E]; the architecture instead makes their uncertainty window replicated and inspectable.This claim is conditioned on the explicit external-effect assumptions of §3.Source: §8.6 · p. 30

9.1 Secrets and confidential state

• Ciphertext-only journals use per-subject DEKs and epoch KEKs, while explicit delegation chains or a capability gateway carry effect authority.The gateway remains a confidentiality and availability dependency for legacy credentials; the failover set is also the key-holding set.Source: §9.1 · pp. 30–31

9.2 Availability: tiers, proofs, and honest death; 9.3 Erasure versus append-only

• Availability ranges from mutual-stake replication to contracted custody and best-effort survival, while crypto-shredding cannot revoke plaintext or keys already copied.The contracted tier’s possession proof depends on timing assumptions; redacted replay after shredding is sound only if the plaintext never affected recorded control flow.Source: §9.2 · pp. 31–32, §9.3 · p. 32

9.4 Timers without a scheduler

• Wake services publish horizon notifications rather than replicating journals or acquiring execution authority, so missed wakes delay runs without corrupting them.Unanswered pings trigger the liveness challenge under the stated synchrony assumptions, not a fault proof.Source: §9.4 · p. 32

9.5 Determinism across heterogeneous peers

• Cross-engine agreement is managed through profiling, boundary checks, and pinned builds, not established as a theorem.Divergence between boundaries may escape detection until the next commitment, and a conformance corpus and differential harness remain open work.Source: §9.5 · pp. 32–33

9.6 Latency and the durability dial

• The per-run durability dial ranges from local append to replica acknowledgments or a quorum-backed AckCertificate, with effect-bearing steps defaulting to survivable.Survivable protection costs a coordination-finality round-trip; the design trades colocated-database latency for joint custody, verifiability, and executor portability.Source: §9.6 · p. 33

9.7 The unit of swarming; 9.8 The wire: possession-gated admission, not ACLs

• Swarm admission is based on possession of nested secrets rather than an admission server, while per-application swarms limit discovery overhead.A global passive observer can still correlate traffic timing and volume; cover traffic and mixnet integration are left open.Source: §9.7 · p. 33, §9.8 · pp. 34–35

9.9 Scale: pull is backpressure, cores are cheap, fan-out is fission

• Pull-based replication isolates slow readers, and child-run cores split hot parallel workloads while preserving composable checkpoint verification.The proposal also shards horizon indexes into time-bucketed cores so wake services need not replicate every sleeping run’s full schedule.Source: §9.9 · p. 35

9.10 Foreign code on local machines: the isolation gap

• Effectful steps should run only on their owning principal’s infrastructure, while the shared orchestrator remains the sandboxable portion of the workflow.This proposed change adds per-step ownership and failover sets and a finality round-trip for foreign steps; its design and validation remain future work.Source: §9.10 · pp. 35–36

10.1 Durable streams are native, not a feature

• A streaming step writes chunks to a dedicated stream core and records its key in the journal, while clients resume replication from any peer holding the core.A reconnecting client is a sparse replica whose received chunks are Merkle-verified.Source: §10.1 · p. 37

10.2 Observability without privileges

• Inspectors become read-only peers, and recomputable indexers can provide organization-wide views without privileged vendor access.Peers can inspect with relevant capability keys and verify rendered facts through inclusion proofs.Source: §10.2 · p. 37

10.3 Cancellation and manifest amendments

• Cancellation and policy changes become signed coordination events, while amendments form a co-signed manifest chain evaluated against the version in force at each entry’s HLC.Source: §10.3 · p. 37

10.4 Migration: the Mirror World

• Migration proceeds from hosted-authoritative dual writes to per-run or per-application authority changes, making replication the common operation for shifting custody.Mirroring incurs latency, storage and egress costs, key-distribution work, and possible divergence requiring reconciliation; Phase 1 declares the hosted store authoritative.Source: §10.4 · pp. 37–38

11 Outlook: One Trust Fabric from Code to Execution

• Execution receipts can be verified by counterparties, but finding them and trusting their context remain unresolved without a shared attestation log.Source: §11 · p. 38
• The proposed Merkle-structured log would notarize execution receipts, custody records, and code-publication claims that bind provenance to pinned bundle infohashes.Source: §11 · p. 38
• The transparency-log system remains future work and is not required by the paper’s architecture, though the design is intended to compose with it.Source: §11 · p. 39

12 Future Work: An Evidence-Native Custody Market

• The market is future work whose validation depends on coordination finality and custody timing assumptions, but the core mutual-stake and best-effort availability tiers stand independently.Source: §12 · p. 39

12.1 The contract and the loop

• Custody contracts are written against content identity, size, and term, with evidence objects carrying the basis for payment rather than promise or advance reputation.The loop uses quorum-observed non-response at coordination finality for breach claims, and custodians need only prove possession of ciphertext.Source: §12 · p. 39, §12.1 · p. 40, Figure 8 · p. 40

12.2 The custody proof and its stated assumption; 12.3 Settlement mechanics and reputation

• The custody proof’s nonce binding and response SLO make outsourcing a timing race, but the assumption weakens against a custodian colocated with another replica.Per-epoch invoicing is the default settlement; challenge-based probabilistic micropayments can reduce settlement events, and portable receipts and breach records support queryable reputation.Source: §12.2 · p. 40, §12.3 · p. 41

Research agenda

• The agenda identifies the first three experiments as the ones on which the design stands or falls.The listed agenda orders work by its bearing on the architecture’s central claims.Source: §13 · p. 41

Minimal prototype

• A minimal prototype tests cross-machine and cross-engine resumption through two gates, including whether the intent gate stops a deliberately skewed engine.The scope includes an epoch chain, pinned bundles, deterministic replay, transcript commitments, a cold standby, and a specified handoff path.Source: §13 · p. 41

Checkpoint composition

• Checkpoint composition requires deterministic mapping between global stream positions and epoch-local core lengths, plus configuration-bound thresholds for pruning authorization.During a joint window, both constituent sets must meet the checkpoint threshold; after the authorized barrier, only the new set applies.Source: §13 · pp. 41–42

Fencing validation

• Fencing validation must test closure races, cross-branch mismatches, partitioned indexers, and capsule-based resume with a pending operation against real Hypercore semantics.The deliverable is an observed safety argument or a documented failure that revises the design.Source: §13 · p. 42

Coordination finality measurement

• Autobase measurements must characterize checkpoint finality, reordering, paused majorities, and the latency finality gates add to approvals and epoch transitions.The measurements determine whether the assumed coordination costs are acceptable.Source: §13 · p. 42

World conformance

• The “code unchanged, only a new World” claim remains a hypothesis until the exact versioned contract passes the upstream conformance suite.Source: §13 · p. 42

Systems measurements

• Systems evaluation covers durability latency, resume and capsule costs, partition behavior, dormant-run overhead, NAT traversal, and payload-distribution crossover.The proposed measurements include false-eviction rates under policy changes and capsule size relative to journal size across workloads.Source: §13 · p. 42

Open problems

• Open problems include step ownership, effect-truth attestation, Byzantine coordination, custody markets, erasure-aware control flow, conformance tooling, and network-observer privacy.These are described as unsettled design problems, not merely unvalidated mechanisms.Source: §13 · p. 42

Conclusion

• Durable workflow journals are promising objects for authenticated, multi-party replication, potentially enabling portable state and independently verifiable custody without source-code changes.Source: §14 · p. 42
• The proposed machinery includes a threat model separating log integrity from effect truth, next-intent transcript commitments, epoch-core fencing, explicit finality gates, pruning rules, and surfaced at-least-once uncertainty.Source: §14 · pp. 42–43
• Exclusive storage custody is not necessary in the proposed design, but scheduling, fencing, credentials, availability, and finality still require evidence or fungible roles.The paper identifies experiments to test whether those mechanisms can carry the load.Source: §14 · p. 43

Appendix scope

• The appendix specifies transcript commitment encoding precisely enough for independent implementations to produce identical hashes or fail closed.Source: A The Transcript Encoding:… · p. 43
• The specification underpins attestations, checkpoints, and receipts in §7, eviction defenses in §8, and custody receipts over checkpointed content in §12.Source: A The Transcript Encoding:… · p. 43
• Its stated scope is the transcript.commit commitment, whose precise encoding supports the cited mechanisms.Source: A The Transcript Encoding:… · p. 43

A.1 Goal and non-goals

• The transcript is a commitment computable from the verified log, not a snapshot or a resumption medium; the journal remains the resumption medium.The design excludes information reconstructible from the journal to avoid representational disagreements.Source: §A.1 · p. 43

A.2 The transcript state

• TranscriptState records sequence, settled-step commitment, pending work, open obligations, epoch, entropy cursor, and terminal result, while settled outcomes fold into an O(active work) step-chain accumulator.The accumulator preserves commitments to settled history without retaining an unbounded list, and checkpoint folding can resume from the checkpointed state.Source: §A.2 · p. 44, §A.2.1 · p. 44

A.3 The fold: a total, fail-closed transition table

• The fold skips transcript.commit and checkpoint metadata, but unknown entry types or field shapes halt resumption rather than being ignored.The totality rule requires a worldContract version bump for extensions.Source: §A.3 · p. 44

A.4 Commitments by reference

• The transcript commits to independently authenticated structures by their roots or hashes, including hook views, child checkpoints, manifests, and payloads.This makes it a compact commitment of commitments rather than a re-encoding of those structures.Source: §A.4 · p. 46

A.5 The canonical encoding profile

• A closed canonical encoding profile fixes field representation and ordering, while versioned domain-separated BLAKE3 contexts construct transcript and related hashes.The profile is intended to make encoding injective on TranscriptState up to value equality.Source: §A.5 · p. 46, §A.6 · p. 46

A.6 Hash construction and why excluding frames is sound

• Excluding suspended frames depends on a determinism profile that orders concurrent results by journal sequence and closes or tapes ambient nondeterminism.A missed leak is intended to produce detectable divergence at a verification seam; engine pinning is a recovery attempt, not a guarantee.Source: §A.6 · pp. 46–47

A.7 The next-intent record: where the engine enters

• At suspension, the engine supplies a next-intent record checked against replay; a replay capsule supplies settled values alongside snapshot state and suffix for equivalent resumption.The capsule does not itself reproduce TranscriptState, and its payload references do not restore erased data.Source: §A.7 · p. 48, §A.8 · pp. 48–49

A.9 The entropy and time tape

• The entropy tape records nondeterministic values for replay, worldContract bridges make version changes co-verifiable, and conformance is tested against published success and adversarial-error vectors.A differential harness compares engines, while heterogeneous-engine handoffs provide production conformance checks.Source: §A.9 · p. 49, §A.10 · p. 49, §A.11 · p. 50