In this article
Payment diversion is the single most financially destructive moment in a deal — the point where funds that should flow to the right parties land somewhere else entirely, permanently and without recourse. Brokers, closing attorneys, escrow agents, and advisors sit at the center of these transactions, and that positioning makes them — and their clients — the primary targets. The attack is almost never technical in the sense of breaking encryption or cracking a blockchain; it is operational. The destination address gets swapped. That single substitution routes everything to the wrong place. Understanding exactly how that swap happens, why it works so reliably, and what pre-verified, preset recipient addresses do to stop it is what this article is about.
Figures cited in this article: Carnegie Mellon research on address poisoning, and a documented clipboard-hijacking variant.
What payment diversion actually looks like in practice
Payment diversion in real property and commercial transactions does not require a sophisticated exploit. These crimes often begin when perpetrators weaponize open-source information on property owners and public records, then send targeted, timely emails to someone involved in a deal — typically a real estate agent, attorney, title agent, or buyer. The attackers are patient. They hack into email accounts, monitor the progress of the transaction, and wait for precisely the right moment when the transfer of funds is necessary for the closing.
The interception itself is elegant in its simplicity. Lenders and brokers send buyers wiring instructions directing them where to transfer closing funds, and if a hacker has access to any of those email accounts, they have what they need to intercept those instructions and replace them with their own. A common variation involves last-minute changes to wiring instructions sent just before closing — a message claiming that an unforeseen complication has arisen, or that the original account was compromised and funds must be sent to a new one immediately.
The numbers confirm the scale of the problem. Real estate fraud alone accounted for 12,368 complaints and $275.1 million in losses in a single year; business email compromise — a scheme frequently targeting home closings and wire transfers — ranked second in total losses at $3.04 billion across 24,768 complaints. Those are the reported figures. Industry professionals widely acknowledge that a substantial portion of incidents go unreported because the professional whose email was compromised faces reputational and legal exposure.
The fraud survives because of one structural vulnerability: the destination address — whether a bank account and routing number in a wire transfer, or a wallet address in an onchain payment — is transmitted through a communication channel that can be intercepted and modified. The fix to that vulnerability is not to communicate better. It is to remove the destination from the communication channel altogether.
The mechanics of address substitution
To stop payment diversion cold, you need to understand the precise mechanism that enables it — because the countermeasure is a direct structural response to that mechanism.
In traditional wire-based transactions
The standard wire transfer closing workflow passes instructions through email or document. A person involved in the transaction, such as an attorney or realtor, has their email account compromised by malware. Unbeknownst to the professional, the fraudster can now monitor emails to look for upcoming transactions. Just as a closing date approaches, the fraudster uses the compromised account to send a legitimate-looking message to the buyer. These sophisticated fraudulent emails mimic the real person's identity using company logos and email addresses that are very close but off by a letter or number.
The buyer acts on what they believe are verified instructions from a trusted professional. In one documented case, a couple signed a contract and wired their $91,500 payment to an account number emailed to them by their real estate attorney. Two days later, when they arrived at closing and handed over their proof of transfer, the seller's representative said: "That's not our account." By the time everyone understood what had happened, it was too late to reverse the transfer. All of their savings, and money they had borrowed, was gone.
Losses from these scams are typically not covered or reimbursed by the bank. Since the wires go overseas, it is nearly impossible for victims to recover their money.
In onchain transactions: address poisoning and clipboard hijacking
Crypto wallet addresses introduce a different — and in some ways more insidious — attack surface. A wallet address is a long string of alphanumeric characters, typically 26 to 42 characters on common chains. Because crypto addresses are 26–42 character strings of random letters and numbers, most users paste without reading. Attackers understand this, and they exploit it through two primary methods.
The first is address poisoning. Address poisoning is one of the simplest and most effective scams in cryptocurrency. The attacker generates a wallet address that looks nearly identical to one you frequently send to, then slips it into your transaction history with a tiny transfer. When you later copy what you think is a familiar address, you send funds directly to the attacker. The attack requires no malware, no exploits, and no access to your private keys. It exploits a single human habit: copying addresses from recent transactions instead of verifying them character by character.
The scale of this attack is staggering. Between July 2022 and June 2024, researchers at Carnegie Mellon University documented 270 million address poisoning attempts across Ethereum and BNB Chain, targeting 17 million unique wallet addresses. Address poisoning has produced some of the largest single-transaction losses in cryptocurrency history. The economics are striking: the May 2024 campaign that netted $68 million required just $0.65 per poisoning transaction.
The second method is clipboard hijacking. If malware on a device identifies a clipboard entry in a matching address format, it replaces it with the attacker's address. Users commonly copy-paste addresses when creating a new transaction. If the malware is preloaded with several different addresses, it could substitute the one that most resembles the target address. Because users typically paste wallet addresses rather than typing them, the substitution happens invisibly. The victim unknowingly sends funds to the attacker's wallet instead of the intended recipient.
Both address poisoning and clipboard hijacking rely on the same fundamental exploit: swapping genuine wallet addresses for attacker-owned ones. Attackers exploit human trust in copy-paste processes rather than breaking blockchain cryptography. The cryptography is fine. The problem is the moment between the address being decided and the address being used.
What these two worlds share
Whether you are wiring $1.2 million in loan proceeds at closing, disbursing a commission split, or routing onchain proceeds to multiple parties simultaneously, the structural vulnerability is identical: a human at some point in the chain holds an address received through a medium that can be intercepted or manipulated. The address is dynamic. It arrives through email, a document, a copy-paste, a text message — and any of those channels can deliver a substituted destination.
That is the opening that payment diversion requires. Close the opening, and the fraud fails before it begins.
Why verification-after-the-fact is an insufficient defense
The conventional response to payment diversion has been verification — calling the other party to confirm account numbers, verifying routing details by phone rather than email, requiring a callback before processing any change of instructions. These are sensible practices, and they help. But they are defenses layered on top of a vulnerable architecture, not a replacement for it.
Consider the operating reality. A closing attorney managing six files simultaneously receives a PDF with updated wire instructions. The instructions look exactly right because they came from a spoofed version of the title company's domain. The attorney is two hours from table and calls to verify — but the attacker has also set up a spoofed phone number that mirrors the title company's switchboard. In some cases, criminals even follow up with phone calls to the victim, purporting to be from a representative for the title company or seller's law office, and reassuring them the wire transfer request is real.
The problem with after-the-fact verification is that it assumes the verification channel itself is clean. When attackers have compromised an email account and spent weeks monitoring a transaction, they can anticipate the verification call and prepare for it. "The technical skill level is near zero for this crime, but the operational sophistication is very high," one security researcher explained. "That means the phishing kits and other technical tools are freely available, but they are investing more time and effort into taking steps to trick the consumer."
The same problem exists in the onchain world. Both address poisoning and clipboard hijacking exploit the same final step: the user not verifying the full destination address before confirming a transaction. Checking the first few characters of an address is the natural human behavior — and attackers design their substitute addresses specifically to match those leading characters. Most often, the start and end of the fraudulent address are exactly the same as the real one. Despite many warnings from blockchain security firms, users typically just check the beginning and end. A 42-character Ethereum address where characters 5 through 38 have been swapped will pass a casual visual check every time.
Even the most disciplined professional cannot adequately defend against a threat that operates at this resolution, at the speed of a copy-paste, under the time pressure of a live closing. Vigilance is necessary, but it is not sufficient. The architecture has to change.
What preset, verified recipients actually do
The protection offered by a pre-verified, preset recipient address is not a better version of checking an address before sending. It is a fundamentally different category of control. The destination is established, confirmed, and locked before the payment event — ideally before the deal even heats up to the stage where an attacker would be watching.
Here is the structural difference:
| Destination address | Traditional architecture | Preset verified recipients |
|---|---|---|
| When it is set | At payment time | Ahead of time, before the clock was ticking |
| How it is established | Travels through the communication channel | Out-of-band, in a controlled session, confirmed directly with each recipient |
| Exposure | Can be intercepted, modified, and substituted | Stored in the payment instruction, not arriving through email at closing |
| Protection | Only human vigilance applied at the last moment, under pressure | Nothing left to substitute |
With preset verified recipients, there is no communication-channel substitution attack because the address is not being communicated at payment time.
This distinction matters especially when multiple parties are receiving proceeds from the same transaction. A commercial deal might require simultaneous disbursement to a listing broker, a buyer's broker, a transaction coordinator, a referring agent, and a closing advisor — each at different percentages of a different base amount. In the conventional workflow, each of those parties communicates their payment details, and someone assembles them into instructions that get executed. That assembly process is an attack surface: any one of those communications could be intercepted or spoofed.
When the recipient wallets and their percentage splits are set and verified before the deal goes into motion, the disbursement instruction contains no newly communicated addresses. Every destination was verified in a prior session, confirmed by the recipient from their own device or through an out-of-band process. The payment event executes against an immutable record of pre-approved destinations. There is nothing for a copy-paste hijacker to substitute, no last-minute wire instruction change to spoof, and no confusion about which account was supposed to receive the funds.
The professional liability dimension
Payment diversion is not just a financial loss for the client. For the professional whose email was the vector of the attack, or whose instructions were trusted and turned out to be fraudulent, the exposure extends well beyond the deal.
When a professional's negligence contributes to a client's loss, that party may face civil liability, depending on the specific facts and applicable law. Determining who is liable requires a careful look at how the fraud happened, whose account was breached, and what safeguards should have been in place. Brokers and closing attorneys have faced lawsuits from clients who acted on wire instructions that came through the professional's compromised accounts. In one well-documented case, the real estate attorney and the agent both claimed they had no legal responsibility to warn buyers of the scam, and they unsuccessfully attempted to have the case dismissed.
The professional's professional indemnity carrier will want to know what protocols were in place. Saying that instructions were sent securely by email, and that the email account may have been compromised, does not end the inquiry — it begins it. Increasingly, best practice in the profession is being defined not just by what you communicated, but by the architecture of how payment destinations were established, verified, and locked.
For a closing attorney or advisor managing disbursements, the ability to demonstrate that recipient wallet addresses were verified and preset — not dynamically communicated at the point of payment — is a meaningful operational and liability distinction. It is the difference between a workflow where fraud is possible and a workflow where the specific fraud vector of address substitution has been removed.
Where diversion becomes structurally impossible
Payment diversion of the address-substitution type requires three conditions to be met simultaneously: the destination must be in motion (being communicated or transmitted), the attacker must have access to that communication channel, and the payment must execute before the substitution is discovered. Remove any one of those conditions and the attack fails.
Pre-verified, preset recipients remove the first condition. The destination is not in motion at payment time. It was decided in a prior session, confirmed, and fixed. The attacker has nothing to intercept because nothing is being transmitted. The payment event is the execution of a pre-established instruction, not the delivery of a new one.
This is why the timing of address verification matters so much. Verifying the recipient address on the same day as the payment — even moments before execution — still leaves a window. The clipboard hijacker does not need much time. Once installed, a clipper runs silently in the background, polling the clipboard at rapid intervals — one documented Linux variant monitors the clipboard every 200 milliseconds. If you copy an address from one application and paste it into a transaction field, the substitution has already occurred before you hit send.
The only architecture that closes this window completely is one where the address in the payment instruction was set in a prior, protected session — not retrieved or re-pasted at the time of payment. The address in the instruction at payment time is the same address that was there when the deal structure was built. No copy-paste event at closing. No late-arriving email with updated instructions. No last-minute change that triggers a rushed verification call.
Shaka is built around this architecture. When a professional creates a payment link, the recipient wallets — with their percentage splits — are set into the transaction structure at deal-build time, not payment time. When the deal closes and funds move, they move to the addresses that were verified and locked when the deal was constructed. The payment event cannot introduce a new address. The split executes exactly as the professional configured it, to exactly the wallets that were pre-verified. There is no substitutable destination in flight.
Verification hygiene before you set the address
Because the protection only holds if the initial verification was clean, how you verify recipient addresses before setting them matters significantly. A pre-verified recipient who gave you a poisoned address — perhaps because their own clipboard was compromised when they generated or copied their wallet address — transfers the vulnerability upstream, not eliminates it.
Best practice for confirming recipient wallet addresses before locking them into a deal structure:
Require out-of-band confirmation. Do not accept a wallet address by email only. Require the recipient to confirm the address through a second, independent channel — a voice call where they read back the address, or a secure portal where they enter it directly. If the address was provided by email, have them confirm the last six and first six characters verbally.
Check that the address is active. A wallet address with no transaction history is not evidence of fraud, but it warrants a conversation. If a co-broker gives you an address they have never received funds to before, verify they generated it from a known, clean wallet application on a device they control.
Be particularly careful with addresses sourced from transaction history. Do not copy destination addresses from transaction history. Use saved and verified addresses instead. An address that appeared in a previous transaction may have been seeded there by an address poisoning attempt specifically to be there when you go looking for it.
The practical reality at the closing table
In a live deal disbursement — say, a $4.2 million commercial sale with a 4% total commission splitting between a listing team and a buyer's team, with a referring broker holding a quarter-point, and a transaction advisor on a flat-fee arrangement — the closing attorney is coordinating funds movement to five separate recipients at the moment of maximum pressure. Title has just cleared. The wire from the buyer's lender has arrived. Sellers are waiting. Everyone wants this done in the next 30 minutes.
This is exactly when a fraudulent last-minute instruction change is most effective. Scammers cause confusion and panic to convince you to go against your better judgment and wire money to an undisclosed party. The closing table is structurally the most psychologically compromised moment in the deal — everyone is ready to be done, and the cost of slowing down feels enormous.
The professional whose recipient addresses were pre-verified and preset into the disbursement instruction does not face that pressure point. There is no decision to make about whether a late instruction change is legitimate. There is no address to verify in real time. The disbursement executes against what was already settled, days or weeks before closing day. The recipients were confirmed when there was no urgency, no time pressure, and no transaction-day anxiety degrading everyone's judgment.
That is the operational value of the preset verified recipient: it moves the security decision to a calm, deliberate moment and removes it from a chaotic one. It does not add a step at closing — it removes one, by having already done it properly.
One character is all it takes
A blockchain address that differs from the correct one by a single character in the middle of a 40-character string looks identical to a casual human check. It passes in half a second of visual inspection. It passes when the first four and last four characters match. It passes when you are busy and confident and ready to close. In crypto, even a minor mistake can be expensive because transactions are generally irreversible once confirmed.
The attackers who build lookalike addresses understand this precisely. Address poisoning is cheap to execute and highly profitable for attackers. According to Carnegie Mellon research, the most successful attack group generated $29 million in revenue against $2.7 million in costs — a net profit of $26.3 million. The economics of this attack are so favorable that it is not going away. Sophistication is increasing, not decreasing. Criminals are rapidly adopting artificial intelligence to enhance the credibility of their schemes, and IC3 received more than 22,000 complaints referencing AI in a single year, with adjusted losses exceeding $893 million.
The answer is not to become better at character-by-character inspection under pressure. The answer is to build a payment workflow in which the inspection happened before the pressure, the address was locked after that inspection, and the payment event has no new address to examine. When the destination was verified and preset, there is no attack surface at the moment of payment — not because the professional was more vigilant, but because there was nothing left to divert.
