DRep Votes
  • Total Stake: ₳ 14.91B
  • Yes Votes (Stake)
    ₳ 215.8M
  • Total No (Stake)
    ₳ 5.32B
    Explicit No
    ₳ 1.59M
    No Confidence
    ₳ 183.91M
    Not Voted
    ₳ 5.13B
  • Excluded (Stake)
    ₳ 9.38B
    Explicit Abstain
    ₳ 0.00
    Auto Abstain
    ₳ 9.16B
    Inactive
    ₳ 210.39M
CC Votes
  • Total Committee Members: 7
  • Yes Votes
    0
  • Total No
    7
    Voted No
    0
    Not Voted
    7
  • Abstain Votes
    0

Abstract

This Treasury Withdrawal funds Daedalus Wallet Maintenance and Improvements
2026–2027, delivered by Se7en Labs, Inc.

Daedalus is Cardano's only full-node desktop wallet — it runs an embedded
Cardano node and derives all wallet and governance data directly from the
chain, with no third-party APIs or trusted backends. Because it participates
in P2P networking and maintains its own local mempool, Daedalus transactions
compete for block inclusion on equal footing with full-node participants,
providing reliable submission even under high chain utilisation where lite
wallets can fail for hours.

Daedalus's security model is equally distinctive. Private keys are generated
and stored on your own device and never transmitted to any external service.
Because Daedalus is open-source under the Apache License 2.0, this is not
a claim users must take on faith — anyone can audit the source code to
verify that key handling works exactly as described. Se7en Labs actively
works to ensure a positive user experience that balances the trade-offs
inherent in running a full-node wallet.

According to opt-in telemetry, Daedalus has approximately 4,000 monthly
active users — though the true count is meaningfully higher, as
privacy-conscious full-node users are the least likely to opt in.

This is a time and materials engagement covering three areas:
1. Protocol Maintenance — Node upgrades, hard fork readiness (Leios,
Peras, Nested Transactions), with a compatible release at least 2
weeks before every mainnet hard fork
2. Ecosystem Expansion — Keystone and Flex hardware wallet support,
CIP-30 dApp connector, Japanese localisation
3. User Support — Responsive support for the Daedalus user base,
with dedicated attention to the Japanese community and a commitment
to keeping Daedalus fully translated for Japanese users

IOG continues to support binary signing, ensuring cryptographic release
authenticity as funding transitions to the treasury.

Motivation

Pillar 1: Infrastructure & Research Excellence (Primary)

The Cardano Vision & Strategy framework (ratified on-chain by DRep
supermajority, January 2026) calls for Cardano to keep Cardano secure,
fast, and interoperable so it can host more economic activity.
Daedalus
is the only full-node desktop wallet in the ecosystem — every installation
is a full Cardano node, contributing directly to the decentralization and
resilience of the network.

This proposal directly advances I.2 (Security & Resilience),
specifically the strategy's focus on client diversity: Support
additional full-node and light-client implementations with conformance
testing — Better decentralization.
Daedalus is the primary vehicle
through which non-technical users run a full node. A maintained Daedalus
is a maintained contribution to client diversity. If it falls behind on
protocol compatibility, OS support, or security, those users have no
alternative that preserves their standards for self-sovereignty.

This proposal also supports I.1 (Scalability & Interoperability) by
ensuring Daedalus ships updated node versions as Leios (CIP-0164) and
Peras progress toward mainnet. Both are consensus protocol changes
handled by the node — but a wallet running an incompatible node version
cannot sync, meaning timely node upgrades are essential for Daedalus
users to benefit from the scalability improvements the strategy depends
on.

Pillar 2: Adoption & Utility (Secondary)

CIP-30 support advances A.1 (High-Value Verticals) — specifically
DeFi access. Daedalus users are currently locked out of DeFi and dApp
interactions unless they switch to a browser wallet. CIP-30 changes that,
opening the full dApp ecosystem to full-node users without compromising
their trust model.

