Skip to main content
For the complete documentation index, see llms.txt

Wallet reference

Reference material for the community wallets covered in the overview: the full functionality matrix, troubleshooting, a security checklist, broader ecosystem compatibility, and a glossary.

Functionality matrix

The granular tie-breakers, once the matrix and a wallet's footprint have narrowed your choice. Legend: Yes / No / Partial (caveats below) / Not documented (not publicly documented as of June 2026) / n/a.

Platforms and availability

WalletBrowser extensionMobile appMidnight-nativeOpen source
LaceYes (Chrome/Edge)No (Midnight)NoYes
1AMYes (Chrome, Firefox)Yes (beta)YesNo
KuiraNoYes (Android, alpha)YesPartial (source jars; repo private)
urbleNoYesYesNot documented
DynamicNo (SDK)Via SDKNoNo
CtrlYes (Chrome)YesNoNo
GeroYesYesNoNo

Privacy and assets

WalletNIGHTDUSTShielded txnsUnshielded txnsShielded by defaultSelective disclosure
LaceYesYesYesYesNoNot documented
1AMYesYesYesYesYesYes
KuiraYesYesYesYesNot documentedNot documented
urbleNot documentedNot documentedYesNot documentedYesYes
DynamicNoNoNoNoNoNo
CtrlYesNot documentedNot documentedNot documentedNoNot documented
GeroYesNot documentedNot documentedNot documentedNot documentedNot documented

Proving and fees

WalletIn-browser provingLocal prover neededgetProvingProviderGas sponsorship
LaceNoYesNoNo
1AMYes (WASM; Halo2/BLS12-381)NoYesNot documented
KuiraYes (on-device, mobile)Non/aNot documented
urbleNot documentedNot documentedNot documentedNot documented
DynamicNon/aNot documentedYes (non-Midnight)
CtrlNot documentedNot documentedNot documentedNot documented
GeroNot documentedNot documentedNot documentedNot documented

Developer integration

WalletDApp ConnectorsignDataDedicated SDKDApp browserHardware walletCardano / multi-chainStaking
LaceYes (mnLace)NoNon/aYes (Cardano)YesYes (Cardano)
1AMYes ('1am')Not documentedAnnounced / Not documentedYesNot documentedNoNot documented
KuiraNot documentedNot documentedYes (Android, public docs)n/aNot documentedNoNot documented
urbleNoNot documentedNoNoNot documentedNoNo
DynamicNoNot documentedYes (non-Midnight)n/aNoNo (other chains)No
CtrlPartialNot documentedNoYesYes (Ledger/Trezor)YesYes
GeroNot documentedNot documentedNoNot documentedNot documentedYesNot documented

Key notes:

  • Partial (Ctrl): a connector stated by the vendor, so feature-detect at runtime.
  • Not documented (Gero): vendor-stated, pending public documentation; Gero is a valid Cardano-side NIGHT claim wallet.
  • Dynamic cells reflect its lack of documented Midnight support.
  • 1AM gas sponsorship is not documented (see the note in 1AM).
  • 1AM "Dedicated SDK" is announced, not documented; the advertised "Proof Station SDK" has no published package or docs (see 1AM), so integrate 1AM via the standard connector.
  • Kuira "in-browser proving" means on-device mobile proving (Android), not browser WASM.
  • Kuira "Dedicated SDK: Yes" is the one mobile SDK with public docs (see Kuira).

Developer experience

Beyond who holds the keys and how the wallet is reached, the daily question while building is which wallet gives the best development loop: can it talk to a local network (undeployed, disposable Midnight-in-Docker, no faucets), point at custom servers, create reproducible test wallets from a known seed, and run headless in CI with no human clicking approve?

WalletLocal network (undeployed)Custom serversReproducible test walletsHeadless / CI
wallet-CLIYes (localnet up)Yes (config set)Yes (seed-based wallet generate)Yes (serve --approve-all)
LacePartial (local proof server)Partial (proof-server URL)No (UI-generated seed)No (manual pop-up approval)
1AMNot documentedNot documentedNoNo (manual approval)
KuiraNot documentedNot documentedPartial (wallet-seed module)No (mobile, biometric approval)

