# How to split a domain sale three ways among a group

When a domain is co-owned, brokered, and sold, the single payment arriving at close has to reach three separate parties correctly, instantly, and with finality — here is exactly how that works.

---


A six-figure domain sale is, on the surface, a clean transaction: a buyer agrees to a price, funds are confirmed through a settlement process, the domain is pushed to a new registrar account, and everyone goes home. In practice, the moment a domain has more than one legitimate economic claim against its proceeds — a co-owner, a broker, a finder, an investor who provided acquisition capital — the "clean transaction" fractures into a series of manual disbursements, sequential wires, and an uncomfortable period of trust.

That period of trust is where deals go sideways. Not because people are dishonest, but because the settlement infrastructure available to most domain professionals was designed to protect a single seller from a single buyer. It was not designed to simultaneously honor three, four, or five separate claims on the same payment. The gap between what the contract says and what actually happens at closing is exactly where this article lives.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>$150,000</b><span>sale price of the worked example, one payment from one buyer</span></div>
<div><b>50 / 30 / 20</b><span>percentage shares of the registrant, the silent co-investor and the sell-side broker</span></div>
<div><b>5–10 days</b><span>business days a typical domain transfer takes, before any downstream wire</span></div>
</div>
<p class="fig-src">Figures from the worked example and the closing process described in this article.</p>
</figure>

## Why three-way splits are more common than they look

Most people picture a domain sale as a bilateral event. One owner, one buyer. But the market does not actually look like that, especially at the premium end. Consider how a single high-value domain can accumulate multiple legitimate claims before the sale date:

**Scenario 1 — Co-investment.** Two investors pool capital to buy a premium domain speculatively. Neither has the resources alone. They document a 60/40 ownership split in a co-ownership agreement and hold the domain for two years while they field offers. When a buyer finally emerges, the sale proceeds need to flow to two separate parties at two separate percentages — not to one, and certainly not one-at-a-time.

**Scenario 2 — The brokered sale with a finder.** A domain sits dormant in a portfolio. A sell-side broker is engaged under a formal brokerage agreement. Many brokers will require a domain owner to pay a commission if a deal is closed between a domain owner and a prospect that was initially contacted by the broker. Now add a finder who made the first introduction between buyer and seller before the broker was formally engaged. The seller agreed to a finder's fee in writing. The sale closes, and three parties have a contractual claim: the seller, the broker, the finder.

**Scenario 3 — The portfolio investor backstory.** A domain developer built a category-defining domain, but used outside capital to fund the registration and holding costs. The investor holds a promissory note with a revenue share right triggered on sale. The developer is the named registrant and the one coordinating the sale. When the wire arrives, they owe a slice to an investor who may be sitting in a different country, banking at a different institution.

These are not edge cases. Most domain brokers earn their income through commissions, meaning they receive a percentage of the sale price when they successfully match a buyer with a seller. Stack a co-ownership arrangement on top of commission-based brokerage, and you are now structurally guaranteed to have a multi-party disbursement problem at every close.

## The standard closing process and where it breaks

The industry standard is to close through a licensed third-party escrow provider. The buyer wires funds to escrow, escrow confirms receipt, then the seller initiates the transfer. Escrow only releases funds after the buyer confirms the domain is in their account.

This is sound process. Escrow protects the buyer from releasing payment before the domain arrives and protects the seller from releasing the domain before payment clears. The professional who manages that escrow — whether that is an attorney, an escrow officer, or a specialist domain escrow service — is performing a genuinely important function: they are the neutral third party confirming conditions are met before any party acts.

The actual transfer process, once terms are agreed upon, usually takes 5–10 business days. This includes time for escrow payment processing, domain unlock procedures, authorization code transfers, and DNS propagation.

But notice what escrow is designed to do: hold funds and release them to **one** designated party upon condition satisfaction. The moment the proceeds need to go to three parties, escrow has fulfilled its mandate the instant it releases the full sum to one of them. The multi-party distribution problem now belongs to whoever received those funds first.

What typically happens next:

1. The escrow service releases the full sale amount to the designated seller (or the listing broker, depending on the agreement structure).
2. The recipient is now responsible for calculating and distributing shares to the co-owner, the broker, and the finder — each potentially via a separate wire, each with its own banking delay, each with its own international transfer friction.
3. The parties who have not yet received their money are in a position of trust, waiting for someone else to remember them, calculate correctly, and act.

Adding sequential wires downstream of that 5–10 business day window can extend the time before every party is whole by several more days — or longer if there are international correspondent banking delays.

