# Daedalus: the Electron wallet for Cardano with a Nix-based dev environment

> The open source cryptocurrency wallet for ada, an Electron application whose renderer and main processes are built separately with webpack and whose developers run it against a local Cardano cluster through Nix shells, one per network. The hard part of adopting it is not the wallet, it is the toolchain.

**input-output-hk/daedalus** — The open source cryptocurrency wallet for ada, built to grow with the community

- Repository: https://github.com/input-output-hk/daedalus
- Website: https://daedaluswallet.io/
- Stars: 1,247 · Forks: 296
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/input-output-hk-daedalus

## What Daedalus is, and who maintains the documentation

Daedalus is the open source cryptocurrency wallet for ada, built to grow with the community. The primary language in the repository metadata is TypeScript, the application is Electron based, and the licence is Apache-2.0 with both a `LICENSE` file and a `LICENSE NOTICE` file at the root.

The README is short, which is unusual for a project of this size, and it opens with a documentation status block: the document maintainer is Daniel Main and the document status is Active. That block is a promise about the documentation, and the README then routes every other question elsewhere.

Support is delegated to a `SUPPORT.md` guide, and the service response and GitHub issue triage targets are documented in a Service Level Targets document. The contributing guide, the issue triage rules with the labelling, assignment and Good First Issue standards, are all separate documents.

There is a naming wrinkle that is worth flagging. The build badge and the release badge point at `input-output-hk/daedalus`, while the support, contributing and triage links point at `se7en-labs-inc/daedalus`. So the code and the published releases live under the IOHK organisation and the active documents live under a different organisation, `se7en-labs-inc`. The default branch in the metadata is `master`.

The recent releases are 11.5.0 from 2026-10-14, 11.4.0 from 2026-09-18 and 11.3.0 from 2026-09-01, so the wallet ships roughly every two to three weeks, and the last push was on 2026-10-14.

## Nix shells are the entry point, and there is one per network

The development environment section is the substantial part of the README, and it is built around Nix rather than around a language-specific toolchain.

Yarn is required to install the npm dependencies, and Nix is needed to run Daedalus in a `nix develop` shell. The installation of Nix itself uses the Determinate Nix Installer, and then the configuration has to point at the signed IOHK binary cache. The settings to add to `nix.custom.conf` are:

```
trusted-users = <your_user_id>

substituters = https://cache.iog.io https://cache.nixos.org/

trusted-public-keys = hydra.iohk.io:f/Ea+s+dFdN+3Y/G+FDgSq+a5NEWhJGzdjvKNGv0/EQ= cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=

experimental-features = nix-command flakes

# If you are running on a Mac with Apple Silicon chip, but want to also build for Intel:
extra-platforms = x86_64-darwin aarch64-darwin
```

The comment about Apple Silicon and Intel is the kind of detail that saves a day: a developer on an M-series Mac who needs an Intel build has to declare both platforms explicitly.

Once the daemon is reloaded, the shell is entered with `nix develop -L.#mainnet`, which the README says is equivalent to `yarn nix:mainnet`. The other networks have their own scripts, `yarn nix:preview` and `yarn nix:preprod`, and in each case you then run `yarn dev` from the shell that opens.

That per-network structure is the point of the whole arrangement. A wallet has to be tested against a chain, and a local chain that is fast, disposable and configured the same way for every developer is worth the Nix investment.

## A local Cardano cluster with four tuned parameters

Running Daedalus with a Cardano node means running a local cluster, and the README documents its parameters:

| Parameter | Value
| --- | --- |
| slotLength | 0.2 sec
| epochLength | 50 slots
| desiredPoolNumber | 3
| minimumUtxoValue | 1 ADA

A slot length of 0.2 seconds and an epoch of 50 slots make the chain produce epochs very quickly, which is what you need when you are testing staking behaviour or epoch transitions rather than waiting for them. Three stake pools is the minimum that lets the test exercise the multi-pool case, and the minimum UTxO value of 1 ADA keeps the ledger small.

The notes around the cluster explain the behaviour a developer should expect. The Cardano wallet process ID shown on the Diagnostics screen is faked and is expected to match the Cardano node process ID, which is a detail that matters when you are reading a log or an issue report. Stake pool metadata is fetched directly by default, and the IOHK SMASH server option is not available. Token metadata is fetched from a mock token metadata server that is automatically run alongside the local cluster.

