2025 will the year where we push hard to make ethui the most powerful and developer-friendly tool to use when building for web3.

https://github.com/ethui/ethui/releases/tag/v1.12.0

The new release comes with some changes that have been brewing for some time:

Revamped UI

We moved away from Mui’s Material UI into a shadcn based component library, and also took the chance to clean up and polish the entire UI. The end result is cleaner, snappier, and much more enjoyable to use (and the code is greatly simplified too).

Specific adjustments have also been made for macOS users to get more of the native feel they’re expecting.

Proxy contracts are now support

The contract explorer tool now supports all major standards for proxy contracts, by allowing you to interact with proxies using their implementation’s ABI rather than the proxy itself.

This work was built as a separate proxy-detect crate, which is itself a re-implementation of an existing Typescript package.

Remote anvil instances

A lot of changes and optimizations have been built to enable a rather powerful use case: you can now host your own anvil instances remotely, even using non-standard chain IDs, and ethui will properly sync with them in realtime, just like it did previously with local ones.

We at Subvisual have been using this feature internally across our web3 projects, by hosting our own private testnet for each project, and using ethui to connect to it.

Safer and faster anvil interactions

Whenever you interact with an anvil chain, all your transactions will now be impersonated by default, all thanks to anvil’s cheatcodes, which we’ve incorporated into our transaction flow.

This means you can now use Fast Mode and skip dialogs and password checks, even when using your actual password-protected HD Wallet to test a contract.

Since you never end up decrypting your private key, or signing any message, this ends up as an even safer way than the default behavior.

New website & docs

Previously, the only written documentation were these blog posts. We’ve now compiled some of the main features and highlights into our own website:

https://ethui.dev/docs

Become a user / contributor

The new release can be downloaded from our website, or directly from github’s releases. You can also build directly from source.

As always, feedback and contributions are most welcome!

https://github.com/ethui/ethui/releases/tag/v1.13.0

https://github.com/ethui/ethui/releases/tag/v1.7.0

ethui already allowed you, since a very early 0.3 version, to interact with arbitrary contracts as if you were on etherscan. This had the benefit of working fully locally, in private anvil chains, and more importantly, without requiring you to publish or verify your solidity source code anywhere

One problem remained though. That interaction was awkward at best. Similarly to etherscan’s UI, you’re forced to juggle inline arrays and tuples anytime you want to interact with something slightly more complex.

@ethui/form

This new package, built primarily for our app, but usable by anyone on their own projects, renders a dynamic form based on a given ABI input.

https://github.com/ethui/demos/raw/main/1.7.0-form.mp4?loop=true&autoplay=true?controls=true

The new form allows for much more complex use cases where it wouldn’t be feasible to manipulate complex fields in a single text box. We’re already using it internally to test merkle-tree based transactions, where a long proof must be submitted.

This is additionally powered by a second package, @ethui/abiparse, which handles some of the tedious work of parsing your raw input into valid transaction parameters.

As you may notice in the video, you can now type “1 ether”, or other subunits, and have it parsed into the correct uint256 amount.

Ironically, this whole feature was initially a side-quest for what we were originally trying to achieve….

Transaction editing

After this release, the transaction preview dialog is now a transaction editing dialog, where you can see a similar form as the one in the contract interaction tool, and tweak your transaction params before actually submitting

Why, you ask? Well, in many cases, it’s a convenient way to see the simulation update in real-time, and provide you with information of how it would react to slightly different params.

https://github.com/ethui/demos/raw/main/1.7.0-tx-review.mp4?autoplay=true&loop=true&controls=true

What’s next?

Next up, we plan to redirect our attention back to indexing, taking the chance that reth has now released Execution Extensions, which could make our work much more pleasant and efficient

https://github.com/ethui/ethui

https://github.com/ethui/ethui/releases/tag/v1.6.0

A new name?

Long story short: a cease & desist from a project that has recently registered a trademark that created a conflict with our name. Being an open-source tool, and a rather young one at that, and without any legal structure in place we didn’t have any legal structure in place, it became a good opportunity for a change.

It’s also a good opportunity to do away with the “Wallet” part of the name. That quickly became a confusing bit, since our goal is not necessarily to be a direct competitor in the wallet space.

Our value proposition, at least for the moment, is not for the average user, but for the developers and power users who want better tooling to interface with the Ethereum ecosystem.

