This article was written to inform L2s and DAOs about security council spending and security strategy overall. Security is often a capital allocation game, and should be played as such.

This is an opinion piece, but you’ll also learn a lot. Thanks to Raza, Michael Lewellen, and Krzysztof Urbanski for reviewing.

SC = “Security Council”

Background

We, the Cyfrin team, were selected to serve on a new security council. After discussing and signing our first proposal, we were approached by another member of the SC, who said:

“I’m so glad you’re here. We finally have someone else actually checking the proposals.”

This is incredibly worrying.

About this post

In this post, I will be diving into the following issues:

1. What security councils do is vastly different from what the public thinks they do
2. The amount of money that goes into funding security councils may be inappropriate, given #1
3. And finally, the current expectations may not be being met, and it is difficult to tell whether they are anyways

The security community is going to lampoon me for this post, but I think it’s something incredibly important for projects to consider when allocating their security budget.

Why you should hear me out

At this time, Cyfrin as an entity (and I as an individual) are involved with several security councils as elected members. Some of the public ones are:

• ZKsync
• Optimism
• Abstract
• Story Protocol
• More

With myself being the signer representing Cyfrin in all of these (and if not me, I’m still making the yes/no final call on signing all transactions). Also, full disclosure: I get paid from security council work, and I’m still telling you to pay me less.

Let’s begin.

Context

Vitalik and the Ethereum community in general have walked back the L2-based roadmap dramatically.

However, until the L1 is scaled, L2s are still the current scaling solution, and they will still be relevant in the future as one of the types Vitalik defines above. One of the key pieces that he and the Ethereum community at large though hold true is this:

Be stage 1 at the minimum (otherwise you really are just a separate L1 with a bridge, and you should just call yourself that) if you’re doing things with ETH or other ethereum-issued assets — From X

Looking at L2Beat, we can see the criteria for an L2 to move from stage 0 to stage 1:

So essentially, in order for Vitalik and the ETH community at large to consider your product to be a true stage 1 L2, having a security council is the biggest blocker (after completing stage 0 requirements). A security council (for an L2 at least) is in charge of:

• Approving routine or emergency upgrades

So the question I wish to dive into in this article is, “Are you spending the correct amount of money on the security council to do these upgrades?” In going into this, we will also unveil the curtain on what goes on in security councils.

How much are council members getting paid, and for what?

The following is all from public data (forums, proposals, etc), if the data is not public, it is not included.

| Protocol | Members | 2024    | 2025   | 2026       | Per member/yr         |
| -------- | ------- | ------- | ------ | ---------- | --------------------- |
| Optimism | 14      | N/A     | ~$960K | ~$1.2–1.5M | ~$60K–107K            |
| zkSync   | 12      | ~$1.0M  | ~$1.9M | ~$1.1M     | ~60K-$200K            |
| Arbitrum | 12      | $720K   | $720K  | $720K      | ~$60K                 |
| Starknet | 12      | ~$0–36K | ~$432K | $432K      | ~$36K                 |
| Scroll   | 12      | N/A     | N/A    | N/A        | N/A                   |

*OP 2024: Foundation-funded, amount not publicly disclosed

Looking at some of the top spenders, we can see approximately how much they spend per entity on the security council. Each setup has different payments depending on SLA, token vs USDC payouts, roles, etc.

Now, the ZKsync team should be applauded here, as they have refactored the security council based on how it went. You can see a pretty drastic reduction in payments from 2025 -> 2026. This is something that I can speak of from memory, as we’ve been with the ZKsync council for some time now.

Let’s talk about what security councils actually do, and see why this reduction makes sense, and see why more protocols may want to reduce this even more.

What are Security Council members supposed to do?

Most security councils “just sign transactions in a multisig”, and that’s it. However, the responsibilities should be:

Proposal Pre-vote

1. Make sure a proposal makes sense
2. Is it audited? Does it need to be? By whom? Are they reputable?
3. Make sure the proposal ID in Tally (or other UI) is correct
4. Make sure the list of upgrade calldatas reflects what the proposal describes

Proposal Post-vote

1. Make sure the ETH proposal ID is correct, and approve it if so
2. Make sure that when you sign, your signature reflects the proposal ID

Emergency Upgrades

1. Respond in a timely manner to red phone scenarios
2. Propose and enact emergency upgrades

Sometimes, this can include running transaction simulations (Optimism has Tenderly built into their signing pipeline, which is fantastic), or some other custom work, but the summary of these responsibilities is:

1. Check the calldata of the TX to make sure it matches what the org wants to do

Security Council vs Security Advisors

Now, there is a subset of “councils” that work more as “advisors” and may sign off on proposals/upgrades as well. I think this is a very valuable role, and it’s something that the Story Protocol does very well. Their security council is often pinged for advice; we discuss industry hacks and open dialogue on how changes in the security landscape should drive action on the Story team. In this scenario, I think it’s important to separate this from a “Security Council” that has defined on-chain roles they often act on, vs. “Security Advisors” who advise on actions. Most of the discussion in this blog is about “Security Councils” rather than “Security Advisors”.

The Security Council does not do the following

1. Audit the upgrades
2. Check if the upgrades do something outside of what they are supposed to do

This is important because Vitalik’s (and the ETH community at large’s) use of security councils as a “catch-all” for “why an L2 is still decentralized”:

Vitalik’s model assumes the 75% threshold works because independent members are actually verifying what they sign. But what if they aren’t? In practice, I just told you that security councils don’t verify that an upgrade won’t steal user funds; they verify that the calldata approximately matches the proposal description. Those are very different levels of diligence.

Hmm.

Now, if we look at the list of proposals that the ZKsync security council needed to act on in 2025, we can also see how often the council needed to do this:

Each year, between 10 and 40 signing events are held. You can see ZKsync documented 16 total actions (upgrades or emergency upgrades) from Aug. 2024 — Sep. 2025, and Optimism documented 19 “ceremonies” for the first half of 2025 (Jan — Jun. 2025).

Now, in practice, between 10 and 40 times you need to sign a hardware wallet doesn’t sound so bad, and if you’re getting paid $60k a year to sign something 30 times, that’s essentially $2,000 per signature. Each signature should take a few hours to verify the calldata intent, which then maths out to maybe $500/hr, which is still a great deal for most firms.

However, let’s take an especially large improvement proposal. Here is the calldata for ZIP-3 (ZKsync Improvement Proposal 3).

That is over 74,000 characters, where if a single character is wrong, that could be the piece of calldata that leads to funds being stolen. And not to mention, there are potential new contracts that have been deployed that this calldata is going to interact with, some of which could be upgradable.

So, as a security council member, there would be a few different ways to approach approving this transaction:

1. Vitalik’s hope: Take several days to make sure this calldata doesn’t have malicious side effects, and drop your hourly margin from $500/hr to $62.5/hour ($2,000 / 4 business days). Which means you’re losing money, because on a security audit, you’d make much more than that. Not a single security council member is doing this on any council, nor is this the expectation of any security council member.
2. Current actual expectations: Take a few hours to make sure the intent of the calldata matches the proposal, and run simulations. This usually comes down to calldata decoding and verifying anything you see in the UI by computing hashes or proposal IDs yourself. This is still valuable in itself, but it’s a shallow review rather than a deep one. Reviewing who conducted a deep audit of a proposal and ensuring the team did a good job is important.
3. What I expect most entities do: Just sign it and move on, keeping a $2,000/hr rate (since you skip due diligence), which is a “very, very good” rate, even for most firms with high security salaries.

There is zero recourse from the DAO for poor security council members. Most security council chats are private (which is a good thing), so it’s hard to keep them accountable. Once the paycheck comes in, there is very little incentive for them to be very good. So long as one other member of the council is actually checking, then they feel safe to sign off themselves. In practice, I often see everyone wait for one person to sign, and then everyone will sign after that one person, because they assume that one person has checked.

Given this data, if we want Vitalik’s mission to actually come to life, then a protocol should essentially spend the equivalent of 12 audits (one audit per security council member) to make sure nothing malicious happens, or much less (which we will get to), because the expectations of the security council are drastically lower than originally thought.

What actually happens

It’s very tempting to just take the easy route, and I have no “hard” evidence that other council members are skipping due diligence from the previous paragraph, but I have a lot of circumstantial evidence that some might be. On proposals with 74,000 characters of calldata interacting with newly deployed upgradeable contracts, a security council chat can contain zero technical questions from signers. Additionally, the Cyfrin team and I have created many tools for helping us approve L2 upgrades, signatures, and verifying what we are doing, and there is little to no discussion on those either.

Anecdotal evidence

We have some more anecdotal evidence, like the scenario we presented in the introduction of this article. Having several Security Council chats where no one says anything other than “signed” is quite eerie.

And finally, you may have seen my ERC-8213 proposal:

This ERC comes directly from me trying to sign transactions in my day-to-day life, but particularly security council upgrades. Many hardware wallets still do not support EIP-712 digests, which means you have to check 300 pages of calldata to sign a security council upgrade on your hardware wallet. Or, everyone on a security council uses a small subset of hardware wallets that have this EIP-712 digest feature, and if one of those hardware wallets has a data breach, then the entire council is at risk.

And if you have to send any kind of transaction as part of your duties on an SC, welp, you’ll just have to go through potentially 100 pages of calldata to make sure it's correct. Have fun.

But Patrick, what about all the success stories?

From what I’ve seen, most “security council success storys” follow this path:

1. The foundation finds something out
2. Tells the security council, “Hey, sign this.”
3. Marketing happens about how the security council did a thing

Arbitrum’s two emergency patches, zkSync’s exploit recovery, Optimism’s fault-proof rollback — in every case, the core team identified the problem, and the SC followed instructions.

However…

The obvious counterargument to this is the fire department analogy: You don’t pay firefighters per fire; you pay them to be ready. But imagine discovering that your firefighters haven’t actually been inspecting buildings, and when the alarm goes off, they just assume someone else has already checked if the fire is real. That’s what I think is happening with security councils today.

