Somewhere on the Ethereum blockchain, there is a contract I deployed. It does nothing useful. Tokens were minted, nothing of consequence happened, and I have not thought about it in years. But the bytecode is still there—sitting in the state, waiting to be executed by rules I did not fully understand when I wrote it. It will be there indefinitely, under those same rules, whether I like it or not.

At some point, almost everyone in this space has done something like this—written a contract, deployed something, just to see if they could. Pump.fun has made it easier. But there was a time when you had to write the Solidity yourself. I bought my first ETH in 2017. I have traded it, bridged it, lost some of it to gas fees I did not understand, and at some point deployed that meme coin just to see if I could. The contract worked. But the part that stuck with me was not that it worked—it was that I had no real idea what was executing it.

The thing about Ethereum is that most people who use it—trading, providing liquidity, deploying contracts—never have to think about what is actually executing their transactions. There is a machine underneath all of it. It has rules. Those rules were written in 2015, and some of them turned out to be wrong, or at least incomplete. Fixing them without breaking everything already on-chain turns out to be one of the more interesting engineering constraints in the space.

This piece is about that machine. Some of its rules have already been changed. Others cannot be—not really. The difference turns out to matter more than you might expect.

2. What Actually Executes When You Hit Send

Most people who interact with Ethereum have a mental model that looks something like this: you send a transaction, it gets picked up by validators, it lands in a block, and something happens. The "something happens" part is where most mental models stop.

That something is the EVM.

When Satoshi designed Bitcoin, the scripting language was deliberately limited—intentionally not Turing complete. You could express "send X bitcoin to Y address if Z condition is met." You could not express much else. Ethereum's founding insight was that the interesting design space lived in that "much else"—arbitrary computation, not just payment logic.

The EVM is what makes that possible. It is the runtime environment that every Ethereum node runs identically—opcode by opcode, every node producing the same output. The blockchain records the outcome. The EVM is what produces it.

Wait. If the EVM produces the outcome, but the blockchain only records it—where does the EVM actually live?

Not on-chain. The rules of the EVM—which opcodes exist, what they cost, what they do—are encoded in every node's software. Nobody owns it. Nobody controls it. And yet, somehow, thousands of independent machines all run the same rules.

So what stops anyone from just... changing theirs?

3. You Can Cheat. Nobody Cares.

A natural thought at this point: if the EVM runs locally on every node, what stops me from modifying mine to produce a different result?

Nothing, technically. You can fork the client software, change whatever you want, and run your modified version. Your node will execute transactions under your custom rules and arrive at different outputs.

The network will then ignore you.

Every other node is running the standard rules. When your modified node produces a result that diverges from theirs, the rest of the network rejects it as invalid. Your transactions do not get included in any block that the network accepts. Your modified chain forks off into isolation, a parallel ledger that no one else recognizes or builds on.

That is consensus. The word you always heard about.

The corollary is the one that matters for this piece: changing the EVM rules legitimately requires the entire network to upgrade simultaneously. Not because anyone can force nodes to upgrade, but because a rule change that only some nodes adopt splits the network. The upgrade is all-or-nothing.

But here is the harder question. If someone's money gets stolen—not a bug in their contract, but a fundamental exploit—can the network revert it? Most people assume the answer is obviously no. Ethereum is immutable. Code is law. The whole point of a trustless system is that no one gets to make exceptions.

Except once.

4. When the Chain Splits and Doesn't Come Back

Ethereum has gone through nearly twenty hard forks since 2015. Most people have never noticed.

That is because most forks are planned upgrades with broad consensus. The community agrees, node operators upgrade, the old chain dies quietly because no one stays on it. No drama, no split. Just a software update that the entire network coordinates around.

Then there is The DAO.

In 2016, a smart contract called The DAO was exploited for roughly 3.6 million ETH. [1] The Ethereum community faced a choice: accept the loss as immutable history, or intervene. The majority voted to intervene. What followed was what developers drily called an "irregular state change"—the hard fork did not technically reverse transactions, but directly rewrote Ethereum's ledger to move the funds out of the attacker's child DAO contract and into a recovery contract, allowing original investors to withdraw. [2] The funds were returned.

But not everyone agreed. A portion of the community—roughly 10% by mining power at the time [1]—believed that rolling back the chain violated the core principle of blockchain immutability. Code is law. The hack was valid. They refused to upgrade.

The result: two chains, both alive, both carrying the full transaction history up to block 1,920,000 [1], then diverging permanently. Ethereum (ETH) on the new chain. Ethereum Classic (ETC) on the original. Both still exist today.

5. Sign Once, Collect Twice

The DAO fork left two chains running the same EVM, the same transaction format, the same signature scheme—and every wallet mirrored across both, same address, same keys, same balance.

You are a hacker. The chain just split. Is there any way to profit from this?

Turns out, there is. Here is exactly what you do:

• You sell someone 5 ETH worth of goods. They sign a transaction: send 5 ETH to your address. It confirms on Ethereum.

• Take that signed transaction, byte for byte, and broadcast it to the Ethereum Classic network.

• The ETC nodes validate it. Same signature scheme, same format, same everything. It goes through.

• They signed once. They authorized one transaction. The network validated two. The buyer just sent you 5 ETC they never intended to spend.

Whoo hoo! Free money.

The attack surface was never in any opcode. It was in an assumption baked silently into Ethereum's design: that there would only ever be one chain. No one wrote that assumption down. No one enforced it. It was just true—until the day it wasn't.

The transaction-layer fix came first, and it came fast. EIP-155, included in the Spurious Dragon upgrade four months after the fork (November 2016), embedded the chain ID directly into the transaction signature. [3] A transaction signed for Ethereum now encodes chain 1; one signed for Ethereum Classic encodes chain 61. The signatures are cryptographically distinct. Replaying one on the other fails validation. The replay attack, as described above, was closed.

But closing the signature hole left a second problem open. Smart contracts—executing inside the EVM—had no way to ask which chain they were on. A contract deployed identically on both ETH and ETC would execute identically on both. If a contract's logic depended on chain identity—verifying a signature that embeds a chain ID, for instance—it had no mechanism to inspect that at runtime.

EIP-1344, included in the Istanbul upgrade (2019), added CHAINID [4]—a single opcode that pushes the current chain's numeric identifier onto the stack. Ethereum is chain 1. Ethereum Classic is chain 61. Contracts could now condition their behavior on which chain was actually executing them.