This also supports A.3 (Developer Experience): Incentivize the
maintenance of core Cardano SDKs, frameworks, and infrastructure in line
with open-source best practices.
Daedalus is foundational open-source
infrastructure. Funding its maintenance through the community treasury is
exactly the model the strategy envisions.

Pillar 4: Community & Ecosystem Growth (Secondary)

The 2030 strategy identifies C.2 (Global Engagement & Market Adoption)
with a specific focus on localized adoption — target specific,
high-impact markets (e.g., LATAM, Africa, East Asia) with localized
partnerships and communication strategies.
Japan is one of the most
historically engaged Cardano communities in the world, and Daedalus has
maintained full Japanese translation support since its earliest releases.
This proposal continues that commitment, ensuring the Japanese-language
interface remains current across all new features delivered during the
contract period.

KPI Alignment

Monthly Active Users (MAU) — Target: 1M by 2030

The strategy measures MAU as unique addresses with transactions over a
30-day window.
Every active Daedalus user contributes to this metric.
Keeping Daedalus fast to sync (Mithril), compatible with modern hardware
(Apple Silicon), and current on dependency versions lowers the barrier to
running a full node, directly supporting MAU growth from the self-sovereign
user cohort. CIP-30 support unlocks dApp interactions for this population,
increasing their transaction frequency.

Monthly Transactions — Target: ≥27M submitted transactions/month by 2030

CIP-30 support routes dApp transaction volume through users' own full
nodes. Daedalus users currently have no path to dApp activity without
switching wallets — CIP-30 unlocks that entirely, contributing new
transaction volume from a population that previously had none.

Alternative Full Node Clients — Target: ≥2 live, spec-conformant

The strategy explicitly tracks this under operational resilience. While
Daedalus is a wallet rather than a consensus node, it is the primary
mechanism through which non-technical users run a full Cardano node.
Maintaining Daedalus directly supports the ecosystem's full-node
footprint and the decentralization targets the strategy depends on.

Uptime / Protocol Stability — Target: 99.98% uptime

Shipping a compatible Daedalus release before each hard fork keeps users
online through protocol transitions rather than forcing them offline.

Hardware Wallet Coverage

Supporting newer hardware wallet models grows the population of
security-conscious ADA holders who can use Daedalus without compromising
their signing security.

Rationale

Strategic Pillar Alignment

Pillar Alignment
I.1 Scalability & Interoperability Timely node upgrades for Leios, Peras, and Nested Transactions
I.2 Security & Resilience Client diversity; every Daedalus install is a full Cardano node
A.1 High-Value Verticals CIP-30 unlocks DeFi and dApp access for full-node users
A.3 Developer Experience Maintenance of foundational open-source infrastructure
C.2 Global Engagement Japanese localisation and community support maintained

Nature of This Proposal

Daedalus is free and open-source software released under the Apache
License 2.0. Se7en Labs does not monetize Daedalus usage and captures no
customer relationships, subscription revenue, token value, or IP
exclusivity from this work. All funded outputs — source code, build
tooling, documentation, and release artifacts — are public assets in
perpetuity, forkable by anyone under the Apache 2.0 license. This
proposal is a pure public good grant: the treasury is funding maintenance
of community infrastructure, not subsidizing a private business expansion.

Open-source auditability is especially important for a wallet. Any wallet
can claim not to exfiltrate keys; only an open-source wallet can prove it.
The Apache 2.0 license ensures this auditability is permanent: no future
license change can prevent the community from inspecting, forking, or
continuing the software independently. A treasury-funded wallet under a
permissive open-source license is a public good in the strongest sense —
the community owns it regardless of what happens to any particular vendor.

Track Record

About Se7en Labs

Se7en Labs is a Cardano-native software company. Founding members launched
DripDropz in 2022 — the token distribution platform that has delivered
community token drops every epoch since launch. Members contributed to
the Hydra Doom demonstration and built a live Hydra event platform deployed
at Rare Evo, Token 2049, Cardano Summit Berlin, and Nuluna 2025. Se7en
Labs members served as chair and vice-chair of the Cardano Product
Committee, leading the process that produced the Cardano Vision and
Strategy framework — ratified on-chain by a DRep supermajority in January
2026.