This is not an indictment of any specific professional or platform. It is a structural flaw in applying a bilateral tool to a multilateral problem.

## The specific mechanics of a three-way split

Let's work through a concrete example and name the numbers.

**The deal:** A premium single-word .com sells for **$150,000 USD (approximately $235,000 AUD)**. The parties and their agreed shares are:

- **Co-owner A (the registrant):** 50%
- **Co-owner B (the silent co-investor):** 30%
- **Sell-side broker:** 20% (commission on gross proceeds)

The broker's brokerage agreement was signed before the sale. The commission-only model — the most common approach — involves a percentage of the final sale price, typically ranging from 10–30%. The broker earns only when successfully closing the deal, which aligns their incentives with the seller's — they are motivated to negotiate the best possible price while still completing the transaction.

<figure class="fig">
<figcaption><b>Under a traditional close</b><span>$150,000 sale, shares of 50%, 30% and 20%</span></figcaption>
<ol class="steps">
<li><b>Escrow release</b>Escrow releases $150,000 to Co-owner A (the registrant of record).</li>
<li><b>Wire to the co-investor</b>Co-owner A wires $45,000 to Co-owner B.</li>
<li><b>Wire to the broker</b>Co-owner A wires $30,000 to the broker.</li>
<li><b>Remainder</b>Co-owner A retains $75,000 as their share.</li>
</ol>
</figure>

At no point in steps two and three does Co-owner B or the broker have certainty. They have a contract and a relationship. The contract is only as enforceable as the legal system is accessible. The relationship is only as reliable as the person on the other end of the phone.

Now consider the complications that regularly appear in practice:

**Currency mismatch.** Co-owner B is based in Australia. The sale closes in USD. Co-owner A must now wire AUD-equivalent funds, triggering a foreign exchange conversion. The amount received depends on the exchange rate at the moment of transfer, which may differ from what was calculated at signing.

**Banking delays.** Co-owner A's bank applies a compliance review to the outbound international wire. The $45,000 to Co-owner B is held pending documentation. Co-owner B, who has already spent two years waiting for this domain to sell, now waits another week to see any proceeds.

**Accounting disagreement.** The broker argues their commission should be calculated on gross proceeds before any co-ownership distribution. Co-owner A believes the broker's commission should apply only to their share. The numbers are not dramatically different — the difference might be $6,000 — but the disagreement is real, and it is happening after the close, when the leverage has evaporated.

**The three-into-one-into-three problem.** All of these complications stem from the same structural issue: one incoming payment was received by one party, who must then redistribute it. Any error, delay, or dispute at the redistribution stage affects every other party's receipt.

## What the contract can do — and where it stops

Jointly owned intellectual property in joint ventures requires clear agreements on ownership, licensing, and enforcement to prevent future disputes. The structure of a joint venture intellectual property arrangement determines whether rights are shared, assigned to the joint entity, or licensed between participants. Collaboration without clear IP terms often leads to disagreements over usage rights, profit-sharing, and commercialization.

Domains are a form of digital intellectual property, and the same structural observation applies. A co-ownership agreement can specify the percentage split with precision. A brokerage agreement can define how the commission is calculated and whether it is drawn from gross proceeds or net. A finder's fee letter can set out the triggering conditions and the amount. The agreement should name the profit split, decision rights, capital contributions, exit steps, dispute process, and what happens to intellectual property. Trusted parties still need all of that in writing.

Good contract drafting resolves the "who gets what" question in advance. It does not resolve the "who moves the money" question at the moment of closing, and it does not resolve the "when does each party actually receive their share" question that follows.

A licensed attorney can draft a sales contract that is legally binding for buyer and seller. If any party breaks the contract, they can be sued for damages in court. The attorney can also act as an escrow organization and only transfer money from the buyer to the seller if the terms of the contract are fulfilled. An attorney is crucial in selling domain names to ensure all legal aspects are covered and the transaction is secure.

An attorney overseeing the closing can theoretically direct multi-party disbursements at the time of settlement. This is standard practice in real estate closings. When a settlement agent acts as an escrow agent in a fiduciary capacity, their role is to ensure that the purchaser receives clear title to the property they are purchasing and the seller receives the proceeds from the sale. In high-value domain sales, particularly those structured around multi-party ownership arrangements, this kind of supervised closing is exactly the right approach — and is increasingly being adopted by professional domain brokers who want clean, documented disbursements.