The transaction layer was patched in months. The execution layer took three more years. One broken assumption. Two separate fixes. Different layers of the same stack, addressed on different timelines.

Woah, slow down. What exactly is an opcode? And what is this EIP thing we just talked about?

The answers will be introduced across the next three sections. Section 6 covers the machine itself—what the EVM actually is, and why it is built the way it is. Section 7 covers the origins: what is an opcode, and the initial opcode set that shipped with Ethereum in 2015. Section 8 covers the EIP—the only mechanism the network has for changing a machine that nobody owns. By the end of those three sections, both fixes will look less like patches and more like the only moves available.

6. A Stack of Plates — Determinism Over Performance

The Ethereum Virtual Machine is, at its core, a stack machine. To understand it, it helps to start somewhere familiar.

If you have taken an introductory CS course, you have encountered a stack before—it is one of the first data structures most curricula cover. Last in, first out. You push values onto the top, and you can only pop from the top. The plate stack analogy: the last plate you put down is the first one you pick up. Simple, constrained, and easy to reason about.

A stack machine is a computer that uses a stack as its primary workspace for computation. Instead of named registers (a + b → c), every operation pulls its inputs from the top of the stack and pushes its result back. To add two numbers, you push both onto the stack, then call ADD—which pops both, adds them, and pushes the result. No named variables, no hidden state. Just a sequence of push and pop operations.

A well-known example—Java Virtual Machine—works the same way. When Java compiles your code into bytecode, it produces a sequence of instructions that push values onto a stack, operate on them, and pop results off. This design was chosen for one reason: portability. The same bytecode runs identically on any machine that implements the JVM specification, whether it is running on Windows, Linux, or macOS.

The EVM made the same architectural choice, but for a different reason. Portability across operating systems matters for node software too—Ethereum clients run on Linux, macOS, and Windows. But that is not why the EVM uses a stack. The driving constraint is determinism—the guarantee that the same transaction, executed on ten thousand nodes across the world, produces exactly the same result every single time.

The second reason is economics. EVM bytecode lives on-chain. Every byte costs gas to deploy. Stack instructions do not need to name registers (a, b, c), so the instruction encoding is compact. PUSH1 0x60 is two bytes. That is all.

Same architecture, different motivations: JVM optimizes for portability across operating systems; EVM optimizes for determinism across a global network of adversarial nodes. The distinction matters for what comes next.

7. The Day They Switched It On

On July 30, 2015, the Ethereum genesis block was mined. The network launched with what is now called the Frontier release: a minimal, intentionally rough set of opcodes sufficient to run the machine.

To appreciate what this meant, consider the contrast with Bitcoin. Bitcoin's scripting language is deliberately limited—not Turing complete by design. You can express conditions like "send X to Y if Z signature is provided," but you cannot write loops, you cannot maintain persistent state across transactions, and you cannot build programs that call other programs. This was a conscious choice: a smaller instruction set means a smaller attack surface.

Ethereum's founding bet was the opposite. The EVM is Turing complete—given enough gas, it can compute anything a conventional computer can. Loops, conditionals, recursive calls, arbitrary state. The JUMP and JUMPI opcodes alone are what push it over the Turing threshold: they allow execution to jump to arbitrary positions in the bytecode, enabling loops and branching logic that Bitcoin's script cannot express.

This power came with a tradeoff Bitcoin deliberately avoided: if you can write arbitrary programs, you can write programs with arbitrary bugs. And on a blockchain, those bugs are permanent.

The initial opcode set covered everything needed to make the EVM functional: [5]

• Arithmetic: ADD, MUL, SUB, DIV, MOD

• Comparison: LT, GT, EQ, ISZERO

• Stack manipulation: PUSH1–PUSH32, POP, DUP1–DUP16, SWAP1–SWAP16

• Control flow: JUMP, JUMPI, STOP

• State: SSTORE, SLOAD, MSTORE, MLOAD

• External calls: CALL, CALLCODE, CREATE

• Self-destruction: SUICIDE (later renamed SELFDESTRUCT)

The machine worked. Contracts could be written, deployed, and executed. Ether could move. Logic could run.

What the designers did not fully anticipate was that every decision made in July 2015 would be permanent—permanent in the sense that millions of contracts would be deployed depending on the exact behavior of these opcodes. Changing them later would not be a patch. It would be a betrayal.

They had built a machine. They had also built a constraint.

8. The EIP — Change a Machine That No One Owns

At this point, you have a reasonable question. You understand what an opcode is—an instruction that operates on the stack of plates. You know the initial set shipped in 2015. If those rules are encoded in every node's software, and not locked inside any contract on-chain, then changing them is at least possible. What stops anyone from proposing a new opcode—or modifying an existing one—to change how the EVM behaves?

Anyone can write a proposal. Getting it accepted is another matter entirely.

When a flaw is found in the EVM—a security vulnerability, an inefficiency, an assumption that broke under new conditions—there is exactly one mechanism to address it: an Ethereum Improvement Proposal.

An EIP is a formal specification document. It must define the exact behavior of the change, the gas cost implications, the security analysis, and the backward compatibility impact. It must be implemented by every major Ethereum client: Geth, Reth, Nethermind, Besu. It must be reviewed by core developers, discussed in public forums, and accepted into a hard fork—a network upgrade that all nodes must adopt simultaneously or be left behind.

This process is slow by design. A change to the EVM affects every contract ever deployed, every node currently running, and every developer writing code today. The bar for "this change is worth it" is correspondingly high.

But there is a harder constraint underneath the process. Even if an EIP is accepted, it cannot change the behavior of existing contracts. The bytecode already on-chain will be executed under the old rules forever. An EIP can change what new contracts can do. It can change the rules of the machine going forward. It cannot reach back.

This is the central tension of EVM evolution: the machine must improve, but it cannot forget.

But there is another way to read the EIP process. If the exit is open to anyone, it is also open to attackers.

9. SSTORE — A Safe Change That Wasn't

You have read the EIP process. You understand the review criteria: the change must be beneficial, gas costs must be justified, backward compatibility must be preserved. The process is well-calibrated for deliberate attacks—an EIP that explicitly violates a core EVM invariant does not survive review. Explicit violations are catchable. What the process is not calibrated for is the interaction problem: a change that is individually correct, individually safe, but semantically dangerous when composed with assumptions already baked into deployed contracts. No single reviewer can hold the full state space of every existing contract in their head simultaneously. The attack surface, in this case, is not in any specification line—it is in the gap between what the EIP says and what the network has silently assumed.

