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 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, 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.
