The Guardrail Model
At the center of delta is the Guardrail Model. This constitutes a new mode of verifiable computation, in contrast to the smart contract model of blockchains.
The guardrail model is designed to enforce bounded freedom: as long as specific explicit rules are satisfied, anything goes. This is similar to how physical laws bound our movement and societal laws limit our behavior. Note that smart contracts force full determinism, by making execution itself verifiable.
While the guardrail model is solely focused on outcomes, the verifiable execution of blockchains is centered around process (execution) and ignores the outcomes.
In practice, guardrails are implemented in Rust and compile to zero-knowledge proofs, which are efficiently verified by the delta validators.

The application server executes a list of user intents to compute an SDL. These are submitted together to the Gateway, which proves that the guardrails are satisfied. Only the SDL and the proof (not the user intents) leave the private system and are shared with the settlement layer.
Which guardrails to implement​
Think about the guardrails as the rules of your application: internal policy, external regulations, and the guarantees you’re promising users and other counterparties. By turning these into delta guardrails, the enforcement and verification of these rules become automated, and the need for human-in-the-loop is eliminated.
Here are some examples:
- A constant-function AMM enforces its trade invariant as a guardrail, preventing any non-conforming trade from settling
- A cross-border money movement service ensures AML compliance via guardrails.
- Agents require guardrails. When these agents touch money, those guardrails must provide counterparty guarantees.
- Agentic services: a financial manager agent operates with a user-defined policy (max leverage x, min market cap y, max portfolio concentration z). This policy defines the guardrails for each user.
- Agent-to-agent payments: your agent transacts with other agents. To ensure your agent cannot be exploited, you implement guardrails for your agent so that it can only interact with other agents which also have specific guardrails.
- Agentic commerce: a user’s intent for a purchase defines the guardrails for the transaction, providing both settlement constraints and an auditable cryptographic object for dispute resolution.
Default guardrails​
delta provides default guardrails for standardized checks such as nonce and signature verification. Unless you have a good reason not to (e.g. you want to use a custom signature scheme or other authorization method such as email and password), we suggest you adopt the default guardrails.