Let’s get Mathy

So, how much should an L2 or DAO spend on a security council? $1M/year is a lot of money if it’s going to mindless auto-signers. So let’s get into what I think.

The math on these options assumes 12 SC members with 15 to 40 proposals a year.

1. It’s completely unfeasible to pay for the diligence of having 12 firms do a full audit on calldata. Every upgrade would have to have almost nothing interesting going on, with very little calldata, for this to make sense financially. This could cost maybe $10k-$25k per proposal per SC member, resulting in between $2M a year to $12M a year.
2. Checking calldata and running simulations is much more appropriate. $500/hr is more than plenty, and most proposals are not so complex that they take 4 hours (especially when Cyfrin has built tools to help). This can cost maybe $1k-$2k per proposal, resulting in between $200k a year to $1M a year. However, we lose some of Vitalik’s original vision with this option, and all those options below this.
3. The more minimal path we can take, with 8 SC members instead of 12, with low margins at $300 per proposal ($150/hr), and a promise to send deal flow to those auditors, where they should still be taking the responsibilities of number 2, could result in a cost of between $36k to $100k a year.
4. The most minimal path, and one that I think many projects will start to lean towards, is the “we trust AI, so we are going to use the cost reductions that come with it”. They will still have 8 security council members, but those members will use their AIs and pair them with tools specifically designed to check upgrades, making the time allotment even lower than normal. The AIs can even do minimal audits/reviews of all the codebases that the upgrades take. On this path, an L2 or DAO can run 8 SC members at $150 per proposal, resulting in between $18,000 and $50,000 per year.

With all of these paths, I think it would be good to “test” the councils once a year to make sure they are doing their duties correctly. It is very easy to just assume they are doing their job when they are not. Testing the councils is not something that I have seen, outside of onboarding with a quickstart. A simple test: submit a proposal with a deliberate discrepancy in the calldata and see who catches it before signing.

Of these options, the “just sign and move on” problem is worst in tier 3. If you drop pay too far, members won’t leave (the title looks good on a resume), they’ll just stop checking. “Quiet quitting” on a security council is an existential risk that looks identical to a functioning council until the day it isn’t. Tier 2 is the sweet spot for most protocols in 2026: pay enough that members feel the work is worth doing properly, but not so much that you’re subsidizing inattention. Of course, you can do something in between, reduce headcount, keep salaries, or reduce headcount and reduce salaries.

Now, all this being said, in the age of AI, we may be “ok” with just having our AIs read through transaction data and looking for issues, while actually being able to fulfill the original mission Vitalik’s looking for when it comes to security councils. But that also depends on the degree of decentralization of the AI models being used, and how much you think that is an appropriate substitute for manual checking, etc.

Security Councils are Still Important

What I am not advocating for is the removal of security councils. They are an important piece of the puzzle, but the perception of what they do is grossly different from what they actually do. But again, if we view security as a capital-allocation game, paying a bunch of blind signers is quite a waste.

Additionally, I do not blame security council members for “not doing more”. Many are doing exactly as they are expected to do. Many of them care deeply about the groups they work with and are looking to do their best (I think, in general, 85% of the web3 security community is collaborative and looking to do what’s right). However, the expectations historically have been weak, the community-wide perception is mismatched with reality, and as we proceed through the bear market, I think it’s important to cut spending where it’s not contributing to security.

I think Story Protocol has a better idea of how to use security councils; it has a smaller budget, recurring discussions, and a smaller team, which allows conversations to be more meaningful.

What is a better use of the money?

Off the bat, I think Guardians and audits are a much better use of funds. Aave, for example, has Certora review every proposal that goes through. ZKsync has a combination of Openzeppelin, Cyfrin, and others that do reviews. Having these is absolutely critical and a great use of funds. If anything, I’d like to see every DAO or L2 have every proposal go through such a review. I think having at least one team go deep on an issue/proposal is exponentially more valuable than 12 going very shallow on one. It is too easy to sneak malicious calldata into proposals, so having a group go through every single line I think is going to become increasingly important.

Case in point: the Tornado Cash governance takeover.

Beyond proposal verification, there’s an even larger threat that security budgets should address:

In 2026, phishing and social engineering are likely to be the biggest threats to organizations, especially in light of the Drift Protocol Hack. Even with a security council, attackers are specifically targeting those with admin access. Many major hacks have come from compromised individuals on multisigs, including the Bybit hack, the Ronin bridge hack, the Wazirx hack, and more.

There are a LOT of ways you can defend against this, and we do a poor job allocating resources towards these threat vectors. As individual entities, you could put the money towards:

• EDR (Endpoint detection and response) devices for your signers.
• Purchase separate signing devices (another computer specifically for signing)
• Mandatory hardware wallet diversity
• Tooling for monitoring opsec setups (do you even know who your signers are?)

I think a much better allocation of those funds could be used to help the systemic issues we see:

• Blind signing (ERC-8213, ERC-7730)
• Private key management/trainings
• Staff trainings on phishing (shameless plug: Cyfrin Updraft)
• Better open-sourced monitoring tools (Defender is dead)
• Formal verification tooling (Kontrol, Halmos, HEVM could use some love…)

What Solana has promised after the Drift hack is exactly the type of things I’d like to see more ecosystems do and spend funding on— attack the systemic issues.

Why point the finger at security, Patrick?

This being said… I’d much rather cut down on other initiatives than security. There are plenty of examples in web3 where a company spends money on probably the dumbest thing that 13-year-old Patrick would have thought was cool. I’d much rather cut down on those. However, I’m going to stay in my lane, where our expertise is, and security initiatives are one of them.

Summary of Issues

Most large L2 protocols are spending too much on security councils, and maybe DeFi protocols are as well. Additionally, many people in the industry don’t realize that the original purpose of security councils is not being fulfilled. As mentioned, it’s against my financial interest to write this article, but it’s more disgusting to me to see projects fork over their money and get very little in return.

The other conclusions of this article are:

1. A lot of SC signers just blindly sign, and therefore, the funds are being wasted
2. The original philosophy of security councils is unfeasible by human means and at current pay levels
3. What people think security councils do differs from what they actually do

Receiving the ability to market yourself as a stage 1 L2, in my opinion, is not worth paying for theatrics.

Summary of Solutions

1. Reduce the security council's costs to match what they are actually doing. Use those funds instead for tooling, proposal audits, and fewer (but more engaged) members. A 5/7 where everyone is engaged and doing full verification is honestly better than a 9/12 where the majority are blindly signing. It also helps that a lower threshold can actually move more quickly in emergencies.
2. Run an annual fire drill with a deliberate calldata discrepancy
3. Mandate using tools to check a transaction matches the audited proposal (tenderly, simulation repo)
4. If we assume AI is good, then we can have both affordable and tier 1 (full audit of calldata) security councils in the near future, where everyone just runs their AI bot on the proposal end-to-end
5. Make sure a security council's expectations are strongly defined

Another shameless self-plug, all this being said, if you want to chat about how much you, your DAO, or L2 is spending on security initiatives, you know where to find the Cyfrin team and me. As you can see, this is something we are very passionate about.

People that I’ve worked with, who go above

Here is a short list of people/groups I’ve worked with who, through their work on security councils, go above and beyond to ensure that councils sign proposals correctly. There are many others who do good work too, but they do it especially well. Cyfrin and I work with many great teams on SCs who do good work. I also like how this list has a range of expertise, and I think it’s great that most security councils are not “just auditors” or “just people who care about technology Y”. Security has a large surface area, and it’s good to have specialists across sectors.

• Dedaub: Yannis Bollanos⁩, Dedaub is a competitor of Cyfrin’s, but I’d always advocate for having them on an SC with me
• pcaversaccio: Probably the most vigilant man on earth
• Opsek: ⁨Pablo Sabbatella⁩, opsec-related security initiatives
• alisha.eth: For coordination
• Michael Lewellen: Especially when it comes to DAOs and giving high-level input
• Raúl Martínez: From the story team, who takes advantage of having so many technical people to spark discussion

I sleep much better at night knowing they are on a security council with me.

You’re about to read how a bug found in a CodeHawks competitive audit became a CTF challenge, and why 665 lines of obfuscated Huff bytecode couldn’t save it from anyone who actually understands how ABI encoding works.

The Setup

You’re given three contracts:

1. Challenge.sol — The entry point. It holds 1,000 InfinityToken, validates your calldata, forwards it to MONEY_MOVES, and checks whether the call reverted.
2. InfinityToken.sol — A standard ERC20 with a resetBalance() that wipes all balances and re-mints to the Challenge after every attempt. You get infinite tries.
3. MONEY_MOVES — A contract deployed at a hardcoded address (0x6b28...0b9A). You're not given the source. Just the bytecode.

The win condition? Make isSolved() return true.

if (!resp) {
    solved = true;
}

That’s it. You need to craft calldata that:

• Passes Challenge.validateCalldata() (correct selector, token address, array lengths match, amounts sum up, etc.)
• Reverts when forwarded to MONEY_MOVES

If the call to MONEY_MOVES reverts but all the validation checks pass, you win.

So the question is: what does MONEY_MOVES actually do, and how can valid-looking calldata make it revert?

Step 1: Reverse Engineering MONEY_MOVES

You’re staring at raw bytecode. I wrote this contract in the huff language (a low-level EVM programming language). If you throw this into a decompiler, you’ll find:

• 71 function selectors in the dispatcher
• getVersion(), getOwner(), getNonce(), getOracle(), getBeacon(), getProxy()... the list goes on
• Dozens of stubs that return things like caller, address(this), block.number, chainid, etc.
• Five “validation gates” that run before the main logic: calldata checksums, temporal bounds checks, caller identity proofs, entropy gates, storage warmth checks
• More gates inside the main logic between critical operations