In short, we want to provide a powerful UI for Ethereum development and interaction (or any EVM-capable chain). So the name ethui came along.

What does this mean?

Not much, other than the name change itself.

• ethui.eth is now our canonical ENS address (iron-wallet.eth is still ours, and both point to the same address, for backward compatibility)

• https://iron-wallet.xyz is now https://ethui.dev

• the new release of both the app and the browser extension went through the obligatory Find/Replace process

As a side effect, if you’ve used a previous version of Iron Wallet, you may have to manually port your config over to the new version, or start again from the onboarding process. This should be as easy as:

# for linux
cd ~/.config
mv iron-wallet ethui

# for macos
cd ~/Library/Application\ Support
mv iron-wallet ethui

What about concrete progress?

Of course, we have a few of those, too!

Faster Alchemy.com sync

The previous sync logic was somewhat poorly built, resulting in a huge delay between first adding a wallet, and seeing its mainnet transaction history.

The new approach speeds up the process considerably, while also prioritizing data requested explicitly by the UI.

Improved simulations

Transaction previews now show additional information such as ERC20 transfers, and the number of past known transactions to that address, which should help catch unintended transactions such as phishing attempts.

Improved contract interactions

The built-in explorer and contract interaction tool now supports many broad use cases and argument types that were previously tricky to parse. This is largely thanks to the great work done in the recent alloy-dyn-abi crate.

Better wallet onboarding

The previous onboarding flow was limited, especially when it comes to wallet setup. Since wallet needs vary from user to user, it’s important to make the possibilities clear from the start.

The new flow directly allows you to create as many wallets of as many types as you need, right from the start.

Icons all around

We added Effigy avatars, chain icons, and token icons for well-known currencies, to enrich the UI and more easily identify things at a glance

There are many other incremental improvements, performance optimizations, and bug fixes, that you can check out on the release history.

Check out the wallet, or dive directly into the source code to contribute or make a feature request!

https://ethui.dev/

https://github.com/ethui/ethui

This time, we’ve got some juice.

Iron Wallet 1.1.1 brings three major functionalities, read on for the updates, or download the latest release:

https://github.com/iron-wallet/iron/releases/tag/v1.1.1

Ledger support

One of the few things still forcing me to use other wallets was the need to use my hardware wallet—no more.

Now USB ledgers are fully supported as a signer on the wallet.

Keep in mind that it’s a fresh new feature, so some behaviors may be finicky, but since Ledgers themselves provide security, this is a safe feature to expose and iterate on.

When comparing to MetaMask’s ledger support, a few key advantages stand out:

• Easier to add multiple addresses (although you currently need to input the raw derivation path. We’ll improve that UX soon)

• Transactions are not immediately rejected if you start one without having your ledger available. Instead, the review dialog will wait until your device is ready (unlocked & with the Ethereum app open)

https://github.com/iron-wallet/video-demos/raw/main/1.1.0-ledger.mp4?controls=true&autoplay=true&loop=true

Devtools panel

One of the things we’ve wanted for a long time was the ability to debug RPC calls from a browser tab the same way we debug network requests: by having full access to them in the browser’s devtools, scoped to each tab.

That’s finally available today:

https://github.com/iron-wallet/video-demos/raw/main/1.1.0-devtools.mp4?controls=true&autoplay=true&loop=true

This task was also the result of our bounties published at ETH Lisbon. congrats to @PolpEdu for getting the work going and winning our bounty!

Onboarding flow

From now on, when running the Wallet for the first time, you’ll be greeted with a small setup screen that will walk you through some necessary steps. This includes mainly setting up an alchemy.com API key (required for mainnet indexing), and setting up the browser extension)

Like the previous feature, this was also spearheaded by a first-time contributor, our apprentice Pedro Ferreira!

Live on Gitcoin 19

The latest Gitcoin round is now live, and Iron Wallet is up in the Web3 Open source category. so if the project has been of use to you, consider supporting it.

https://explorer.gitcoin.co/#/round/424/0xd4cc0dd193c7dc1d665ae244ce12d7fab337a008/0xd4cc0dd193c7dc1d665ae244ce12d7fab337a008-94

Or just go say hi to us in DevConnect & WalletUncon. We don’t bite.

https://iron-wallet.xyz/

Along the way, there are some great quality-of-life features now available in 0.7.0. Read on to know more!