January 15, 2019, one day before the Constantinople upgrade was scheduled to go live at block 7,080,000 [6], a smart contract auditing firm called ChainSecurity published a report that made this gap visible. [7]

EIP-1283 [8] reduced gas costs for certain SSTORE operations, specifically "dirty writes": cases where a storage slot is written more than once within the same transaction. The gas savings were real and the EIP had passed review. What the reviewers had not fully traced was the downstream effect on existing contracts.

Solidity developers had long treated address.transfer() and address.send() as reentrancy-safe. The reason was mechanical: both functions forwarded exactly 2,300 gas to the recipient—enough to log an event, not enough to execute a storage write. Reentrancy attacks require the recipient contract to call back into the sender and modify state. At 2,300 gas, that was infeasible. The safety guarantee was not in the code—it was in the gas cost of SSTORE.

EIP-1283 reduced that gas cost. Suddenly, 2,300 gas was enough. Contracts that had been written and audited as reentrancy-safe were no longer safe—not because their code changed, but because the cost of an operation they depended on changed beneath them.

ChainSecurity's follow-up analysis stated the broader lesson plainly: any change to EVM semantics inevitably propagates into the behavior of every deployed contract, and verifying that all existing contracts remain safe under a given change would require reasoning about every contract-specific property—a task that is infeasible in practice. [9]

The upgrade was delayed. When Constantinople eventually launched in February 2019, it shipped simultaneously with a second fork called St. Petersburg, whose sole purpose was to remove EIP-1283. The EIP was proposed, accepted, shipped, and reverted within a single upgrade cycle.

Nobody planted a bug. It was an honest oversight—a change that looked safe in isolation but was not safe in context. The EIP process caught it, barely, at the last possible moment.

This is the actual threat model. Not a trojan horse with a hidden payload, but the irreducible complexity of reasoning about a change that touches every contract ever deployed. The chain split showed how one broken assumption could propagate across two separate layers of the stack—requiring fixes years apart. SSTORE showed a different failure mode: a change that was individually safe but contextually dangerous. Here are two more.

10. SELFDESTRUCT — TNT in the Toolbar

You are not trying to exploit anything. The previous version of you wanted to slip a backdoor past the review committee. This one just wants to see what happens—like a Minecrafter who found a bucket of TNT and has no particular agenda.

You come across SELFDESTRUCT.

You read the description: destroys the contract, wipes its storage, forwards all Ether to a target address. The original name, before they sanitized it, was SUICIDE.

Is there anything interesting you can do with this?

It turns out there is. SELFDESTRUCT can send Ether to any address, with no conditions. Normally, a contract with no receive() or fallback() function refuses incoming Ether. SELFDESTRUCT does not care. You deploy a contract, point it at your target, and fire. The Ether lands whether the target wants it or not.

A lot of contracts make assumptions about their own balance. Logic like: if this contract holds exactly X ETH, allow withdrawal. Or: if balance is zero, this pool is empty. These checks assume the balance can only change through the contract's own sanctioned functions. SELFDESTRUCT breaks that assumption from the outside, using a legitimate opcode exactly as specified.

It was designed as a cleanup tool. The protocol originally gave you a gas refund for using it, as an incentive to delete unused contracts and reduce chain bloat—a mechanism removed separately in EIP-3529 (London, 2021), years before the behavior itself was constrained. The designers were thinking about lifecycle management. Not weaponized Ether injection.

By 2024, SELFDESTRUCT had nine years of dependents. You cannot remove it. So the Ethereum community did what it always does when it cannot delete: constrained it. EIP-6780 [10], included in the Cancun upgrade, changed the rules: full destruction only if called within the same transaction that created the contract. On any existing contract, it transfers the Ether and stops. The code remains. The storage remains.

Why this specific rule? The legitimate use cases—deploy-time cleanup, one-shot factory patterns—still work. The weaponized use case is defused: the Ether transfer no longer carries the threat of deletion. There is also an architectural reason. The Cancun upgrade began restructuring how Ethereum nodes store state, and the original SELFDESTRUCT behavior—immediately wipe all storage—is incompatible with a storage model that cannot guarantee instant deletion. EIP-6780 was not just a security patch. It was a prerequisite.

The TNT is still in the toolbar. It just does not explode anymore.

11. PUSH0 — One Opcode, Billions Saved

This one is not an attack. But it is the most honest illustration of how the EVM actually evolves.

Pull all bytecode executing on Ethereum mainnet and start counting. Roughly 11.5% of all PUSH operations push the constant value zero [11]—not a variable, not a computed result. Just zero. Compilers emit PUSH1 0x00 constantly for initializing variables, clearing slots, setting default return values.

PUSH1 0x00 costs 3 gas and takes 2 bytes. The value being pushed is always the same. There is no reason the EVM should treat it like arbitrary data.

So someone wrote an EIP. PUSH0—an opcode that pushes zero, costs 2 gas, and takes 1 byte. One byte saved. One gas saved. Multiply that across billions of executions, and the aggregate savings are real. EIP-3855. Shanghai, 2023. Done. [11]

No drama. No security incident. No attacker. Just someone who counted carefully.

If zero is common enough to deserve its own opcode, a natural follow-up: what about other high-frequency patterns? Run byte pair encoding—BPE, the compression algorithm behind tokenizers—on all bytecode executing on mainnet, and identify the most common sequences. Give those sequences cheaper representations. The efficiency gains would compound across everything, not just zero-pushes.

The problem is structural. EVM bytecode must be directly executable, opcode by opcode, on every node simultaneously. BPE requires a shared dictionary—a reference that tells each node what a compressed token means. But the EVM has no mechanism for shared references. Common sequences in one contract are not necessarily common in another, and a universal scheme would require either per-contract dictionaries (stateful, expensive) or an approximate dictionary (defeating the purpose). Determinism requires that encoding be explicit and stateless. A compression scheme requires a shared external reference. Those two requirements are incompatible.

PUSH0 works precisely because it needs no dictionary. The value is universally constant. There is nothing to decode.

12. When Backward Compatibility Becomes a Governance Constraint

Four opcodes. Four types of pressure: an environmental assumption that required fixes at two separate layers of the stack, a semantic assumption that broke when gas costs changed beneath it, a security assumption that was weaponized by design, and an efficiency assumption that accumulated silently until the data made it visible.

