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 gap directly affects the customer experience: the customer has already paid, but the operator still cannot see enough to respond.
DeFy was created to close that gap. Holdex worked alongside the founding team to define the product, design the operator experience, and build the system through to production.
The story also began with something we value deeply: a founder coming back. Nick Fitt had previously co-founded Maison QR, a luxury retail product we built together years earlier. When he found a new opportunity in crypto payment operations, he returned to build the next product with us.
Designing around a clear boundary
DeFy began with one firm product decision: it would improve payment visibility without entering the flow of funds. Custody and settlement would remain with the providers operators already trusted, while DeFy would operate as a read-only layer alongside the existing payment stack.
That boundary did more than reduce integration complexity. It focused the product on a specific source of value: identifying an incoming payment sooner and turning that information into a signal an operator could use.
We built EarlyID as the first application of this model. Its role was to detect an incoming transaction as early as the network allowed, pass the information into the operator's systems, and preserve the distinction between an early signal and completed settlement.
DeFy would never move the money. It would make the time spent waiting for it more useful.
The gap between sent and confirmed
After a wallet submits a crypto transaction, the network still needs to confirm it. On networks with a public mempool— the queue of transactions waiting to be processed— monitoring systems can sometimes see that payment before it enters a block and becomes part of the confirmed blockchain record.
EarlyID was designed to use this window. By detecting a relevant transaction in the public mempool, DeFy could tell an operator that a payment was on its way before the usual callback arrived from the payment provider.
However, an early signal is not the same as settlement. We therefore designed the product to make that difference explicit, giving operators useful information sooner without presenting a pending transaction as final.
The opportunity was not simply to see a transaction first. It was to make the time between “sent” and “confirmed” operationally useful.
Where the first assumption met production
The first phase focused on Arbitrum, a faster network built on Ethereum. Arbitrum does not expose pending transactions through a public mempool in the same way Ethereum does, but its fast confirmation times meant the operator could still receive a useful signal close to the moment of payment.
Ethereum appeared to offer a more direct path for the next phase because it has a public mempool. In principle, EarlyID could watch that queue and detect incoming payments before confirmation. Real wallet traffic revealed a more important constraint.
Ethereum wallets submit transactions through RPC providers— the infrastructure that carries a transaction from the wallet to the network. Many commonly used wallets now rely on RPC services with MEV protection, which can route a transaction privately to reduce interference from bots that profit from transaction order.
Private routing protects the customer, but it also means the transaction never appears in the public mempool. An outside monitoring system can only see it once Ethereum includes it in a block. The payment still arrives; what changes is the earliest moment it becomes visible.
This behavior is common enough that public mempool coverage cannot stand in for complete transaction coverage. What began as a question of how to listen earlier therefore became a more important product question: which transaction routes expose an early signal, and how should the system behave when they do not?
Designing for the earliest reliable signal
That discovery sharpened the EarlyID model. Instead of assuming that every transaction follows the same path, DeFy uses the earliest trustworthy signal each path makes available.
When a transaction travels through the public mempool, DeFy can identify it while it is still pending. When a wallet sends it privately, DeFy reports it after the network confirms it. On a faster network such as Arbitrum, confirmation itself may arrive quickly enough to preserve the operator experience.
The product makes these states distinct because they carry different levels of certainty. A pending signal tells an operator that a payment is on its way, while a confirmation shows that the network has processed it. Both can support useful actions, but they should never be treated as the same event.
For supported early-detection flows, at least 95 out of every 100 signals reach the operator in under five seconds. The operational promise is therefore not speed at any cost, but the earliest reliable information the underlying infrastructure can provide.
From one signal to an operations layer
Once EarlyID addressed the first visibility gap, the same transaction data created a broader product opportunity. We designed DeFy to support monitoring, notifications, analytics, reconciliation, and payout workflows from one consistent view of payment activity.
The interface centers on the decisions an operator needs to make: whether a customer has sent a payment, whether it remains pending or has been confirmed, and whether someone needs to investigate. Lower-level blockchain details remain available where they add value, without forcing teams to interpret raw network events during every transaction.
Because DeFy remains separate from custody and settlement, it can sit alongside the operator's existing providers rather than requiring a new payment flow. The technical value begins with earlier data; the product value comes from making that data clear enough to act on.
From premise to production
Holdex worked across product definition, UX, system design, and engineering to take DeFy from its initial premise to a production system used by its first operator in August 2026.
Going live validated the core architecture, but it also exposed conditions a prototype could not fully reproduce: different networks, everyday wallets, protected transaction routes, and the infrastructure connecting them. Because we remained embedded after launch, those discoveries moved directly into the product, shaping clearer transaction states, more precise expectations, and a stronger definition of what operators could safely act on.
This is the distance between proving a mechanism and operating dependable financial infrastructure. The first version demonstrates the opportunity; production reveals the assumptions that must change before the product can earn trust at scale.
DeFy now gives payment teams a clearer answer to two questions that matter in the moment: has the customer sent the money, and what can we safely do next? As networks, wallets, and routing infrastructure continue to evolve, the timing of that answer may change, but the product's responsibility does not: report the state accurately, surface it as early as the infrastructure allows, and remain explicit about its certainty.
Speed opened the opportunity, but trust made it ready for production.