But even a skilled settlement attorney using traditional wire infrastructure is constrained by the same banking rails. Each outbound wire is a separate instruction. Each wire takes time. Each wire can be delayed or recalled. The outcome — multiple parties eventually receiving their correct share — may be exactly right, while the timing and certainty of that outcome remain imperfect.

## The structural case for onchain payment routing

This is where the architecture of the problem points toward a specific solution. The core issue is that the traditional settlement stack was built for sequential, bilateral disbursements. The practical need is for simultaneous, multilateral disbursement — one incoming payment that splits instantly into its correct components at the moment of receipt.

That is precisely what a payment router like [shaka.deal](https://shaka.deal) is built to do. Shaka is a non-custodial onchain payment router on Ethereum. It does not hold funds. It routes them. A settlement is configured with preset wallet addresses and preset percentage shares. When the buyer's payment arrives, the router distributes the total amount simultaneously to every party — Co-owner A, Co-owner B, the broker — in one transaction, at the shares agreed in the contract, with finality.

The practical implications for a domain closing are significant:

**Preset shares remove the redistribution problem entirely.** Rather than releasing the full sum to one party who must then manually redistribute it, the router executes the pre-agreed split atomically. There is no intermediary holding period during which one party is holding another party's money.

**Simultaneous payout means all parties are settled at the same moment.** Co-owner A does not receive their $75,000 USD three days before Co-owner B receives their $45,000 AUD equivalent. All parties receive their allocations in the same transaction. The deal is closed for every party at the same instant.

**Onchain finality is definitional, not provisional.** Settlement finality is the point at which a blockchain transaction becomes irreversible. After finality, the payment cannot be reorganized out of history, double-spent, or unwound by a chain reorg. On a proof-of-stake network like Ethereum, a transaction becomes technically final when it is incorporated into a validated block and subsequently confirmed. Although consensus finality can be formally probabilistic depending on the consensus mechanism used, the economic cost of reversing even a handful of confirmations makes rollback practically impossible.

This matters for domain professionals specifically because payment reversals and disputes over received funds are a real category of post-closing friction. When a traditional wire is reversed — whether by bank error, compliance review, or dispute — the seller may have already pushed the domain transfer. With onchain finality, once the transaction is confirmed and settled, the payment history is public, permanent, and not subject to reversal by any third party's back-office decision.

**The routing contract is transparent.** Every party to the deal can verify, before the payment is made, that the routing addresses and percentages are correctly configured. There is no information asymmetry. Co-owner B does not have to trust Co-owner A's arithmetic. The broker does not have to wait to find out whether their commission was correctly calculated. The split is visible, auditable, and already correct at the moment of payment.

## How this fits into professional closing practice

<aside class="callout">
<span class="callout-label">Scope</span>
<h4>Routing does not replace the closing professional</h4>
<p>It is worth being explicit: shaka.deal does not replace the settlement attorney, the escrow officer, or the domain broker. It replaces the sequential wire instructions that those professionals would otherwise have to manage manually after the primary escrow condition is satisfied.</p>
</aside>

The professional's role in a domain closing — verifying ownership, confirming the domain transfer is properly executed, ensuring the contract conditions are satisfied, coordinating between registrars — remains exactly what it always was. The process typically follows six stages: initial consultation and goal-setting, comprehensive valuation and strategy development, discreet owner outreach, structured negotiation with clear leverage points, contract and escrow coordination, and final transfer with post-sale support. Shaka slots in at the disbursement step of that final stage, after the settlement conditions have been met and confirmed by the professional overseeing the close.

The routing addresses for each party's share can be embedded in a closing instruction sheet alongside the payment terms. The settlement agent confirms that the buyer has funded correctly, confirms the domain transfer is in motion, and instructs the buyer — or the escrow service — to release the payment to the Shaka routing address. At that point, the distribution is automatic, simultaneous, and final. The settlement agent has a clean record of every disbursement in a single transaction hash.

For brokers operating in the premium segment, this is a meaningful operational upgrade. In buy-side representation, the buyer usually covers the commission. In sell-side representation, the seller pays from their proceeds. Some high-value deals involve split commission structures where both parties contribute. Whatever the commission structure, the broker can configure their payment address as one of the routing destinations and receive their allocation in the same transaction as the seller. They do not wait for the seller to remember them. They do not have to follow up with a wire request. The routing is already in the agreement.

## Walking through the routing configuration

To make this concrete, here is how a three-way routing configuration would look for the $150,000 USD (approximately $235,000 AUD) example from earlier:

| Party | Role | Share | Amount |
|---|---|---|---|
| Co-owner A | Registrant / Lead seller | 50% | $75,000 USD |
| Co-owner B | Silent co-investor | 30% | $45,000 USD |
| Sell-side broker | Commission | 20% | $30,000 USD |

Before the close, all three parties confirm their wallet addresses. The routing configuration is built at shaka.deal: one destination address per party, percentage shares summing to 100%, visible and verifiable by everyone. The configuration is shared with the settlement attorney or escrow officer as part of the closing instruction package.

At close, the buyer sends a single payment — in a supported stablecoin — to the configured Shaka routing address. The router immediately distributes $75,000 to Co-owner A's wallet, $45,000 to Co-owner B's wallet, and $30,000 to the broker's wallet. One transaction. Three simultaneous settlements.

There is no period during which Co-owner A is holding Co-owner B's money. There is no window during which the broker is owed money but has not yet received it. There is no arithmetic to verify after the fact, because the arithmetic is embedded in the routing configuration that all parties reviewed before the payment was made.

## What brokers and settlement professionals should put in the agreement

If you are a domain broker, settlement attorney, or escrow officer preparing a closing package for a multi-party domain sale, there are a handful of things to specify clearly in the closing documentation in order to use routing cleanly:

**Pre-agreed wallet addresses.** Each party provides their wallet address in writing as part of the closing instruction sheet. This is no different from providing a bank account number for wire transfer. Treat it with the same formality.

**Gross versus net commission base.** Specify in the brokerage agreement whether the commission percentage is applied to the gross sale price or to net proceeds after certain deductions. Since the routing configuration applies percentages to the incoming total, the percentages need to reflect the agreement correctly. If the broker earns 20% of gross, their share is 20 points out of 100. If they earn 20% of net after a specific deduction, the parties need to agree on the adjusted split before configuring the route.

**Currency and denomination.** Shaka.deal routes payments in stablecoins on Ethereum. The purchase agreement should specify that payment is denominated in the agreed currency equivalent and that the buyer will fund in the specified token. For international deals with parties holding USD and AUD, stablecoin-denominated payment removes the exchange-rate uncertainty at the point of disbursement.

**The routing address as a closing deliverable.** Add the Shaka routing address to the closing checklist alongside the domain push confirmation, the signed purchase agreement, and the escrow release. It is a deliverable, not an afterthought.

## The broader principle: matching the tool to the structure

For federal income tax purposes, an unincorporated joint venture or other contractual or co-ownership arrangement under which several participants conduct a business or investment activity and split the profits is generally treated as a partnership. Whether or not the parties formalize their co-ownership as a legal entity, the economic reality is that of a group with shared proceeds. Groups with shared proceeds need tools that distribute simultaneously — not tools that release to one party and trust the rest to the process.

Domain transactions in the premium segment have grown substantially more complex over the past decade. Domains now carry co-investment structures, revenue share rights, holdback provisions, broker commissions, and finder's fee obligations — often in the same deal. Unclear terms lead to disagreements, and the same principle applies to payment: if the distribution mechanics are not locked in before the money arrives, the post-close period becomes a negotiation under conditions of maximum imbalance — one party already has the money, and everyone else is asking for theirs.

Onchain payment routing is not a workaround for this problem. It is the correct architectural response to a structural limitation in sequential bilateral settlement systems. One incoming payment, preset shares, simultaneous distribution, on-chain finality. That is the mechanic the contract describes. That is what the parties expect. That is what shaka.deal executes.

## Closing summary

Three-way domain sale distributions are not unusual. They are the natural result of how premium domains are acquired, held, and sold — through capital arrangements, brokerage relationships, and finder networks that each carry legitimate economic claims. The problem is not the number of parties. The problem is applying a bilateral settlement tool to a multilateral payment obligation.

Professional closing agents — brokers, settlement attorneys, escrow officers — already do the hard work of verifying conditions, confirming transfers, and protecting both buyer and seller through the close. The disbursement step is the final operational challenge, and it is the one most exposed to human error, banking delay, and trust friction when there are multiple recipients.

Configuring the distribution in advance through a non-custodial onchain router like shaka.deal moves the split from a post-close discretionary action to a pre-agreed, automatically executed, publicly verifiable transaction. Every party sees what they will receive before the payment is made. Every party receives it at the same moment. No one waits. No one follows up. The deal is closed — completely closed — in one transaction.

That is what certainty looks like. And for professionals who close domain deals for a living, certainty is the product.