https://github.com/iron-wallet/iron/releases/tag/v0.7.0

First of all - ETH Lisbon & Bounties

The event starts tomorrow, hosting hundreds of builders for 48 hours of non-stop hacking. We’ll be there. Iron will have a workshop on the first day, and we invite participants to use it when building their own projects.

Additionally, we also snuck in a few bounties ourselves, so if you’re looking to hack something that can directly contribute to the next release, this is your chance to be paid along the way.

Future bounties

ETH Lisbon will be a testing ground for this model. We have plans to open up additional bounties, for various levels and skill sets, on platforms such as OnlyDust.

What’s new in 0.7.0?

HTTP API

One of the long-running tasks we discussed early on was the ability to interact with the wallet in a headless/automated way.

You now have access to a set of HTTP endpoints for some select features:

• Submitting transactions (going through the same confirmation flow as a browser interaction would)

• Simulating transactions

• Querying the name & ABI of contracts found within your filesystem

As a basic example, here’s how you would simulate a transaction:

curl \
  -H "Content-Type: application/json" \
  -d '{"chainId": 31337, "request": {
    "from": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
    "to": "0x5fbdb2315678afecb367f032d93f642f64180aa3",
    "data": "0x6a627842000000000000000000000000f39fd6e51aad88f6f4ce6ab8827279cfffb92266",
    "gasLimit": 669107
}}' \
  http://localhost:9003/iron/transactions/simulate | jq

You specify the target chain, and the transaction parameters (as you would for a regular transaction). This can be coupled with tools such as cast to provide automatic ABI encoding, although that’s something we intend to provide in the future. As a result, you get a response that includes all details about the execution:

{
  "simulationId": 1,
  "gasUsed": 151346,
  "blockNumber": 4,
  "success": true,
  "trace": [
    {
      "callType": "CALL",
      "from": "0x0000000000000000000000000000000000000000",
      "to": "0x0000000000000000000000000000000000000000",
      "value": "0x0"
    }
  ],
  "logs": [
    {
      "address": "0x5fbdb2315678afecb367f032d93f642f64180aa3",
      "topics": [
"0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
"0x0000000000000000000000000000000000000000000000000000000000000000",
"0x000000000000000000000000f39fd6e51aad88f6f4ce6ab8827279cfffb92266",
"0x0000000000000000000000000000000000000000000000000000000000000005"
      ],
      "data": "0x"
    }
  ],
  "exitReason": "Stop",
  "returnData": "0x"
}

This is already being used internally by Iron to power the transaction review dialog, where you can debug the outgoing logs before confirming a transaction.

Transaction View

The UI now includes full details of a past transaction, with a JSON view included that shows you the decoded calldata, as long as an ABI for that contract is known.

Fast mode

As you can see in the sidebar on the previous screenshot, you can easily toggle the new “Fast mode”.

What is “Fast mode” you now ask? It toggles the ability to skip transaction & signature confirmations. This only affects anvil networks + plaintext wallets, for security reasons, but it does allow for very fast feedback loops when building a website, while still allowing the ability to debug specific transactions when needed.

And much more

This release is by far our largest in terms of work hours and merged contributions. Most of those are the quiet type, such as bugfixes, and incremental UI improvements.

But don’t let that fool you, see the changelog for yourself. And do try out the wallet!

http://github.com/iron-wallet/iron

https://github.com/iron-wallet/iron/releases/tag/v0.6.0

0.6.0 brings a bunch of new features, as well as several performance and bundle size improvements to the browser extension. Read on for the main highlights

But first, a big thank you!

To all those who contributed to the ongoing Gitcoin #GG18, where Iron Wallet is performing way better than we could ever anticipate ❤️

Multi-chain routing

A big limitation of most wallets is the existence of a single global connection: you can only be in a single chain, and account, across all the dApps you're using.

Developers face this daily: developing on MetaMask + anvil means we can't keep a separate mainnet workflow on a separate tab, unless we're okay with dealing with constant popups asking us to switch back and forth. With the growth of L2s, this is increasingly a user-facing problem too.

For Iron, that ends today.

https://github.com/iron-wallet/video-demos/raw/main/0.6.0-chain-affinity.mp4?controls=true&autoplay=true&loop=true