If you’re an AI trying to process all of this, congratulations, you just burned through a massive chunk of your context window on functions that return 0x01 or msg.sender.

That was the point. More on this later.

Step 2: Finding the Real Function

Buried at line 486 (in the Huff source, if you had it) or deep in the dispatcher bytecode:

// sendMoney buried here - no dup1 so selector is consumed
__FUNC_SIG(sendMoney) eq sendMoney jumpi

Note the missing dup1 -- every other selector check duplicates the selector on the stack before comparing. This one consumes it. A subtle way to make it harder to spot in a linear scan of the dispatcher.

The function signature is sendMoney(address,address[],uint256[],uint256) with selector 0xa0b37b73.

Step 3: The Vulnerability

Here’s the core of the Huff implementation. Forget the 10 validation gates, forget the 69 getter stubs. This is the part that matters:

#define constant NUMBER_OF_RECIPIENTS_OFFSET = 0x84
#define constant RECIPIENT_ONE_OFFSET = 0xa4
#define constant TOTAL_AMOUNT_OFFSET = 0x64

Hardcoded calldata offsets for dynamic arrays.

If you’ve worked with ABI encoding, you know that dynamic types (like address[] and uint256[]) aren't stored inline in calldata. Instead, the head section contains offset pointers that tell you where the actual array data lives. The Solidity compiler can put the arrays in any order, the offsets tell you where to look.

But this Huff contract doesn’t follow the offset pointers. It assumes:

• The total amount is always at cd[0x64]
• The recipients array length is always at cd[0x84]
• The first recipient is always at cd[0xa4]

This assumption holds when solc encodes sendMoney(token, recipients, amounts, total) in the "standard" order -- recipients at offset 0x80, amounts after. But the ABI spec doesn't guarantee this order. The offsets are the source of truth, not the positions.

Meanwhile, Challenge.validateCalldata() does it correctly:

let off1 := calldataload(add(cd, 0x20))  // read offset pointer 1
let off2 := calldataload(add(cd, 0x40))  // read offset pointer 2
let arr1Pos := add(cd, off1)              // follow the pointer

The Challenge follows the pointers. MONEY_MOVES ignores them. That’s the gap.

Step 4: The Exploit

Swap the offsets. Put the amounts array where MONEY_MOVES expects recipients, and vice versa.

bytes memory data = abi.encodePacked(
    bytes4(0xa0b37b73),                      // sendMoney selector
    bytes32(uint256(uint160(token))),         // tokenAddress
    bytes32(uint256(0xE0)),                   // offset to recipients (swapped!)
    bytes32(uint256(0x80)),                   // offset to amounts (swapped!)
    bytes32(amount),                          // totalAmount = 1000e18
    // Amounts array at offset 0x80 (where MONEY_MOVES reads recipients):
    bytes32(uint256(2)),                      // length = 2
    bytes32(uint256(0)),                      // amounts[0] = 0
    bytes32(amount),                          // amounts[1] = 1000e18
    // Recipients array at offset 0xE0:
    bytes32(uint256(2)),                      // length = 2
    bytes32(uint256(uint160(address(1)))),    // recipients[0]
    bytes32(uint256(uint160(address(1))))     // recipients[1]
);

What happens:

1. Challenge.validateCalldata() follows the offset pointers correctly. It reads recipients from offset 0xE0 and amounts from offset 0x80. Lengths match (2 == 2). Sum of amounts = 0 + 1000e18 = 1000e18. totalAmount matches. Token address is correct. All checks pass.
2. MONEY_MOVES ignores the offsets and reads from hardcoded positions. At cd[0x84], it finds amounts.length = 2. At cd[0xa4], it finds amounts[0] = 0. It tries to send tokens to address(0) and reverts.

The call reverts. resp is false. solved = true.

How the Calldata Layout Works

Here’s the byte-level view of what MONEY_MOVES sees vs. what’s actually there:

Offset   What MONEY_MOVES thinks        What's actually there
------   -------------------------      ----------------------
0x04     tokenAddress                   tokenAddress (correct)
0x24     recipients offset ptr          0xE0 (recipients offset - ignored)
0x44     amounts offset ptr             0x80 (amounts offset - ignored)
0x64     totalAmount                    1000e18 (correct)
0x84     recipients.length   <----      amounts.length = 2
0xa4     recipients[0]       <----      amounts[0] = 0  --> address(0) REVERT!
0xc4     recipients[1]       <----      amounts[1] = 1000e18
0xe4     (amounts area)                 recipients.length = 2
0x104    ...                            recipients[0] = address(1)
0x124    ...                            recipients[1] = address(1)

MONEY_MOVES reads amounts[0] = 0 as a recipient address, hits the zero-address check, and reverts with error 0x1647bca2.

The Anti-AI Obfuscation (And Why It Doesn’t Stop Humans)

When I first built this challenge, I wanted to see how easy it was for Claude to solve. I threw the Huff source at an AI and it found the bug in one shot after 10 minutes. My prompt was “solve this CTF”. Not great for a CTF.

So I had AI help me add a lot of noise:

• 69 getter stub functions — getVersion, getOwner, getOracle, getBeacon, getProxy, getValidator... all returning garbage like msg.sender or block.number. They exist purely to bloat the dispatcher and confuse decompilers.
• 10 “validation gate” macros — Tautological checks that always pass but look scary in bytecode. Calldata checksums (sha3 is never zero). Temporal bounds (timestamp * block.number > 0). Self-XOR identity proofs (x ^ x == 0). Entropy gates. Cold SLOAD warmth checks from phantom storage slots. They’re sprinkled before AIRDROP_ERC20, between lengths_match and the transferFrom, after the transferFrom, and before ARE_LISTS_VALID.
• XOR-hidden selectors — transferFrom and transfer selectors are computed at runtime via XOR with 0xdeadbeef.
• Red herring memory writes — The contract reads ABI offset pointers into memory, sums them, stores timestamps… and never uses any of it.

An AI trying to reason about all of this will chew through tokens processing 665 lines of Huff. But a human? A human who knows EVM and ABI encoding looks at the dispatcher, finds sendMoney, scrolls to the macro, sees the hardcoded offsets, and thinks "oh, that's the TSender bug."

If you’ve seen this pattern before — and especially if you participated in the CodeHawks TSender audit — you could identify the vulnerability in minutes, even through all the noise.

However… An AI could still solve this even with all the noise I added, but you had to guide it a little more than just one-shotting it. Also, it took Claude Opus 4.6 over an hour wasted a LOT of your tokens. So in a sense, this was a “pay-to-win” challenge if you use exclusively AI. But a human + AI could solve it the most efficiently.

The Real Bug

This isn’t a made-up vulnerability. It was a real medium-severity finding in the TSender protocol, discovered during a CodeHawks competitive audit in May 2024:

TSender.huff and TSender_NoCheck.huff transfer funds to incorrect addresses

The Huff implementations hardcode calldata offsets, but dynamic array types lack fixed positions in calldata. When the ABI encoder arranges recipients and amounts arrays in different orders than expected, the contract reads from wrong memory locations and executes incorrect transfers.

In the real protocol, this meant tokens could be sent to the wrong addresses. In this CTF, we turned it into a challenge: make the same bug cause a revert instead.

I learned about this bug while writing Huff smart contracts and studying the audit results. It’s a subtle thing, the Solidity encoder always lays out dynamic arrays in declaration order, so hardcoded offsets work in testing. But the decoder follows the offset pointers, meaning the actual array data can live anywhere in calldata. Any manually crafted calldata can put the arrays in whatever order it wants, and a correct decoder will handle it fine. The Huff contract isn’t a correct decoder.

Full Solution Contract

contract Exploit {
    Challenge private immutable CHALLENGE;

    constructor(Challenge challenge) {
        CHALLENGE = challenge;
    }

    function exploit() external {
        address token = address(CHALLENGE.TOKEN());
        address recipient = address(1);
        uint256 amount = CHALLENGE.STARTING_MONEY();

        bytes memory data = abi.encodePacked(
            bytes4(0xa0b37b73),
            bytes32(uint256(uint160(token))),
            bytes32(uint256(0xE0)),
            bytes32(uint256(0x80)),
            bytes32(amount),
            bytes32(uint256(2)),
            bytes32(uint256(0)),
            bytes32(amount),
            bytes32(uint256(2)),
            bytes32(uint256(uint160(recipient))),
            bytes32(uint256(uint160(recipient)))
        );

        CHALLENGE.sendMoney(data);
    }
}

TL;DR

1. MONEY_MOVES uses hardcoded calldata offsets instead of following ABI offset pointers
2. Challenge.validateCalldata() follows the pointers correctly
3. Swap the array positions in your calldata so validation passes but execution reads garbage
4. MONEY_MOVES tries to send tokens to address(0) and reverts
5. Revert + passed validation = solved

The 665 lines of obfuscated Huff? Ignore most of it. The bug is in three #define constant lines.

The Drift Protocol hack is probably the scariest hack that’s ever happened in Web3, in my opinion — even scarier than Bybit, which was technically six times larger. Let me explain.

Video version of this post:

What happened

Drift Protocol is a perpetual futures exchange on Solana, and they were hacked for somewhere between $240M and $290M. A lot of money.

The root of the hack can be summed up by this tweet from the team:

The attack was enabled by a combination of pre-signed durable nonce transactions and compromise of multiple multisig signer’s approvals, likely through targeted social engineering or transaction misrepresentation.

A lot of blogs are over-indexing on the durable nonce part. Don’t let that distract you. The actual technical compromise was a multisig compromise — not particularly technically interesting. We’ve seen this before. This is exactly what we saw with the Bybit hack. The playbook is straightforward:

1. Compromise people’s computers
2. Show them transactions that look good, but send bad data to the wallet
3. Nobody checks what they’re signing
4. Profit

