Security posture
What we hide, we cannot defend.
So we hide nothing.
The full security model of Asylia - updated as the surface evolves. Last reviewed by the maintainers on May 1, 2026.
01 · Threat model
What Asylia protects against.
And, just as importantly, what it does not.
Asylia is built around three realistic failure modes: one signer becomes unavailable or compromised, the operator machine or browser is untrusted, and the Asylia service tier or database is compromised. Multisig removes the single-signer failure point; hardware-wallet review keeps spend approval on devices; the service tier stores watch-only coordination state, not private keys.
Out of scope: physical coercion against enough signers to satisfy your threshold, a break in Bitcoin consensus, supply-chain compromise, and vulnerabilities in hardware firmware or vendor key-isolation design. We rely on the Trezor and Ledger security models, and we keep our adapters visible in hw-trezor and hw-ledger so that boundary can be reviewed.
02 · Policy
Why only P2WSH multisig.
One script, narrow surface, zero policy ambiguity.
Vaults created in Asylia are native-SegWit P2WSH multisig only. Every vault is represented as a BIP-380 descriptor for wsh(sortedmulti(N, key1, ..., keyN)) - the policy family already understood by Sparrow, Caravan, Bitcoin Core, Trezor, and Ledger.
The only policy we ship
wsh(sortedmulti(N, xpubKey1, …, xpubKeyN))
Narrowing to one script keeps the moving parts explicit: SegWit v0 signing rules, BIP-48 account roots, BIP-67 key sorting, BIP-173 bech32 addresses, PSBT v2, and output descriptors. Imports outside mainnet P2WSH sortedmulti are rejected at the boundary.
"Every script you support is a surface you have to defend."
— The Asylia policy charter
03 · Quantum risk
Multisig is not quantum resistance.
It raises the threshold; it does not change Bitcoin cryptography.
Asylia uses Bitcoin's current cryptography: secp256k1 keys and signatures inside P2WSH multisig. That is not post-quantum cryptography. A future cryptographically relevant quantum computer capable of deriving private keys from public keys would be a Bitcoin-wide risk, not something Asylia can neutralize in the product layer.
The security improvement is threshold separation. A single-key wallet fails when one key is exposed. A 2-of-3 vault requires enough independent signer keys to satisfy the policy before funds can move, so an attacker must compromise more than one root, device, or signing path. P2WSH also keeps the redeem script off-chain until spend, but descriptors and xpubs are public wallet material and should never be treated as quantum-safe secrets.
Our stance is deliberately plain: do not call Asylia quantum-proof. Treat multisig as materially safer than single-key custody under today's threat model, keep wallet policy material controlled, and be ready to migrate when Bitcoin has a credible post-quantum path.
"Threshold makes compromise harder. It does not make Bitcoin post-quantum."
— The Asylia security model
04 · Hardware
Keys never leave the device.
PSBTs travel, signatures travel, private material does not.
Asylia builds a PSBT v2 in the browser, routes signing through the hardware adapter, and merges returned signatures back into the proposal. Ledger signs against a registered wallet policy; Trezor receives the equivalent transaction description through Trezor Connect. In both paths, the browser never sees a private key, the server never stores one, and the seed phrase stays on the device.
Current support: Trezor Safe 3, Model T, and Safe 5 for public-root export and signing; Ledger Nano X and Nano S Plus for public-root export, wallet-policy registration, and signing. No other wallets are currently wired. BitBox02, Coldcard, and Jade remain roadmap candidates, gated on the same signing-model review.
05 · Custody
Non-custodial by design.
Asylia is a view onto your multisig policy, not a container for your coins.
Supabase auth gives you a portable account for watch-only coordination across browsers and machines. The account can store public descriptors, signer metadata, proposal PSBTs and summaries, cached balance/sync state, billing enrolments, sessions, and UI preferences - never seed phrases or private keys. Deleting the account removes Asylia's coordination state; your on-chain funds remain controlled by the multisig policy.
The same policy is visible in every export. Point Sparrow, Caravan, or Bitcoin Core at the same descriptor material and you can recover the same vault from outside Asylia. Replaceability is part of the design, not an escape hatch.
06 · Transparency
Open source core.
Five MIT-licensed packages carry every Bitcoin-touching operation.
The wallet application is proprietary, but the Bitcoin surface is not. The packages that handle descriptors, address derivation, PSBT assembly/finalization, signature checks, chain-data reads, broadcast, hardware transports, and shared domain contracts ship under MIT: btc-core, blockchain-data-btc, hw-trezor, hw-ledger, and shared-types.
07 · Licensing
MIT where it matters.
A clear boundary between the open primitives and the commercial product.
The MIT boundary is drawn on purpose: the primitives your money depends on can be reviewed and forked under MIT. The marketing site, wallet app chrome, and product UI are proprietary so we can operate the service sustainably. If Asylia disappears, exported descriptors and the open-source packages preserve a recovery path through other wsh(sortedmulti) tools.
08 · Audits
Audit status.
Where we are today, what we are working towards, and what you can already verify yourself.
No external security audit has been completed yet. The intended first scope is the Bitcoin-critical layer: btc-core, blockchain-data-btc, and the Trezor/Ledger hardware adapters. When an audit is commissioned and completed, this section will link to the report and the fixes that follow.
In the meantime, the MIT packages, tests, and locked policy are available for review. Limiting Asylia to mainnet wsh(sortedmulti) keeps descriptor parsing, script construction, PSBT assembly, signature verification, and broadcast behavior small enough to inspect directly.
09 · Disclosure
Responsible disclosure.
If you find a problem, tell us before the world.
Email security@asylia.io with a description of the issue, reproduction steps, affected surface, and suggested severity. We aim to acknowledge reports within 48 hours and coordinate a fix or transparent mitigation as quickly as the risk allows. Critical reports get a dedicated coordination channel; we credit reporters unless they ask us not to.
A public bug bounty program is planned for a later stage of security maturity.
Still reading?
Then you are evaluating the right boundary. Open Asylia, create a vault, export the policy, and verify that the recovery path remains yours.