With the new chain router, each domain name stays connected to whichever chain it wants. You can still manually switch individual ones through the "Connections" page of the wallet, and you can opt-in to the previous behavior by setting domains to use the "Global" network.

EIP-6963

We now support the recent Multi Injected Provider Discovery spec. This one was courtesy of the folks over at wagmi, who authored mipd and made the work as trivial as it could possibly be.

This EIP is fairly new, and its effects won't be fully felt until most major wallets and SDKs support it, but it will eventually allow multiple extension providers to co-exist in the same browser.

This was a big limitation for Iron and other extensions and imposes a big blocker to wallet diversity

Livenet contract tracking

Via a new form in the Contracts tab, and the Etherscan API key you can now include in the settings, you’re now able to manually add arbitrary contracts for each network.

Lazy extension connections

Our old version of the "Connections" tab would display every single browser tab, regardless of whether the Web3 connection was used or not.

This caused visual noise, resource waste, and was also a source of confusion for some users. It is now fixed, by ensuring the connection is lazily set up. Only pages that actually trigger a Web3 request will show up.

Some chromium nonsense finally dealt with 🎉

It’s a good feeling when a long-standing bug is finally squashed. Especially when it turns out to be the browser itself at fault.

https://github.com/iron-wallet/iron/pull/356

The bug in question is also considered in the MetaMask codebase, and would cause the Iron extension to sporadically fail to communicate with the desktop app. The workaround has been applied, and provider connections are now fully stable.

What’s next?

Building. and then some more building. Hoping that next release is when we finally get to focus on transaction simulations!

There are also a few backend performance improvements that we stealth-released in 0.4.0 a few weeks ago.

https://github.com/iron-wallet/iron/releases/tag/v0.5.0

Account impersonation

I’m a big fan of impersonator.xyz. But most of our development work is done locally, through Foundry tests and anvil nodes, where this external tool can’t be reached.

But in fact, the job done by this tool is surprisingly simple. It’s nothing more than a glorified anvil_impersonateAccount , but needing to go through the WalletConnect Protocol and an awkward experience of manually pasting URLs. Mainly because the wallets we use are not prepared for such behaviors, primarily needed by developers and security researchers.

In fact, it’s eye-opening to learn that a surprising number of people in the space are not even aware that impersonation is a possibility, and of what can be done with it: locally reproduce the UI state of someone else’s account.

This is an incredibly powerful feature for anyone working on a protocol frontend, where it’s crucial to have reproducibility of whatever bugs our users report.

The only caveat, as you may have guessed, is that this has minimal use for websites that require signing a message at connection time.

But for those that don’t, such as Uniswap, here’s what you can do:

https://github.com/iron-wallet/video-demos/raw/main/0.5.0-impersonator.mp4?autoplay=true&loop=true&controls=true

New logo

This was quietly released during the crazy EthCC week but is only now being made official, and broadly available in all components (extension icon, taskbar icon, and overall branding).

Revamped UI

Our lead front-end has been focused on providing as much of a desktop-native experience as possible. That includes improving on the UI itself and going through the slow & painful process of doing OS-level improvements.

The new sidebar makes for a much more compact and comfortable design. And those of you running macOS may notice some additional tweaks that make Iron feel increasingly more like a native macOS / Linux app rather than a website.

Onboarding flow

If you now open the wallet for the first time, you’ll be greeted with a new onboarding flow, where you’ll have the opportunity to go through some basic settings that are crucial to know about, and were previously hidden away (unless you’ve been following all these posts)

This flow will still suffer more iterations in the future, and we hope this can help reduce the barrier to first getting started with the app.

What’s next?

The impersonation feature is an important milestone, as it means we’re 50% done with our goal of providing the main features we showcased at ETHGlobal Lisbon. The second part (transaction simulation) will expand even more the possibilities of what you can do.

We also plan to be in San Francisco with fellow ETH / Rust developers, so hit us up if you’re there! We’d be happy to hear any constructive feedback, and get our product in as many developer hands as possible.

For local development (via Foundry, Hardhat, or others) you’re out of options though.

Wether you’re writing the contracts, or the UI for your protocol, the ability to explore and interact with your local contracts similarly to Etherscan would be a killer feature.

So we did it. And this is how.

https://github.com/iron-wallet/video-demos/raw/main/0.4.1-forge-abis.mp4?controls=true&autoplay=true&loop=true

Filesystem tracking