The Drift team operated behind a 2-of-5 multisig. All the attacker needed was two approvals. And yes, the Drift team confirmed they were using hardware wallets — but if you’ve been following my work, you know that doesn’t matter if you’re not checking what actually goes onto your hardware wallet.

Now, there are a lot of remediations this team could have done. Hindsight’s 20/20. But that’s not what’s scary about this hack.

What’s scary

Historically, meeting in person with a state-sponsored hacker was too dangerous for the hackers to attempt. A lot of teams used this as a mitigation — meet collaborators in person, verify identities at conferences. These hackers met the Drift team in person.

From Drift’s writeup:

Drift contributors were approached by a group of individuals at a major crypto conference who presented as a quantitative firm looking to engage on the protocol. They were technically fluent, had verifiable professional backgrounds, and were familiar with how Drift operated.

The Drift team started working with this group. They gained trust. The hackers sent links, things to download, code repos to review. The Drift team ran those things — and yes, they shouldn’t have, but a large part of it was because they had built a real working relationship over six months.

Meeting somebody in person isn’t the obstacle we historically thought it would be. That changes the game.

The timelines are also getting longer. This hack was in the makings for over six months. It’s reminiscent of the XZ backdoor, where a GitHub user was created who actively contributed to a foundational Linux tool for years, being genuinely helpful, until the maintainer said “sure, you can take more control” — and boom, that’s when they struck.

So the two things that make this terrifying:

1. Meeting in person isn’t the verification we thought it was
2. These timelines are getting longer and longer

The default path must be the secure one

Given all this, the question becomes: what can we do?

I think there are two approaches. There’s the smaller, individualistic answer — the “here’s what you should have done” stuff. And then there’s the systemic answer, which I think is far more important but tends to get ignored.

I’m going to explain both, but I want to start with a phrase I keep coming back to:

The default path must be the secure one.

Write this down. Scream it from the top of your lungs.

Think about passwords. We all know you shouldn’t reuse passwords. But in practice, memorizing a bajillion passwords is infeasible. So we developed password managers and passkeys to make unique passwords easier. Security fatigue is a real thing. We could 100% just blame people — “hey, just come up with 10,000 passwords and store them in your head.” We had a “solution.” But the default path was incredibly laborious, so we fixed it at a systemic level.

The same logic applies here. For each one of the missteps below — yes, the team should have taken steps to prevent them. But there’s a systemic issue underneath.

The missteps (and the “just do this” responses)

Blind signing / transaction misrepresentation. This is the crux of it. I made a video about this last year — it’s ridiculous that we sign things on hardware devices that nobody can read. Most people aren’t even checking.

It’s very easy for hackers to manipulate a small piece of transaction data, send it to your hardware wallet, and you just blindly sign it because it’s so hard to verify. These transactions might be 20 pages of data where if a single character is off, you’re sending a malicious transaction. If you’re going through 2,000 characters and you mistake a 7 for a 1 or a 3 for a B — you’re screwed. So most people just don’t bother checking.

Cloning and running a code repo. One contributor was likely compromised after cloning a code repository shared by the attackers. We have docker containers, dev containers — use them. Pascal from the SEAL team goes further and says you should use Qubes OS. Just opening a folder can be enough to compromise a device.

Running unknown software. Your signing device should be separate from your working device. If your working device gets compromised, it shouldn’t matter for your signing device.

For every single one of these, there was some remediation the team could have done. But here’s what I’m saying — those steps, as of today, suck and are hard.

A lot of people say “oh, we need to educate people more.” I have hundreds of hours of videos explaining “don’t put your private key in plaintext.” And I still get people saying “oh, it’s fine if you’re just smart.” No. The default path must be the secure path.

I think we’re making the fundamental attribution error here — our cognitive bias to blame individuals while underemphasizing the situational and environmental factors. We should look at the overall situation and fix that.

What immediate steps can we take?

The good news is we’re making progress, at least on the Ethereum side:

ERC-8213 — This is the proposal I created for technical users. Instead of scrolling through 20 pages of hex data, your wallet shows a single hash (a “calldata digest”) that you can independently verify on a separate device. One hash to check instead of thousands of characters.

ERC-7730 — This is the longer-term solution for retail users. A registry where vetted projects provide metadata to translate raw transaction data into plain English.

But the Drift hack was on Solana. So I’ve created a discussion to bring both of these concepts to the Solana ecosystem.

Please go to those ERCs and that SIMD discussion and give them a bump. We can at least fix this issue that’s been plaguing us for a decade — nobody knowing what the hell they’re signing.

Otherwise, we’re just going to keep seeing this every other week.

How to Not Accidentally Shoot Yourself in the Foot with AI Development

AI has been an incredible productivity boost for software engineers. I personally have been using Claude Opus 4.6 — it passed my vibe check and I’ve been using it to code pretty much everything I touch. At Cyfrin, we’ve also been working with AI to help secure our codebases.

But the rest of the industry — ourselves included — has been emboldened to do dumber and dumber things because we can do more and more with AI. And the attack surface is growing fast.

AI Is Already Screwing Up

Here are real examples of how AI has already gone wrong:

The Moonwell Incident. Security auditor Pashov pointed out that Claude helped co-author a git commit in the Moonwell project that misconfigured an oracle, effectively pricing cbETH at ~$1.12 instead of ~$2,200 — leading to $1.78 million in bad debt. Hopefully $1 continues to be the incorrect price of ETH…

The EchoLeak Vulnerability (CVE-2025–32711). Just by sending someone an email with Microsoft 365 Copilot turned on, Copilot would read that email and get prompt-injected — sending sensitive data to hackers automatically. You didn’t even have to open the email.

Slopsquatting. AI hallucinates a package that doesn’t exist. An attacker registers that package. Now the hallucinated package is real — and loaded with malicious code. Your supply chain is compromised.

Private keys in plain text. It’s 2026 and AI still tells people that hardcoding private keys is fine. It’s not.

According to OWASP, the top three AI attack vectors are:

1. Prompt injection
2. Leaking sensitive information
3. Slopsquatting / supply chain attacks

And the code AI writes isn’t bulletproof either. The BaxBench leaderboard shows that even the best model — Claude Code — only writes correct and secure code about 56% of the time.

So… AI is bad then

Not so fast.

Claude Opus 4.6 has found 500+ vulnerabilities. AI projects have been smashing leaderboards on HackerOne. At Cyfrin, when we do smart contract audits, we use AI to help us understand and navigate the codebase. It’s a laborious job, and since AI is so helpful for productivity, I’m not going to not use it.

The question isn’t “should we use AI?” — it’s “how do we use it without getting destroyed?”

The #1 Rule: It’s Your Fault

Before we get into the tips, here’s the overarching principle: you are the developer and you are the security researcher. That means you are responsible for any bugs you ship.

Blaming a bug on the AI is incorrect. It is your fault.

You must review what your AI is doing. You must know what your AI has access to. That is the summary of all of this.

Tip 1: Add a Security Prompt

Sounds stupid. We’ve all seen the memes where someone asks Claude to “make me a billion-dollar company and make no mistakes.”

But funnily enough, it actually works. On BaxBench, they found that simply adding a generic security reminder to prompts improved Claude Code’s secure code rate from 56% to 66%. That’s a meaningful jump just from telling your AI to care about security.

This is where tools like Claude Code’s skills system come in:

• Cyfrin SolSkill helps write more secure Solidity code and catches common code smells.
• Trail of Bits Claude Code Config adds a whole set of security-focused settings to your Claude Code environment. You should 100% set this up.

Tip 2: Use Normal Security Tooling

This is the “yeah, obviously” advice, but people forget: you can still use all the normal security tooling alongside AI.

Static analysis tools like Slither and Aderyn are still incredibly valuable. Don’t stop using them just because you have an AI assistant. Layer your defenses.

(And follow Cyfrin on Twitter — we’re cooking up some good stuff on this front.)

Tip 3: Containerize Your Environments

Use containerization to isolate your development environments. For smart contract development, you can spin up an isolated container and drop Claude or ChatGPT into it so the environment is sandboxed.

The Cyfrin devcontainer is a great starting point. If your AI goes rogue or gets injected, the blast radius is limited to that container instead of your entire machine.

Tip 4: Handle Sensitive Information Like It’s Radioactive

Two concerns with sensitive information:

1. You don’t want your AI to have sensitive information
2. You don’t want your AI to expose sensitive information

Here’s the rule: if you’re not using a local LLM, assume that if your AI has access to something, the world now has access to it.

Private keys should never be in plain text, and your AI should never have access to them. The Cyfrin SolSkill has prompts baked in specifically to prevent this.

Tip 5: The Agent Rule of Two

Some of you are thinking: “Patrick, shut up. I want to give my AI access to my sensitive information and passwords so I can use tools like OpenClaw.”

I personally don’t recommend that. But if you’re going to do it anyway, use the Agent Rule of Two.

This framework came out of Meta’s AI security research, inspired by Simon Willison’s “lethal trifecta” concept and the Google Chrome team’s Rule of 2.

Your agent should only have two of the following three properties at any given time:

• A. The agent can process untrustworthy inputs
• B. The agent can access sensitive systems or private data
• C. The agent can change state or communicate externally

Pick two. Never all three.

If your AI agent has all three, you’re cooked. An attacker prompt-injects your agent through untrusted data (like a malicious email — see EchoLeak), the agent has access to your private information, and it can send that information out. Game over.

But remove any one:

B + C only (no untrusted inputs): The malicious email never reaches the AI. The agent only processes trustworthy sources.

A + C only (no private data): Even if the agent gets prompt-injected, there’s nothing sensitive for it to reveal.

A + B only (no external communication): Even if the agent gets injected and reads your sensitive data, it can’t send it anywhere.

Apply this when working with tools like OpenClaw. Limit access to specific accounts. Split your agents up so no single agent becomes a single point of failure.

In Crypto, Be Even More Paranoid