Daedalus Delivery Record

The team assumed responsibility for Daedalus under an IOG contract in
January 2026. Shipped since then:

  • Mithril Snapshot Bootstrap: Full Mithril integration for fast initial sync — 3-step UX, storage management, fallback flows, E2E test coverage, cross-platform installer hardening across Windows and macOS
  • UTxO-HD / LSM Backend: Integrated cardano-node 10.7.1 with the LSM storage backend, preparing users for Cardano's on-disk UTXO model
  • Apple Silicon (aarch64): First native aarch64 Darwin builds with auto-detection in the updater; existing users migrate transparently
  • drt Release CLI: Purpose-built release toolchain replacing Buildkite scripts — Apple notarization via xcrun notarytool, parallelized signing, internal Windows binary signing before NSIS packaging, hash verification
  • Nix Build Modernization: Migrated to flake-parts, upgraded to nixpkgs-25.11, removed legacy MacInstaller.hs, migrated CI from Buildkite to Hydra + drt

In progress: DRep Selection Dashboard, Ouroboros Genesis support, hardware
wallet support for newer devices, Electron upgrade (17 major versions;
resolving cross-platform native module complexity), and partial Mithril sync
(allowing Daedalus to begin syncing from a Mithril snapshot mid-chain rather
than requiring a full resync).

Proven Capabilities

The team spans Haskell/cardano-node integration, Electron/React frontend,
Nix build systems, release engineering, and QA — the full breadth needed
for Daedalus's complexity. Team members have direct experience with
cardano-node and the on-chain governance stack. The team inherited a
codebase unable to produce a release, performed foundational Nix
refactoring, and shipped Daedalus 8.0 and 11.0 within the IOG contract
period. Daedalus 11.0 was the first wallet capable of crossing the node
11.0 hard fork. The ongoing IOG binary signing
arrangement demonstrates a mature working relationship preserving release
security through the funding transition. The team has been operating under
an IOG contract for Daedalus maintenance since January 2026, closing
August 31, 2026. Se7en Labs has not received ada from the Cardano Treasury
within the last 24 months.

Scope of Work

This work covers all maintenance and development required to keep Daedalus
functional, secure, and compatible with the evolving Cardano protocol
throughout the contract year.

Node & Wallet Backend Currency — Integrate cardano-node and
cardano-wallet releases as shipped; maintain Nix build infrastructure,
dependency updates, security patches, and platform compatibility.

Security & Dependency Maintenance — Keep Electron, Node.js, and all
wallet-adjacent dependencies current to address known vulnerabilities as
they are disclosed. Maintain a reproducible Nix build pipeline so every
release can be independently verified by anyone. Ensure key generation,
storage, and signing code remains auditable, unchanged, and never
transmitted off-device — preserving the core security guarantee that
Daedalus's users depend on.

Hard Fork Integration — All Daedalus changes required for each
upcoming hard fork, with testnet verification and a compatible stable
release at least 2 weeks before mainnet activation.

Leios, Peras & Nested Transactions Readiness — Ship compatible node
versions as these protocols progress toward mainnet; monitor for
user-facing UX impacts; maintain compatibility ahead of each
testnet/mainnet activation.

Binary Signing Continuity — Maintain the IOG signing arrangement
for all official releases throughout the contract period. CI infrastructure
and signing costs are covered under the approved Cardano Node Maintenance
budget.

Platform & Localisation — All platforms maintained: Windows, macOS
x86_64, macOS aarch64, Linux. Full Japanese translation across all
new features.

Hardware Wallet Support — Add support for Keystone and Flex, and other
newer hardware wallet models as they emerge, expanding the population of
security-conscious ADA holders who can use Daedalus with hardware wallet
protection.

CIP-30 dApp Connector — Implement CIP-30 within Daedalus, enabling
compatible dApps to connect to a user's full-node wallet without
switching to a browser wallet.