In each case, the response followed the same pattern. The original opcode could not be removed. Its behavior could not be retroactively changed. The machine could only be extended—new opcodes added, old behaviors constrained at the edges—while everything already carved into the stone continued executing as written.

This is not a failure of engineering. It is the cost of the property that makes Ethereum useful: the guarantee that code deployed today will execute the same way indefinitely. You cannot have that guarantee and also have the freedom to fix mistakes cleanly. Every upgrade since Frontier has been a negotiation with that constraint.

What these four cases do not show is what happens when the constraint is not technical but architectural—when the change required is not a new opcode but a new structure for the bytecode container itself.

13. EOF and RISC-V — From Restructuring to Replacement

EVM Object Format (EOF) was the most ambitious EVM change attempted since Frontier. It did not add opcodes. It restructured the container that holds them—introducing versioning, separating code from data sections, enabling deploy-time validation instead of runtime validation. [12] For new contracts, the benefits were concrete: cheaper deployment, earlier error detection, smaller bytecode. For old contracts, nothing would change—legacy and versioned bytecode would coexist.

In 2025, EOF was removed from the Fusaka upgrade after years of development. Core developers could not reach consensus. "We don't agree, and we're not coming to an agreement about EOF anymore, and so it has to go out," core developer Marius van der Wijden said at the final decision call. [13] The technical case was not seriously contested. The disagreement was about something harder to resolve.

EOF required that several new opcodes—CALLF, JUMPF, and others enabling the structured control flow that EOF was designed to support—be available exclusively to EOF-format contracts. Legacy contracts could not use them. This was not arbitrary: the opcodes relied on the validation guarantees that EOF's deploy-time checking provided, guarantees that legacy bytecode could not satisfy. But the practical effect was migration pressure. Developers who wanted access to those opcodes had to move to EOF format. Some stakeholders read this as reasonable incentive—adoption had to come from somewhere. Others read it as coercion: the network penalizing contracts for the format they were written in, using opcode access as leverage. Both readings were defensible. Neither side was wrong on the technical merits. That is precisely why the disagreement could not be resolved: it was not a dispute about facts, but about what the network is permitted to do to its existing participants.

The constraint that has governed every opcode change since 2015—the machine can only be extended, never corrected—has propagated upward. It is no longer just technical. It is social. Every new contract deployed under the current format is another argument against restructuring. The surface area of "things that cannot be disturbed" grows with every block.

There is a larger question now on the table. Vitalik Buterin has proposed migrating Ethereum's execution environment to RISC-V—an open, modular processor architecture used across smartphones, servers, and embedded systems. [14] If this direction succeeds, the EVM itself would eventually be replaced by a RISC-V-based VM. Not restructured. Replaced.

The proposal does not claim that RISC-V is categorically superior for all use cases. The argument is simpler: RISC-V is a widely-understood, extensively-tooled architecture with a large existing ecosystem. Moving to it would allow Ethereum's execution environment to benefit from compiler toolchains, formal verification frameworks, and optimization work that already exists outside the Ethereum ecosystem, rather than rebuilding those capabilities for a bespoke VM.

The backward-compatibility question is answered by layering. Legacy EVM contracts would continue to execute through an EVM interpreter implemented in RISC-V—the old machine running as software on the new one. New contracts would target RISC-V natively. The two execution environments would coexist, exactly as EOF proposed for legacy and versioned bytecode, but at a larger scale.

Whether this is achievable is a question that does not yet have an answer. The EVM interpreter layer introduces its own complexity. The migration path requires client teams to implement and maintain two runtimes simultaneously during a transition period of unknown length. And the governance problem that sank EOF does not disappear: a change of this scale would require the same near-unanimous consensus, across the same distributed set of stakeholders, that EOF could not achieve.

But the RISC-V proposal is not primarily an engineering proposal. It is an argument about the shape of the constraint. The claim is that the EVM's limitations are not intrinsic to decentralized execution—they are specific to this particular VM's design—and that a sufficiently well-designed replacement could inherit Ethereum's permanence guarantees without inheriting the accumulated technical debt.

That argument may be correct. It may also be that the constraint is not in the VM design but in the governance structure around it, in which case replacing the VM solves the wrong problem.

The question RISC-V raises is more fundamental: whether the machine can be replaced without breaking what it has already carved, and whether the network that built the machine can agree on anything large enough to try.

There is a version of this story where the question becomes moot. L2 execution environments—Arbitrum Stylus accepting Rust and C++, StarkNet running Cairo, zkSync's zkEVM diverging from EVM semantics at the proof layer—exist precisely because L1 evolution is this constrained. Innovation that cannot happen at L1 does not stop; it relocates. If RISC-V does not succeed, or does not succeed fast enough, the EVM does not disappear. It becomes a settlement layer—a compatibility surface that legacy contracts execute against while real execution happens elsewhere. That is not obviously a bad outcome. But it is a different one than Ethereum's designers intended, and it is already partially underway. The RISC-V proposal is, among other things, an attempt to reclaim that ground before the center of gravity shifts permanently.

References

[1] Andreas M. Antonopoulos and Gavin Wood, Mastering Ethereum, "Appendix A: Ethereum Fork History." https://cypherpunks-core.github.io/ethereumbook/appdx-forks-history.html — Primary source for: 3.6 million ETH drained from The DAO; hard fork executed at block 1,920,000 on July 20, 2016; ETC initial mining power approximately 10% of the combined network.

[2] CoinDesk, "CoinDesk Turns 10: How The DAO Hack Changed Ethereum and Crypto," May 9, 2023. https://www.coindesk.com/consensus-magazine/2023/05/09/coindesk-turns-10-how-the-dao-hack-changed-ethereum-and-crypto

[3] Ethereum Improvement Proposals, EIP-155: Simple replay attack protection, 2016. https://eips.ethereum.org/EIPS/eip-155 — Introduced chain ID into transaction signatures via the Spurious Dragon upgrade (November 2016), closing the transaction-layer replay attack four months after the DAO fork.

[4] Ethereum Improvement Proposals, EIP-1344: ChainID opcode, 2018. https://eips.ethereum.org/EIPS/eip-1344

[5] Ethereum Foundation, "Ethereum Launches," July 30, 2015. https://blog.ethereum.org/2015/07/30/ethereum-launches — Official announcement of the Frontier release, marking the genesis block and the initial live deployment of the EVM.