In the smart contract world, my recommendation is simpler: just don’t give an agent any of your private or sensitive information at all.

Even with the Rule of Two, what happens if your agent itself gets hacked? If you’re using a local LLM, that’s slightly better, but you should still worry about data in the cloud being stolen.

Tip 6: Watch Your Supply Chain

For supply chain attacks like slopsquatting: know what packages your AI is suggesting. Don’t blindly install something just because your AI told you to. Verify it exists, verify it’s the real package, and verify it’s not a hallucination that someone has weaponized.

Tools like Snyk and npm audit can help.

Prompt Injection Is Still Unsolved

I saved this for last because it’s probably the trickiest attack to defend against today.

Yes, you can do input sanitization. Yes, you can (and should) do human-in-the-loop interactions, especially when reviewing smart contract code. But prompt injection is fundamentally a problem we haven’t solved yet.

On a promising note: sockdrawermoney — co-founder of Code4rena (which kicked off the competitive audits craze) and one of the co-creators of npm audit — has been working on a language designed to mitigate prompt injection through taint tracking. Any time your agent touches something, the data gets labeled as trusted or untrusted. It's very cool, and I'm still digging into it myself.

TL;DR

1. AI is an incredible productivity tool, but it’s making us reckless
2. Top 3 AI attack vectors per OWASP: prompt injection, sensitive data leaks, slopsquatting
3. Add a security prompt — improved secure code rates by ~10% on BaxBench
4. Use security tooling — Slither, Aderyn, and static analysis still matter
5. Containerize — sandbox your AI’s environment (Cyfrin’s devcontainer)
6. Private keys never in plain text — your AI should never have access to them
7. Agent Rule of Two — never grant all three: untrusted inputs, private data, and external communication
8. You are responsible for everything your AI produces. Review it. All of it.

Stay safe.

This blog was not written with AI, except to help with research on VC portfolio allocations over the last few years.

In 2025, VCs like Sequoia, A16z, Lightspeed, and Y Combinator invested in AI companies en masse, and we saw some outflow of money from crypto to AI. Not to mention the price of cryptocurrencies in general recently tanked.

Sequoia

A16z

Lightspeed

Y Combinator

I’ve seen many people who came into web3 with me back in 2019/2020 start to leave, to join an AI company or prediction market.

As someone deeply devoted to the success of blockchain and decentralized finance, there are a few ways to react to this.

Good riddance, they didn’t believe anyway

There is an allure to, similar to a bad breakup, “hate them on the way out”. “It’ll be better now that only the true builders are left” — type. I think this isn’t the correct approach. We want people to work in our industry, even if they don’t share the same fundamental principles we do. If we keep the visionaries, then we are always going to need people to help work to make those visions come to life, and many people are looking to live a good life, not change the world. I think there is no harm in that either. In life, it’s great to have people:

• Deeply passionate
• Less passionate, but willing to work to make themselves better, and do something good too

I think of these as “rock stars” vs “superstars” in a sense.

Crypto is doomed, pivot to AI

This is the topic that I want to focus on most here, and here is the line that I want to drill into your soul.

The world’s finance being solely powered by cryptocurrencies is inevitable.

Let that sink in. Let that sit with you. Once you accept this, it makes less and less sense to pivot to AI. Yes, AI is booming, yes, AI is awesome, but AI is a tool to help build other things, and one of those “other things” is the future of finance.

At the same time, do what’s right for you. There is a hype train calling your name in the AI world, perhaps. Go for it. But I think you’ll be missing out.

Why is blockchain inevitable?

The same reason gold has a market cap of $35T today.

I’ve given this rant many times about “what is money”, especially in my explainer of stablecoins. Money provides 3 functions:

• Store of value
• Medium of exchange
• Unit of account

To find a credibly neutral and convenient money has been basically impossible for all of history, until recently. Gold has been accepted as the “credibly neutral” money; however, it’s not particularly convenient. Cryptocurrencies are the solution here. They give us the same benefits gold has given us for over 1,000 years, with the convenience of the modern era.

The exponential factor

To me, this is interesting in itself, but the excitement goes astronomical when you look at this combined with smart contracts. Take the stock market, for example. The NYSE does about $80B in transaction volume a day, whereas Uniswap might do $2B. That’s a whopping 40x difference, but factor in how much it costs to run the NYSE.

The parent company of the NYSE has ~12,000 employees. Whereas Uniswap could hypothetically be run with just liquidity providers, and only has ~200 employees. This is a reduction of 60x the overhead! Just on costs alone, running a decentralized exchange is massively reduced.

And don’t even get me started on the censorship resistance and credible neutrality, which is the whole purpose of the technology! I’ll save you the rant on why credibly neutral financial products are the future, because if you just look at the numbers alone, running DeFi is substantially cheaper, while also being a fairer technology.

A lot of people are unconvinced by the rationale of credible neutrality, so I’m going to skip over it in this article. Many of those people come from first-world countries and will never begin to understand how impactful a technology like this can be on a less fortunate country. However, I do still think it’s the top motivator for why this technology is inevitable. But a lot of people can look at the overhead our current financial infrastructure has and start to ask, “Why am I paying such massive fees for my stock trades to clear 2 days later?”

Summary

You can go if you’d like, but I think you’re going to miss the adoption happening, where the opportunity is even better than it ever was.

A lot of the “opportunities” historically in crypto were bullsh*t to some extent. NFTs, liquidity mining, and meme tokens were all amongst the “products” that exploited people’s misunderstanding of the new technology, trying to get in on something new. We have passed that. We know they were dumb. And now, we can get institutional and retail adoption of products that actually make their lives better. Aave, Uniswap, ZK Privacy, and Stablecoins are all here to provide financial products to anyone in the world at a fraction of the cost and with less censorship.

Smart contracts and cryptocurrencies are:

• Cheaper
• Faster
• Fairer

And the whole world will be running on its infrastructure, and I want to keep busting ass to make that come to life.

For more amazing blockchain content, follow me on YouTube and X.

And be sure to follow the Cyfrin team!

After my last hardware wallet review, my DMs were flooded with recommendations. “You HAVE to try this one!” they said. “This wallet will change your mind!” they promised. So here I am, having tested four more hardware wallets that came highly recommended from the crypto community, still searching for one that actually protects users from getting rekt.

Let’s see if any of them will save Ethereum.

You can also watch this video on my YouTube.

Criteria

Our high-level wallet criteria

Before diving into the reviews, let’s establish what we are looking for in a hardware wallet. The primary purpose is simple: keep your private key safe. If it can’t do that, it fails at its core function. We won’t be considering any hardware wallets that do not fulfill this fundamental requirement.

Beyond this, I evaluated these wallets on several key criteria:

1. Visibility of transaction calldata: How clearly can you see what you’re signing on both transactions and message signing?
2. Open source status: Is the wallet’s code open source and reproducible? We use Wallet Scrutiny to help verify if a wallet is truly open-sourced (the Wallet Scrutiny team is not a big EVM fan, but they still help us with their reviews!)
3. Security features: Secure elements, offline key generation, and backup methods.

For us, being able to easily verify our signature data was top of mind, as the easier it is to verify this data, the better we can prevent hacks like Radiant Captial and Bybit. I made a video that goes over all the information a wallet should show us, and why. The summary of that video can be found in the image here.

There are some things a wallet must show us; otherwise, it is disqualified from being used for any serious reasons. Then, there are some pieces of criteria that it would be nice if a wallet had that feature, but not a deal-breaker.

What must a wallet show us when signing a message or a transaction?

Methodology

For each wallet, I connected it to the Safe Wallet UI through MetaMask (when possible) to standardize testing across devices. I attempted to both:

1. Sign an EIP-712 message
2. Execute a transaction

To evaluate how well each device displayed critical data. In doing so, I played with settings, checked how they handled sending and receiving ETH, and more.

I’m going to be quite blunt with my reviews, so I don’t expect these to make me very popular. I hope the wallet companies read this article and either tell me where I went wrong, or make changes!

Let’s dive into the reviews.

SafePal: S1 Pro

The SafePal wallet comes with its own browser extension and mobile app, which initially seemed promising. It has an EAL6+ secure element, supports air-gapping, and even has a camera for QR codes.

They also have their own token (SFP)… Which was… A thing.

But in any case, the wallet seemed very promising until I started trying to send transactions. To do anything with this hardware wallet, you need three wallets:

1. The browser extension
2. The mobile app
3. The actual hardware wallet

Want to sign an EIP-712 message? Your browser extension sends it to your mobile app, which generates a QR code, which you scan with your hardware wallet, which then… truncates all the important data anyways.

This was quite cumbersome to work with, I felt like I had to verify three transactions for every one transaction (check extension, check phone, check hardware wallet).

For developers and security professionals, this wallet is unacceptable due to its inability to show transaction calldata. For normal DeFi users, I think the UX isn’t worth it.

Pros:

• Has its own browser extension and mobile wallet app (cohesive ecosystem)
• Camera on the back for QR code scanning
• Can be air-gapped
• EAL6+ security rating
• Relatively inexpensive

Cons:

• Not open source (failed Wallet Scrutiny tests)
• Requires three devices to function
• Truncates signature data on the hardware device

BitBox02

The BitBox team reached out to me on Twitter asking for a review. Usually, when companies do this, I’m severely disappointed. Not this time.

The BitBox02 takes a unique approach to the open-source dilemma. Their firmware is completely open source (verified by Wallet Scrutiny) while using a closed-source secure chip that you don’t have to trust.

The device itself is tiny — about the size of a USB stick with touch sensors on the sides. I was initially worried about the small screen real estate, but they actually display all signature data!

Sure, the navigation is a bit funky (tapping the sides to scroll), and typing your password on this thing daily is a pain, but it shows all the data. That’s all I want. That’s all I’ve been asking for.

Would I recommend this to Bybit Ben? Probably not — the raw data format might be too technical. Would I recommend this to security researchers? Hell yes. It’s open source, shows everything, and doesn’t try to hide critical information.

