The problem VeilEscrow solves

For the demo video, please check the README file in the GitHub repo linked.
2-demo videos

Problem Statement

Freelancing platforms like Upwork solve a basic trust problem between clients and freelancers: the client doesn't want to pay before seeing the work, while the freelancer doesn't want to work without knowing they'll be paid. For fixed-price work, Upwork addresses this by having the client fund a milestone upfront and holding those funds until the freelancer submits the work and the client approves it.

However, this model introduces a centralized intermediary. For example, if a client hires a freelancer for $500, the platform sits between both parties, holds the funds, manages the release process, and handles disputes. The platform also charges service-related fees.

There is a second problem when these interactions move to public blockchains: financial activity becomes highly visible. If a client pays a freelancer 0.5 ETH, the transaction can expose the wallets involved, the amount transferred, and potentially allow anyone to study their broader on-chain financial activity.

Our Solution

VeilEscrow combines the familiar idea of freelance escrow with blockchain-based automation and privacy.

Imagine a client hires a freelancer to build a website for 0.5 ETH.

Instead of sending the money directly to the freelancer:

Client → VeilEscrow Smart Contract → Freelancer

the client deposits the 0.5 ETH into a smart contract. The contract holds the funds and enforces the job's rules:

Create Job → Submit Work → Approve → Release Payment

If the freelancer submits the work and the client approves it, the contract releases the payment automatically according to the predefined rules. If there is a dispute, the funds remain locked while the dispute process takes place.

This removes the need for a traditional platform to manually control the escrowed funds.

But VeilEscrow also addresses the privacy problem.

Alongside the escrow system, we integrate a Railgun-powered private payment module. Users can shield public ETH into private WETH, transfer it privately using zero-knowledge proofs, and later unshield it back to a public address.

So instead of exposing a straightforward public transaction like:

Client wallet → 0.5 ETH → Freelancer wallet

the private payment layer demonstrates how the financial movement can occur without exposing the normal sender-recipient-amount relationship.

In short, VeilEscrow combines two properties that traditional freelance platforms and ordinary public blockchains handle separately:

Escrow: "The money is protected until the agreed conditions are met."
Privacy: "The financial activity does not have to be publicly exposed."

The current hackathon version demonstrates these two systems independently—JobEscrow on Anvil and private payments through Railgun on Sepolia—with the next step being to cryptographically connect private payments to individual escrow jobs.

Challenges I ran into

Challenges Faced
Connecting two very different blockchain systems
The biggest architectural challenge was keeping the freelance escrow logic and private payment system separate while figuring out how they could eventually work together. The escrow contract runs on Anvil, while Railgun operates on Sepolia, creating a clear network and integration boundary.
Designing the escrow state machine
We had to carefully define how a job moves through Created → Submitted → Approved/Disputed → Resolved, while ensuring that only the correct party can perform each action. This included handling edge cases like repeated approvals, unauthorized actions, and disputes raised at different stages.
Building a fair dispute mechanism
Escrow becomes more complicated when the client and freelancer disagree. We implemented a response window, allowed the other party to submit a response, and added an owner-based resolution mechanism. Handling the case where the other party doesn't respond required a separate claim flow.
Integrating Railgun's client-side ZK system
Getting private payments working wasn't simply a normal blockchain transaction. We had to initialize the Railgun WASM engine, synchronize private balances, generate zero-knowledge proofs in the browser, and handle shield, private transfer, and unshield operations.
Managing privacy without losing usability
The private wallets are deliberately ephemeral for the demo. This means their keys cannot simply be persisted like a normal wallet, while the UI still needs to clearly communicate balances, addresses, transaction states, and the risk of losing access after a page reload.
Handling multiple networks in one application
The same frontend operates across Anvil for escrow and Sepolia for Railgun. We therefore needed network-aware UI and safeguards so that users don't accidentally attempt an escrow transaction on Sepolia or a Railgun operation on Anvil.
Understanding what should actually be public vs private
A major design challenge was deciding what the escrow contract should know and what Railgun should hide. The contract needs to know things like the job status and who can approve or resolve it, while the actual payment movement should remain private.
The hardest unresolved challenge: linking private payment to escrow
The current system demonstrates escrow and private payments independently. The difficult next step is proving that a specific private Railgun payment actually funds a specific escrow job, without revealing the payment amount or parties publicly. This is where the commitment/verification architecture becomes necessary.