[6] Ethereum Foundation, "Ethereum Constantinople Upgrade Announcement," January 11, 2019. https://blog.ethereum.org/2019/01/11/ethereum-constantinople-upgrade-announcement — Official announcement confirming Constantinople scheduled for block 7,080,000.

[7] ChainSecurity, "Constantinople Enables New Reentrancy Attack," January 15, 2019. https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9

[8] Ethereum Improvement Proposals, EIP-1283: Net gas metering for SSTORE without dirty maps, 2018. https://eips.ethereum.org/EIPS/eip-1283

[9] ChainSecurity, "Constantinople Security Update," January 2019. https://medium.com/chainsecurity/constantinople-security-update-3d02017747f2 — Follow-up analysis stating the broader lesson after the upgrade delay; distinct from the original vulnerability disclosure cited as [7].

[10] Ethereum Improvement Proposals, EIP-6780: SELFDESTRUCT only in same transaction, 2023. https://eips.ethereum.org/EIPS/eip-6780

[11] Ethereum Improvement Proposals, EIP-3855: PUSH0 instruction, 2021. https://eips.ethereum.org/EIPS/eip-3855

[12] Ethereum Improvement Proposals, EIP-3540: EOF - EVM Object Format v1, 2021. https://eips.ethereum.org/EIPS/eip-3540

[13] Blockworks, "Ethereum Consensus Shifts on EVM Upgrade," June 9, 2025. https://blockworks.co/news/ethereum-consensus-evm-upgrade-fusaka-devs

[14] Vitalik Buterin, "Ethereum's Execution Layer: Long-Run Architecture," Ethereum Research, 2025. https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617

I had been trading on Uniswap for years before I sat down to derive how it actually worked. Tokens that never made it onto centralized exchanges, positions on obscure chains — Uniswap was infrastructure I used without thinking about. When I finally worked through the math, my first reaction was: this is it?

Uniswap has settled hundreds of billions of dollars in trades. It has survived multiple market collapses, regulatory pressure, and the death of protocols far more sophisticated in design. The core pricing mechanism is:

$$x \cdot y = k$$

Two asset reserves, $$x$$ and $$y$$. A constant $$k$$ maintained across every trade. To swap $$\Delta x$$ of asset $$X$$ for some quantity of $$Y$$:

$$(x + \Delta x)(y - \Delta y) = k$$

$$\Delta y = \frac{y \cdot \Delta x}{x + \Delta x}$$

High school algebra. No order book, no counterparty coordination, no off-chain matching engine. The invariant is the market maker. [1]

The mechanism's durability follows directly from its constraint structure. The pool holds real assets at all times. $$k$$ can only increase via fees. There is no liability side to the balance sheet — no promise that can be honored only conditionally. This is the structural distinction between Uniswap and Luna: Luna's stability mechanism required the protocol to honor a peg its assets could not always cover. Confidence breaks, the liability exceeds assets, the spiral is mechanical. Uniswap has no equivalent failure mode because it has no equivalent promise.

The natural question is whether this extends to perpetual contracts. It does not, for reasons that are also structural. Identifying exactly where the invariant breaks — and what replaces it — is the subject of the rest of this piece.

2. When Conservation Laws Have Nothing Left to Conserve

Start with what $$x \cdot y = k$$ actually conserves. When you buy $$Y$$ from a spot AMM, the pool transfers real Y from its balance to you. Nominal exposure and real assets are the same thing. The invariant holds because the quantities it tracks — reserves — are physical.

Now ask what a perpetual contract position actually is. Not a claim on a real asset in the pool. A claim on a future price difference. The pool never transfers the underlying — it settles the delta between entry price and exit price in collateral.

This means the aggregate notional exposure of the book — total longs $$L$$ plus total shorts $$S$$ — has no upper bound imposed by the pool's real assets. A pool with collateral $$V$$ can have $$L + S \gg V$$. That is the point of leverage.

So what happens if you try to apply $$x \cdot y = k$$ to $$L$$ and $$S$$ directly? Let $$x = L$$, $$y = S$$. The invariant says $$L \cdot S = k$$. Now a trader opens a large long, pushing $$L$$ up. The invariant forces $$S$$ down — but $$S$$ is not a reserve the pool controls. It is the aggregate of other traders' positions. The pool cannot conjure short interest to balance the book. Three things follow immediately:

• No real-asset anchor. Virtual reserves track nominal positions, not collateral. The pool can appear balanced on paper while being structurally insolvent.

• No conservation law to enforce. $$x \cdot y = k$$ requires both sides to be quantities the pool holds. The pool holds collateral — it does not hold $$L$$ or $$S$$.

• Asymmetric unwind risk. If the dominant side exits simultaneously, settlement obligations exceed available collateral. The invariant provides no mechanism to prevent this.

The constant product formula is a conservation law. Perpetuals have no equivalent quantity to conserve — what they need is a mechanism to penalize imbalance.

3. What the Pool Actually Needs to Track

We need to replace $$x \cdot y = k$$ with something that works for perpetuals. Start by asking: what is the minimal quantity the pool actually needs to track?

Not the absolute size of $$L$$ or $$S$$ individually — those numbers alone tell you nothing about the pool's exposure. What matters is their difference, normalized against their sum.

First, a note on what $$L$$ and $$S$$ actually are. Define long open interest $$L$$ as the total notional value of all outstanding long positions, and short open interest $$S$$ as the total notional value of all outstanding short positions, both denominated in USD. Unlike in traditional order book futures markets — where a contract only comes into existence when a buyer and seller are matched, so any unmatched order simply waits on the book and never enters open interest; $$L = S$$ is therefore an accounting identity, not an equilibrium condition — a perpetual AMM absorbs the net imbalance directly. $$L$$ and $$S$$ are therefore independent quantities. The pool holds collateral; it does not hold the underlying asset. The difference $$L - S$$ is the net directional exposure the pool is implicitly carrying.

Define the book skew:

$$\delta = \frac{L - S}{L + S}$$

The denominator $$L + S$$ is the gross open interest — the total bilateral notional exposure in the pool. Since $$L, S \geq 0$$, we always have $$|L - S| \leq L + S$$, so:

$$\delta \in (-1, 1)$$

This follows directly from the definition, without any external constraint or position cap. When $$\delta = 0$$, the book is balanced. When $$\delta \to 1$$, the book is overwhelmingly long. When $$\delta \to -1$$, overwhelmingly short.

Now ask what $$\delta$$ actually measures — and what it does not.

