Cryptographic cursors

A cryptographic cursor is a sealed point in an execution graph. It is simultaneously:

• a resumable checkpoint reference;
• a causal claim about parent execution;
• a manifest of inputs, outputs, continuation, and authority references;
• a portable unit of scheduling;
• an audit point that can be signed and independently verified.

It is not a memory address, bearer token, packet, process, or serialized heap.

Version 0 record

The executable model seals this payload:

The author signs the canonical payload. The record identifier commits the payload, author identity, public key, and signature using a domain-separated hash.

Operations

Advance

One or more parents become a child after verified execution. Advancing never mutates a parent.

Pause

Publish a cursor whose state root and continuation are sufficient for a compatible executor to resume. Pausing is a normal advancement, not an out-of-band debugger trick.

Resume

Resolve the state and program, verify grants, select a compatible executor, then create a child cursor. The body may differ from the parent.

Chop

Replace a large state root with independently addressable subgraphs and an assembly description. Chopping changes storage granularity without changing the logical continuation.

Split / fan out

Create multiple children from the same parent, normally paired with an explicit capability split or read-only delegation. Each child has independent failure and scheduling history.

Return

Publish outputs as immutable references. “Returning” across a network does not require pushing all bytes to the parent body; it makes results resolvable under explicit grants.

Join / fan in

Create one child that names every joined parent. Join logic is program-defined: union, reduction, CRDT merge, conflict object, proof aggregation, or explicit human decision.

Rebase

Re-execute a continuation against a different admissible input/state root and produce a new branch. History is not rewritten and the new parentage must be explicit.

Local, network, and world cursors

These are roles, not incompatible record formats:

• a local cursor advances on one body and may use local-only resolution hints;
• a network cursor is advertised or delegated through a fabric;
• a world cursor names a coherent root of a Self's inspectable environment;
• a resource cursor waits on or advances through a device/resource state machine;
• a program cursor selects a continuation in an immutable module graph.

The same cursor can occupy several roles. Policy decides which fields and referenced objects may cross a boundary.

Cursor compatibility

An executor advertises constraints as tuples: architecture, continuation ABI, module formats, page sizes, accelerators, device access, trust level, and budget. Scheduling matches a cursor's requirements against these assertions.

A continuation should prefer portable logical state over blind address-space dumping. Native stack snapshots can be supported as an optimization with strict compatibility labels; WASM, bytecode VMs, and Smalltalk images offer more portable continuation forms.

Invariants worth proving

• canonical equivalent payloads produce identical signing bytes;
• a child logical clock exceeds every parent;
• every referenced output was durably published before the cursor;
• grant chains verify against chosen trust anchors;
• a split conserves declared consumable budgets;
• an effect receipt is stable across retrying bodies;
• cursor publication is idempotent;
• secrets and local resolver hints are absent from durable cursor bytes.

See protocol/curso-0.md for byte-level rules.