Your payment system exists to move money — which is exactly why hot wallets, signing flows, and admin privileges are direct targets for attackers. As the cases below show, the attack surface has moved beyond smart-contract bugs to the signing infrastructure, the keys, and the people who operate them.
That's the pattern behind three of crypto's largest payment-related incidents from 2025. We've analyzed the attack chains in depth, and each one maps to a distinct attack path: a supply-chain attack on signing infrastructure, a leaked admin key, and operations staff broken by social engineering. Below, we break down what happened in each case, what it says about where crypto payment hacks are headed, and then go one level down into the contract layer those payments run on — where smart contracts actually show up in a payment system, how the two leading stablecoins differ in who can freeze or mint your funds, and what a self-deployed payment contract needs before and after it goes live.
Bybit, $1.5 Billion: When the Signing Tool Becomes the Attack
The attackers never exploited a bug in Bybit's own contracts — they compromised the third-party Safe{Wallet} interface the signers trusted. They injected malicious JavaScript into the front-end code of Safe{Wallet}, the third-party multisig management tool Bybit used. When Bybit's signers saw what looked like a routine "internal transfer" in the Safe{Wallet} web interface and signed it, they were actually signing a delegatecall operation that replaced proxy slot 0 of the multisig contract with an attacker-controlled implementation contract. Once signed, the attackers drained the entire wallet within minutes.
Four things had to fail at once for that to work:
- Endpoint security — the signers' web UI came from a third party, with no independent verification.
- Transaction verification — blind signing meant signers couldn't tell a normal transfer from a delegatecall on-screen.
- Contract design — the proxy upgrade privilege had no timelock protection.
- Operational isolation — the signing environment wasn't physically isolated from the everyday office environment.
That last point is worth sitting with: even a well-resourced exchange can lose $1.5 billion when several safeguards fail at once — endpoint security, transaction verification, contract design, and operational isolation. For a deeper look at hardening the signing environment itself, see key management and signing infrastructure.
UPCX, $70 Million: One Leaked Admin Key, Total Control
In 2025, the payment protocol UPCX lost about $70 million to a leaked admin private key.
Here, the attacker didn't need to trick anyone into signing anything. They simply obtained the ProxyAdmin private key, used the contract upgrade function to swap the implementation contract for a malicious version, and then called withdrawByAdmin to drain all funds.
The lesson is blunt: a leaked key plus contract upgrade privilege equals total control. That's why ProxyAdmin key management must use MPC or multisig — never a single holder — and why contract upgrades need a timelock (for example, a 48-hour delay) that gives the team a window to spot anomalies before an upgrade takes effect. We go deeper on how to structure that kind of key management setup elsewhere in this series.
MoonPay, $250,000: When Attackers Skip the Code Entirely
Not every crypto payment hack touches a contract or a key system at all. According to a 2025 U.S. Department of Justice forfeiture filing, the CEO and CFO of crypto payment firm MoonPay were phished out of about $250,000 in USDT by a single email.
The attacker impersonated a well-known figure and used typosquatting to spoof the sender address — swapping a capital "I" for a lowercase "l," nearly invisible in a sans-serif font — to lure MoonPay executives into transferring USDT to an attacker-controlled address. There was no technical vulnerability here, and the key system was never touched. It was pure social engineering.
Tether later froze about $40,000 of the stolen funds, while the rest went overseas for the DOJ to pursue.
A few things stand out:
- Social engineering doesn't discriminate — even a top payment firm's technically sophisticated executives can fall for it.
- Always verify the recipient address independently before sending, never just from the address shown in an email. Combine address verification, whitelisting, and a cooling-off period for large amounts.
- Stablecoin freezability helped recover part of the loss after the fact, but only a fraction was recovered. Prevention beats post-hoc freezing.
The Pattern: Three Attack Paths, One Lesson
Line these three cases up and a pattern falls out — each is a different point of failure, but each has a well-defined defense:
| Attack pattern | Case | Target | Core defense |
|---|---|---|---|
| Supply-chain attack | Bybit | Signing tool / front end | Independent verification + signing-environment isolation |
| Key leak | UPCX | Admin private key | MPC/multisig + timelock |
| Social engineering | MoonPay | Operations staff / executives | Address verification + whitelist + security awareness training |
The attack surface has moved: it's no longer just about smart-contract bugs, it's the signing infrastructure, the admin keys, and the operations staff around them. If you're responsible for a crypto payment system, the practical takeaway is to defend all three — your signing tools, your admin keys, and your operations staff — as separate attack surfaces, each with its own controls.
That said, contract privileges featured in two of these three cases — the untimelocked proxy upgrade was one of the four failures behind Bybit, and UPCX's ProxyAdmin key was the whole attack. So it's worth going one level down: what the contract layer of a payment system actually consists of, and what it needs.
Where Smart Contracts Actually Show Up in Payments
If you're building a crypto payment product, it's easy to assume smart contract security means DeFi-level complexity: a dozen interacting protocols, a web of economic assumptions, and a huge attack surface to defend. That's not usually where payment companies live. Compared with DeFi, where a scenario may involve a dozen contracts interacting under a complex economic model, payment contract logic is usually far more direct. From low to high complexity, the uses cluster in four places.
Stablecoin contracts, used by almost every company. USDC and USDT are themselves smart contracts, with admin functions like mint, burn, blacklist, and pause. You're a user of these contracts, not the deployer — but you still need to understand their permission model and freeze capability, which we'll get into next.
Contract multisig and account abstraction, the wallet and governance layer. Contract multisigs like Safe manage funds and contract privileges and sit at the core of the wallet layer. Account abstraction (ERC-4337) has begun entering payment scenarios too, powering gasless payments (a paymaster covers the gas so the user doesn't need to hold the native token), enterprise spending limits, and session keys.
Automatic splits, conditional release, and cross-chain settlement — the category scaling right now. This is where "programmable money" earns its name. Coinbase and Shopify's Commerce Payments Protocol splits a receipt on-chain in real time: at capture, the contract atomically routes the fee to the feeReceiver and the remainder to the merchant, and it can split a single authorization into multiple captures at different rates to different recipients — for example, capturing 1,000 USDC in two parts, paying fees to different recipients and settling the remainder to the merchant. The same protocol brings the card networks' familiar authorize/capture flow on-chain: an escrow contract holds funds after the buyer authorizes, so the merchant can capture or refund later. On the settlement side, Circle's CCTP uses native burn-and-mint for cross-chain USDC transfer and can trigger follow-on contract actions on arrival, stringing cross-chain movement and automated settlement together.
Automatic yield and treasury management — still early. This means putting idle reserves into low-risk DeFi protocols to earn yield, or automating treasury movement with contracts. Most payment companies haven't adopted this at scale, and for good reason: it introduces external protocol dependencies, which widens the attack surface.
Most payment companies today stay in the first two categories, the third is just starting to scale, and the fourth is still early. The simpler the usage, the smaller the attack surface — so add contract complexity only as your business requires it, not for the sake of being "programmable."
The Permission Model Behind Every Stablecoin You Touch
As a stablecoin user, you need to understand the permission design baked into the contract itself. The two leading stablecoins take opposite approaches.
USDC (Circle) uses a separated-powers model: masterMinter manages minter allowances, pauser can pause the contract, blacklister manages the blacklist, and owner manages role assignment. Each role is independent, with no overlap in privileges (see the Circle stablecoin-evm contract source).
USDT (Tether) uses a single-owner model: one owner address holds all privileges at once — mint, pause, and addBlackList. It's simpler in design, but more concentrated.
Neither model is strictly better — they trade off differently. USDC's separated powers are more secure but more complex to operate, while USDT's concentrated model is efficient but leans more heavily on the security of a single owner address. That difference isn't just academic: it directly affects your freeze risk if a stablecoin issuer ever needs to act on your funds.
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Securing the Contracts You Build Yourself
If you deploy your own receiving, settlement, split, or escrow contracts, you need a professional payment contract audit before deployment and a set of security mechanisms built in.
Before deployment, get an independent third-party security firm audit, plus automated static and dynamic scanning. Make sure the review specifically covers permission management, fund flows, reentrancy, and split-ratio overflow — the payment-specific risks, not just generic contract bugs.
At runtime, four mechanisms apply:
- Timelock — a delay (for example, 48 hours) on contract upgrades and parameter changes, giving your team and community a window to catch problems before they take effect.
- Circuit breaker — automatically pauses contract operations the moment an anomaly is detected.
- Role separation — deployer, upgrader, pauser, and admin each use different keys, so no single credential controls everything.
- Upgradeable proxy pattern — a transparent proxy or UUPS, with upgrades protected by timelock plus multisig.
After deployment, revoking the developer's elevated privileges right away is the core measure against insider threats, and it's the direct lesson of the UPCX incident above: transfer admin and owner privileges to a multisig contract, protect the ProxyAdmin key with multisig plus timelock, regularly review the contract's permission state to confirm no residual developer privileges remain, and make sure every on-chain permission change emits an event log for monitoring and audit.
None of this replaces the audit itself — it's what keeps a clean audit from decaying into an unmonitored, over-privileged contract after launch.
Defend Four Surfaces, and Keep the Fourth as Small as Possible
Three of the surfaces the 2025 incidents exposed are operational: your signing tools, your admin keys, and your operations staff. The fourth is the contract layer, and there the goal is different — not matching DeFi's complexity, but matching your actual usage: know the permission model of the stablecoins you touch, keep your own contracts as simple as the business allows, and treat the audit as day one of an ongoing permission-hygiene practice, not the finish line.
For where each of these surfaces sits in the system as a whole, see our breakdown of the six-layer payment architecture. For a full breakdown of how these controls fit together, download the full playbook (PDF), and for real-time monitoring that can automatically block attack transactions at the mempool stage, take a look at on-chain security monitoring.
FAQ
What was the biggest crypto payment hack in 2025? Bybit, in February 2025, losing about $1.5 billion (401,347 ETH) after attackers compromised the front-end code of the third-party multisig tool Safe{Wallet} and tricked signers into approving a malicious delegatecall.
How did the UPCX hack happen?
An attacker obtained UPCX's ProxyAdmin private key, used the contract upgrade function to swap in a malicious implementation contract, and called withdrawByAdmin to drain about $70 million in funds.
Was the MoonPay incident a smart contract exploit? No. The MoonPay incident, where the CEO and CFO were phished out of about $250,000 in USDT, involved no technical vulnerability. It was pure social engineering using a spoofed, typosquatted sender address.
What do Bybit, UPCX, and MoonPay have in common? Each attack targeted a different layer of a payment system — the signing tool, the admin key, and operations staff — showing that the biggest threat has moved from smart-contract bugs to signing infrastructure, keys, and operations.
What's the difference between USDC and USDT's permission models?
USDC (Circle) uses a separated-powers model, with independent masterMinter, pauser, blacklister, and owner roles. USDT (Tether) uses a single-owner model, where one address holds all privileges — mint, pause, and addBlackList — at once.
What security mechanisms should a self-deployed payment contract have? Before deployment: an independent third-party audit plus automated scanning, with focused review of permission management, fund flows, reentrancy, and split-ratio overflow. At runtime: a timelock on upgrades, a circuit breaker, role separation across keys, and an upgradeable proxy pattern protected by timelock plus multisig.
Why does revoking developer privileges after deployment matter so much? It's the core measure against insider threats, and it's the direct lesson of the UPCX case. Transferring admin and owner privileges to a multisig contract and regularly reviewing permission state to confirm no residual developer privileges remain both close that gap.