$$\delta$$ measures directional imbalance: which side dominates the book, and by how much relative to total bilateral exposure. This is useful. A pool with $$\delta$$ near zero is structurally safer than one with $$\delta$$ near $$\pm 1$$.

What $$\delta$$ does not measure is solvency under stress. $$L$$ and $$S$$ are notional values — the face value of positions, not the pool's actual payment obligations. If all longs are liquidated simultaneously during a sharp price move, the pool's settlement obligation is:

$$\text{obligation} = L \cdot \frac{|P_{\text{exit}} - P_{\text{entry}}|}{P_{\text{entry}}}$$

where $$P_{\text{entry}}$$ and $$P_{\text{exit}}$$ are the average entry and liquidation prices across all long positions. This number scales with both notional exposure and price displacement — neither of which is bounded by the gross open interest. A pool with $$\delta = 0$$ and $$L = S$$ facing a 50% price move has a settlement obligation of $$0.5L$$ on each side. Its actual collateral may be a fraction of that. $$\delta = 0$$ does not mean the pool can survive a correlated unwind. It means the book is directionally balanced at this moment, under current prices.

This is the distinction between directional risk and solvency risk. $$\delta$$ measures the former. When $$\delta \approx 0$$, the pool's net settlement obligation approaches zero regardless of total open interest — longs and shorts cancel out. Solvency risk is only material when $$\delta$$ drifts significantly, or when a correlated unwind outpaces the liquidation engine. The funding rate, derived in the next section, is what keeps $$\delta$$ near zero in the first place.

This distinction also matters for what the cost function can and cannot guarantee, which is the subject of the next section.

Note that $$\delta$$ is a signed quantity. This matters for the cost function below.

4. Why Binance Has Never Gone Bankrupt on Perpetuals

We have $$\delta$$ as a measure of book imbalance. Now ask: what should the pool do about it?

The pool cannot force traders to close positions. What it can do is make it increasingly expensive to push the book further out of balance — and increasingly cheap to push it back. If opening a long position when $$\delta > 0$$ costs more than when $$\delta = 0$$, rational traders will arbitrage the book toward balance. This gives us the shape of the cost function:

• At $$\delta = 0$$: baseline cost $$c_0$$

• As $$\delta \to \pm 1$$: cost must diverge to infinity — no finite capital should be able to corner the book entirely

A function that satisfies both conditions:

$$\text{cost}(\delta) = \frac{c_0}{1 - \delta^2}$$

As $$\delta \to \pm 1$$:

$$\lim_{\delta \to 1^-} \frac{c_0}{1 - \delta^2} = +\infty$$

This is the perpetuals analogue of $$x \cdot y = k$$: just as infinite capital would be required to drain one side of a spot pool entirely, infinite capital is required to push $$\delta$$ to its theoretical maximum. The pool cannot be cornered.

The marginal cost of an incremental long position of size $$d\ell$$ is:

$$\frac{d(\text{cost})}{d\delta} \cdot \frac{d\delta}{d\ell} = \frac{2c_0\delta}{(1-\delta^2)^2} \cdot \frac{1}{L+S}$$

where the factor $$1/(L+S)$$ follows from $$d\delta/dL = 1/(L+S)$$ — opening a long of size $$d\ell$$ increases $$L$$ by $$d\ell$$, shifting $$\delta$$ by $$d\ell/(L+S)$$. Positive when $$\delta > 0$$ — adding more longs to an already long-heavy book costs extra. Negative when $$\delta < 0$$ — adding longs when the book is short-heavy is effectively subsidized, because it moves toward balance. The function is symmetric and convex in $$\delta$$.

Now ask a second question: what about positions that are already open? The opening cost penalizes the act of creating imbalance. But a trader who opened a long yesterday when $$\delta$$ was small is still holding that position today when $$\delta$$ is large. The opening cost alone is insufficient — the pool also needs a continuous charge on the holding of imbalanced positions.

This gives a natural definition for the instantaneous funding rate:

$$r(\delta) = r_0 \cdot \frac{\delta}{1 - \delta^2}$$

When $$\delta = 0$$, the funding rate is zero — perfectly balanced books require no correction. As imbalance grows, the funding rate grows superlinearly, making it increasingly expensive to hold the dominant side. The dominant side pays the minority side. The mechanism self-corrects.

Voilà. We just derived why funding rates must exist — and why Binance, despite running hundreds of billions in perpetual exposure, has never been bankrupted by it.

The argument is structural, but the causal order matters. $$\delta \approx 0$$ is not the premise — it is the equilibrium that $$r(\delta)$$ produces. Because holding the dominant side incurs a continuous payment to the minority side, rational traders have a standing incentive to rebalance the book. When that equilibrium holds, any price movement results in longs losing exactly what shorts gain, and Binance's net settlement obligation is zero. It is not absorbing directional risk; it is a clearinghouse between two matched sides.

The failure condition: if the funding signal is suppressed — through opaque internal netting or misreporting — $$\delta$$ can drift without triggering correction. The exchange still appears to be a clearinghouse while accumulating net directional exposure. FTX's internal risk models reported matched books while the exchange held billions in net long FTT exposure. The mechanism is only as reliable as the signal it depends on.

Binance's actual funding rate formula looks different from $$r(\delta)$$. Rather than measuring position imbalance directly, it uses the deviation between the perpetual's mark price and the spot index price as a proxy — clamped to a cap to prevent runaway payments. [2] The intuition is the same: when longs dominate, buying pressure pushes the perpetual price above spot, the premium index goes positive, and longs pay shorts. When shorts dominate, the reverse. Price deviation is an observable market signal for $$\delta$$ — easier to compute on-chain than aggregating all open positions. The proxy is imperfect, but the corrective direction is identical.

The funding rate is the only self-consistent solution to the imbalance problem, regardless of how you measure that imbalance. Every exchange that runs perpetuals arrives at the same place.

5. What If We Rebuilt Binance Perpetuals Without Binance?

Binance's mechanism works. But it runs on a centralized server — one system, one state, no consensus required. And if you have been following the derivation so far, a thought might have occurred to you: this is just math. $$\delta$$, a cost function, a funding rate. The formula fits on half a page. What if you put this on-chain? What if you built the decentralized version — permissionless, trustless, no Binance in the middle? You could be first. This could be a company.

It turns out someone had the same thought. Several someones. dYdX launched in 2021. Hyperliquid followed. The on-chain perpetuals AMM already exists, and it is already running billions in volume. Sadly, you are not first.

