delta for Stablecoin Issuers

delta's benefits: Blockchain properties without the limitations

To be successful, agentic economics, onchain finance, and all other stateful digital systems will depend on the same three primitives:

• Neutral shared state: a shared state space in which all participants are equivalent;
• Verifiable guardrails: the ability to provide users and other counterparties with programmable guarantees about execution or outcomes;
• Tamper-proof ledger: the current state can be deterministically derived from the ledger history, no ledger entry can be altered after the fact.

Blockchains introduced these properties to the world, but they came at the cost of a highly limited developer and execution environment. delta has been developed precisely to break this compromise: provide any internet-based service with minimal infrastructure to add selective access to shared state and program any verifiable guardrails on top of the existing system. By definition, this makes it possible to turn any service or application into a “blockchain-y” one, which has the same desirable properties of a smart contract (verifiability, interoperability, composability).

We can think about this in terms of the tech stack:

• Modern software consists of a deep stack, such that each element serves a very specific purpose and does not interfere with the other elements.
• When building on a blockchain, you have no stack flexibility. Storage, programming model, identity etc. are all chosen for you by the blockchain.
• delta embraces the modern software approach: businesses choose the right tools for their application, and we provide a module to be added on top of their existing stack.

Core concept: Selective verifiability

Crypto people typically view verifiability through the lens of independent execution audit: anyone can run a given program on given inputs to verify the outputs of the system. This is how blockchains work: validators re-execute the same code, and if you don’t trust them, you can too.

With re-execution, invalid state transitions can settle, but you can catch them after the fact through independent checks. Zero-knowledge proofs have been introduced as a stand-in replacement for re-execution. Zk-based blockchains (e.g. zk-rollups) have a stronger kind of verifiability than classical blockchains, which we call preventive verifiability, where rule-breaking behavior is not possible at all. Post-hoc audits are replaced with pre-settlement constraint checks.

Preventive verifiability presents a much stronger case for verifiability than re-execution: it lets us elevate policy to physical laws. Today, only physics has laws which are unbreakable by design, whereas political, economic and software-based systems all rely on post-hoc audits and enforcement. Preventive verifiability suggests that any system with clearly and objectively checkable rules could replace its (often enormous) system of internal and third-party inspectors with real-time automated checks. In turn, any such system could confidently automate workflows without requiring human-in-the-loop checks.

But zk-rollups undersell the true value of zero-knowledge proofs. They started with the blockchain as the first principle, rather than from zk itself. Therefore, rollups do not enable any use cases that couldn’t be built on a re-execution-based blockchains. They cannot provide preventive verifiability to any system apart from the very few that can be expressed as smart contracts on the blockchain.

When adopting zk from the perspective of re-execution, the answer to the question “What should I prove?” is obviously the full execution path. On the other hand, delta is developed with programmable zero-knowledge proofs as the base.

With the starting point being zk itself, the answer clearly becomes “Prove the properties you want to make verifiable”. We do not by default have to prove the full execution of our system, so why would we? We call this selective verifiability, and although it might seem subtle, the switch from verifiable execution to selective verifiability will be what lets the entire open internet integrate with a verifiable state machine, rather in contrast to the closed ecosystems of blockchains.

We assume selective verifiability to be preventive, since the alternative doesn’t exist.

Intuitively, selective verifiability is strongly aligned with the way people think about systems: every important system (video games, markets, the universe) has bounded freedom. A set of clearly defined rules declare constraints on behavior, without forcing the entire system to be rigidly deterministic. On the other hand, verifiable execution offers no freedom at all; the rules are so strong that all behavior is fully determined. It’s fundamentally impossible to build expressive applications in such a restrictive environment. This is why blockchain applications remain toy-like.

Building selectively verifiable applications looks different than verifiable execution. Rather than writing the entire codebase from scratch inside a verifiable environment, you write your execution logic as in Web2, and then explicitly write down constraints in a cryptographic computer. For example, you might write your AMM in Python, and then attach three simple checks: “signature is valid”, “has sufficient balance”, and “receives y = k/x of token B”. Or let’s say you wanted offer an AI for trading or portfolio rebalancing. The domain could use standard price feeds from Bloomberg to define a constraint where trades can only settle only if the asset ratio falls within some margin of the actual prices.