Daedalus also asks whether you want to keep the local cluster running after it exits, and the README says that option is useful if you need to preserve local cluster state between Daedalus restarts.

There is one more environment variable worth knowing, for the case where the sandbox blocks the app:

```bash
$ export ELECTRON_DISABLE_SANDBOX=true
```

Disabling the Chrome sandbox is a development-only concession, and the README presents it as the answer to a sandbox error when running Daedalus.

## The token metadata server and the registry file you can edit

For every network except mainnet, Daedalus uses the metadata server at `https://metadata.cardano-testnet.iohkdev.io/`. For local work, the README describes running a mock server inside the `nix develop` shell:

```
$ mock-token-metadata-server --port 65432 ./utils/cardano/native-tokens/registry.json
Mock metadata server running with url http://localhost:65432/
```

Then Daedalus is started with the port passed in:

```
$ MOCK_TOKEN_METADATA_SERVER_PORT=65432 yarn dev
```

The point of the mock is that its data is a file in the repository, at `utils/cardano/native-tokens/registry.json`, so you can edit it directly and the change is visible in the wallet:

```
$ vi ./utils/cardano/native-tokens/registry.json
```

The README also gives a curl command to check that the mock server is answering, which posts a subject hash and a list of properties to the metadata query endpoint. That is the kind of documentation that saves an hour of guessing, because the endpoint and the request shape are the parts that are hard to infer.

For a wallet, token metadata is where a lot of the visible behaviour lives. A native token with no metadata has no name, no ticker and no logo, and the balance screen shows an opaque asset. Being able to edit the registry locally and see the change is what makes working on that path possible.

## Two webpack builds, Cucumber unit tests and Jest

The `package.json` describes the build as two separate webpack bundles, one for the main process and one for the renderer, and the `dev` script runs them concurrently with `concurrently --kill-others --success first --names renderer,main`, waiting on `http://localhost:8080` before starting the main process.

The split is visible in the scripts. `dev:renderer` runs the sass typedef step in watch mode and then webpack serve against `source/renderer/webpack.config.js`, and `dev:main` runs webpack build in watch mode against `source/main/webpack.config.js`. The production `build` chains a cleanup with `rimraf ./dist` and then both builds.

The test story is layered. `test` sets `NODE_ENV=test`, builds, then runs the unit tests and the end-to-end tests fail-fast. The unit tests are Cucumber, with step definitions required from the unit test directories and a tag filter for `@unit and not @skip and not @wip`, and there is a rerun variant for the Cucumber rerun plugin. Jest is present as a separate script, and there is a `test:generate:report` script that runs a reporter script through node-swc.

The quality gate script `check:all` is a list of the project's expectations: formatting check, lint, compile, stylelint, i18n management and a storybook build. The presence of a `storybook/` directory and an i18n step in the same command says the wallet has a component library and translated user interface, which matches the `translations/` directory at the root.

There is also `build:electron`, a script that runs `scripts/rebuild-native-modules.sh`, because an Electron app with native modules has to rebuild them for the runtime it will ship with.

## The repository is much more than the wallet

The top level entries describe an organisation as much as a codebase. Beyond the expected `source/`, `tests/`, `docs/`, `scripts/`, `utils/` and `packaging/`, there are `installers/`, `perSystem/`, `ops/`, `release-cli/`, `release-build.nix`, `flake.nix` and `flake.lock`.

The `perSystem/` and `installers/` directories are the packaging side, and `release-build.nix` plus `release-cli/` are the release pipeline. The `flake/` directory and `flake.nix` are the Nix side. `ops/` is operations, `matomo.docker-compose.yml` is analytics, and `dummy-certs/` and `perSystem/` suggest the packaging deals with certificate handling.

Then there are the files that describe how the project is worked on. `AGENTS.md`, `CLAUDE.md`, `BESTPRACTICES.md`, an `opencode.jsonc` at the root, a `.agent/` directory and a `.claude` file. That is a repository that has formalised how coding agents participate in it, alongside a human-readable best-practices document.

