Technical Report · POLARIS-TR-2026-001 · v0.5 · April 2026

Polaris Protocol: Commit-Gated Execution and Causal Integrity

Daniel Lindberg

Independent Researcher

daniel@polaris-protocol.org

April 2026

Abstract

Systems execute from state. That state may be stale, invalid, or later rejected. In no widely deployed architecture is execution authority structurally derived from committed canonical state. Logs record what happened. Audit reconstructs it. Replay reproduces it. None of these establish that execution was structurally authorized to occur from the state it acted upon.

Polaris introduces commit-gated execution: side effects are permitted only as consequences of transitions that have been validated and committed — and that fact is independently verifiable.

Execution authority is derived from committed canonical state — not inferred from logs, not reconstructed after the fact. The architecture enforces this structurally — not through policy, not through trust, not through audit. The result: execution authority is verifiable by anyone, trusted by none.

Keywords: commit-gated execution, canonical state, execution gating, deterministic validation, causal integrity, distributed systems

Polaris is a constraint layer on execution authority. It constrains when execution is valid — not how systems are built, governed, or operated.

It does not provide consensus, storage, scheduling, or fairness. It does not replace existing distributed system primitives. It composes with them.

One constraint. One guarantee:

Execution authority must be derived from committed canonical state — not inferred, not reconstructed, not assumed.

1 Introduction

Systems execute from state.

That state may be stale, invalidated by a concurrent transition, or superseded before execution began. The system does not know. Execution occurs regardless.

This is not an edge case. It is the default condition of every widely deployed distributed system.

Logs record what happened. Audit reconstructs the sequence. Replay reproduces the effects. These describe execution — they do not establish authority to execute.

This is not a failure of implementation. It is an absence of definition. No existing architecture specifies execution authority as a structural property of committed canonical state. The property has never been defined, enforced, or independently verifiable.

Polaris closes this gap.

It introduces commit-gated execution: side effects are permitted only as consequences of transitions that have been validated and committed. Execution authority is derived from the identity of committed canonical state — independently verifiable without runtime trust.

This is distinct from blockchain. Blockchain achieves consensus among mutually distrusting parties — that is its contribution. Polaris assumes a trusted commit authority and contributes something blockchain does not have: a structural execution gate that prevents side effects from occurring without a committed transition as precondition. A blockchain records what happened. Polaris prevents unauthorized execution from happening in the first place.

C1Commit-Gated Execution Principle: the what.
C2Commit-Gated Causal Architecture: the how.
C3Deterministic Replay Verification: the proof.
C4Commit-Gated Causal Systems: the class.

Together, these establish commit-gated execution as a structural method for enforcing causal integrity in distributed and autonomous systems.

This work does not address consensus, scheduling, governance, or policy semantics. It addresses one question: was execution structurally authorized to occur from the state it acted upon.

2 System Model

The system enforces one constraint: execution authority must be derived from committed canonical state.

To enforce this, components operate in strict sequence. Clients propose transitions. A validation pipeline evaluates each transition deterministically before it can proceed. A commit authority — and only the commit authority — advances canonical state atomically, appending to an immutable record. An execution gate permits side effects only when an execution request references the current canonical state.

Formal Definitions

Definition 1 (Canonical State)

A state Sn ∈ H is canonical at pointer value n. Every element of H is canonical. No state outside H is canonical. A proposed state is a candidate state carried by a transition awaiting evaluation; it becomes canonical only upon successful commit, at which point it is appended to H.

The system maintains a history: a totally ordered sequence of states

H = (S₀, S₁, S₂, …)

where S₀ is the genesis state and each Si is identified by its index i ∈ ℕ, called the pointer.

We write Si for the state at index i ∈ ℕ. The pointer n ∈ ℕ denotes the index of the most recently committed state; the current canonical state is Sn. The pointer n is monotonically non-decreasing. Only the commit authority may advance n.

Four properties hold by construction:

P1 (Single Authority). Transitions from Sn to Sn+1 are controlled by exactly one commit authority. No other component may advance the pointer.
P2 (Uniqueness). For any pointer value i, at most one state Si exists. The sequence is linear, not branching.
P3 (Immutability). Once committed, Si is immutable. Retroactive modification is excluded.
P4 (Monotonicity). The pointer n is monotonically non-decreasing. There are no rollbacks.

