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.

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.

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.

---