Secure Escrow

Product landing page

What Inspired Us

We were motivated by a practical observation about payment behaviour. Crypto systems treat finality as the default good, but many real-world payments do not start with certainty. People pay taxes, invoices, medical bills, and utilities after receiving instructions through email, PDFs, or portals that they may not fully trust yet. In that environment, fraud does not need to be technically sophisticated, just fast.

In our earliest brainstorming ,we explored purpose-restricted transfers, where funds could be constrained to specific uses. That was appealing for welfare-style distributions and voucher systems (eg Singapore's CDC). However, it depended heavily on issuer adoption and merchant acceptance patterns that are not yet widespread for on-chain payments. We pivoted toward a problem with immediate relevance: protecting senders at the moment they are most likely to make an irreversible mistake.

The core question became: how can a payment be prepared and committed on-chain, while still giving the sender time to confirm legitimacy before settlement becomes final?

What We Learned

We learned to think about XRPL as a payments protocol that exposes a small set of hardened primitives rather than a general-purpose execution environment. That distinction changes the risk model. On many chains, the main uncertainty is whether custom code behaves correctly under adversarial conditions. On XRPL, the contract surface is intentionally narrow, so the design work shifts toward how to compose primitives to shape incentives and failure modes.

Escrow is one of those primitives. It provides a ledger-enforced lifecycle where funds are locked under explicit constraints. More importantly, escrow on XRPL can be paired with crypto-conditions, which let us represent authority using cryptographic proof rather than trust or business logic.

We implemented a hashlock-style condition. The ledger stores:

[ C = \text{SHA-256}(s) ]

where ( s ) is a secret generated by the sender. Settlement requires a fulfillment that reveals ( s ) such that:

[ \text{SHA-256}(s) = C ]

This gave us a clean separation of concerns. The ledger enforces the rule. The application only decides when to reveal the fulfillment. In other words, we treat settlement as an explicit act of intent rather than an automatic consequence of clicking send.

We also learned that time is not a UX feature, but a security boundary. It only helps if the party you are protecting retains the ability to control the settlement outcome during that window. This forced us to evaluate escrow parameters not as configuration, but as an adversarial game with clear incentives.

How We Built the Project

We built an approval-gated escrow payment flow. A sender initiates a payment that locks funds on XRPL under a crypto-condition and an expiry window. Funds do not move to the recipient unless the sender later submits the correct fulfillment. If that fulfillment is never submitted, the ledger returns funds after expiry by design.

At the user layer, we focused on reducing the probability of sending to the wrong destination in the first place. The frontend validates recipients against a registry of known entities and provides close-match suggestions when an input resembles a verified payee. We treated this as a human factors problem rather than a pure security problem. Most payment mistakes are not complex. They are copy-paste errors, look-alike strings, and rushed decisions.

At the system layer, we used FastAPI to orchestrate escrow creation and approval flows while keeping enforcement on-chain. We persist transaction metadata for observability and demo fidelity, but the safety guarantees do not depend on the database or server being honest. The ledger remains the source of truth for whether funds can move.

This architecture was intentional. We wanted the application to help users make better decisions, but we wanted the XRP Ledger to be the final arbiter of settlement.

Challenges We Faced

The biggest challenge was balancing security with practicality. Any protection mechanism that depends on perfect user behaviour is fragile. We therefore designed around predictable human failure modes. People miss details, they get stressed, and they act quickly. Our goal was to make the safe outcome the default without requiring the user to be an expert.

A second challenge was designing a flow that remains credible for institutional adoption. Public-sector and enterprise payments require deterministic behaviour, clear auditability, and minimal execution risk. That pushed us toward XRPL-native primitives and away from complex programmable logic. It also forced us to be honest about trade-offs. Approval-gated settlement introduces latency relative to instant transfers, but it buys verification time that is valuable in high-stakes contexts.

Finally, we learned to frame the product as infrastructure rather than an app. The defensible value is not a UI screen. The defensible value is a reusable primitive: sender-controlled settlement windows for payments where finality without verification is a liability.

This project changed how we think about payments on-chain. Adoption is not only about faster settlement. It is about making settlement safe enough for real-world workflows that involve verification, accountability, and consequences.