These properties are not enforced by policy. They are enforced by the structure of the commit authority and the append-only history.

Transitions are not submitted as raw state changes. They are structured descriptors — called Proposed State Transition Objects (PSTOs) — that carry both the candidate change and a reference to the state they act upon.

The commit authority evaluates each PSTO through a deterministic function V:

V(Sn, PSTO) → {PASS, FAIL}

A PSTO is valid only if it references the current pointer value n. A PSTO referencing any other value is structurally rejected — not by policy, but because the pointer has moved.

If V = PASS, the commit authority advances the pointer atomically: n becomes n + 1, and Sn+1 is appended to the history. If multiple PSTOs are valid concurrently, at most one advances the pointer. The others are rejected — consistent with I1. Selection is determined by the commit authority’s ordering mechanism. Polaris guarantees that whatever wins is valid. It does not prescribe which valid transition is chosen.

Execution is permitted only from the current canonical state Sn. A request referencing any Si where i ≠ n is rejected at the execution gate.

The properties above define what the system must enforce. Section 3 describes one architecture that enforces them. Other architectures are possible provided I1–I3 continue to hold.

Identity is not asserted — it is derived.

Definition 2 (Canonical State Identity)

The canonical state identity is the cryptographic identifier referenced by the canonical state pointer and derived deterministically from the committed state transition record. Formally:

id(Sn) = H(recordn)

where H is a collision-resistant hash function and recordn is the canonical encoding of the committed transition producing Sn.

Definition 3 (Replay Determinism)

Given the committed sequence H = (S₀, S₁, …, Sn), any conformant verifier applying the same validation function V from the same genesis state S₀ reconstructs identical canonical state. Replay determinism holds by A2: V is a pure function of its inputs.

We define three operations used in Section 4:

2.1 Requirements

R1 (Single Authority). Exactly one canonical state Sn is authoritative at any time.
R2 (Mandatory Validation). No transition without V(T) = PASS.
R3 (Exclusive Commit). One logical commit authority advances state, atomically.
R4 (Execution Causality). Side effects only when request references canonical pointer.
R5 (Deterministic Replay). Independent verifiers reconstruct identical state sequences.

Each requirement is necessary. None is sufficient alone. A system satisfying R1–R4 without R5 cannot be independently verified. A system satisfying R1–R3 without R4 permits execution from uncommitted state. The architecture is designed to satisfy all five simultaneously — within its defined model.

2.2 Assumptions

A1 (Store integrity). The append-only history is reliable and not subject to silent corruption. Records, once written, are preserved exactly as committed.
A2 (Deterministic validation). Validation produces the same result whenever it is given the same inputs. Specifically, for a given prior state and a proposed transition, validation always returns the same outcome. Validation does not depend on wall-clock time, external network state, or any input outside the append-only history. This property makes independent replay verification possible.
A3 (Authenticated commit authority). Only authenticated requests are permitted to advance the canonical state pointer. Unauthenticated or unverifiable requests are rejected before any state change occurs.

2.3 Threat Model

We model adversaries that can propose inputs, corrupt components, and attempt to induce invalid state transitions or unauthorized execution.

T1 (Byzantine proposers). An adversary submits invalid or malformed transitions, including incorrect pointer references or replayed inputs. [Addressed by I2: only validated transitions may commit]
T2 (Compromised validators). An adversary causes one or more validation components to return incorrect results. [Addressed by I2: commit requires recomputation of validation conditions]
T3 (Pointer forgery). An adversary constructs a transition that references a non-current or fabricated state. [Addressed by I1: only a single canonical successor may follow a state]
T4 (Concurrent fork attempt). Multiple adversaries submit valid transitions concurrently, each attempting to advance the same prior state. [Addressed by I1: atomic pointer advancement enforces a single successor]
T5 (Execution bypass). An adversary attempts to produce externally observable effects without a corresponding committed transition. [Addressed by I3: execution is permitted only for committed transitions]

We assume cryptographic primitives remain secure and the append-only history preserves integrity. Byzantine failure of the commit authority itself is out of scope and treated as a deployment concern (Section 9).