The magic happens in our iron-forge crate.

Since this behavior relies on filesystem monitoring, we make opt-in rather than opt-out. This is due to potential concerns users may have with us snooping into their filesystem, and because we need to give control over which path to scan:

Enabling the ABI watcher, along with a watch path, will cause Iron to listen to filesystem events under that path.

We’re interested only in events related to Foundry’s compilation outputs. By default, those have the format <project>/out/<Contract>.sol/<Contract>json

So whenever a file matching such a path is modified/deleted, we immediately update our in-memory index.

We also do some additional parsing, to ensure the file is of the expected format (and not a false-positive), and to extract ABI information.

On-chain bytecode

Iron already was anvil-aware since the very first version.

We track all transaction traces, to not only construct your account state (balances, transaction history) but also to detect newly deployed smart contracts.

Doing this via traces allows us to detect not only plain contract deploy transactions but also internal ones triggering new `CREATE` and `CREATE2` opcodes. With `ethers-rs`, this becomes trivial:

async fn expand_trace(trace: Trace, provider: &Provider<Http>) -> Result<Vec<Event>> {
    let events = match trace {
        // detecting contract deploys
        Trace {
            action: Action::Create(Create { from, value, .. }),
            result: Some(Res::Create(CreateResult { address, .. })),
            ..
        } => {
            // a contract deploy was detected!
            ContractDeployed {
                address,
                code: provider.get_code(address, None).await.ok(),
            }
            .into(),
        }
        
        // other detectors...

Notice we also run eth_getCode. This is used to later match on-chain contracts with the corresponding ABIs we compiled above. But how can we do that if all we have is bytecode?

Matching ABIs - Naive version

What Etherscan does is something too complex for our use case: they expect to have the full source code, exact compiler version used, and full constructor arguments given during deployment. By running the exact same compilation & deployment process, they should end up with the same bytecode, thus verifying that the ABI for the given source does indeed match the contract.

Instead, we started with a much simpler solution: we already have the final bytecode from the Foundry output:

{
  "abi": [
     ...
  ],
  "bytecode": {
    "object": "0x60a06040523480156...",
  },
  "deployedBytecode": {
    "object": "0x60806040523480156...",
  }
 }

The deployedBytecode the field should match the on-chain code we got from eth_getCode, right?

Narrator: it would not.

Oh... how so?

Many different bytecodes

You may have heard about Initialization bytecode and Runtime bytecode (or other variations of those names).

That's because, to deploy a contract on EVM, a snippet of bytecode is executed, which will return the runtime code to the EVM. Constructor arguments also need to be included somehow, even though they're not stored as part of the final bytecode itself.

This great article provides a complete explanation of this process if you're curious.

When Foundry builds our contracts, it doesn't have any context of what the constructor arguments will be. And similarly, it doesn't know the final value of immutable slots, since those depend on those same arguments.

Here's a complete example of a small contract, and its corresponding output bytecode:

pragma solidity ^0.8.13;

contract Immutable {
    uint256 constant foo2 = 100;
    uint256 immutable foo;

    constructor(uint256 _foo) {
        foo = _foo;
    }

    function get() external view returns (uint256) {
        return foo;
    }
}

Notice the suspicious string of 00s somewhere in there? Those correspond to the 256-bits where the value for foo will eventually go, once the constructor is executed.

This is a nice trick by Solidity to create more gas-optimized contracts, but it does mess a bit with our ability to match against on-chain bytecode.

In the end, it turns out a simple & elegant solution already existed on the Foundry codebase itself (thanks to Matt Solomon who shared it):

pub fn diff_score(a: &[u8], b: &[u8]) -> f64 {
    let cutoff_len = usize::min(a.len(), b.len());
    if cutoff_len == 0 {
        return 1.0;
    }

    let a = &a[..cutoff_len];
    let b = &b[..cutoff_len];
    let mut diff_chars = 0;
    for i in 0..cutoff_len {
        if a[i] != b[i] {
            diff_chars += 1;
        }
    }
    diff_chars as f64 / cutoff_len as f64
}

This will compare two bytecode snippets, and compute how different they are. Since contract logic is typically large enough to out-weight the bytecode length of all immutables, it's sufficient to consider any contract with a difference of < 10% to be a match. As described in the original code, this should only be expected to fail for contracts that are essentially only immutable variables, which are unlikely to be found in real-world usage.

Next up

One glaring omission we don’t support yet are Proxy contracts. Those will be a challenge on their own, but one we expect to tackle pretty soon. Stay tuned!

This release is focused on supporting live networks, particularly Ethereum mainnet.

While our main target is developer tooling, we also believe it’s crucial to support regular interactions and use Iron as our daily driver for Ethereum. This release is what finally allows for that

https://github.com/iron-wallet/iron/releases/tag/v0.3.1

HD Wallets

https://github.com/iron-wallet/video-demos/raw/main/0.3.0-hd-wallet-setup.mp4?autoplay=true&controls=true&loop=true

The most critical feature to allow us to migrate from other wallets into Iron is the ability to import the same seed phrase, so we get access to the same set of addresses.

This one is important to get right because a big part of the security aspects hinges on how well we protect this secret.

That’s why we took the time to investigate how other wallets implement this, and what our own approach should be. What cryptographic primitives should we favor? What attack vectors should we look out for?

After a period of research, where we dug into the codebases of MetaMask, Frame.sh, and other wallets, we arrived at an implementation that uses state-of-the-art cryptographic primitives (Argon2 and XChaCha20Poly1305), as well as OS-level memory protection, provided mainly by the Rust secrets crate.

On this iteration, we held off on allowing users to generate their own seed within the app. That feature will be dealt with on its own later, as it has its own security concerns to take into account.

For now, though, the setup flow already looks comfortable enough to migrate existing seeds:

Transaction indexing

Getting real-time and historical data from blockchains is a real problem. Blockchains are great for reaching consensus on state, but terrible at allowing arbitrary queries to that same state. Simple operations such as “Give me the transaction history for this wallet” or “What ERC20 tokens am I holding?” are actually complex to implement, because they mostly rely on 3rd party indexers or bespoke clients to crunch the data for you

In this first iteration, we rely on alchemy.com as our data provider for live networks.

You first need to add an Alchemy API key to your wallet settings. After that, transaction and asset indexing should happen automatically and periodically for all your connected wallets.

There are two main points for improvement here in the future:

• Support for additional providers. We do not want vendor lock-in

• Better heuristics for updating addresses, while being mindful of rate limits

New version notices

A simple but effective feature: from now on, the UI will notify you of new releases as soon as they happen!

Future plans and branding

We’re already actively working on the next batch of updates, including transaction simulation. But a lot of the recent work has been done outside of Github: we’ve been working with one of Subvisual’s designers to finally improve our branding and image.

Expect news here on the very next release, particularly in the form of a brand-new logo. Our Minecraft placeholder has run its course.

https://github.com/iron-wallet/iron

Around a week after the first public release, here’s a new batch of updates. This time, the focus is a significantly improved UI, but there are also some interesting updates regarding secure wallets.

https://github.com/iron-wallet/iron/releases/tag/v0.2.1

Address Aliases

You can now right-click any address and assign it an alias. This should greatly improve readability, and help you understand which accounts or contracts you’re interacting with. (#203)

https://github.com/iron-wallet/video-demos/raw/main/0.2.0-alias.mp4?autoplay=true&loop=true&controls=true

Command Bar

Ctrl+K will likely be the main navigation tool within the app. Quick network & account switching is now a breeze. (#182, #207)

https://github.com/iron-wallet/video-demos/raw/main/0.2.0-kbar.mp4?autoplay=true&loop=true&controls=true

Secure wallets (JSON Keystore)

The initial release only supported a single wallet type: a plaintext mnemonic, meant purely for testing purposes and not fit for storing actual funds.

Two steps were missing to enable asset security and confidence when interacting with mainnet: secure wallets, and an external indexer.

This is the first step towards that. While JSON Keystores are not the most popular, they’re a solid foundation on the way to broader support. Having this means we now have first-class support for multiple types of wallets (essential for good abstractions), proper logic for handling wallet unlock through dialogs, and a lot of the foundations needed to properly store secrets in memory (more on this in a future, more technical, blog post).

https://github.com/iron-wallet/video-demos/raw/main/0.2.0-json-keystore.mp4?autoplay=true&loop=true&controls=true

Copy to clipboard

A small but effective detail. Clicking on various elements (addresses, ETH amounts, transaction hashes, …) will now copy its raw value to your clipboard.

Viem & smaller bundle

We migrated from ethers.js to the newer viem.sh. This significantly reduces the UI’s bundle size of the UI build. (#204, #205).

What’s next

Here are some of the main highlights of what we’re already working on:

• mainnet data indexing. initially through alchemy.com but other providers to come later

• Support for encrypted mnemonic wallets

• A proper logo

All updates will be done via Mirror and Github, so keep an eye out, and feel free to create issues if anything comes up!

https://github.com/iron-wallet/iron/releases/tag/v0.1.0

TL;DR

If you’re a developer or any type of Ethereum power user, this will likely interest you.

Iron is a crypto wallet built, from the ground up, with development & debugging in mind. It bundles together features that, as of now, exist only as loose CLI tools and 3rd party websites and, guess what? It all runs locally on your device, with fully open-source code.

The initial version is already incredibly more powerful than alternatives as a companion to the Foundry toolkit. Read on for the list of current features and to get updated on what’s next.

Our aim is to make this as community-driven as possible, so your feedback and suggestions are the most important thing right now.

Yet another wallet?

This project was born out of frustrations with existing tooling.

When working with diverse teams, where not everyone is an EVM expert – think frontend developers, product managers, or newcomers to the blockchain space – it becomes clear that a lot of tooling already exists, but often in a very loose and low-level way, accessible mostly to the experts.

We want to address this problem by making all of these tools accessible directly from the wallet, with the speed and intuitiveness we’ve come to expect from other tools. Our wallet is what sits between us and a blockchain. As developers, we need it to be helpful, not a hindrance.

The current offering of wallets is unfortunately subpar in several ways. MetaMask suffers from various UX issues, and from being stuck in the browser’s sandbox. Snaps are mostly a band-aid with a fair number of limitations themselves. Frame proves the advantage of an OS-level wallet and brings the welcome addition of OmniChain routing, but the advantages mostly stop there.

Not to throw any shade on projects such as MetaMask – huge respect for their team and for all their contributions, a lot of which are powering this project as well – but we can and should do better on what comes to developer tools.

What does it do?

First of all, in good ol’ Rust fashion, it’s blazingly fast. Here’s a NFT minting demo running on anvil:

Other than basic wallet features, the bulk of the work so far was focused on a tight integration with Foundry, specifically:

1. Instant detection of chain restarts/reverts. Fully re-syncs local data (transaction history, balances, and most importantly, nonces);

2. Instant detection of smart contract deploys. This works via transaction traces, so even internal transaction deploys are indexed;

3. Filesystem monitoring, to automatically index known ABIs found within foundry projects;

4. Built-in contract explorer & interaction UI (built from same ABIs);

5. No password-protection or confirmation popups when using anvil with a development wallet;

It also provides a native desktop experience (e.g. keyboard shortcuts, minimize to system tray, contextual menus) and most importantly … dark mode!

Soon

There are two key features we want to launch on the next iteration:

• Support for encrypted (not plaintext) wallets. Initially from a JSON keystore file, but with other formats, such as GPG & hardware wallets, soon to come. The initial work for this is nearly ready;

• Integration with a 3rd party indexer for mainnet/testnet data.

Next up, there’s the project we hacked at ETHGlobal Lisbon: the ability to impersonate wallets, and locally simulate transactions, and inspect for side effects before actually submitting. This is powered by the REVM. It provides the same capabilities as Tenderly and Impersonator, right from your wallet.

There’s also a lot of work to be done on standards, both implementing them — looking at you, EIP-6963 — and working on improved ones.

There’s a lot more to be done after this, but we’re not committed to any specific roadmap, especially because we want help from the community on deciding what’s important.

Who’s building this?

I’ve (@naps62) started this as a side project over the past couple of months.

I’m a blockchain developer with over a decade of coding experience: building products, mentoring teams, and obsessing over type safety. I am also an Associate Security Researcher at Spearbit.

Both Lightshift Capital and the Subvisual community have provided tons of help in the form of time, code contributions and feedback. There were many contributions and helpful discussions from various peers, but a shoutout in particular to @gabrielgpoca and @pvgo.

Can I help?

Of course! All help is welcome.

The next set of features will mainly be informed by community feedback. The project is and will always be free, open-source and community-drive. The most important step right now is to hear from you, whether that’s through a feature request, a bug fix, or just a message to one of us.

https://github.com/iron-wallet/iron