It just does not work quite the way you would imagine.

The problem surfaces the moment you try to maintain a global $$\delta$$ on-chain. In Binance's centralized system, updating $$L$$, $$S$$, and $$\delta$$ after every trade is trivial — one process, one state, sequential writes. On-chain, every state update is a transaction that must be included in a block, executed by every node, and finalized by consensus. Two transactions cannot atomically and simultaneously update $$L$$, $$S$$, and $$\delta$$ without one reading a stale value or the other being blocked. This is not an EVM quirk — it is a fundamental property of any system maintaining a single global consensus state.

The consequence is a trilemma. You cannot have all three simultaneously:

• Global consistency: every participant sees the same $$\delta$$

• Real-time continuity: $$\delta$$ updates with every trade

• High throughput: many trades processed per block

This is the perpetuals AMM equivalent of the CAP theorem. Pick two.

The 8-hour funding rate snapshot — used by dYdX, Hyperliquid, and virtually every production perpetuals protocol — is the engineering resolution. Instead of computing $$\delta$$ continuously, the protocol:

1. Snapshots $$L$$, $$S$$ at fixed intervals $$T$$ (typically 8 hours)

2. Computes the time-weighted average imbalance over the window:

$$\bar{\delta} = \frac{1}{T}\int_0^T \delta(t) , dt$$

3. Settles the funding payment based on $$\bar{\delta}$$

This recovers global consistency and high throughput at the cost of real-time continuity.

The 8-hour number comes from BitMEX, which invented the perpetual swap in 2016 and chose it as an arbitrary design parameter to approximate daily lending rates divided by three. [3][4] Binance copied it. Every exchange that followed copied Binance. The window predates on-chain perpetuals entirely.

For Binance, $$T$$ is a policy parameter it can adjust. Under extreme volatility, Binance has shortened the settlement interval to one hour. [5] For an on-chain protocol, the serial write constraint turns $$T$$ into a structural floor. The same attack surface exists on Binance; Binance can close it by turning a dial. The on-chain protocol cannot.

6. A Thought Experiment With Real Money

You have been following the derivation. You understand $$\delta$$. You understand the 8-hour snapshot window. You understand that dYdX and Hyperliquid are on-chain — every position, every settlement, every liquidation is a public transaction on a public ledger. No KYC. No one can trace a wallet to a person.

A thought occurs to you. A malicious one.

The snapshot window is $$[0, T]$$, eight hours long. A snapshot just cleared — meaning the funding rate just settled to near zero. The next settlement is eight hours away. During this window, your holding cost is determined not by the instantaneous $$r(\delta)$$ you create, but by the time-weighted average $$\bar{\delta} = \frac{1}{T}\int \delta(t),dt$$ across the entire window. If you enter at $$t = 0$$, the integral starts from zero. For the first hours of the window, $$\bar{\delta} \ll \delta$$ — you are holding a massively imbalanced position at a fraction of its steady-state cost. The cost function penalizes opening at high $$\delta$$. It does not penalize holding at high $$\delta$$ until the window closes.

What if you used that window?

Here is what the attack looks like, step by step:

Step 1: Enter immediately after the snapshot. Open a large long position the moment a funding snapshot clears, pushing $$\delta$$ significantly toward $$+1$$. The cost function makes entry expensive — but expensive is not infinite, and the carry cost for the next eight hours is near zero. Your capital is at risk for one window. The funding clock just reset.

Step 2: Hold and distort the mark price. A concentrated long position creates sustained buying pressure on the perpetual. The mark price — computed as a TWAP over the window — begins to diverge from the spot index price. Other traders' long positions are now marked at inflated prices. Their short positions are approaching liquidation thresholds.

Step 3: Trigger liquidations. As the mark price displacement grows, undercollateralized short positions get liquidated — settled against your manipulated mark. The insurance fund absorbs the difference between the manipulated mark and the fair value. You collect the P&L from the displacement.

Step 4: Exit before settlement. Close your position before the snapshot. Your cost: the funding payment for one window, plus execution slippage. Your upside: the P&L extracted from liquidations exceeds the cost of capital.

The condition for a profitable attack is simply:

$$\text{PnL} > \text{cost}(\delta_{\text{attack}}) \cdot T + \text{slippage}$$

The 8-hour window determines how long you must hold capital at risk. Shorten $$T$$ and the attack becomes harder to sustain. Lengthen $$T$$ and the attack window grows. There is no value of $$T$$ that eliminates the surface entirely — only values that change its economics.

Even among people entertaining malicious thoughts, you are not first. How unfortunate. The attack vector was already in production before you finished reading this section.

7. The Blockchain Is Not Anonymous. It Is Pseudonymous.

On November 12, 2025, someone withdrew 3 million in USDC from OKX, split it across 19 wallets, bridged to Hyperliquid via Arbitrum, and opened 20–30 million in leveraged long positions on POPCAT — a Solana-based memecoin. They placed a 20 million buy wall near 0.21 to simulate organic demand, pushing the price up roughly 30%. Then they pulled the buy wall. POPCAT crashed 43% in minutes. Cascading liquidations followed. Hyperliquid's community-owned HLP vault absorbed $4.9 million in bad debt — roughly three months of prior profits, gone in an afternoon. [6]

This was not a smart contract exploit. The protocol functioned exactly as designed. It was a mechanism exploit — and the mechanism is the one described in Section 6. The attacker entered immediately after a funding snapshot, when carry cost on the imbalanced position was near zero. They held through the window, distorting the mark price via sustained buying pressure. Cascading liquidations followed as undercollateralized shorts hit their thresholds. Each of these steps follows directly from the attack surface derived above.

The one departure from Section 6's model is where the profit landed. Section 6 describes collecting P&L as the liquidation counterparty on-chain. In practice, that leg is structurally crowded out: the HLP vault acts as mandatory backstop for positions too large to be absorbed by the order book, which means the attacker cannot straightforwardly stand on the other side of the liquidations they trigger. The attacker did not attempt to collect on-chain. Instead, the on-chain position served only to distort the mark price. The actual profit came from opposing short positions held simultaneously on OKX and Bybit. The on-chain loss — $3–4 million in collateral — was not a cost. It was the weapon.