3 Architecture

The architecture enforces the invariants I1–I3 through five components with strictly separated roles and a constrained execution flow. Each component is bound to exactly one role. No component may hold more than one role — this structurally excludes privilege escalation.

Proposer. Submits candidate transitions. It has no authority to validate or commit.
Validation Pipeline. Evaluates each proposed transition deterministically. Gates are pure functions of the current state and the proposed transition, returning PASS or FAIL. No gate depends on wall-clock time, external network state, or inputs outside the canonical history. This enables replay verification.
Commit Authority. The sole component permitted to advance the pointer. It accepts only transitions that satisfy validation conditions, which it verifies independently before advancing the pointer. Pointer advancement is atomic via compare-and-swap and defines the system’s linearization point.
Canonical State Store. An append-only record of committed transitions, forming a single linear history. Any modification invalidates all subsequent records.
Execution Gate. Permits side effects only when the execution request references the current pointer value. All other requests are rejected. This enforces I3 at the system boundary.

A transition progresses through the system as follows:

  1. A proposer submits a transition referencing the current state.
  2. The validation pipeline evaluates it deterministically.
  3. If valid, the commit authority attempts to advance the pointer.
  4. On success, the transition is recorded in the append-only store.
  5. Execution may be requested only against the committed state — not before, and not against any prior state.

Implementation details — encoding, transport, consensus, and storage — are deployment concerns and not prescribed by the protocol. The normative specification is available at: https://github.com/polaris-specs/polaris-protocol

For implementers: QUICKSTART.md defines five conformance requirements. A system satisfying them is a conformant Polaris implementation.

4 Formal Properties

The following invariants hold by construction under the model and assumptions of Section 2.

Figure 2: Execution Gate Enforcement
Figure 1. Execution Gate enforcement. Every execution request carries a state pointer that is checked against the current canonical state pointer. Mismatch results in structural rejection with no side effect. This mechanism enforces invariant I3 — execution causality binding — at the gate boundary.

4.1 I1: Canonical Progression Uniqueness

Invariant 1

For any committed state Sn, successor(Sn) is a partial function: it is defined for at most one Sn+1.

∀ Sn : successor(Sn), if defined, is unique

Without I1, concurrent transitions could produce divergent histories. Atomic pointer advancement via compare-and-swap enforces this — not by coordination, but by construction.

4.2 I2: Mandatory Validation Precondition

Invariant 2

No transition becomes committed without satisfying the validation conditions for the current state.

∀ T : commit(T) ⇒ V(T) = PASS

Without I2, an invalid transition could advance the pointer. The commit authority enforces this independently — not by trusting the validation pipeline, but by verifying the conditions before advancing the pointer.

4.3 I3: Execution Causality Binding

Invariant 3

Execution is permitted only when the request references the current pointer value.

execute(E, Sr) ⇒ Sr = Scurrent

Without I3, execution could occur from stale or superseded state. The execution gate enforces this at the system boundary — not by policy, but by structural rejection.

4.4 Commit-Execution Asymmetry

Commit and execution are distinct events with asymmetric properties.

Commit is atomic and verifiable: given a validated transition and the current canonical state, the commit authority advances the pointer atomically via compare-and-swap, appends the record, and produces a result that any verifier can reconstruct from the history alone.

Execution is not constrained by the protocol in the same way. Polaris does not bound what execution does, when it occurs relative to commit, or whether it is deterministic. A committed transition may be executed immediately, deferred indefinitely, or never executed at all. Timing and triggering of execution are the implementing system’s responsibility.

What Polaris constrains is the precondition: execution may not begin without a corresponding committed transition. The gate enforces this structurally. What happens after the gate permits execution is outside the protocol.

The protocol guarantees structural authorization, not execution correctness. Every executed side effect is traceable to a committed transition. What that transition produces is outside the protocol boundary.

4.5 Corollary: Cross-Implementation Causal Equivalence

Corollary 1

From I1–I3 it follows that two independent implementations conforming to the Polaris specification, processing the same sequence of proposed transitions from the same genesis state, will permit exactly the same set of execution effects — independently, without communication, and without trust in either implementation’s internal behavior.

