# DeFy

*A read-only intelligence layer that sees deposits before they land*

**Authors:** [John Gist](https://holdex.io/people/john-gist)

---

Crypto payment operations often have a visibility gap between the moment a
customer sends a transaction and the moment a payment provider reports it back
to the operator.
For businesses in iGaming, forex and CFD trading, luxury, and hospitality,
that delay directly affects the customer experience:
the customer has already committed to a payment,
but the operator cannot respond until its existing infrastructure recognizes it.
[DeFy](https://defynet.io/) was created to close that gap,
and Holdex worked with the team as its product
and engineering partner to define the architecture,
shape the operator experience, and build the system through to production.

DeFy began as a founder coming back.
Nick Fitt had co-founded [Maison QR](/works/maison-qr),
a smart-QR layer for luxury retail that Holdex co-built years earlier.
When he saw a new market opportunity in crypto payment operations,
he returned with the product idea and asked us to build it with him.

The core product decision was to give operators earlier visibility into incoming
payments without taking custody of funds or replacing their existing payment
providers.
We built DeFy as a read-only crypto operations intelligence layer
that monitors Ethereum and Arbitrum for incoming USDT, USDC,
and ETH transactions, detecting deposits from the moment they are broadcast
and making that signal available to operator systems at P95 under five seconds.
That early transaction signal became the foundation for the wider platform,
including notifications, analytics, reconciliation, and payout workflows.

## Designing around a clear constraint

The defining constraint came from Nick's brief:
the platform would never touch custody of funds.
Our job was to design the architecture that turned
that constraint into the product's advantage,
keeping DeFy completely separate from custody and settlement.
DeFy does not hold funds, control wallets, process payments,
or replace regulated payment providers; instead,
it observes transaction activity
and passes relevant information into the operator's existing workflows.
We treated this as a product
and architecture requirement rather than a limitation,
because separating observation from money movement allowed us to keep
integrations lightweight, reduce the compliance surface, and focus the system on
transaction intelligence rather than payment processing.

This separation also created the product's main advantage.
Because DeFy does not need to wait
for a settlement provider to complete its own processing cycle
before identifying activity,
it can surface transaction information earlier while leaving custody
and settlement with the infrastructure operators already use.
The result is a product that improves visibility without requiring businesses to
introduce another layer of financial control or restructure their existing
payment stack.

## Building EarlyID

We developed EarlyID as the first application of that architecture.
The system monitors supported deposits at broadcast and identifies them
before confirmation, allowing operator systems to receive
and use transaction information before a downstream payment callback arrives.
The engineering challenge was only part of the work;
we also had to define how the product should represent a transaction
that had been detected but had not yet reached final confirmation.

We designed the experience around a clear distinction between early visibility
and completed settlement.
Operators needed enough information to respond sooner,
but the product could not present an unconfirmed transaction as final.
By structuring the transaction states and workflows around that distinction,
we made the period between broadcast and confirmation operationally useful:
teams could update internal systems, trigger notifications,
and prepare downstream actions
while settlement continued through the existing payment infrastructure.

## Turning transaction data into an operations product

Early detection solved the initial visibility problem,
but the broader product opportunity was to turn
that transaction intelligence into a useful operations layer.
We designed DeFy so that the same data could support monitoring, analytics,
reconciliation, and payout workflows across the platform,
giving operators a consistent view of payment activity rather than forcing them
to interpret raw blockchain events across separate tools.

A significant part of the product work involved deciding how much onchain detail
operators actually needed.
Instead of reproducing the complexity of a blockchain explorer,
we structured the interface around transaction status, timing, exceptions,
and actions, while keeping lower-level blockchain information available
where it added operational value.
This allowed DeFy to sit alongside the existing payment stack
as an intelligence layer,
giving teams a faster and more complete picture of what is happening without
changing how funds are ultimately settled.

## Taking DeFy into production

Holdex worked across product definition, UX, system design,
and engineering through to launch,
taking DeFy from its initial product premise to a production system used by its
first operator in August 2026.
The launch validated the core architecture in a live operational environment
and created the foundation for the next phase of the platform,
which extends the same model to additional chains
and a broader set of operational workflows.

The product continues to follow the principle we established at the start:
improve crypto payment operations by giving teams better information earlier,
while keeping custody, settlement,
and regulated payment infrastructure where they already belong.