Was the attacker caught? Not formally. But recall the premise from Section 6: no one can track me down on-chain. That premise was wrong. Blockchain analyst Specter published an on-chain investigation the following day tracing the 26 wallets through OKX and Bybit deposit addresses, cross-chain flows via Polygon and Ethereum, and wallet reuse from a prior August 2025 manipulation. The trail led to BTX Capital, a U.S.-based crypto investment firm, and its founder Vanessa Cao. [7] The blockchain is not anonymous. It is pseudonymous — and pseudonymity, given enough on-chain activity, is effectively traceable.

No charges were filed. Vanessa Cao publicly denied involvement. [8]

Was the vulnerability fixed? Hyperliquid responded by tightening leverage limits and position caps on low-liquidity assets. The snapshot window remains. The root cause — the structural gap between real-time $$\delta$$ and periodic settlement — was not addressed. What was patched was the symptom: the specific leverage ratio and position size that made POPCAT eligible. The mechanism that produced the eligibility was left intact.

It is worth noting that this was not the first time. POPCAT was Hyperliquid's third major manipulation event in 2025, following JELLYJELLY in March [9] and another incident in July. The fixes after the first two attacks did not prevent the third. Patching leverage limits on thin markets is not the same as fixing the mechanism. The attacker simply waited for the next eligible token.

The structural attack surface described in Section 6 remains open. If you have a few million dollars and the appetite for it, the playbook is sitting right here.

Most readers do not. If you found this article searching for a way to get rich quick, the unfortunate reality is that you are probably not the target demographic for a $3 million kamikaze trade. Too bad.

For those who are — the argument that more demonstrated exploits force the industry to take structural vulnerabilities seriously is, at minimum, not wrong. Hyperliquid did not patch the snapshot window after the first attack, or the second. Whether a fourth incident changes that calculus is an open question.

8. The Math Is Solved. The Infrastructure Isn't.

The snapshot window is an engineering compromise forced by the cost of on-chain computation. Which raises the obvious question: what if that cost dropped dramatically?

The theoretical fix is to embed the funding rate continuously into the cost function itself, eliminating the snapshot window entirely. Instead of settling funding periodically based on $$\bar{\delta}$$, the cost of opening and holding a position at imbalance level $$\delta$$ already prices in the expected funding burden:

$$\text{cost}(\delta, t) = \frac{c_0}{1 - \delta^2} + \int_0^t r(\delta(\tau)) , d\tau$$

Under this formulation, the snapshot window collapses to zero. Every block settles the continuous funding accrual. The attack window disappears, because there is no gap between current $$\delta$$ and settled funding.

The reason this has not been implemented on Ethereum mainnet is straightforward: evaluating $$\int r(\delta(\tau)),d\tau$$ requires storing every intermediate state of $$\delta(\tau)$$. On a chain where every storage write costs real money, this is prohibitive. The serial write problem from Section 5 resurfaces immediately.

But the constraint is economic in nature. A practical approximation: settle funding every block, with $$\delta$$ computed from the previous block's state. This reduces the attack window from 8 hours to one block time. On Ethereum mainnet, that is ~12 seconds — still an attack surface, but orders of magnitude smaller. On a high-throughput L2 with sub-cent transaction fees and 250ms block times, per-block funding settlement becomes not just viable but cheap.

This is the design space worth thinking about. The mechanism is fully derived. The math is not the bottleneck. The question is purely infrastructural: which L2 provides the execution environment where continuous $$\delta$$ settlement becomes economically feasible? What does the gas model look like? How does the serial write constraint behave at 100ms block times?

Nobody has fully committed to this in production yet. That is either a gap in the market or a warning sign. Probably worth figuring out which.

9. What We Just Did

The chain above — from $$x \cdot y = k$$ to $$\delta$$, from $$\delta$$ to the cost function, from the cost function to the snapshot constraint, from the snapshot to the attack window, from the attack window to POPCAT — is not a series of independent observations. Each step follows structurally from the previous one.

We did not start with the attack. We started with the invariant, asked where it breaks, derived the replacement primitive, and followed the engineering constraints until an attack surface appeared naturally at the end of the chain. The three numbers that characterize the vulnerability — attack cost, window duration, mark price sensitivity — were not looked up. They were derived.

That is mechanism auditing. Not reading code for reentrancy bugs. Not running static analysis tools. Starting from first principles, tracing which design decisions create structural attack surfaces, and quantifying the minimum-cost exploit at each one.

The funding rate vulnerability is not in the funding rate calculation. It is in the decision to use a snapshot window — which is the only viable solution to the serial write constraint — which is caused by the requirement for global consistency. You cannot find this by reading the Solidity. You find it by understanding why the Solidity is written the way it is.

Three numbers. One chain of reasoning. That is the audit.

References

[1] Hayden Adams, Noah Zinsmeister, Dan Robinson. "Uniswap v2 Core," March 2020. https://uniswap.org/whitepaper.pdf

[2] Binance, "Introduction to Binance Futures Funding Rates." https://www.binance.info/en/support/faq/detail/360033525031

[3] BitMEX, "Perpetual Contracts Guide." https://www.services.bitmex.com/app/perpetualContractsGuide

[4] BitMEX, "Q3 2025 Derivatives Report: Funding Rates Structure." https://www.bitmex.com/blog/2025q3-derivatives-report

[5] Binance, "Important Updates on Funding Rate Settlement Frequency," May 2, 2025. https://www.binance.com/en/support/announcement/detail/3243c81a35bd4f0c86a37315c3dc96cc

[6] CoinDesk, "Peak Degen Warfare: Alleged POPCAT Manipulation Hits Hyperliquid with $4.9M Loss," November 13, 2025. https://www.coindesk.com/markets/2025/11/13/peak-degen-warfare-alleged-popcat-manipulation-hits-hyperliquid-with-usd4-9m-loss

[7] Tekedia, "POPCAT Attack on Hyperliquid Linked to BTX Capital Founder Vanessa Cao," November 15, 2025. https://www.tekedia.com/popcat-attack-on-hyperliquid-linked-to-btx-capital-founder-vanessa-cao/

[8] Cryptopolitan, "BTX Capital's Vanessa Cao Denies Role in POPCAT Manipulation on Hyperliquid," November 14, 2025. https://www.cryptopolitan.com/btx-capital-vanessa-cao-popcat-manipulation/

[9] OAK Research, "Hyperliquid and the JELLY Attack: Context, Vulnerability and Team Solution," March 28, 2025. https://oakresearch.io/en/analyses/investigations/hyperliquid-jelly-attack-context-vulnerability-team-solution