Deterministic Control Framework

zkCross is built on the principle that automation should operate without custody and without discretion.

The deterministic control framework is what makes that principle real.

It defines what actions are allowed, what is blocked by design, who can approve execution, how unexpected events are handled and how external reviewers can verify the system’s behavioural boundaries.

If a rule is violated, execution does not proceed.

The control model

zkCross separates automation into three distinct roles.

Intelligence proposes

A planning or intelligence layer can analyse conditions, simulate options and recommend actions. It has no direct authority to move funds.

Guardian enforces

The Guardian is the deterministic enforcement layer. It evaluates every proposed action against rule sets that define scope, risk boundaries, invariant requirements and emergency conditions.

Execution performs

The execution layer submits only those actions that have passed Guardian enforcement and meet signing requirements.

This separation is essential. It means system intelligence can become more capable over time without becoming more powerful in a discretionary sense.

Guardian enforcement

The Guardian ensures automation behaves like infrastructure rather than like an unrestricted trading bot.

At a high level, it enforces:

• protocol, contract, asset and venue allowlists
• per-action and per-vault limits
• exposure and concentration boundaries
• slippage ceilings and price deviation checks
• cooldowns, rate limits and anomaly checks
• circuit breakers and containment conditions
• invariant checks before, during and after execution

A simple mental model captures the design:

Intelligence can ask. Guardian decides. Execution obeys.

Deterministic rules and invariants

The rule system is designed to be explicit, testable, enforceable at execution time, resistant to silent drift and reviewable over time.

Rule categories include:

Scope rules

These define which protocols, contracts, actions and target classes are permitted.

Risk boundary rules

These define exposure caps, concentration limits, slippage ceilings and price deviation bounds.

State validity rules

These define the preconditions and postconditions required for valid execution.

Emergency rules

These define the conditions that should pause execution, isolate a venue, or contain vault-level risk.

zkCross is designed so that these boundaries are not soft policy statements. They are part of the execution path itself.