The conjunction of I1, I2, and I3 means that canonical state identity is not an internal implementation detail. It is an externally verifiable fact, reconstructible by any conformant verifier from the append-only record alone — without access to implementation-specific state or execution traces.

This is not a description of what happened, but a structural guarantee that any permitted execution must follow from a committed and validated state transition.

Verifiable by anyone. Trusted by none.

5 Deterministic Replay and Verification

Independent verification is possible because I1–I3 constrain all permitted state transitions and A2 guarantees that validation is deterministic.

A verifier needs only the append-only history and the validation function V as defined by the specification. Given these, the verifier can reconstruct the canonical state sequence from genesis without access to the original system, without communication with any participant, and without trust in any component’s internal behavior.

The verification procedure follows directly from the architecture:

  1. Load the genesis state S₀.
  2. For each committed record in sequence, confirm that the transition satisfies V against the prior state.
  3. Confirm that the sequence of records forms a valid progression from each prior state.
  4. Confirm that the final pointer matches the expected value.

Any deviation fails verification.

This is possible because of A2: validation is deterministic. Given identical inputs, V always returns the same result. A verifier evaluating a committed record will reach the same conclusion as the original commit authority — not because they share state, but because the function is identical.

This establishes that any conformant verifier will reconstruct the same canonical state sequence from the same history.

Complexity. Verification is O(n) in the number of committed transitions. Each step depends on the prior state, forming a linear verification path.

What verification establishes. A passing verification does not confirm that the system behaved correctly in all respects. It confirms one thing: every committed transition was valid at the time of commit, and execution authority was structurally derived from committed canonical state.

This is the scope of the guarantee.

6 Deliberate Exclusions

The architecture excludes three classes of operations by design.

No override. No operation may advance the canonical pointer except through the validation and commit sequence. There is no privileged path — not for administrators, not for the system itself. An override would break I2: a transition could become committed without satisfying validation conditions.

No bypass. No operation may produce externally observable effects except through the execution gate. A bypass would break I3: execution could occur from state that has not been committed.

No retroactive modification. Once a transition is committed, it cannot be altered. The history is append-only in the strongest sense: there is no delete, no update, no correction. A retroactive modification would introduce ambiguity into the canonical history, violating I1’s requirement of a single authoritative progression.

These are not policy decisions. They are structural requirements. A system that permits any of these operations cannot enforce I1–I3, and therefore cannot guarantee that execution is derived solely from committed canonical state.

These exclusions are what make independent verification possible.

Execution non-determinism. Polaris does not constrain what execution produces, when it occurs, or whether its effects are deterministic. A committed transition authorizes execution — it does not prescribe it. The protocol boundary ends at the execution gate. What occurs beyond the gate is the responsibility of the implementing system.

Selection non-determinism. When multiple valid transitions are proposed concurrently, Polaris does not determine which one commits. Selection is determined by the commit authority’s ordering mechanism. The protocol guarantees that whatever commits is valid — not that a specific valid transition is chosen. Replay verifies the committed sequence; it does not reconstruct the selection process that produced it.

Together, execution non-determinism and selection non-determinism define the limit of the protocol’s determinism claim. Polaris guarantees replay determinism (Definition 3, Section 2): given the committed sequence, any verifier reconstructs identical state. It does not guarantee that a specific execution will occur, nor that a specific valid transition will win contention. This distinction is the scope of the protocol.

7 Security and Failure Properties

7.1 Security Properties

The following properties are direct consequences of I1–I3.

Execution integrity. No externally observable effect occurs unless it originates from a committed transition. Follows from I3.
Replay safety. A transition referencing a superseded pointer value is rejected before commit. Follows from I1.
Causal traceability. Every permitted execution effect is traceable to a committed transition, which is traceable to a validation-pass event. Follows from I2 and I3.
Authority isolation. No component may both validate and commit, or commit and execute. This separation prevents any single component from unilaterally satisfying validation and advancing state or producing effects, preserving the enforcement of I2 and I3.
Prefix verifiability. For any committed state Sn, the complete sequence of transitions from S₀ to Sn is reconstructible from the append-only record. Any alteration to prior records invalidates the reconstructed progression. Follows from A1 and the append-only model.

