> 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/security-model-and-invariants.md).

# Security Model and Invariants

zkCross security is built on deterministic execution control.

Oracle freshness, deviation thresholds, cross-reference pricing and volatility limits are checked before actions are authorised.

<figure><img src="/files/1XAVtha6ZPqXBnOLgTbL" alt=""><figcaption></figcaption></figure>

### Security foundations

The architecture is built around a few core principles:

* non-custodial vault custody
* deterministic rule enforcement
* protocol and asset allowlisting
* permissioned signing
* post-execution verification
* fail-closed default behaviour

These principles are simple individually, but powerful when combined into one execution framework.

### Custody and vault invariants

Vault integrity is foundational to zkCross.

The following properties are central:

* assets reside in vault contracts
* the vault is the only approved origin of capital movement
* no arbitrary external transfers are allowed
* unrestricted approvals are not part of the model
* no hidden custody layer exists behind the interface

Associated invariants include:

* vault balances cannot decrease except through approved adapters
* destination contracts must be allowlisted
* transfers must match expected deltas
* no execution path can bypass Guardian enforcement

### Protocol allowlist criteria

Not every protocol is eligible for routing.

zkCross evaluates venues before they are added to the allowed execution set. Review factors include:

* smart contract audit history
* liquidity depth and stability
* upgradeability model
* oracle dependency risk
* administrative key structure
* pause and emergency design
* exploit history
* operational uptime

This means routing is not simply a search for attractive yields. It is bounded by risk eligibility.

### Core invariant categories

zkCross applies invariants across multiple layers.

<figure><img src="/files/3VZjlRlDLK27CiKkbctb" alt=""><figcaption></figcaption></figure>

#### Execution invariants

Action types, size limits, slippage bounds, route termination, oracle validity,  intent expiry must all remain valid before execution proceeds.

#### Price and oracle invariants

Oracle freshness, deviation thresholds, cross-reference pricing, and volatility limits are checked before actions are authorised.

#### Exposure and allocation invariants

Per-venue caps, per-asset caps, total vault exposure bounds and concentration limits help prevent over-allocation.

#### Cross-chain invariants

Destination chains must be allowlisted, routes must remain constrained, message ordering must preserve determinism and settlement receipts must match expected outcomes.

#### Settlement invariants

Net asset deltas, fees, position state and accounting must reconcile after execution. Unexplained residual balances are not accepted.

### External validation

The security model is strengthened by independent reviews and by sustained production use. zkCross has undergone external security assessments across EVM and non-EVM deployments, including contract audits, cross-chain execution reviews, signing constraints, settlement logic and penetration testing.

Just as important, the infrastructure has already operated in live market environments. Security is not only a paper exercise. It has been exercised under production conditions.

***


---

# 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/security-model-and-invariants.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.