> For the complete documentation index, see [llms.txt](https://zkcross-network-1.gitbook.io/learn.zkcross.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zkcross-network-1.gitbook.io/learn.zkcross.network/core-infrastructure/deterministic-control-framework.md).

# 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.

<figure><img src="/files/nAK71Q36gJOTGkbCQhfZ" alt=""><figcaption></figcaption></figure>

### 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.

<figure><img src="/files/hZUTzSaeqnSk6IfzOGdF" alt=""><figcaption></figcaption></figure>

### 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zkcross-network-1.gitbook.io/learn.zkcross.network/core-infrastructure/deterministic-control-framework.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.