7.2 Failure Handling

The architecture is designed so that failures preserve canonical state and produce no externally observable effects.

Validation failure. The transition is rejected. The pointer does not advance. Canonical state is unchanged.
Pointer mismatch at commit. The request is rejected. The proposer must re-derive from the current pointer before resubmitting.
Execution gate rejection. No side effect occurs. The committed history is unaffected.

In all cases, I1–I3 continue to hold. Canonical state is never modified by a failure.

Safety is unconditional within the model: failures cannot violate I1–I3.

Liveness depends on commit authority availability and is not analyzed in this report.

8 Non-Goals

Polaris enforces causal integrity: execution authority is derived from committed canonical state.

The following are outside the scope of this protocol:

Consensus. Polaris assumes a commit authority exists. How that authority achieves agreement among distributed nodes — Paxos, Raft, threshold signatures, or other mechanisms — is a deployment decision.
Scheduling and fairness. Polaris does not determine which valid transition is selected when multiple are proposed concurrently. Selection is determined by the commit authority’s ordering mechanism. Fairness among proposers is not a protocol concern.
Governance. Polaris does not prescribe how the commit authority is selected, replaced, or held accountable. These are institutional concerns that compose with the protocol.

The following are explicitly not enforced by the protocol:

Policy semantics. Polaris does not define what validation logic should check — only that it must be deterministic and referentially transparent. The correctness of gate logic is outside the protocol boundary. Replay verifies conformance to deployed logic, not logic correctness.
Byzantine failure of the commit authority. If the commit authority is Byzantine, the protocol’s invariants (I1–I2) cannot be guaranteed. Distributed commit embodiments address this at the deployment level.

These boundaries are what make the protocol composable with existing infrastructure.

9 Extended Embodiments

The protocol admits multiple implementation embodiments, provided they preserve its invariants.

Transport agnosticism. The protocol places no requirements on the communication channel between components, provided that the inputs to validation are preserved without alteration.
Distributed commit. The commit authority is a logical role. It may be implemented as a single node, a quorum, a threshold signature scheme, or a replicated state machine — provided that exactly one canonical pointer value is authoritative at any time, satisfying I1.
Policy-derived validation. Validation logic may be compiled from declarative rules or constraint grammars. Updates to validation logic propagate as committed transitions, preserving the append-only history and replay verifiability.
Multi-agent systems. In systems where multiple autonomous agents propose transitions, each agent operates as a proposer. Coordination constraints between agents are expressed as validation conditions.
Autonomous system oversight. The validation pipeline provides a mechanically enforceable boundary for externally observable behavior. Any action that produces effects must pass through the execution gate.

An embodiment is conformant if and only if I1–I3 continue to hold.

10 Related Work

The following comparisons situate the protocol relative to existing system models by identifying which invariants they do and do not enforce.

10.1 Ordering Systems

State machine replication (SMR) [1, 2, 3] establishes agreement among replicas on an ordered sequence of operations and typically validates requests before committing them. The distinction from commit-gated execution is structural: SMR binds replicas to an agreed ordering, but does not bind execution authority to canonical state identity at evaluation time (R4), nor enforce configurable domain-specific validation (R2). Execution in SMR proceeds as a consequence of replica agreement, not as a consequence of a committed canonical state pointer. Linearizability [11] formalizes the ordering properties that underpin the commit authority’s CAS operation.

10.2 Persistence Systems

ACID databases [9] enforce atomicity, consistency, isolation, and durability. I2 and I3 are not intrinsic properties of the ACID model — mandatory pre-commit validation, role separation, and execution gating are not guaranteed by the model. Event sourcing [6] provides an append-only record as an application pattern. Events are appended without mandatory pre-validation; the record describes what happened but does not constrain execution authority.

10.3 Consistency and Convergence

Conflict-free replicated data types (CRDTs) [16] permit concurrent, divergent state evolution that later converges, rather than enforcing a single canonical progression at all times. Commit-gated execution occupies the opposite end of this design space — it requires commitment before execution, trading availability for strict causal verifiability. The Just-Right Consistency framework [17] maps the spectrum between these poles. Commit-gated execution defines the maximum-verifiability point on that spectrum within its defined model.

