Programmable Settlement - Primitives
Deterministic, auditable settlement programs that net, route, and finalize value across chains — with proofs.
What it is
Section titled "What it is"The network’s settlement plane. It runs small, purpose-built programs that transfer, net, escrow, stream, or split value. Every run produces a signed receipt and anchors into checkpoints for network-wide finality.
What you get
Section titled "What you get"-
Deterministic outcomes: same inputs, same outputs - no hidden side effects.
-
Atomicity across assets and chains: bundle many legs into one program, finalized under a single global checkpoint.
-
Netting and batching: compress obligations to cut gas and daylight risk with batch auctions and cycle breaking.
-
Programmable controls: escrow, locktimes, vesting, streaming, waterfalls, tranches, allowlists.
-
Compliance by construction: Travel Rule proofs, sanctions checks, and per-jurisdiction policies built in as hooks.
-
Receipts with evidence: every run returns a verifiable receipt of inputs, outputs, oracles used, and quorum signatures.
How it works
Section titled "How it works"-
Author: build a settlement program with drag-and-drop blocks or the SDK. Declare required oracles and assets up front.
-
Register: publish a signed manifest with guarantees, fees, limits, and failure semantics. Each version is pinned for auditability.
-
Fund: deposit assets or grant pull allowances. Programs can net obligations before posting the remainder.
-
Trigger: start executions via schedules, webhooks, order flow, or cross-primitive events.
-
Execute: a deterministic VM runs the program. Oracle reads are locked to specific round IDs and manifests, eliminating ambiguity.
-
Finalize: the primitive emits a SET PCkpt[k] with program roots and receipts. The Master Chain ingests it into the GCkpt for network-wide finality.
Concepts
Section titled "Concepts"-
Settlement Program (immutable): a declarative graph of typed steps and inputs. Examples include payment splits, market maker rebalances, payroll streams, fee rebates, and vesting unlocks.
-
Run (immutable): a single execution instance with input references, oracle round IDs, state deltas, outputs, gas/fee stats, and a signature bundle.
-
Account (owned): program-scoped vaults and allowances for assets. Supports pull models with guardrails like rate limits.
-
Assurance Profile (shared): defines limits for gas, step count, oracle staleness, and failure semantics.
-
Receipt (immutable): machine-verifiable evidence that ties a run to its inputs, oracles, and the PCkpt that finalized it.
Blocks
Section titled "Blocks"-
Escrow and release: hold funds until a set of conditions is met, then release or refund.
-
Netting and compression: multilateral netting with cycle detection to reduce transfers.
-
Vesting and streaming: cliffs, linear or stepped schedules, and drips with pause and catch‑up.
-
Split and waterfall: percentage or priority based distribution with caps and floors.
-
Conversion and routing: use approved venues or AMMs, respect slippage and price bands.
-
Compliance checks: require Travel Rule existence proofs and sanctions digests without exposing PII.
-
Rewards and engagement: issue a rewards coin, cashback, or fee rebates based on qualified actions. This is one example block, not the only programmable pattern.
-
Start: pick a template or begin with a blank canvas.
-
Design: drag blocks into a graph, wire inputs and guards, and set your limits.
-
Bind data: choose oracle feeds and an assurance profile to anchor execution.
-
Register: publish the manifest, pin the version, and assign roles.
-
Fund: deposit assets or approve allowances.
-
Trigger: kick off runs via schedules, webhooks, or cross-primitive events.
-
Observe: watch execution step by step, receive a signed receipt, and export an evidence pack for audit.
Program properties
Section titled "Program properties"Every settlement program publishes a signed manifest anchored in checkpoints, its contract with users and auditors. Manifests define:
-
Finality class: GCkpt inclusion target and dispute window.
-
Latency: p95 from trigger to receipt, plus grace windows.
-
Throughput: max runs per second, batch size, and gas ceilings per run.
-
Atomicity: which legs and assets must succeed together, or all revert.
-
Oracle envelope: required feeds, max staleness, quorum size, and diversity rules.
-
Failure semantics: whether to revert, compensate, retry with backoff, or park for operator action.
-
Fee model: base per run plus per byte, with optional priority lanes and rebates for batching/netting.
-
Delivery modes: on-chain calls, SDK/webhook triggers, or cross-chain fan-out via Zero Layer.
-
Access control: who can trigger, update limits, or rotate keys — with support for session keys.
-
Jurisdiction & compliance: residency requirements, allowlists, and reporting hooks.
-
Observability: metrics, logs, audit exports, and public dashboards.
-
Version & upgrades: notice periods, compatibility windows, and template provenance.
Proof of correctness and freshness
Section titled "Proof of correctness and freshness"Every run comes with anchors that make it fully reproducible:
-
The program manifest hash in effect at execution.
-
The input set with content hashes.
-
The oracle round IDs and AttestationBundles used.
-
The SET PCkpt that committed the run.
-
The GCkpt height where that PCkpt was accepted.
With these items, auditors (or counterparties) can replay the run and verify the results against declared limits and oracle data, proof that the program did exactly what it promised.
Cross-chain and cross-asset
Section titled "Cross-chain and cross-asset"-
Single trigger, many legs: one action can span multiple chains e.g. move stablecoins on chain A, release collateral on chain B, and pay fees on chain C.
-
Safety: every leg executes under the GCkpt stream. If one leg fails, the whole bundle either reverts or compensates exactly as the manifest specifies.
-
Bridges: Zero Layer handles message passing and proofs. No pooled liquidity, no custodial risk.
Security
Section titled "Security"-
Deterministic VM: bounded execution, gas ceilings, and pure functions over declared inputs.
-
Replay and reentrancy protections: nonce and domain separation, idempotent receipts.
-
Manipulation resistance: oracle diversity and staleness guards enforced at runtime.
-
Accountability: staking, slashing, and dispute windows for operators. Failed runs surface with evidence.
-
Key management: roles, session keys, rate limits, and safe rotation.
Performance (targets)
Section titled "Performance (targets)"-
Latency: runs typically finalize within a few seconds from trigger to receipt under normal conditions.
-
Throughput: thousands of simple runs per second in aggregate, boosted by batching and netting.
-
Finality: every run is anchored into the GCkpt stream within the network’s target window. Exact SLOs are defined per program profile.
Economics
Section titled "Economics"-
Fees: charged per run and per byte, with discounts for batched or netted runs. Priority lanes available when urgency matters.
-
Incentives: operators and mirrors earn for availability and low latency; repeated breaches trigger penalties or slashing.
Developer surface
Section titled "Developer surface"Small, typed APIs and drag‑and‑drop.
openProgram(manifest) → programIdrun(programId, inputs) → receiptsimulate(programId, inputs) → diffsetLimits(programId, limits)subscribe(programId, handler) → streamverify(receipt) → true|false
Programs compile from the visual graph into portable outputs: manifests, receipts, and evidence packs that run the same across EVM and non-EVM chains via the shared IR.
Templates and local simulators are available for CI and deterministic testing.
Observability
Section titled "Observability"-
Program explorer: browse manifests, runs, receipts, PCkpts, and GCkpt inclusion.
-
Metrics: track latency, success rate, gas/fee totals, and netting efficiency.
-
Alerts: catch retries, parked runs, stale oracles, and limit breaches.
-
Evidence packs: machine-readable bundles for auditors, counterparties, and risk teams.
Upgrades and governance
Section titled "Upgrades and governance"-
Template governance: public templates go through review, versioning, and provenance tracking.
-
Limits & profiles: updates carry notice periods and migration windows so apps don’t break mid-run.
-
Operator rotation: committees rotate with continuity rules to keep programs live without interruption.
Roles
Section titled "Roles"-
Program owner: authors the program and sets its limits.
-
Operator committee: executes runs and signs SET PCkpts according to the assurance profile.
-
Master Chain: re-validates SET PCkpts into the GCkpt stream for global finality.
-
Not a generalized smart contract platform for arbitrary compute.
-
Not a pooled-liquidity bridge.
-
Not a soft-SLA batcher with unverifiable receipts.
TL;DR
Section titled "TL;DR"Programmable Settlement turns flowcharts into deterministic settlement programs with receipts, netting, and compliance baked in - provable across chains.