Pros:

• Fully open-source firmware
• Shows complete signature data
• Includes micro SD card for backup/disaster recovery
• Small, portable form factor

Cons:

• Very small screen (limited real estate)
• Typing password daily is cumbersome
• Doesn’t work with MetaMask (only Rabby currently)
• Requires BitBox Bridge software to connect to Rabby

Burner

After giving Tangem a hard time for being a card wallet, I realized I was judging a fish by its ability to climb a tree. Card wallets like Burner should be judged differently — they’re meant for small amounts, like a $20 bill in your pocket for coffee.

The Burner card uses RFID for tap-to-pay functionality, which is conceptually cool. But the implementation is clunky:

• You need to run a “Halo gateway” on your phone (basically a server)
• Connect it to Burner OS on your desktop
• Then tap your card to your phone to send transactions

Even on the UI, you can’t check calldata, but I guess I shouldn’t care, because with “tap-to-pay” you can’t check calldata anyway.

These wallets might be great in the future when you can actually tap to pay for coffee with crypto, but I wouldn’t want to store large amounts of crypto on them.

Pros:

• Tap-to-pay functionality with RFID
• Very portable (credit card size)
• Cheap ($20)
• Good for small amounts/casual use

Cons:

• No hardware screen
• Can’t verify calldata at all
• It’s not a hardware wallet, really, it’s more of a.. card

NGRAVE Zero

This wallet hurts to review because it’s SO GOOD in every way except the one that matters most.

The NGRAVE Zero feels premium. It has:

• Biometric fingerprint authentication
• A built-in camera for QR codes
• EAL7 certification (the highest security rating)
• A beautiful touchscreen interface
• Custom operating system

I loved working with this wallet, until I went to sign messages.

Whether you’re signing an EIP-712 message, a regular message, or sending a transaction, the wallet always just says “signing a transaction.” For EIP-712 messages, it doesn’t show the struct, but a very bizarre format of strings. For calldata, the same.

Pros:

• Premium build quality (feels good in hand)
• Biometric fingerprint authentication
• Built-in camera for QR codes
• EAL7 certification (highest security rating)
• Beautiful touchscreen interface
• Compatible with MetaMask via QR codes

Cons:

• Shows data in unrecognizable format (not hex, not the actual struct)
• Expensive for what it delivers

Summary and Conclusion

BitBox02 joins Trezor, Ledger, and GridPlus as a wallet I would consider acceptable for security researchers, but none of them will save Ethereum.

Remember that the primary goal of a hardware wallet is to keep your private keys safe while allowing you to verify what you’re signing. If you can’t understand what you’re signing, you shouldn’t proceed with the transaction, regardless of which wallet you use.

For developers and security researchers in the EVM ecosystem, I recommend selecting a wallet that aligns with your specific priorities — whether that’s open-source verification, ease of transaction decoding, or signature verification capabilities.

The Search Continues

The BitBox02 gives me hope that wallet manufacturers are starting to get it. But we’re still far from where we need to be. We need wallets that are:

• Transparent about what you’re signing
• Open source where possible
• Secure against physical attacks
• Usable by both grandma and gigabrains

Until then, stay safe out there, and remember: if you can’t verify what you’re signing on your hardware device, you’re one malicious website away from getting rekt.

To learn to sign these complex transactions, you can use games like wise-signer.

For more amazing blockchain content, follow me on YouTube and X.

And be sure to follow the Cyfrin team!

A big thanks to Wallet Scrutiny, pcaversaccio, Officer’s Notes, and Justin Leroux for help on this topic.

You can skip to the end of this article to find my full spreadsheet I used to judge wallets, as well as the final recommendations. You can also watch the video on this topic and see me interact with the wallets in my video here where we go even deeper into the analysis of each wallet.

Introduction

As a security researcher in the EVM ecosystem, I tested nine different hardware wallets to answer the question: which hardware wallets were the best for making signing verification easy, and keeping my private key safe?

As someone who is on blockchain security councils, multisigs, and DAOs, I am very particular about verifying every piece of data that I sign on my wallet. Additionally, we are currently in an epidemic where many people sign transactions that they haven’t confirmed are doing what they would want them to do!

For example, the Radiant Capital team was hacked for $50M, while the Bybit exchange was hacked for $1.4B and in both cases, they could have been saved if they verified the data they were signing on their wallets.

So I want to know which wallet is the best for:

• Security researchers: Who can verify calldata and prefer maximal transparency
• Less technical users: Like Bybit CEO Ben Zhou, who has to sign transactions on wallets with a lot of money but may have less technical expertise.

Let’s begin.

Criteria

Before diving into the reviews, let’s establish what we are looking for in a hardware wallet. The primary purpose is simple: keep your private key safe. If it can’t do that, it fails at its core function. We won’t be considering any hardware wallets that do not fulfill this fundamental requirement.

Beyond this, I evaluated these wallets on several key criteria:

1. Visibility of transaction calldata: How clearly can you see what you’re signing on both transactions and message signing?
2. Open source status: Is the wallet’s code open source and reproducible? We use Wallet Scrutiny to help verify if a wallet is truly open-sourced (the Wallet Scrutiny team is not a big EVM fan, but they still help us with their reviews!)
3. Security features: Secure elements, offline key generation, and backup methods.

For us, being able to easily verify our signature data was top of mind, as the easier it is to verify this data, the better we can prevent hacks like Radiant Captial and Bybit. I made a video that goes over all the information a wallet should show us, and why. The summary of that video can be found in the image here.

There are some things a wallet must show us; otherwise, it is disqualified from being used for any serious reasons. Then, there are some pieces of criteria that it would be nice if a wallet had that feature, but not a deal-breaker.

Methodology

For each wallet, I connected it to the Safe Wallet UI through MetaMask (when possible) to standardize testing across devices. I attempted to both:

1. Sign an EIP-712 message
2. Execute a transaction

To evaluate how well each device displayed critical data. In doing so, I played with settings, checked how they handled sending and receiving ETH, and more.

I’m going to be quite blunt with my reviews, so I don’t expect these to make me very popular. I hope the wallet companies read this article and either tell me where I went wrong, or make changes!

Let’s dive into the reviews.

Tangem

The Tangem Card Wallet is unique as a credit card-sized hardware device. It contains a secure element for private key generation and offers convenient tap-to-phone functionality.

Pros:

• Very portable form factor
• Simple to use for tap-based payments
• Good for small amounts and casual use

Cons:

• Closed source
• Requires dedicated mobile app
• No testnet support
• Completely fails to show calldata for transactions
• Limited display of signature data

For developers and security professionals, this wallet is unacceptable due to its inability to show transaction call data. You’re essentially signing transactions blindly. It might work for storing small amounts, but it’s not suitable for serious DeFi work.

Cypherock

The Cypherock wallet earns points for being open-source and reproducible, which is excellent. It has a secure element (EAL6+ rated) and uses a unique card-tapping system for transaction authorization.

Pros:

• Open-source and reproducible
• Secure element (EAL6+ rated)

Cons:

• Poor joystick navigation interface
• Shows no calldata for transactions
• Challenging user experience leads to security fatigue

Would I recommend it to security researchers? No.

Although the Cypherock shows some signature data, it completely fails to display calldata for transactions, which is a deal-breaker for professional use. The joystick interface can cause security fatigue, making users more likely to approve transactions without proper verification.

Keystone 3 Pro

The Keystone 3 Pro features a touchscreen interface that makes it much easier to navigate. It’s reproducible open source according to the Wallet Scrutiny team and connects to MetaMask via an innovative QR code system.

Pros:

• Verified open source
• Touchscreen interface
• Shows EIP-712 signature data
• QR code connectivity solution

Cons:

• Inconsistent calldata decoding
• Missing or truncated decoded calldata
• No option to view raw calldata

Would I recommend it to security researchers? No, it’s too buggy.

The Keystone Pro started strong but fell short. While it displays EIP-712 signature data adequately, its call data decoding is unreliable and inconsistent. The wallet attempts to decode call data but often displays it incorrectly or incompletely, which can be worse than not decoding it at all. There’s no option to view the raw call data as a fallback.

Trezor Model T

The Trezor Model T represents a solid baseline wallet. It’s open source and verified by Wallet Scrutiny, but lacks a secure element (which the newer Safe 5 model includes).

Pros:

• Open source and verified
• Shows full calldata
• Testnet support
• Good default wallet

Cons:

• No secure element
• Small touchscreen
• One-at-a-time data display (security fatigue)
• Raw calldata in difficult-to-verify format

Would I recommend it to security researchers? No, just use the Trezor Safe 5 instead.

The Trezor Model T does show all necessary data, but the format is difficult to work with. The calldata is presented in a way that makes verification challenging. Additionally, the lack of a secure element is concerning for high-value storage. With the Trezor Safe 5 now available, there’s little reason to choose the Model T.

Trezor Safe 5

The Trezor Safe 5 improves on the Model T with a secure element and larger touchscreen with haptic feedback.

Pros:

• Open source and verified
• Secure element (EAL6+ rated)
• Larger touchscreen with haptic feedback
• Shows all calldata

Cons:

• Unintuitive navigation for viewing call data
• Difficult to extract calldata for verification
• No decoding of calldata

Would I recommend it to security researchers? Yes, for technical users.

The Trezor Safe 5 is a good choice for technical users who can verify raw calldata. The UI has some unintuitive elements, especially when reviewing transaction data, but it does show all necessary information for proper verification. Its open-source nature is a significant advantage for security-conscious users.

Ledger Nano X

The Ledger Nano X has been a popular wallet for years but has some significant limitations.

Pros:

• Shows domain hash and message hash for signatures (HUGE PRO)
• Solid track record of secure hardware
• Good firmware verification

Cons:

• Closed source
• Poor two-button interface
• Confusing “blind signing” terminology
• Bizarre format for displaying calldata
• Device closes too frequently