10.4 Accountability

PeerReview [18] establishes accountability by detecting deviating behavior through append-only logs after execution has occurred. Commit-gated execution operates before execution, excluding unauthorized effects rather than detecting them afterward. The two approaches are complementary — PeerReview addresses what to do when behavior deviates; Polaris addresses what prevents deviation structurally. Both rely on append-only records as the foundation of verifiability, but serve different points in the causal chain.

10.5 Policy and Capability Systems

Capability systems [7, 13] provide invocation-level authorization: a component may act if it holds the appropriate capability at the time of invocation. Commit-gated execution enforces authorization as a property of state progression, not invocation — execution authority is derived from committed canonical state, not from a held token. Policy engines and workflow orchestrators enforce rules at runtime but do not bind execution to canonical state; policy is evaluated at invocation time and is not structurally bound to canonical state progression. I3 is not a property of capability or policy systems.

10.6 Workflow and Orchestration Systems

Workflow engines such as Temporal [14, 15] provide durable execution with retry semantics, task ordering, and fault tolerance. They are the closest deployed analogues to commit-gated execution in practice. However, they do not enforce a mandatory pre-commit validation gate with structural invariants — I2 is not a property of workflow orchestration. They do not bind execution authority to canonical state identity — I3 is not enforced. They do not provide deterministic replay verification without runtime trust. Commit-gated execution is composable with workflow orchestrators as an execution integrity layer beneath their scheduling and retry mechanisms. The Dedalus model [19] formalizes distributed computation in terms of time and causality; the canonical pointer in Polaris serves an analogous role as the single linearization point that determines valid execution, grounded in I1.

10.7 Blockchain and Distributed Ledgers

Distributed ledger technologies maintain append-only records with cryptographic hash chains and achieve consensus among mutually distrusting parties. The surface resemblance to Polaris is strong: both use hash-linked records, both use cryptographic signing, both provide tamper evidence.

The distinction is structural. Blockchain achieves verifiability through distributed replication and consensus — the record is trusted because many independent parties agree on it. Polaris achieves verifiability through cryptographic signing by a known commit authority — the record is trusted because any verifier can independently check the signature and the hash chain without trusting the producing system.

More fundamentally: a blockchain can tell you that a transaction was recorded. It cannot structurally prevent a side effect from occurring from unvalidated or superseded state. I3 is not a blockchain property.

Whether a particular blockchain system satisfies I1, I2, and I3 as defined here is an empirical question. Polaris’ invariants can be applied as a verification lens. But the contribution of Polaris is not the hash chain — it is the execution gate and the structural binding of execution authority to committed canonical state.

11 Limitations

The commit authority is a serialization point. Under high contention, multiple valid transitions compete for a single pointer advancement, introducing a latency floor proportional to the commit authority’s round-trip time. Validation occurs in parallel and does not contribute to this bottleneck — the critical section is constant-time pointer advancement.

The protocol enforces a single canonical progression. It does not support concurrent commits to multiple authoritative states.

The model assumes correct validation logic. Replay verification confirms that transitions conformed to deployed gate profiles — it does not verify that those profiles were correct. The correctness of validation logic is outside the protocol boundary.

The genesis state is a deployment parameter. The protocol assumes a trusted starting point. How that starting point is established and agreed upon is outside the protocol’s scope.

Formal machine-checked verification of I1–I3 is not addressed in this report. The invariants are argued by construction; mechanical proof constitutes future work.

These limitations reflect a deliberate design position: structural causal integrity over maximal availability and flexibility.

12 Discussion

The central insight of commit-gated execution is a separation that existing systems do not enforce: validation, commit, and execution are distinct operations with distinct authorities. In most deployed systems, these collapse — a component that can propose can often commit, and a component that commits often triggers execution. This collapse is where unauthorized execution originates.

By enforcing strict role separation and binding execution to committed canonical state, the architecture excludes a class of failures that logs, audit, and monitoring do not prevent — phantom executions, where side effects are triggered from state that is later invalidated or superseded. These are not detectable in advance by any observational mechanism. They are only preventable structurally.

The trade-off is deliberate. Serialization at the commit boundary introduces latency. Systems that require causal integrity must accept this cost. Systems that do not require it should not use this protocol.