The real game changer of selective verifiability lies in the ability to make arbitrary systems verifiable. For a traditional equities exchange that might mean making its matching rules externally verifiable; for an AI agent it turns its guardrails into settlement constraints which perfectly defend the agent and its counterparties from prompt injection. Relative to the current ecosystem of crypto apps, the delta-enabled ecosystem of selectively verifiable systems, services, and actors will be vastly richer: it’s the economy of the open internet, unified on a shared state, with ubiquitous secure automation as selective verifiability replaces trust.

Only possible on delta: Agentic Commerce with Verifiable Guardrails

tl;dr: Agents currently lack a shared, real‑time way to prove and enforce owner intent to counterparties without a human in the loop. delta provides pre‑settlement, externally verifiable, programmable guarantees that an agent will act within its mandate, allowing for agentic behavior which is secure even on the open internet. This reflects expressed goals and work of companies like Google and OpenAI.

Blockchains, which have historically championed the view that we need to replace trust-based systems with verifiable guarantees, are ironically focused on building reputation infrastructure for agents (see ERC-8004). This is because it would simply be impossible for blockchains to provide smart contract-like guarantees for agentic actions. But these guarantees are arguably even more important for agents than they are in the case of regular, human-administered software. Given the rapidly shifting landscape of AI and the to-be unbounded scale of agentic economies, reputation-based systems simply will not suffice.

Google’s AP2 is the first attempt at addressing the threat of prompt injections, as well as unprompted outlier behavior posed to people letting agents transact on the open internet. It provides the agent with a cryptographic certificate corresponding to its owner’s intent, which can be used in matters of dispute.

There are three major problems with this standard:

• Post-hoc vs. realtime. Current payments are primarily secured in realtime, via e.g. 3DS for cards.
• No programmability. To be effective in the case of dispute, the action signed over by the human must be extremely narrowly defined.
• Each purchase must correspond to a human action. Autonomous agents working independently in their own time, e.g. to automate supply chains, cannot use AP2; they can only make purchases which have been individually permitted by a human.

On the other hand, guardrails such as the ones introduced with OpenAI’s AgentKit do offer arbitrary expressivity, but no counterparty guarantees (not even post-hoc auditable certificates such as AP2). While you can trust an agent with guardrails that you built yourself, you have no way of knowing that an external agent is constrained by a given rule.

Enter delta

delta’s approach takes the best of AP2, AgentKit, and blockchains: like AP2, delta-based agents are tied to cryptographic mandates; like AgentKit’s guardrails, these mandates are arbitrarily programmable; like blockchains, the execution constraints expressed through the mandates form settlement constraints that must be satisfied in order for an agent’s action to settle/finalize.

This solves all three problems:

1. Settlement guarantees. A transaction’s settlement happens only if the agent complied with the predefined rules. This is cryptographically guaranteed.
2. Full programmability. The cryptographic machinery of delta is defined with a high-level, popular programming language (Rust). This means that any constraint or requirement which can be written in code is possible to implement.
3. Autonomous agents by default. While per-action flows as defined by AP2 are possible, it’s strictly unnecessary if we have sufficiently capable AIs (arguably already the case) combined with protection against prohibited behavior.

Agentic commerce as it’s currently conceived requires a human in the loop at all times, similar to how early iterations of Cursor would only allow for short, independent pieces of work to be executed by the AI before requiring re-prompting. With delta, it’s like the world of coding agents, in which you can give the agent a high-level prompt and it can work continuously 24/7 without requiring re-prompting, and without accidentally losing all your money.

Agentic economies are not currently held back by the intelligence of AI, but by the fact that agents are not perfectly reliable. delta will provide the necessary verifiable protection that enables secure economic agents to roam the open internet freely.

Only possible on delta: All finance going onchain

tl;dr: Blockchains cannot host the confidential, identity‑aware, high‑performance, interoperable, and controllable‑settlement workflows real markets require. Public state blocks private data and KYC/AML; constrained compute and volatile fees preclude MEV‑free FIFO matching and advanced algorithms; weak offchain links keep price‑forming data and rails elsewhere; instant finality removes pre‑settlement safety nets. With delta, systems that already satisfy all of these requirements can simply connect to delta to activate verifiable guarantees and participate in shared state.