User-Facing CIP Implementations — Track and implement user-facing
CIPs finalized during the contract period (token standards, metadata,
transaction capabilities).

User Support — Responsive support for the Daedalus user base across
GitHub, community forums, and direct channels. The Japanese community
receives first-class support alongside English speakers; Daedalus will
remain fully translated into Japanese throughout the contract period
and across every feature shipped.

Architecture Assessment — Scoped investigation into a potential
Daedalus architecture rewrite; assessment published regardless of outcome.

Expected Value

Users who run Daedalus because they don't trust Lite wallets are
particularly exposed if Daedalus falls behind on protocol compatibility.
A Lite wallet user can switch backends during a hard fork; a Daedalus
user running an incompatible version cannot sync the chain at all.
Timely protocol support is existential for this user base.

Cardano is in its most protocol-intensive period since CIP-1694, with
the intra-era hard fork, Leios, Peras, and Nested Transactions all on
the horizon. Each requires Daedalus to ship an updated node version.

Full-node users are currently locked out of the dApp ecosystem — any
dApp interaction requires switching to a browser wallet, undermining
the self-sovereignty model. CIP-30 closes this gap entirely.

The binary signing arrangement with IOG preserves years of user trust
built through consistently signed releases. Maintaining it through the
funding transition is the responsible approach.

Risk Register

Risk Likelihood Impact Mitigation
ADA/USD exchange rate volatility High High ADA received is converted promptly to USD-backed stablecoins; labor costs are denominated in USD and invoiced at spot rate, capping exposure to price swings during the contract period
cardano-node upstream API changes Medium High T&M engagement absorbs scope changes; team has an established working relationship with upstream IOG engineers providing early visibility into breaking changes
Leios/Peras complexity underestimate Medium Medium T&M removes fixed-price risk; the engagement scales to actual complexity rather than an estimate made before specifications are final
Platform dependency changes (Apple notarization policy, Windows signing infrastructure) Low High IOG binary signing arrangement is maintained throughout; drt toolchain is purpose-built and not dependent on third-party CI services that could change terms
Team continuity over 12-month contract Low High Core team members are founding members of Se7en Labs with multi-year Cardano track records; key processes are documented in the drt toolchain and Nix build infrastructure

Success Metrics

  • Compatible release available at least 2 weeks before each mainnet hard fork; development builds on DijkstraNet throughout testing
  • cardano-node no more than 2 major versions behind mainnet recommended at any time
  • 100% of official releases cryptographically signed
  • All four platform builds passing CI in every stable release
  • Critical security issues addressed in a timely manner
  • Keystone and Flex supported in a stable release within contract period
  • CIP-30 connector implemented and available in a stable release
  • User support maintained throughout the contract period; Japanese users receive responses in Japanese
  • Full Japanese translation current across all features shipped during the contract year
  • Architecture assessment published by Q3 2027

All release-timing and version-currency metrics are independently
verifiable from public GitHub repositories and the Cardano mainnet chain
without reliance on applicant self-reporting.

Milestones

Hard Fork Integration (Duration: 6 weeks)

Deliverables:
- All Daedalus changes for hard fork compatibility completed
- Development builds provided on relevant testnet throughout testing
- Compatible stable release published at least 2 weeks before mainnet
hard fork activation

Acceptance Criteria:
- Compatible stable release available at least 2 weeks before mainnet
activation
- Daedalus fully functional post-hard-fork across all platforms

Ongoing Maintenance (Duration: 52 weeks)

Deliverables:
- Continuous node and wallet backend updates integrated as released
- All releases signed per the IOG binary signing arrangement
- Full Japanese translation coverage across all new features
- CI maintained across all platform targets

Acceptance Criteria:
- Compatible stable release available at least 2 weeks before each
mainnet hard fork
- All releases carry valid signatures
- All platform targets maintained throughout the contract year

Leios/Peras Readiness (Duration: 26 weeks)

