The Problem Nobody Solved

Smart contracts can do almost anything with crypto. They can swap tokens, provide liquidity, manage treasuries, execute complex financial derivatives. But they can’t do one simple thing: pay your landlord.

The cryptocurrency ecosystem remains fundamentally isolated from traditional financial rails. Autonomous agents are even more constrained - an AI can manage a million dollar portfolio on-chain, but can’t order you a pizza.

Previous attempts at bridging this gap all hit the same wall: centralized intermediaries. Offramps require KYC. Fiat bridges require trust. Every solution reintroduced the counterparty risk that crypto was supposed to eliminate.

We asked: what if you could make fiat payments trustless?

The Insight: Asymmetric Information Games

The clever part of zkRail isn’t the ZK proofs. It’s the game theory.

Here’s the core insight: in a fiat payment, both parties eventually have access to the same information. The payer knows they sent money. The recipient knows they received it. Banks keep records. Banking APIs expose this data.

The question becomes: how do you incentivize honest behavior before you can verify it?

The Protocol

Actors

Three parties participate in zkRail:

Takers want to convert crypto to fiat payments. They lock tokens in a vault and specify: destination account, amount, acceptable slippage.

Solvers are the liquidity providers. They have fiat in bank accounts and want crypto. They compete to fulfill payment intents.

Verifiers generate ZK proofs from banking API data when disputes arise.

The Flow

1. Intent submission: Taker locks 150% collateral in the vault, posts payment intent specifying destination and amount.

2. Solver commitment: Solvers race to commit via EIP-712 signatures. Winner gets exclusive right to fulfill the intent. They post a bond.

3. Fiat execution: Solver sends the actual fiat payment through traditional rails (UPI, SEPA, ACH, whatever).

4. Optimistic settlement: After timeout, if no dispute, solver claims the locked tokens. Done.

5. Dispute resolution: If either party claims fraud, verifiers generate ZK proofs from banking API data. Proofs settle the dispute on-chain.

Why 150% Collateral?

This is where it gets clever.

The taker overcollateralizes because they might lie. If a taker claims they never received payment, but the solver can prove they sent it, the solver claims the entire 150%. That’s a 50% profit on top of the payment amount.

This creates strong incentive alignment:

• Honest takers never lose money (they get exactly what they asked for)
• Dishonest takers lose 50% of their collateral
• Solvers are incentivized to serve honest takers (guaranteed profit)
• Solvers are incentivized to catch dishonest takers (bonus profit)

The Solver Bond

Solvers also post bonds, but the mechanics are different.

A solver bond isn’t locked per-transaction. It’s a reputation stake. High-reputation solvers with large bonds can take larger transactions. They earn fees from successful settlements.

If a solver takes the crypto but never sends fiat, the taker disputes. The verifier proves non-payment, and the solver loses their bond. The taker is made whole from the bond plus receives compensation.

The key insight: solver bonds need to be larger than the maximum transaction they can take. This makes fraud unprofitable at any scale.

Why ZK?

You might wonder: why zero-knowledge proofs? Can’t you just submit banking data directly?

Three reasons:

Privacy: Banking data contains sensitive information. ZK proofs prove payment happened without revealing account numbers, balances, or transaction histories.

Standardization: Different banking APIs return different data formats. ZK circuits normalize this into a standard proof format the contract can verify.

Fraud prevention: Raw API data can be forged. ZK proofs over signed banking API responses can’t be.

The proofs verify: “This payment of X amount was sent to account Y at time Z, and the banking API cryptographically attested to this.”

The Eigenlayer Connection

We use Eigenlayer for the intent aggregation layer. Here’s why:

Payment intents need to be ordered and matched with solvers. This is a sequencing problem. Rather than running our own consensus, we restake on Eigenlayer’s economic security.

The aggregator receives intents, batches them, and posts commitments on-chain. If the aggregator misbehaves (censors intents, reorders unfairly), they get slashed.

This gives us decentralized intent aggregation without running our own validator set.

The MEV Opportunity

Here’s something we didn’t fully appreciate until building it: payment routing has MEV.

Solvers compete on price. But they also compete on speed, reliability, and geographic coverage. A solver with accounts in multiple countries can route payments more efficiently.

Cross-border payments especially: the solver who can route USD→EUR→INR with minimal hops captures value. This creates a natural marketplace for payment routing optimization.

Eventually, we expect sophisticated solvers to emerge who specialize in specific corridors, run their own liquidity pools, and capture routing MEV.

What This Enables

Autonomous Agent Payments

An AI agent with a crypto wallet can now pay for real-world services. No bank account. No KYC (on the agent side). Just lock tokens, submit intent, receive service.

This is the primitive that makes autonomous economic agents actually autonomous.

Programmable Fiat

Smart contracts can now include fiat payments in their logic. Escrow that releases on fiat confirmation. DAOs that pay contractors directly. Prediction markets that settle in fiat.

The gap between “on-chain” and “off-chain” economics narrows significantly.

Privacy-Preserving Offramps

Current offramps require extensive KYC and create permanent records linking on-chain and off-chain identities. zkRail preserves privacy: the solver knows the destination, but the proof doesn’t reveal the taker’s identity.

The Hackathon Build

We built this in 36 hours at ETHIndia 2024. The scope was insane:

• Solidity contracts for the vault, intent aggregation, and dispute resolution
• ZK circuits for banking API proof verification
• Integration with India’s Account Aggregator framework
• Natural language interface via GPT-4 for “pay 5000 rupees to this UPI”
• Solver matching engine
• Frontend demo

The contracts are rough. The circuits are proof-of-concept. But the core protocol works.

We won because the judges understood: this is a new primitive. Not an incremental improvement on existing infrastructure, but a fundamentally new capability.

What’s Next

The hackathon version works but isn’t production-ready. Key areas for development:

Multi-region support: Account Aggregator works in India. PSD2 in Europe. Plaid in the US. Each needs custom ZK circuits.

Solver marketplace: Currently basic matching. Needs reputation systems, bonding curves, slashing conditions.

Intent expressiveness: Beyond simple payments to recurring transfers, conditional payments, multi-party settlements.

Formal verification: The game theory needs rigorous analysis. Are there attack vectors we haven’t considered?

The protocol design is solid. Now it needs engineering.

The Bigger Vision

zkRail is one primitive in a larger vision of autonomous finance.

Imagine AI agents that earn, spend, save, and invest. That negotiate contracts, pay for compute, hire other agents. An economy of machines that transacts with humans and with each other.

This requires trustless interfaces between on-chain and off-chain systems. zkRail is the fiat interface. Others will build the compute interface, the legal interface, the physical world interface.

We’re building the infrastructure for a post-human economy. That sounds grandiose for a hackathon project, but every big thing starts small.

The code is rough. The vision is clear.