In return for verifiability and shared state, blockchains force us to write applications which are incredibly limited in terms of capability. More concretely, TradFi markets cannot move onchain in a meaningful way for the following reasons:

• Lack of confidentiality: Any data that is used onchain is transparent; sensitive financial data cannot be stored on a blockchain;
• Lack of identity: Legally reliable identity and compliance information (KYC/AML) can’t be maintained in an onchain setting;
• Restrictive resource bounds: Traditional financial services consist of heavy machinery, far too powerful for blockchains to support. Unreliable gas fees are a result of heavy resource constraints;
• No real-world interoperability: Blockchains are self-contained, and don’t integrate well with the outside world. For example, income, employment, collateral status, and bureau data cannot be accessed by oracles; there is no interoperability with traditional payment rails;
• Instant settlement: There exists no intermediate state between execution and settlement. Errors and hacks automatically move assets; flows can never be netted; reversibility does not exist. Instant finality is an asset when the intention is to settle, a liability before then.

delta is minimal. It lets you selectively share your state and add verifiable guardrails to your pre-existing programs, without forcing your entire application to be built from scratch. That is, you simply integrate delta as you would with a regular library. For the above limitations, this means:

• Confidentiality: Data is by default private, and can nevertheless be computed over verifiably. Applications use rich offchain data sources and settle verifiable results.

• Identity: Similarly, identity data can be kept offchain and bound to a delta account. delta’s native passkeys solidify this: a user signs transactions with the same electronic signature that is legally binding under e.g. US and EU regulations.

• Web2 resource limits: No gas fees, no compute constraints. The only introduced resource constraints are:

  1. how much data you post to delta, and
  2. which cryptographic guarantees you provide to users.

  Re 1), because they can maintain arbitrarily big state locally, applications will generally only settle user-triggered state changes to delta. For 2), these guarantees are typically tied to either the integrity of private input data, or the verification of simple equations. Much cheaper than the computation it took to get there.

• Real-world interoperability: Any system can become a delta domain. That is to say that a system which e.g. connects to card rails can seamlessly marry these with the delta rails and provide interoperability between the two. Similarly, delta applications can call APIs natively, with no need for oracles.

• Oracle‑free market data & risk: domains can ingest data directly from exchanges, custodians, transfer agents, and on‑chain venues — no third‑party oracle pushes. Domains can use multi‑source aggregation (CEX/DEX/issuer feeds/PoR) with cross‑venue deviation limits, TWAP/median fallbacks, and conversion‑ratio or NAV‑based valuation for wrapped/tokenized assets. Only attested digests would settle to delta, eliminating mempool/MEV and block‑time delays that make on‑chain price updates gameable, just as we saw again in the 10/10/25 liquidation cascade.

• On-demand settlement: A delta application can choose not to settle its transactions instantly and instead do so e.g. at a daily or weekly cadence.

• Stress‑aware liquidation policies: Domains can throttle or stage liquidations when connectivity degrades or cross‑venue consensus breaks, and auto‑enter circuit‑breaker mode on venue‑local outliers. True market repricings still flow through; venue‑local anomalies do not.

The combination of these features make realizable true state-of-the-art applications which fundamentally cannot be built on blockchains:

• Credit: Only overcollateralized crypto loans can currently exist onchain because there is a lack of strong identity, underwriting data, and legal enforceability. delta lets credit service providers provide verifiable lending markets which are tied to confidential data such as the above, and binds the borrower to legal agreements.
• Asset exchanges: Traditional equities exchanges are built with hyper-optimized code which runs in the tens of microseconds, two orders of magnitude faster than even the most efficient centralized blockchains. delta will let these integrate their existing codebases, and additionally provide MEV-free FIFO ordering, process KYC etc., all necessary for a regulated exchange.
• Competitive DeFi: DeFi protocols such as perp dexes, lending markets, and AMMs rely on math. Blockchains are however far too compute-constrained to allow anything beyond high-school math. Methods such as convex optimization, which would provide traders with better prices and LPs with better risk-adjusted returns, are simply far too heavy for blockchains. With delta, we will see whole new classes of DeFi protocols, relying on linear algebra, Markov processes, PDEs and beyond.

More Resources

• Read the delta litepaper
• delta Detailed Network Overview
• Request access to our code documentation and SDK