> 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="https://2970403064-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwOUbJmiTegGBEv1M988A%2Fuploads%2FIAyI8kQnuUSpwIy8Tx0I%2FFull-Stack%20DeFi%20Infra.png?alt=media&amp;token=08dd0dc1-3daa-4ecd-9fe8-9fd675f3c5cb" 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="https://2970403064-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwOUbJmiTegGBEv1M988A%2Fuploads%2F7To9UIeD9APhJGjA9til%2FSecurity%20Model%20and%20Invariants.png?alt=media&amp;token=1a7a6675-c1ed-41f0-9b59-24851c26a101" 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.

***