For Smart Contract Developers

Web2 DevEx, Web3 Guarantees

Blockchains are excellent asset ledgers, but painful application runtimes. With delta, your app can run on normal infrastructure and still offer verifiable, hard guarantees that are enforced at settlement.

View Docs
Delta for Smart Contract Developers
Slide 1 of 4

A fitness contest app you'd actually want

Stream heart-rate packets and activity data from wearables. Run the model in Python. Push alerts to Slack.

It's ordinary software: real-time, event-driven, and connected. Normal backend, normal deployment loop.

Fitness aggregator Python code with wearables integration
Slide 2 of 4

Add a prize pool with real money

Weekly challenge: fastest 5K wins. Friends stake $25 each for a $100 USDC pool.

Two requirements appear: funds must be non-custodial, and the contest results must be trustworthy. This means authenticated inputs provably correct scoring.

Weekly challenge leaderboard with USDC prize pool
Slide 3 of 4

Connect your app to a domain, anchor rules to delta.

1. Pick the state others must trust (e.g., a daily VO₂ claim).
2. Write local laws: a small constraints program that proves the claim came from signed device packets and the right formula, within bounds.
3. Deploy a domain (a thin adapter) that publishes the claim + proof to delta. delta verifies the proof and settles the contest.

Three-stage architecture: client, domain, and base layer
Slide 4 of 4

Your app stays the same, delta's integrity layer satisfies your requirements.

Your app keeps its streams, models, sockets, files, redeploys, and monitoring. Only the narrow, explicit guarantee surface goes on the network.

Now the contest can settle real money with hard guarantees: the rules can't be broken, even if the domain wanted to.

Your App vs Constraints comparison showing minimal audit scope
01 / 04

why delta

Blockchain Friction
Gas Optimization
Developers spend weeks rewriting perfectly working logic (e.g., bit-packing booleans into uint256, avoiding loops) to save users $2 in fees.
Delta Equivalent
No Gas Needed
Write code for readability, not for gas. Run on standard servers where compute is cheap.
Blockchain Friction
Fixed-Point Math
Solidity doesn't support floating point. You must manually manage decimals (Wad/Ray math), precision loss, and overflow checks.
Delta Equivalent
No Fixed-Point Restrictions
Use native floats/decimals and standard math libraries. Stop rewriting finance logic to fit Solidity. float amount = price * quantity
Blockchain Friction
Oracle Integration
You cannot verify real-world data. You must integrate Chainlink feeds, handle "stale price" checks, fallback logic, and fund subscription accounts.
Delta Equivalent
No Oracles Needed
Make HTTP requests and call APIs natively. requests.get(api_url)
Blockchain Friction
Data Structures
You cannot use HashMaps, complex arrays, or large strings efficiently. Forced to architect "weird" storage patterns to fit EVM constraints.
Delta Equivalent
No Storage Constraints
Use List, Dict, JSON—any data structure your language supports.
Blockchain Friction
MEV & Reentrancy
You must defensively code against transaction ordering attacks (sandwich attacks) and reentrancy. Logic is often convoluted just to prevent exploits.
Delta Equivalent
No MEV or Reentrancy Worries
These attack vectors don't exist. Standard execution model with normal concurrency guarantees.
Blockchain Friction
Indexing Layer
You cannot efficiently query your own data from the contract. You must build a separate "Subgraph" or middleware just to read your own database.
Delta Equivalent
No Indexing Required
Query your data directly with SQL. And or update event logs like any normal app. SELECT * FROM items WHERE owner = 'X'
Blockchain Friction
Immutability (Proxies)
You can't update code. You must use "Proxy Patterns" and manually ensure storage slots don't collide between versions, or corrupt the entire database.
Delta Equivalent
Mutable Execution Logic
Update code like Web2: git push. Security guardrails remain unaffected.
Blockchain Friction
State Migration
If you change a data structure, you cannot run a migration script. Users must often manually migrate their funds from Contract V1 to V2.
Delta Equivalent
Seamless Migrations
Standard database migrations. ALTER TABLE and done in under a minute.
Blockchain Friction
Fork-Based Testing
You cannot reliably mock dependencies. You must set up a "Mainnet Fork" to test your code against actual blockchain state.
Delta Equivalent
No Fork Required
Mock dependencies normally. Standard unit and integration tests with Jest, PyTest, etc.
Blockchain Friction
Incident Response
If a bug is found, you cannot simply "patch" it. You must trigger a "Pause", convene a Multisig council (4/7 humans), and sign a transaction to freeze.
Delta Equivalent
Instant Rollback
Revert to a previous commit in minutes. No multisig, no governance, no waiting.
Blockchain Friction
Third-Party Audits
You cannot ship "MVP" code. You must pay external firms to read every line. Code for 3 months, wait 2 months for audit, fix, and re-audit.
Delta Equivalent
Ship When Ready
Standard CI/CD. No audit cycles blocking your releases.
Blockchain Friction
Formal Verification
For high-value apps, audits aren't enough. You write mathematical specs (Certora, K) to prove code is bug-free—effectively writing code twice.
Delta Equivalent
Standard Testing Only
No formal proofs required. Write tests like you normally would.
Blockchain Friction
Talent Scarcity
Hiring a dev who understands both "Software Engineering" AND "EVM Security" is incredibly hard. You pay a premium and spend months sourcing.
Delta Equivalent
No Specialized Talent Needed
Hire from the massive pool of standard software engineers. No EVM or SVM expertise required.

FAQ

Domains can censor or delay, but they can't steal funds or fake outcomes. Users can always exit to another domain via the base layer. Assets live on the base layer, not inside domains.

We currently support local laws written in Rust.

In two ways:

1. zk-rollups are themselves blockchains and use zk to prove full execution. delta domains prove only specific rules. Business logic runs on a regular server as execution itself does not need to be verifiable.

2. All domains share state via the delta base layer. No bridging needed within delta.

First, note that proving is async and does not impact UX. Settlement happens in the background and the prover time will be in the seconds to minutes, depending on the number of transactions being proven and the complexity of the constraints.

It is! Verifiability in delta's case comes from zk proofs, not decentralization. Users only interact with the decentralized delta base layer if they're being censored by their domain, i.e. for censorship resistance.