Hook:
- A prominent zk-rollup sees a 40% drop in daily active addresses over a single weekend. The team posts a blog: "We upgraded our sequencer to reduce latency." But the real story lies in the transaction logs. Users who had been sending custom calldata—encoded with specific nonce patterns and fee caps—suddenly found their transactions failing. The upgrade changed the mempool logic. The protocol team assumed users would adapt. They didn't. Four thousand LPs withdrew. The price of the native token dropped 12% in 48 hours.
I've seen this pattern before. In 2017, it was ICO smart contracts with integer overflows. In 2020, it was Uniswap v2 pairs with incorrect slippage parameters. Now, in 2025, it's the same problem wearing a different hat: users are performing a form of "prompt engineering" on Layer 2 protocols, and most protocol developers don't even know it exists.
Context:
Let's step back. The core idea of human feedback reinforcement learning (RLHF) is that you train a model to prefer certain outputs by having human annotators rank responses. The model learns not a "correct answer" but a "preferred style"—more detailed, more structured, more willing to admit uncertainty. That alignment happens at the training stage, done by the model developer.
But there's a second stage of alignment that happens at inference time: the user's prompt. The same model, with the same parameters, produces wildly different outputs depending on how the user phrases the request. A prompt like "Explain RLHF" yields a textbook definition. Add "as if I'm a beginner" and the output changes entirely. The user is doing "alignment work"—shaping the model's behavior through natural language.
Now map this to blockchain. A Layer 2 protocol is a system of rules encoded in smart contracts. The protocol's "behavior" is defined by its state machine—the allowed transitions, the fee mechanisms, the ordering rules. The user interacts with this system by submitting transactions. Each transaction is a "prompt"—a set of parameters (gas limit, calldata, nonce, priority fee) that the protocol interprets. The protocol's response depends on how the user constructs that prompt.
Yet most users treat transactions as black boxes. They click "approve" on a wallet interface without understanding that the calldata they just signed contains a specific function selector that triggers a particular code path. They don't know that the priority fee they set determines whether their transaction gets included in the next block or waits for hours. They are, in effect, speaking a language they barely understand.
Core:
Based on my experience auditing zk-rollup withdrawal engines—I spent five months in 2025 verifying the soundness proofs of a leading Layer 2 solution—I've come to see transaction construction as a form of "prompt engineering" for decentralized systems. The parallel is precise.
In RLHF, the reward model is trained on human preferences. The language model learns to maximize that reward. In a Layer 2, the reward is ultimately the state transition—the protocol's execution of the user's intent. But the "reward model" is the smart contract logic itself. The user's transaction is the prompt. The protocol's response is the output.
Consider a simple example: a token transfer on Arbitrum. The user constructs a transaction with: - to: the recipient address - value: the amount - data: empty (for a simple transfer) or encoded function call (for ERC-20) - gasLimit: the max gas to use - maxPriorityFeePerGas: the tip to the sequencer
Every parameter is a choice. Set gasLimit too low, the transaction reverts. Set maxPriorityFeePerGas too high, you waste funds. This is not different from asking a language model: "Explain RLHF" versus "Explain RLHF in simple terms, using examples, and keep it under 200 words." The prompt structure determines the output quality.
But the analogy goes deeper. In RLHF, the model's training data determines its knowledge boundaries. No amount of prompt engineering can make a model give a correct answer about a topic it was never trained on. Similarly, in a Layer 2, the protocol's smart contract defines the possible states. No amount of clever calldata can make a protocol execute a function that doesn't exist. The prompt works within the constraints of the system.
Yet within those constraints, the user's "prompt" can dramatically alter outcomes. I've seen traders exploit the ordering of multi-call transactions to front-run their own swaps—a technique known as "atomic arbitrage" that relies on precise calldata construction. The protocol's mev-boost software processes the transactions in order, but the user's prompt (the sequence of function calls) determines the profit. It's not a bug; it's a feature of the user's alignment work.
This alignment work is invisible. It's not documented in the protocol's whitepaper. It's not part of the smart contract audit. It's a skill that users develop through trial and error—a kind of "operational literacy" that determines who wins and who loses in a permissionless system.
Let me give you a concrete example from my own experience. In 2024, I was analyzing the fee market of a popular L2 that used a priority fee auction. The protocol's documentation said: "Transactions are ordered by maxPriorityFeePerGas, highest first." Naive users set high fees to get included quickly. But I discovered that the sequencer's internal ordering algorithm also considered the transaction's gasLimit and the current block's remaining capacity. A transaction with a slightly lower tip but a carefully chosen gasLimit (just enough to execute) would be included before a high-tip transaction with a bloated gasLimit that consumed too much space. The protocol's behavior was not a simple linear function of the fee. It was a multi-dimensional optimization problem. The users who understood this—who "prompted" the sequencer with the right parameters—got better execution. They were performing invisible labor.
Now, the protocol's developers didn't design this. It emerged from the interaction between the sequencer's code and the constraints of the Ethereum execution environment. The protocol's "alignment" with user intent was incomplete. The users had to compensate by adjusting their prompts.
This is not a bug. It is a feature of all complex systems. The question is: who does the work? In RLHF, the model developer does the alignment at training time. The user then does additional alignment at inference time through prompt engineering. In Layer 2s, the protocol developer does the alignment at deployment time—defining the smart contract logic. The user then does additional alignment at transaction time through parameter selection. The invisible labor is simply shifted from the developer to the user.
But here's the contrarian angle: this invisible labor is actually a form of censorship resistance. Because the protocol cannot fully control how users construct their transactions, users retain the ability to express complex intents—to execute atomic swaps, to batch operations, to encode conditional logic in calldata. If the protocol forced all transactions into a rigid template, it would eliminate the user's ability to innovate. The invisible labor is a byproduct of flexibility.
Contrarian:
Most security analyses focus on smart contract vulnerabilities—reentrancy, integer overflow, oracle manipulation. But the real blind spot is the user's transaction construction. I've seen audits that verify the correctness of a protocol's withdraw() function but never test what happens when a user submits a transaction with unexpected calldata. The protocol's behavior under strange prompts is rarely documented.
Consider this: in 2023, a major L2's bridge suffered a $1.5 million exploit because a user submitted a transaction with a msg.value that exceeded the expected deposit amount. The protocol's code didn't check the overpayment. The user's "prompt"—a seemingly malicious transaction—triggered a state change that the protocol developers hadn't anticipated. The exploit was not a bug in the smart contract logic; it was a failure of the protocol to handle unexpected user prompts.
Impermanent loss is real. Do your math. But the real loss in L2s is often informational—the user's inability to correctly prompt the protocol. The protocol's assumption that users will behave in a certain way is a form of "alignment debt." Each unexpected transaction is a test of that assumption.
I've also noticed that the same user who meticulously crafts a prompt for a language model—setting persona, format, constraints—will blindly copy-paste a transaction hash into a block explorer without reading the decoded calldata. The skills are transferable, but the awareness is not. The blockchain industry has spent billions on L2 scaling without spending a penny on user education about transaction prompts. The result is a system that is mathematically secure but operationally fragile.
Takeaway:
Entropy wins. Always check the fees. But also check the calldata. The next major vulnerability in L2s will not be a reentrancy bug. It will be a collection of users who, through a combination of poorly constructed prompts, accidentally trigger a cascade of failing transactions that overwhelm the sequencer. The invisible labor of transaction construction is about to become visible—when the protocol stops and the users realize they've been the ones keeping it running all along.
2017 vibes. Proceed with skepticism. But with a new kind of literacy: read the transaction as if it were a prompt. Understand the protocol's reward model. Debug your params before you hit send. The ones who do will survive the next chop. The rest will be the liquidity that feeds the entropy.