The defining property — verifiable by anyone, trusted by none — is not a feature of the implementation. It is a consequence of the invariants.

13 Conclusion

Systems execute from state. In no widely deployed architecture is that execution structurally constrained to originate from committed canonical state. This is not typically enforced as a structural property in existing systems.

Polaris defines it.

Commit-gated execution binds execution authority to committed canonical state identity — enforced through mandatory validation, exclusive commit, and execution gating. Three structural invariants enforced by construction establish that all observable effects originate from validated canonical history.

From these invariants a non-trivial consequence follows: two independent conformant implementations, given the same history, will permit exactly the same set of execution effects — without communication, without shared state, without trust.

Execution authority is verifiable by anyone. Trusted by none.

Future work includes formal machine-checked verification of I1–I3, throughput evaluation under distributed commit embodiments, and application of the protocol in autonomous system oversight.

Implementation Notes

A reference implementation was validated against the conformance checklist in a single-node configuration. Replay verification was performed on valid and tampered execution histories. In both cases, the implementation satisfied I1–I3. Valid histories were accepted and tampered histories were rejected.

These results do not constitute performance benchmarks. They demonstrate that the invariants are implementable and that the verification procedure produces deterministic outcomes for a conformant implementation. Replay verification produced identical results when re-evaluated from the recorded history.

The normative specification is available at: https://github.com/polaris-specs/polaris-protocol

For implementers: QUICKSTART.md defines the minimal conformance path.

References

[1]L. Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Comm. ACM 21(7), 1978.
[2]F. B. Schneider, “Implementing Fault-Tolerant Services Using the State Machine Approach,” ACM Comp. Surveys 22(4), 1990.
[3]L. Lamport, “The Part-Time Parliament,” ACM Trans. Comp. Systems 16(2), 1998.
[4]M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” OSDI, 1999.
[5]S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008.
[6]M. Fowler, “Event Sourcing,” martinfowler.com, 2005.
[7]M. S. Miller, K.-P. Yee, J. Shapiro, “Capability Myths Demolished,” JHU SRL2003-02, 2003.
[8]D. J. Bernstein, T. Lange, P. Schwabe, “The Security Impact of a New Cryptographic Library,” CHES, LNCS 7428, 2012.
[9]J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1993.
[10]D. Ongaro and J. Ousterhout, “In Search of an Understandable Consensus Algorithm,” USENIX ATC, 2014.
[11]M. Herlihy and J. M. Wing, “Linearizability,” ACM TOPLAS 12(3), 1990.
[12]V. Buterin, “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform,” 2014.
[13]J. Dennis and E. Van Horn, “Programming Semantics for Multiprogrammed Computations,” Comm. ACM 9(3), 1966.
[14]Temporal Technologies, “Temporal Platform Documentation,” accessed 2026. https://docs.temporal.io
[15]Temporal Technologies, “How the Temporal Platform Works,” accessed 2026. https://docs.temporal.io/temporal
[16]M. Shapiro, N. Preguiça, C. Baquero, M. Zawirski, “Conflict-Free Replicated Data Types,” SSS, LNCS 6976, 2011.
[17]M. Shapiro, A. Bieniusa, N. Preguiça, V. Balegas, C. Meiklejohn, “Just-Right Consistency: Reconciling Availability and Safety,” Inria Research Report RR-9145, 2018.
[18]A. Haeberlen, P. Kouznetsov, P. Druschel, “PeerReview: Practical Accountability for Distributed Systems,” SOSP, 2007.
[19]P. Alvaro, W. R. Marczak, N. Conway, J. M. Hellerstein, D. Maier, R. Sears, “Dedalus: Datalog in Time and Space,” Datalog Reloaded Workshop, 2010.
[20]H. Howard, D. Malkhi, A. Spiegelman, “Flexible Paxos: Quorum Intersection Revisited,” OPODIS, 2016.

How to cite

Lindberg, Daniel. “Polaris Protocol: Commit-Gated Execution and Causal Integrity.” Polaris Protocol Technical Report POLARIS-TR-2026-001, v0.5, April 2026. https://polaris-protocol.org/paper/