`ralph.sh` is a script of some kind, and `bors.toml` is the configuration for the bors merge bot.

The `hardware-wallet-tests/` directory is a reminder of what this wallet actually is. It talks to hardware wallets, and a test suite for that path is a different kind of requirement from a unit test, because it needs the device.

The `CHANGELOG.md` at the root is the version history, and the build badge points at Buildkite rather than GitHub Actions, so the continuous integration for this project runs on Buildkite.

## Where Daedalus is the wrong choice

The first wrong case is a team that wants a web or mobile wallet. Daedalus is a desktop Electron application with a native node integration, per-system installers and a local cluster for development. There is no web build in the scripts and no mobile target, so a browser-based or phone product is a different project.

The second wrong case is a build environment without Nix. The development shells are the documented entry point, and the IOHK binary cache, the trusted public keys and the flakes configuration are all part of it. A team with a locked-down workstation where the user cannot write to `/etc/nix` and install a daemon is not going to have a pleasant time, and the README's own troubleshooting path for an SSL error during `nix develop` is a reinstall of Nix, which is not a fix, it is a reset.

The third is a user who needs a wallet today rather than a codebase to read. This is a desktop application with a node behind it, and the operational footprint of running your own node is not trivial. A hosted wallet service or a light wallet is the right answer for someone who just wants to hold ada.

The fourth is a team that has a policy against Electron, or that needs a wallet with a threat model its own engineers can audit end to end. Reading the source is a legitimate reason to choose this wallet, and it is also a lot of code to read.

The fifth is an organisation that needs a formal support commitment. The service level targets document the response and triage targets, which is better than nothing, but they are a community project run by a company with its own commercial interests, not a vendor contract.

## Conclusion

Daedalus fits a developer who wants to work on the reference desktop wallet for Cardano, or a user who prefers a wallet whose key handling and node integration they can read, and who is prepared to install Nix and Yarn. It does not fit a team that wants a web or mobile wallet, and it does not fit a build environment without Nix, because the development shells are the entry point. Before setting it up, read `CONTRIBUTING.md` and `docs/SERVICE_LEVELS.md` for the triage and response targets, decide which cluster you will run against with `DAEDALUS_CLUSTER`, and note that the repository documentation links point at `se7en-labs-inc` while the code and releases live under the `input-output-hk` organisation.

## FAQ

### How do I set up the Daedalus development environment?

Install Yarn for the npm dependencies and Nix for the development shell, configure `nix.custom.conf` with the IOHK binary cache settings, then enter a shell with `nix develop -L .#mainnet`, which is equivalent to `yarn nix:mainnet`, and run `yarn dev` from it. There are equivalent scripts for the preview and preprod networks.

### How do I run Daedalus against a local Cardano cluster?

The local cluster uses a slot length of 0.2 seconds, an epoch length of 50 slots, 3 desired stake pools and a minimum UTxO value of 1 ADA. Daedalus can be run with a local cluster through the `yarn nix:mainnet`, `yarn nix:preview` and `yarn nix:preprod` scripts.

### What is the mock token metadata server for?

It lets you run a local metadata server backed by the registry file at `utils/cardano/native-tokens/registry.json`, so you can edit token metadata directly and see the change in the wallet. Start it with `mock-token-metadata-server --port 65432` and then set `MOCK_TOKEN_METADATA_SERVER_PORT=65432` when starting Daedalus.

### How are Daedalus tests run?

The `test` script builds the project, then runs the Cucumber unit tests with the `@unit` tag filter, then the end-to-end tests fail-fast. The `check:all` script runs the format check, lint, compile, stylelint, the i18n management step and the storybook build.

### Which licence is Daedalus released under?

Apache-2.0, with both a `LICENSE` file and a `LICENSE NOTICE` file at the repository root, and the licence badge in the README header linking to it.

## Sources

- [input-output-hk/daedalus on GitHub](https://github.com/input-output-hk/daedalus)
- [License: Apache-2.0](https://github.com/input-output-hk/daedalus/blob/master/LICENSE)
- [Project website](https://daedaluswallet.io/)
- [README](https://github.com/input-output-hk/daedalus/blob/master/README.md)
- [Releases](https://github.com/input-output-hk/daedalus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/input-output-hk-daedalus