Takeaway. For the inner dev loop (local network, reproducible fixtures, no human in the way) the wallet CLI covers every column (see Develop and test without a wallet). The browser and mobile wallets are end-user surfaces: build and test against the CLI, then let users connect with Lace/1AM (or ship Kuira embedded).

Troubleshooting and error reference

Symptom → cause → fix. First the ledger / connector errors; then the CLI JSON error contract (--json returns {error, code, message, exitCode}).

Symptom / errorLikely causeFix
BalanceCheckOverspend (138)Not enough DUST for feesWait for DUST (about 12 h fresh Lace; about 5 min local) or designate more NIGHT; read getDustBalance() first
Authorize pop-up never appears / connect hangsconnect() not called synchronously on clickCall connect() directly in the click handler; don't await/setTimeout before it
window.midnight is undefinedExtension not installed/enabled, or injected after loadPrompt to install, then refresh; for auto-reconnect, poll before connecting
getProvingProvider is not a function (Lace)Lace doesn't implement itFeature-detect; use a local proof server (lace#2224)
signData "Method not implemented" (Lace)Unimplemented on LaceAvoid signature-based auth on Lace (lace#2165)
Proof generation fails / prover unreachableLocal proof server down, or Brave Shields blocking itStart it (localhost:6300); disable Brave Shields for the origin
Network mismatchDApp and wallet on different networksReconcile to getConnectionStatus().networkId via setNetworkId(...)
1AM first proof very slowA few MB WASM cold-startPre-warm / show a "loading prover" state
Deploy fails before it startsWallet not fully syncedWait for wallet sync to complete before deploying
CLI DUST_REQUIRED (exit 5)No DUSTmidnight dust register, retry once DUST generates
CLI INSUFFICIENT_BALANCE (exit 5)Not enough NIGHTFund the wallet (faucet on testnets; airdrop only on undeployed)
CLI NETWORK_ERROR (exit 4)Connection refused / timeout / DNSCheck node/indexer endpoints
CLI PROOF_TIMEOUT (exit 6)ZK proof timed outEnsure the proof server is healthy; retry; reduce circuit complexity
CLI STALE_UTXO (exit 6)UTXOs consumed by another txmidnight cache clear and rebuild
CLI TX_REJECTED (exit 6)Node rejected the tx (TTL / validity)Inspect the message; rebuild with current state

CLI codes are a documented contract (see the CLI's JSON-output reference); for canonical Midnight error/status codes, use the midnight-status-codes reference.

Security checklist

The connector hands your page data from an untrusted extension, so treat it accordingly:

  • Sanitize the wallet name; render the icon via <img src>, never innerHTML (XSS).
  • Validate networkId: reconcile to getConnectionStatus().networkId and refuse mismatches.
  • Don't trust injected data as authority: rdns/name are for display and selection, not security decisions; match the expected rdns and tell users to install only from official stores.
  • Keep witness data local: prefer in-browser proving (1AM) or a local proof server (Lace); if you ever use a hosted prover, say so.
  • Confirm fee sponsorship: not all wallets sponsor fees; verify on your target network before promising a "no DUST needed" experience.
  • Guard agent (MCP) access hard: scope tools, cap spend per action and per day, allowlist destinations, and require human confirmation for anything irreversible. An agent with unbounded signing authority is the highest-risk cell on the grid.

Broader ecosystem compatibility

Beyond the wallets profiled in the overview, a wider set of Cardano wallets announced Midnight / NIGHT compatibility around the TGE (token generation event) and Glacier Drop, mostly for claiming and holding NIGHT (more entries in the Self-custody × Browser/Mobile cells), not deep DApp integration:

  • Announced self-custody (pre-mainnet): Lace, SubWallet, NuFi, Vespr, Gero, Tokeo, Keystone, Yoroi, Begin Wallet; forward-looking, so treat as announced. (Midnight blog)
  • Glacier Drop claim wallets (Cardano side): Yoroi, Typhon, Gero, VESPR, Eternl (desktop), NuFi. (compatibility)
  • Embedded / Wallet-as-a-Service: Dynamic (social/passkey login, TSS-MPC keys, gas sponsorship) lists EVM, Solana, Bitcoin, and Sui but does not list Midnight or Cardano, appearing as dynamic_xyz in the catalog with no first-party Midnight support as of June 2026. Treat Midnight support as unconfirmed; for passkey onboarding on Midnight use Wallet-IaaS / Smart Custody. (dynamic.xyz, TSS-MPC)
  • Institutional / MPC: Fireblocks for institutional custody of NIGHT (the MPC × console/API cell). (Midnight × Fireblocks)

Authoritative current list: the ecosystem catalog (the institutional-custody tag for the custody/MPC slice).

Glossary

Wallet-relevant terms.

  • Custody model: who controls the keys; the matrix rows (self-custody, custodial, AA, MPC). Maps to Full Sovereignty → Delegated → Smart Custody.
  • Self-custody / Custodial: keys on the user's device (no third party can sign) versus a provider that holds and signs.
  • Account Abstraction (AA): the account is on-chain code with programmable auth. Not native to Midnight as of June 2026.
  • MPC / threshold (TSS): the key is split into shares; an m-of-n quorum signs without reconstructing a full key. Basis of institutional custody (Fireblocks for NIGHT).
  • Interface: how the wallet is reached; the matrix columns (browser, mobile, CLI, MCP).
  • MCP (Model Context Protocol): a standard by which AI agents call tools, either wallet tools (move funds) or developer tools (help you build).
  • Coverage footprint: the set of cells a wallet occupies; reading it shows who can use it and how far it reaches.
  • Midnight Passport: announced first-party seedless, QR-onboarded consumer wallet (browser plus mobile) from IOG; per-device hardware-resident keys with trusted-helper recovery. Exact scheme (MPC versus secure-enclave) not yet publicly detailed (see Midnight Passport).
  • Sigil: Kuira's identity primitive: a passkey-derived DID minted by one biometric (no seed phrase, seedless onboarding). Exposed in the SDK as a swappable SigilIdentityProvider, with Midnight Passport named as a planned future backend.
  • On-device proving: generating a transaction's ZK proof on the user's phone (Kuira, Android) in seconds, with no local proof server to run and nothing leaving the device; the mobile counterpart to 1AM's in-browser WASM proving.
  • NIGHT / DUST: native value token (public; generates DUST) versus a shielded, non-transferable, decaying fee resource with a balance and a cap.
  • Shielded vs unshielded: Midnight's dual ledger, private versus public state. 1AM/urble default to shielded; Lace is opt-in.
  • Selective disclosure / viewing key: reveal specific facts without exposing full data; a read-only key for auditors.
  • DApp Connector / CAIP-372: the standard by which a wallet injects an API under window.midnight.
  • rdns: reverse-DNS wallet id used for discovery (mnLace, '1am').
  • Intent: an (often unbalanced) set of inputs/outputs; the building block for transfers and swaps.
  • Sealed vs unsealed tx: ready-to-submit (proofs plus binding) versus pre-binding.
  • Relayer: submits a tx and pays its fees on the user's behalf (the basis of "gas sponsorship").
  • Proving provider: the abstraction (getProvingProvider) for delegating ZK proving to the wallet.
  • Bech32m: the address encoding the connector returns.
  • Local proof server: the native binary (localhost:6300) that generates ZK proofs for wallets that don't prove in-browser.
  • Wallet-IaaS / Smart Custody: Midnight infrastructure for delegated or embedded wallet provisioning (also called Wallet-as-a-Service, WaaS); the route for social/passkey onboarding.
  • DID (decentralized identifier): a self-owned identifier (for example did:key:…) not issued by a central authority; in Kuira a DID is derived from a passkey to form the Sigil.

Sources

DApp Connector / standard

Custody models / institutional

Midnight Passport: announced by IOG; follow Midnight's official channels for updates.

Developer / AI and agent tooling (MCP)

Lace

1AM

Kuira

urble · Dynamic · Ctrl · Gero

Broader compatibility / dev workflow

Reference implementation: the connect and discovery patterns in the integration guide are implemented in the Edda Labs midnight-starter-template (wallet-widget module), wiring Lace + 1AM through @midnight-ntwrk/dapp-connector-api v4.0.1.