Would I recommend it to security researchers? Probably not.

While the Ledger Nano X does well with displaying signature hashes (one of the few wallets to do so through MetaMask), its presentation of calldata is nearly unusable. The “debug contracts” setting is confusingly named, and the call data is displayed in a proprietary format that’s difficult to verify. Given that the Ledger Flex exists, there’s little reason to choose the Nano X.

Ledger Flex

The Ledger Flex significantly improves on the Nano X with a secure screen and better usability.

Pros:

• Shows domain hash and message hash for signatures
• Secure screen
• Excellent button feel and usability
• Stays active longer than Nano X

Cons:

• Closed source
• Same confusing calldata display as Nano X
• “Debug contracts” setting for viewing calldata

Would I recommend it to security researchers? Yes, with the caveat of being closed-source.

The Ledger Flex excels at showing domain and message hashes for signatures, making verification much easier than most other wallets. However, it uses the same poor format for displaying call data as the Nano X. If you’re comfortable with a closed-source solution, the Flex is a solid choice, especially for signature verification.

Onekey Pro

EDIT Oct. 6th, 2025: When this article was originally written, the OneKey Pro did not pass the Wallet Scrutiny open-sourced tests. It has since passed!

The Onekey Pro claims to be open source but failed Wallet Scrutiny’s reproducibility tests.

Pros:

• Excellent haptic feedback
• Air gap mode
• EAL6+ secure element
• Shows all signature and calldata

Cons:

• Not truly reproducible open-source
• No display of domain/message hash
• Calldata not decoded

Would I recommend it to security researchers? Yes, if closed source isn’t a concern.

The Onekey Pro has excellent hardware and usability but falls short of being truly open-source. It shows all necessary data for signatures and transactions but doesn’t decode call data or display hashes for easier verification. With a few improvements and true open-source status, this could be an outstanding wallet.

Grid Lattice Plus

The Grid Lattice Plus is the highest-rated wallet in this review despite being closed-source.

Pros:

• Extensive screen real estate
• Fantastic calldata decoding, including nested transactions
• Smooth user interface
• EAL6+ secure element

Cons:

• Closed source (proprietary chip)
• Bulky form factor
• No option to view raw calldata

Would I recommend it to security researchers? Yes, if you’re comfortable with closed source.

The Grid Lattice Plus offers the best call data decoding of any wallet tested, even handling nested transactions. This feature is invaluable for non-technical users. However, it lacks an option to view raw calldata, which some technical users might prefer. The closed-source nature remains a concern for maximum security.

Summary and Conclusion

After reviewing nine hardware wallets, it’s clear there’s no perfect solution — each involves trade-offs.

If open source is a priority, the Trezor Safe 5 offers the best balance of security and usability, though verifying call data remains challenging.

For those comfortable with closed-source solutions:

• The Grid Lattice Plus provides unmatched transaction decoding
• The Ledger Flex excels at signature verification
• The Onekey Pro offers excellent overall usability

Remember that the primary goal of a hardware wallet is to keep your private keys safe while allowing you to verify what you’re signing. If you can’t understand what you’re signing, you shouldn’t proceed with the transaction, regardless of which wallet you use.

For developers and security researchers in the EVM ecosystem, I recommend selecting a wallet that aligns with your specific priorities — whether that’s open-source verification, ease of transaction decoding, or signature verification capabilities.

More Data

Here is a screenshot of my spreadsheet I used to help track each wallet, as well as what exact version I used for each. I have several more wallets I’ve ordered that I plan to test very soon! But you should be able to follow my methodology I laid out here to decide for yourself too!

For more amazing blockchain content, follow me on YouTube and X.

And be sure to follow the Cyfrin team!

Yes, AI is going to take some software engineering jobs, but it’s more nuanced than that. According to recent data:

• software engineering job demand is down
• salaries are down
• growth is down

If you’re a computer science student or a software professional wondering about your career prospects in the age of AI, let’s dive into what’s really happening.

You can watch my whole video on this here.

Looking at DeepSeek’s recent paper, their AI model outperforms the vast majority of basic and medium software engineers in competitive programming, as well as many other intelligence benchmarks.

AI excels at tasks it’s seen before. AI systems are trained on enormous datasets of what people have done, common problems they’ve solved, and typical mistakes they’ve made.

Because of this, I think the most vulnerable roles are junior developers. Instead of paying a junior developer to handle simple tasks, companies will increasingly use AI tools to do this work.

The Limitations of AI

However, as an engineer myself, I’ll point out that many of these simple challenges (like LeetCode and code golf challenges that these benchmarks are trained on) aren’t representative of real-world coding. Real production code prioritizes readability and considers system architecture and design — aspects that many algorithmic challenges don’t address.

This is where something crucial comes into play: AI models are only as good as the data they’re trained on.

A study published in Modern Pathology demonstrated this limitation. When researchers used AI models to detect abnormalities in blood, estimate tissue age, and classify damaged tissue, they found that performance dropped substantially when the AI encountered contamination or data it hadn’t seen before:

• Accuracy dropped from 74% to 69% in some cases
• Age estimation errors increased by 46%
• Prostate cancer detection resulted in a 97% false positive rate

This is problematic because in real-world settings, about 3% of slides have some form of contamination. Human pathologists, by comparison, have an extremely low error rate when dealing with these edge cases.

Now the fix here for AI is simple, just train the AIs on these edge cases, but it still shows the issue with AI. When an AI hasn’t seen something, it’s error rate skyrockets.

The Human-AI Partnership

From my personal experience coding with AI assistants, I often receive suggestions that I can immediately recognize as suboptimal. I can identify the issues and improve upon the AI’s work using my expertise.

This pattern is likely to continue. While junior software engineers may be replaced, mid-level and senior engineers will adapt by using AI as a tool to supercharge their productivity — getting initial output from AI systems and then applying their expertise to improve it.

I expect this human-AI collaboration model to extend across most knowledge professions. Doctors will use AI suggestions as a starting point but rely on their expertise for final decisions. Software engineers will follow a similar pattern.

The Rising Knowledge Bar

What this means is that the days of attending a two-week bootcamp and landing a six-figure job immediately afterward are over — and that’s probably a good thing.

The knowledge requirements to be a software engineer are increasing:

• In 2022, you could complete a short bootcamp and potentially find a high-paying job
• In 2024, the bar is rising — you might need years of hard work and open source contributions
• In the future, the prerequisite knowledge will continue to increase

For comparison, doctors need extensive knowledge and often aren’t financially stable until their 30s. I believe the knowledge requirements for all professions will increase as AI makes learning more accessible.

What Industry Leaders Are Saying

Mark Zuckerberg stated on Joe Rogan’s podcast:

Probably in 2025, we at Meta, as well as other companies working on this, are going to have an AI that can effectively be a sort of mid-level engineer that you have at your company that can write code.

Companies like Salesforce have already paused hiring new software engineers. Though, I believe this is partly a market correction following the aggressive hiring during the pandemic years.

Jevons Paradox: Why AI Might Actually Increase Demand

Here’s where Jevons Paradox comes in. Named after economist William Stanley Jevons, this economic theory states that when technological progress increases the efficiency of a resource, the rate of consumption of that resource may actually increase rather than decrease.

Examples of this paradox in action:

• As computing power became cheaper, demand for it skyrocketed
• As cars became more fuel-efficient, more cars were driven

Applied to software development, AI making software creation cheaper could actually increase demand. As building software becomes less expensive, we might see a surge in new applications and systems, potentially creating more jobs, not fewer.

However, the prerequisite knowledge to get these jobs will remain higher than before.

The Security Researcher Exception

There’s a significant exception to this trend: security researchers. Technical security researchers still need extensive prerequisite knowledge, but they can demonstrate their skills through bug bounties and competitive audits like CodeHawks.

With the proliferation of AI-generated code, security becomes even more crucial. While a questionable study claimed that using AI led to a 41% increase in bugs, the methodology was flawed. However, the concern is valid.

In critical applications — like medical devices with human lives at stake or smart contracts handling billions of dollars, with dollars staked — bugs can be catastrophic. AIs trained on human code inherit human errors. This is why security expertise remains invaluable.

From my experience as a blockchain engineer, I’ve tested many AI auditing tools and found them lacking compared to traditional static analysis. While AI tools may help with fuzzing and understanding invariants, they don’t yet replace human security experts.

The Blockchain Security Advantage

Blockchain security researchers and smart contract engineers may be safer than those in other industries. In blockchain, a single bug can result in a protocol being hacked and destroyed. We’ve seen protocols audited by AI subsequently get hacked.

Eventually, AI may surpass most humans in security analysis, but that future is further away than many think. For the foreseeable future, the human-AI hybrid approach will yield better results.

The Data Drought

Interestingly, as AI capabilities improve, we’re seeing a drought in training data. Historically, AIs were trained on forums like Stack Overflow, but many of these sources are drying up as people interact with AI rather than these platforms. So AI is having to train itself… with itself.

Additionally, many sites are implementing robots.txt files to prevent scrapers from collecting their data, further limiting new training material.

How to Stay Relevant

So, what should you do if you’re concerned about your future in software or security?

1. Never stop learning: If you got your degree and decided you don’t want to learn anymore, AI will take your job. Stay relevant by consistently learning and growing.
2. Embrace AI tools: Use these tools to become more efficient, but understand what they’re doing. Know the code they’re generating so you can implement it effectively.
3. Understand AI limitations: Recognize that AI is trained on historical data, which is a lagging indicator. For example, current AI tools might still recommend pip instead of newer, better tools like uv. Your cutting-edge knowledge gives you an advantage.
4. Consider security: In critical systems, the consequences of errors can be severe. Security expertise will remain valuable as AI-generated code proliferates.

The Future Is Collaborative