Deliverables:
- Daedalus running a Leios/Peras compatible node version ahead of any
testnet or mainnet activation
- Assessment of user-facing UX impacts with adjustments shipped as
needed

Acceptance Criteria:
- Compatible node version shipped and verified on testnet before mainnet
- No disruption to Daedalus users during protocol transition

Hardware Wallet Support (Duration: 12 weeks)

Deliverables:
- Support for Keystone and Flex shipped in a stable release, plus
additional newer hardware wallet models as they emerge during the
contract period

Acceptance Criteria:
- Keystone and Flex functional in QA testing
- No regression in existing hardware wallet support (Ledger Nano, Trezor)

CIP-30 dApp Connector (Duration: 20 weeks)

Deliverables:
- CIP-30 (Cardano dApp-Wallet Web Bridge) implementation within Daedalus
- Verified interoperability with the CIP-30 dApp ecosystem
- User documentation for connecting dApps to Daedalus

Acceptance Criteria:
- CIP-30 connector available in a stable release
- Verified working with CIP-30 compatible dApps
- No external API dependency introduced

User Support (Duration: 52 weeks)

Deliverables:
- Ongoing support for Daedalus users via GitHub issues, community forums,
and direct channels throughout the contract period
- Japanese-language support for Japanese users; full Japanese translation
maintained across all features shipped during the contract year

Acceptance Criteria:
- Support channels actively monitored and responded to throughout the
contract period
- All new features ship with complete Japanese translation

Architecture Assessment (Duration: 8 weeks)

Deliverables:
- Architecture assessment covering current state, options, and resource
estimates with a clear recommendation
- If rewrite initiated: foundational implementation on development branch

Acceptance Criteria:
- Assessment published publicly with clear recommendation and rationale

Net Change Limit Compliance

The requested amount does not at time of submission, on its own or in
aggregate, breach the applicable 350M Net Change Limit
covering Epoch 613 to Epoch 713. In accordance with the guardrail
TREASURY-02a, this withdrawal does not exceed the NCL at the moment of
submission.

Audit & Oversight

Audit and oversight costs are included within the overhead applied to
this proposal. The Intersect administration fee covers administrative
oversight and is reflected within the cost of this proposal. Independent
oversight will be provided through Intersect and technically capable
third-party, including reporting obligations and milestone-based
disbursement controls.

Prior Treasury Funding Disclosure

Se7en Labs has not received ada from the Cardano Treasury within the last
24 months. The team has operated under a direct IOG contract for Daedalus
maintenance since January 2026, closing August 31, 2026.

Budget Summary

The minimum team required to keep Daedalus maintained — node upgrades,
hard fork readiness, platform support, release engineering — is not
significantly smaller or cheaper than the team needed to also ship
lightweight feature work. The development items in this proposal (hardware
wallet support, CIP-30 connector, architecture assessment) are
comparatively low-cost additions on top of a team that must exist anyway.
The bulk of this proposal is maintenance; the features come largely for
free.

  • Team | Resources (Labor) | 1,666,667 ADA: Team effort covering all protocol maintenance and ecosystem improvements: node/wallet integration, hard fork support, hardware wallet support, CIP-30 dApp connector implementation, architecture assessment, build infrastructure, platform maintenance, and release engineering. CI infrastructure and binary signing costs are covered under the approved Cardano Node Maintenance budget. Any unspent labor budget at contract close is returned to the treasury.
  • Test Hardware | Equipment | 33,333 ADA: As a small team taking on a multi-platform product, we need to acquire and maintain test devices — primarily macOS laptops covering both x86_64 and aarch64, and hardware wallets representing the range of devices Daedalus supports — to ensure every release is verified on real hardware before shipping. Any unspent hardware budget is returned to the treasury.
  • Financial Audit | Audit | 33,333 ADA: Independent financial audit of funds received and expended under this proposal. Any unspent audit budget is returned to the treasury.
Work Package Total (ADA)
Maintenance and Improvements 1,666,667
Test Hardware 33,333
Financial Audit 33,333
Intersect Budget Administration fee 52,000
Total 1,785,333

