How a domain broker gets paid without transferring first
The domain sale was done. Terms agreed, buyer confirmed, seller ready. Three parties stood to be paid: the domain owner, the broker who sourced and negotiated the deal, and a sourcing partner who had referred the buyer. The number on the contract was high enough that everyone in the room cared. The number that would actually land in each account, and when, was a different question entirely — one the standard playbook answered badly.
This is the case of a deal that closed cleanly on paper and then entered a friction zone that most brokers know well but rarely discuss in full. Not because anything went wrong. Because the structure of how domain sales typically get paid created a sequence problem that put the broker in an impossible position: collect the money before giving up the asset, or give up the asset and trust that the money follows.
Neither answer was acceptable. This is what that looks like in practice.
The Situation
Marcus — not his real name — runs a boutique domain brokerage. He operates primarily in the premium end of the market, handling acquisitions and sell-side mandates for companies that need category-defining .com names and understand that acquiring one means negotiating with a private owner, not clicking a buy button on a marketplace.
The deal in question was a six-figure acquisition. A growth-stage technology company had authorised him to secure a specific .com that was held by a domain investor. Marcus had spent four weeks in negotiation, working through a sourcing partner — a contact who had a direct relationship with the seller and whose introduction made the negotiation possible. The deal was structured with a commission for Marcus and a referral cut for his partner, both taken from the buyer's total payment.
On paper, this is a clean, professional transaction. Three parties with aligned incentives. A clear price. A defined split. In practice, the payment structure required to execute it was about to create a problem that none of them had fully anticipated when they shook hands.
The Payment Problem in a Domain Transaction
When selling a domain name, the seller wants to ensure they receive the agreed-upon payment before transferring ownership, while the buyer wants to guarantee they receive the domain after making the payment. This is the core tension in every domain sale, and it is not unique to premium transactions. When you sell a domain, the buyer is trusting that you control the name, that you will move it, and that no one else has a claim on it. You are trusting that the buyer can pay and will not reverse that payment after you have already given up the asset. Those two trust gaps point in opposite directions, and they cannot both be closed by good intentions.
The industry's answer to this has always been the same: escrow. Escrow is an arrangement in which a neutral third party temporarily holds money meant for a purchase until specific conditions are met. The money will only be transferred to the intended recipient when the conditions are met. If the conditions are not fulfilled, the money will go back to the buyer. For straightforward two-party deals, this works. The buyer funds the escrow account, the domain transfers, the escrow company confirms receipt and disburses to the seller.
But Marcus's situation had a third party — his sourcing partner — and that changed everything.
Where the Standard Model Breaks
The conventional escrow model assumes two principals: a buyer and a seller. When a broker enters the picture, their commission typically flows through the seller. In sell-side representation, the seller pays from their proceeds. The escrow releases to the seller, and the seller then pays the broker. This is standard. It is also where the trust problem relocates rather than disappears.
In Marcus's deal, the seller was a sophisticated domain investor who had agreed to the transaction price net of broker fees — meaning he expected to receive his amount cleanly, and the broker's split was supposed to come directly from the buyer's payment, not as a deduction from the seller's disbursement. This is a common arrangement in premium brokerage, where the seller refuses to absorb commission costs, and the buyer accepts the total price inclusive of brokerage. Some high-value deals involve split commission structures where both parties contribute.
The problem is structural. Someone has to receive the buyer's total payment first and then redistribute it. Traditional escrow does this sequentially: the escrow process works like this: you deposit funds into the escrow account, the seller initiates the domain transfer, the escrow service verifies the transfer is complete and you have full control, then the funds are released to the seller.
There is no automatic lane for a broker's fee in that sequence. When all payments are completed, the domain is transferred to an account for the buyer and the last payment is made to the seller — and broker, if applicable. "If applicable" is doing significant work in that sentence. The escrow provider's primary obligation is to the buyer and seller. Whether the broker gets paid, and when, and how much, is a side arrangement — usually resolved by the seller passing funds after receipt, or by the broker being manually named in the escrow agreement as an additional recipient.
When the escrow provider pays the seller first and the seller pays the broker second, a new trust gap opens. It is smaller than the original trust gap, but it is real. The broker has now helped orchestrate a transaction worth six figures, has surrendered the asset, and is waiting for a wire that no smart contract enforces and no registry confirms. The seller may be completely trustworthy. Most are. But "most" is not a settlement guarantee.
In Marcus's case, it was worse. Because his deal had a sourcing partner — a third party who was owed a referral split from Marcus's fee — the redistribution chain had three links. Buyer to escrow. Escrow to seller. Seller to Marcus. Marcus to partner. Each link was a manual wire initiated by a human on their own timeline.
The Technical Trap: How the Transfer Window Compounds Everything
To understand why this matters at the operational level, you have to understand the mechanics of how a domain actually changes hands. It is not like sending a file. It is a regulated process with multiple actors and mandatory waiting periods.
Under ICANN's Transfer Policy, once a transfer is requested the losing registrar has up to five calendar days to act. If it explicitly approves or the owner approves on its side, the transfer completes within hours. Best case: hours. Standard case: days. The process requires the current domain owner to unlock the domain, then generate and share an authorization code — the EPP code — which the gaining registrar uses to validate and initiate the move.
The authorization code, also called the auth code or EPP code, is the credential the gaining registrar needs to prove the transfer is authorised. An invalid, expired, or missing code is one of the leading reasons a transfer never starts. Beyond that, EPP codes don't last forever. Expiration windows vary by domain extension and registrar. Some codes remain valid for 30 days or more, while others expire in as little as 24 hours. If you request a code but don't initiate the transfer promptly, you may need to generate a new one.
This is the technical environment Marcus's deal had to move through. The seller would not initiate any of these steps — would not unlock the domain, would not generate the transfer code — until confirmed payment. The buyer's escrow was funded, but escrow confirmation took time. The escrow provider reviewed the transaction, confirmed cleared funds, then instructed the seller to begin the transfer. Only at that point did the seller act.
A transfer moves through five stages: preparation on day zero, the transfer request, the losing registrar's authorization window of up to five days, completion at the gaining registrar, and DNS propagation as a tail of up to 48 hours. Add to that the clearing time for the buyer's wire into escrow — which can itself take several business days, particularly in cross-border transactions — and a deal that closed on a Monday might not result in confirmed domain ownership until the following week.
Wire transfers can be recalled in some windows. Credit card payments can be charged back for months. A buyer with no bad intent can still trigger a reversal because their bank flagged the transaction, or their accounting team did not recognize the charge. The escrow provider knows this. They wait for cleared funds before instructing the transfer. That is the right call. It also means the whole clock starts later than the buyer assumes.
The Stakes
By the time Marcus's deal was in the transfer window, the timeline was already stretched. The buyer's finance team had processed the wire on a Thursday. It cleared the following Tuesday — a four-business-day window, partly because of correspondent banking routing on an international transfer. The escrow provider confirmed on Wednesday morning and instructed the seller to initiate. The seller unlocked the domain and provided the EPP code the same day.
The gaining registrar confirmed receipt of the transfer request. The five-day ICANN window began. The worst-case timeline for a clean transfer is five days — and that's only if the old registrar sits on its hands the entire time. The best case is minutes. In this case, the seller had already approved on his side. The transfer completed in under 24 hours. The buyer confirmed receipt. The escrow released funds.
Then Marcus waited.
The seller received his disbursement that afternoon. He had committed to wiring Marcus's commission the same day. The wire didn't arrive until Friday — three days later. No fraud, no bad faith. The seller's bank had a daily outbound wire limit, and his accounting team initiated the payment from the wrong account, triggering an internal compliance review. Standard banking friction. The money arrived clean.
Marcus then wired his sourcing partner. Another two days.
From deal closure to the sourcing partner receiving his portion: eleven days. The deal had closed in under a week. The payment distribution took nearly double that time, and every day of that tail was a day in which Marcus was exposed. Not dramatically. Not in a way that made headlines. But in a way that every working broker recognises: he had delivered the asset and was waiting on a manual chain to close behind him.
Domain transactions involve multiple risks: paying for a domain you never receive, transferring ownership before receiving payment, disputes over domain history or trademark issues, and technical problems during transfer. The industry literature focuses on the buyer's risk and the seller's risk. The broker's risk — the unsecured gap between deal completion and commission receipt, amplified when multiple parties are owed splits — is less discussed and just as real.
Why the Standard Workarounds Don't Fully Solve It
The obvious answer is to name every payee in the escrow agreement and have the escrow provider distribute to all of them simultaneously. Some escrow platforms support this. The catch is that it requires all parties to agree on the split before the escrow is opened, adds administrative overhead to the escrow provider's process, and — crucially — still routes through the escrow provider's own timeline for manual disbursement. Escrow.com sends the buyer and seller (and broker, if applicable) the domain holding agreement and asks all parties to review, sign, and return. That signature round adds time. With a sourcing partner who was not formally party to the escrow agreement, the workaround collapses.
Another common approach is for the broker to hold the EPP code — to insert themselves into the transfer process as a gatekeeper who releases the code only after personal confirmation of payment. This is a leverage play rather than a structural fix. It creates its own trust problem in reverse: the seller won't cooperate with the transfer until he receives the funds; the broker is holding a technical key that doesn't belong to him; the buyer is now waiting on a chain of manual confirmations from three separate humans. Timelines vary a lot. Some deals close in a few days when the current owner is responsive and motivated, while others can take weeks or months, especially if the broker needs to track down an unresponsive owner, negotiate price, or coordinate escrow and DNS transfer across registrars.
A third approach — common in the real estate world — is for the broker to extract a formal written undertaking from the seller to pay commission from proceeds, with the undertaking executed at the same time as the sale agreement. This helps in a dispute. It does not accelerate payment. It does not remove the dependency on the seller's banking infrastructure. And in a multi-party deal where the sourcing partner needs their slice, it adds another layer of paperwork without solving the timing problem.
None of these workarounds address the root issue: in a deal with multiple payees, someone has to receive the full amount and manually redistribute it. Until payment distribution can be made simultaneous rather than sequential, there will always be a gap in which the broker has performed and not yet been paid.
What a Payment-First Structure Actually Looks Like
The question Marcus was left asking after this deal was whether there was a structure in which no one had to wait on anyone else — in which the moment the buyer's payment confirmed, every party received their portion in the same instant, with no redistribution step, no bank holding period, no manual wire.
The answer is that this kind of structure does exist, and it operates differently from traditional escrow at a fundamental level. Rather than routing the full payment to a single recipient who then redistributes, the payment is split and distributed at the contract layer — before any human bank account is involved in the routing decision.
Shaka is built for exactly this scenario. A deal creator defines the payment split — seller's net, broker's commission, sourcing partner's referral fee — and generates a payment link. The buyer pays once. The smart contract calculates and distributes to every named recipient simultaneously. The domain owner receives his amount. Marcus receives his commission. The sourcing partner receives his referral fee. All three disbursements happen in the same transaction, the moment the payment confirms. No one waits on anyone. No one holds the money and passes it on. No redistribution step exists to get delayed.
The Trust Architecture That Changes
What makes this structurally different from the escrow-then-wire model is not just speed. It is the elimination of discretionary human steps in the payment chain. Every delay Marcus experienced — the seller's outbound wire limit, the accounting team's wrong account, the two days to his sourcing partner — was a delay introduced by human banking infrastructure operating on its own timeline. The payment routing decision was made by humans after the fact. In a contract-layer distribution, the routing decision is made at deal creation and executed automatically at payment confirmation. There is no post-payment discretion. There is no redistribution.
There is a second reason to think carefully about payment mechanics, and it has nothing to do with fraud. It has to do with payment reversals. In a standard escrow, the escrow provider waits for cleared funds before instructing the transfer. That wait is protection. In an onchain payment, confirmation is finality. The payment doesn't pend. It settles.
For a broker managing multiple deals simultaneously — each with a different commission structure, different split parties, different escrow timelines — the operational gain is significant. The trust problem that is currently solved by relationships, written undertakings, and careful counterparty selection is instead solved structurally. The deal creator encodes the split. The contract executes it. The broker's commission is not a courtesy from the seller. It is a term of the payment.
What This Means for Brokers Operating at This Level
A $100,000 domain acquisition gone wrong could result in total loss of funds, legal disputes, or acquisition of a domain with undisclosed liabilities. That is the buyer's risk. The broker's version of the same sentence is less dramatic but just as structural: a successful deal can leave the broker in an unsecured position for days while banking infrastructure catches up to an agreement that is already legally closed.
Premium domain brokerage operates on reputation and on the quality of deals closed. A broker who cannot reliably control when they get paid is a broker who is absorbing operational risk on behalf of other people's transactions. Professional brokers have seen every possible problem and know how to prevent them. The next evolution in that expertise is building transactions where the payment structure is as tight as the negotiation — where the commission is not a gentleman's agreement to be honoured after the fact, but a parameter encoded at deal creation and enforced at settlement.
Marcus's deal resolved fine. It almost always does. But "almost always" is a phrase that describes a risk, not the absence of one. The eleven-day tail between deal close and final distribution was eleven days in which the trust underpinning a successful transaction was extended past its useful life. The asset was gone. The buyer was happy. The money was in transit. And no mechanism existed to make it arrive faster or guarantee it would arrive at all.
That is the problem a payment-first structure solves — not by making counterparties more trustworthy, but by making their trustworthiness irrelevant to the mechanics of getting paid.