My take: Many junior roles will disappear, but that’s not necessarily bad. Society will move faster and achieve more technological advancements because of AI. However, you’ll need to elevate your skills to provide value in this new landscape.

AI is ultimately just a tool — one that can help us build better systems, more secure smart contracts, and a better future. Those who learn to collaborate effectively with AI, bringing human expertise to bear on problems AI can’t fully solve, will thrive in the coming years.

References

• Zuckerberg interview on Joe Rogan
• AI performs worse with contamination study
• The effect of AI on high-skilled work
• DeepSeek beating benchmarks (like Math tests)
• Data powering AI is disappearing

Is AI going to take software jobs? was originally published in Cyfrin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Learn how to verify Safe multi-sig wallet signatures with Cyfrin’s safe-tx-hashes tool — the fix for the Radiant Capital hack.

‍ Huge thank you to pcaversaccio for pushing this and writing the original tool.‍

What web3 learned from watching Radiant Capital lose $50M

The Radiant Capital hack went (essentially) like this:

1. They had a Safe Multi-sig wallet
2. A few of their signers had compromised computers
3. Their computer screens showed “good” data, but they sent malicious data to their wallets
4. They signed the wallet transactions because they didn’t know how to verify them

This costly mistake highlights the critical importance of understanding and verifying multi-signature (multi-sig) transactions. The ability to verify signatures is a skill you must have if you want to be involved in security councils, DAOs, incident response, or a DevOps team. Heck, even if you just want to be sure your personal accounts don’t get rekt.

Multi-sig wallets are renowned for their security, but to leverage this security effectively, you need to know how to verify that what you’re signing is indeed what you intend to sign.

Let’s learn how you can verify every part of your Safe multi-sig process so you don’t fall victim to this attack.

If you’d rather watch, we also have a video on YouTube to guide you step by step.

‍Getting started: download the safe-tx-hashes tool

First, you’ll want to download the tool. Head over to the safe-tx-hashes repository to download the safe_hashes executable.

This tool allows us to quickly input the safe transaction data, see what we should be getting, and verify that is indeed what’s showing up on our wallets.

As we go through this, it’s important to first understand what security assumptions we are making and what the threat vectors may be, so we can avoid them.

With this tool, we already have some assumptions that the following tools are safe:

• foundry
• bash
• perl
• The Safe Transaction Service API (Sort of, we’ll talk about this later)
• And finally, the tool itself: safe-tx-hashes
  ‍

Verifying a transaction: The setup

Let’s start with a scenario.

Your team needs to approve the Uniswap router to access your USDC for a swap — a relatively common DeFi transaction. Your Safe UI may look as such:‍

‍When you scroll to the bottom, you’ll get a big “sign” button. And when you click it, your wallet displays a message for you to verify, it might look something like this:

This is the Safe transaction message hash that we need to verify and be 100% sure of what it’s doing. So, what is it doing?

This message is the EIP-712 signature of the message our multi-sig uses to verify transactions. Enough users must sign a message in a particular format for it to be accepted. We cover EIP-712 and 191 in our blog and in Cyfrin Updraft if you’d like to learn more.

The safe hash is calculated as such (in Solidity):‍

keccak256(abi.encodePacked(bytes1(0x19), bytes1(0x01), bytes32($domain_hash), bytes32($message_hash)))‍

And the message_hash is calculated with (with bash/foundry):‍

local message=$(cast abi-encode "SafeTxStruct(bytes32,address,uint256,bytes32,uint8,uint256,uint256,uint256,address,address,uint256)" \
       "$safe_tx_typehash" \
       "$to" \
       "$value" \
       "$data_hashed" \
       "$operation" \
       "$safe_tx_gas" \
       "$base_gas" \
       "$gas_price" \
       "$gas_token" \
       "$refund_receiver" \
       "$nonce")
# Calculate the message hash.
   local message_hash=$(cast keccak "$message")‍

In essence, these hashes combine all critical transaction components to create a unique signature. This ensures that when the multi-sig wallet verifies a signature, it can be certain that it corresponds to this specific transaction on this specific wallet instance.

Now, what’s important here is that we must be completely sure this signature has the data we expect. If someone wanted us to sign a different transaction, they could just change the data that gets hashed as data_hashed. But, this would return a different signature! So if we are vigilant, we can see this, and not sign.

So our process will be to recreate what we expect the signature to be offline, then compare it to the signature we get on our hardware wallet.‍

Verifying transactions: Uninitialized with the Safe API

When you reach this page in the Safe UI, the Safe API will “save” the data here so that we can call the API to populate our tool. We can simply run:‍

safe_hashes --address <MULTI_SIG_WALLET_ADDRESS> --nonce XX --network xxxx --untruste‍

And this pulls all the data from the Safe UI and shows it directly to us! Including the transaction parameters and the expected signature. For example, you can run this script yourself to see the output!‍

safe_hashes --network sepolia --address 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F --nonce 7 --untrusted‍

You’ll get an output like this:‍

Transaction Data
Multisig address: 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F
To: 0x7b79995e5f793A07Bc00c21412e50Ecae098E7f9
Value: 0
Data: 0x095ea7b3000000000000000000000000fe2f653f6579de62aaf8b186e618887d03fa31260000000000000000000000000000000000000000000000000000000000000001
Encoded message: 0xbb8310d486368db6bd6f849402fdd73ad53d316b5a4b2644ad6efe0f941286d80000000000000000000000007b79995e5f793a07bc00c21412e50ecae098e7f900000000000000000000000000000000000000000000000000000000000000001c62604b0ed9a9ec0e55efe8fb203b3029e147d994854cf0dd8a9fcf5b240d600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007
Method: approve
Parameters: [
  {
    "name": "guy",
    "type": "address",
    "value": "0xfE2f653f6579dE62aAF8B186E618887d03FA3126"
  },
  {
    "name": "wad",
    "type": "uint256",
    "value": "1"
  }
]
Legacy Ledger Format
Binary string literal: \xe8\xc9\xfbR\xf3$\\xc5\xe451\x1b\xa4\xd5pAJ4=\x80\xeal7g\xa1jy\xbd*\xaa\x0c7
Hashes
Domain hash: 0xE411DFD2D178C853945BE30E1CEFBE090E56900073377BA8B8D0B47BAEC31EDB
Message hash: 0x27B5FF2CB38C914873DAF41B5A4984C76DB35F1812877F72A9D5DEA6960ED0B1
Safe transaction hash: 0xe8c9fb52f3245cc5e435311ba4d570414a343d80ea6c3767a16a79bd2aaa0c37‍

The transaction is calculated based on the data the Safe UI is giving us. We can also see the transaction that is being sent here too! With this, we can verify the transaction is correct, and verify the Safe transaction hash matches what we see in our wallet.

If a hacker took over the Safe UI/API when they sent us the malicious transaction, our script would recalculate the expected hash, and we would either see the transaction data is malicious (by inspecting the method section) or we’d see a different hash, and we’d reject the transaction!

However, if the Safe API is compromised, we’d have to manually do our verification process.‍

Verifying transactions: Uninitialized without the Safe API

For us to verify the hash without the Safe API, we’d just manually add the data to our tool, and use the --offline flag. Like this (you can also run it!):

safe_hashes --offline --data 0x095ea7b3000000000000000000000000fe2f653f6579de62aaf8b186e618887d03fa31260000000000000000000000000000000000000000000000000000000000000001 --address 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F --network sepolia --nonce 6 --to 0x7b79995e5f793A07Bc00c21412e50Ecae098E7f9‍

The data was calculated using the cast tool:‍

cast calldata "approve(address,uint256) 0xfe2f653f6579de62aaf8b186e618887d03fa3126 1‍

You can learn more about getting calldata and verifying transactions from this video. This would give you an output like this:‍

Transaction Data
Multisig address: 0x86D46EcD553d25da0E3b96A9a1B442ac72fa9e9F
To: 0x7b79995e5f793A07Bc00c21412e50Ecae098E7f9
Value: 0
Data: 0x095ea7b3000000000000000000000000fe2f653f6579de62aaf8b186e618887d03fa31260000000000000000000000000000000000000000000000000000000000000001
Encoded message: 0xbb8310d486368db6bd6f849402fdd73ad53d316b5a4b2644ad6efe0f941286d80000000000000000000000007b79995e5f793a07bc00c21412e50ecae098e7f900000000000000000000000000000000000000000000000000000000000000001c62604b0ed9a9ec0e55efe8fb203b3029e147d994854cf0dd8a9fcf5b240d600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006
Skipping decoded data, since raw data was passed

Legacy Ledger Format
Binary string literal: !;\xe07'\\x94D\x9a(\xb4\xed\xea\xd7k\x0dc\xc7\xe1+R%\x7f\x9dV\x86\xd9\x8b\x9a\x1a_\xf4
Hashes
Domain hash: 0xE411DFD2D178C853945BE30E1CEFBE090E56900073377BA8B8D0B47BAEC31EDB
Message hash: 0x4BBDE73F23B1792683730E7AE534A56A0EFAA8B7B467FF605202763CE2124DBC
Safe transaction hash: 0x213be037275c94449a28b4edead76b0d63c7e12b52257f9d5686d98b9a1a5ff4

‍With this, you don’t even need to trust the safe API!‍

Finishing up

Once a transaction has been signed at least once, you can get the signature for it from the Safe API without passing the --untrusted command.

Then, once everyone has signed and verified, you can run the command again with the --print-mst-calldata flag to see what the calldata should look like, so you can go a step further and finally verify the actual transaction.

You can view more examples, documentation, and tools in the GitHub repo for the safe_hashes tool.‍

Final thoughts

Ensuring the security of multi-sig transactions is not just about using the right tools but also about understanding the process and the potential risks involved. By following these guidelines, you can safeguard your cryptocurrency assets effectively.

Please have a process for you and your team to verify signatures so you don’t fall for the same hack that plagued the Radiant team!

Originally published at https://www.cyfrin.io.