Administration and Oversight

Intersect serves as the administrator and independent milestone verifier
for this proposal, in accordance with Article II.7.5 of the Cardano
Constitution. Intersect is responsible for monitoring how funds are used,
independently confirming that acceptance criteria are met, and authorizing
disbursements. As a time and materials engagement, funds are disbursed
monthly against verified work. Funds received from the treasury withdrawal
will be held by Intersect in a dedicated account auditable by the Cardano
Community, delegated to the predefined abstain voting option, prior to
monthly disbursement to Se7en Labs.

Intersect Budget Management Tooling

To administrate treasury funds on-chain, Intersect will utilize the
treasury management smart contract framework developed by Sundae Labs.
A new instance of these smart contracts has been deployed for 2026,
mirroring the contracts from the 2025 budget cycle.

  • The 2026 Treasury Reserve Smart Contract stake address: stake1784sdxt6jjennmstphgdu7l7c2scf5d02a6cve2dgn5s2kq5u3j9v
  • The 2026 Treasury Reserve Smart Contract payment address: addr1x84sdxt6jjennmstphgdu7l7c2scf5d02a6cve2dgn5s2k8tq6vh499n88hqkrwsmealas4psng674m4sej5638fq4vqmxs59w
  • The 2026 Project Specific Smart Contract payment address: addr1x9d6k9z6t6fvsetj2djmerargk475lef9gfvshy4rwh4h7jm4v295h5jepjhy5m9hj86x3dtafljj2sjepwf2xa0t0aq048cay

Specifics

Intersect will utilize a single Treasury Reserve Smart Contract (TRSC),
with one Project-Specific Smart Contract (PSSC). Intersect's management
consists of five 'admin' and three Intersect 'leadership' roles. An
Oversight Committee consisting of six external, independent third-party
entities will provide checks and balances on Intersect, and safeguard
against errors and unilateral control. The administration of both TRSC
and PSSC will be managed by Intersect, with external oversight on certain
actions from the Oversight Committee.

The Oversight Committee consists of Sundae Labs, Cardano Foundation,
Dquadrant, NMKR, Sundial and Eternl. Their role is to independently
verify key administrative actions using on-chain logic, ensuring accuracy
and consistency without exercising discretion over governance decisions.

For all details on Intersect's configuration please see the
Smart Contract Guide
on the knowledgebase.

The high level permissions are as follows:

  • TRSC Fund and PSSC Modify
    • Two of the five Intersect admins, two of the six trusted entities and one of the three Intersect leadership sign-off must authorize
  • TRSC Disburse
    • Two of five Intersect admins, three of six trusted entities and two of three Intersect leadership sign-off must authorize
  • TRSC Pause and Resume
    • Two of five Intersect admins, and one of three Intersect leadership sign-off must authorize
  • TRSC Sweep
    • One of five Intersect admins, and one of three Intersect leadership sign-off must authorize
  • TRSC Reorganize
    • Two of five Intersect admins and three of six trusted entities must authorize

Processes

Upon enactment of this governance action, funding for this project will
be directed into the TRSC's stake address. All instances of TRSC and PSSC
can not be staked with a SPO and are delegated to the auto-abstain
predefined DRep. From here funds will be withdrawn into a UTxO remaining
at the TRSC payment address.

When the Legal contract is prepared and the vendor is ready, funding for
this project will be transferred using the Fund action to the PSSC. All
milestones will be outlined within the metadata.

A dashboard is available
(treasury.sundae.fi)
for the community to audit the TRSC or PSSC and track metrics related to
this withdrawn ada as well as being immutably verifiable on chain.

References

Votes

Your vote

DRep

Rationale
No rationale added yet.
Your current vote
Pending on chain
Submitted at
Rationale
Rationale
No rationale added
Proposal Information
  • Type
    Treasury Withdrawal
  • Status
    Voting
  • Submitted On
    Jun 24, 2026
  • Expires On
    Jul 28, 2026
  • Voting Parties
    DRepCC
Voting
DRep

View voting area