What shipped. When it shipped.
Why it matters.

Asylia now has a documented release flow: feature branches move through release/test, the wallet test deployment validates the shared candidate, and production merges into main require a release security audit record.

The audit registry is published on /security/audits and exported to the public Bitcoin toolkit repository through the existing OSS sync path.

This release hardens the layer around money movement. Hardware signing is only one part of a self-custody wallet; the surrounding coordination has to keep inputs, change addresses, mempool data, and broadcast state consistent while the operator moves between tabs, devices, and network providers.

Money-moving safety

• Active proposal inputs are locked so two pending PSBTs cannot silently reserve the same outpoint.
• Change indexes are reserved while a proposal is active, reducing the chance of two proposals pointing change at the same fresh slot.
• Broadcast finalization happens locally from the signed PSBT, then the outcome is persisted through the authenticated btc-broadcast edge function.

Live wallet data

• Vault sync now tracks receive/change address state, balances, pending sats, transaction counts, and the last scanned indexes.
• A short sync lease prevents two browser tabs from spending provider budget on the same vault refresh.
• Network fee and fiat-rate snapshots are cached in Supabase, refreshed by scheduled functions, and delivered to the wallet through Realtime updates.

Provider resilience

The chain-data SDK can rotate through public providers and escalate to the edge fallback when needed. That keeps normal reads fast in the browser while giving the product a controlled path for rate limits, broadcast persistence, and operator-visible failure states.

Ledger is now a full hardware signer inside Asylia for the models we support today. The wallet can export the public root, register the exact multisig policy in the Ledger Bitcoin app, verify vault addresses against that policy, and collect partial signatures for PSBT v2 spend proposals.

Signing model

• Ledger signing runs through WebHID and the @asylia/hw-ledger boundary.
• The wallet policy is registered once, then matched through the stored policy HMAC before signing.
• Returned partial signatures are verified against the expected cosigner before they are merged back into the PSBT.

Product impact

Trezor and Ledger can now share the same quorum without leaving the product. Operators can build a vault with mixed hardware families, review the proposal in Asylia, approve on-device, and broadcast only after the required threshold is actually present in the PSBT.

Trezor signing is now part of the same proposal flow that operators use to build and review a spend. Asylia prepares the PSBT v2, routes the signing request through Trezor Connect, verifies the returned signature against the expected cosigner, and keeps signer progress derived from the PSBT itself.

What changed

• Trezor rows in the signer list call the real hardware adapter, not a file export/import handoff.
• The same component works while creating a new proposal and while signing an existing pending proposal.
• Receive-address verification uses the device display so the vault address can be checked outside the browser.

Scope

The supported script remains native-SegWit P2WSH multisig only: wsh(sortedmulti(...)) at m/48'/0'/0'/2'. Private keys and seed words stay on the device; Asylia handles descriptors, PSBT assembly, proposal persistence, and broadcast after the threshold is reached.

Ledger support started with the safe prerequisites for signing: environment detection, public-root export, and wallet-policy registration. This gave Asylia enough device-approved metadata to place a Ledger key in a P2WSH multisig vault without claiming the signing path was complete.

What changed

• The Ledger connect wizard checks browser/WebHID support before asking for a device permission prompt.
• The exported root is locked to the Asylia BIP-48 branch: m/48'/0'/0'/2'.
• The wallet can preview and register the deterministic Ledger wallet policy, then persist the returned policy HMAC for later signing.

Why it mattered

Ledger's Bitcoin app signs multisig PSBTs against a registered policy. Shipping registration first made the later signing release smaller and easier to review: the key identity, derivation path, policy ID, and device prompts were already observable in the wallet.

Interoperability is part of the custody model. A vault should remain usable even if the operator wants to inspect it in another tool or recover from outside the Asylia interface. The export layer now generates each format from the same canonical descriptor material instead of maintaining separate templates by hand.

Formats

• Asylia JSON - a self-contained backup with vault metadata, signers, and provider-specific payloads.
• Caravan JSON - P2WSH quorum data for Caravan-compatible multisig review.
• Sparrow JSON - MULTI / P2WSH wallet configuration with keystore origins and public roots.
• Bitcoin Core descriptor sheet - receive and change descriptors with checksums for descriptor-based Core workflows.

The exports do not contain seed words or private keys. They carry only public descriptor data and signer metadata, which is exactly the recovery material a watch-only multisig tool needs.

The public beta sets the product contract that the rest of the wallet now builds on: Asylia is Bitcoin-only, mainnet-only, hardware-first, and intentionally narrow around native-SegWit P2WSH multisig.

Product surface

• Supabase account access for a portable watch-only workspace.
• Hardware key registration before a vault can be assembled.
• Vault creation around wsh(sortedmulti(...)) descriptors and BIP-48 roots.
• Receive/change address derivation, sync state, UTXO discovery, and transaction history.
• PSBT proposal creation with explicit recipient, change, miner fee, and optional Asylia platform-fee output before signing.

What we are not shipping

No altcoins, no single-sig wallets, no nested-SegWit multisig, no seed storage in the browser, and no private keys on Asylia servers. The first public version is not trying to be a generic wallet. It is a focused multisig workspace for long-term Bitcoin custody.

The security page now states the current posture plainly: no completed external security audit yet, a narrow Bitcoin-critical surface prepared for review, and a responsible-disclosure channel for researchers.

Review boundary

• @asylia/btc-core - descriptors, address derivation, PSBT build/finalize, signature checks, and coin selection.
• @asylia/blockchain-data-btc - normalized chain data, fee/rate reads, provider failover, and broadcast support.
• @asylia/hw-trezor - Trezor public-root export, address display, event stream, and PSBT signing adapter.
• @asylia/hw-ledger - Ledger WebHID, wallet-policy registration, address display, and PSBT signing adapter.
• @asylia/shared-types - shared domain contracts.

Current stance

The wallet app and product UI remain proprietary, but the Bitcoin-touching layer is MIT-licensed and reviewable. When a third-party audit is commissioned and completed, the report and follow-up fixes will be linked from the security page and the changelog.