Wallet-centric access: what this release changes

This release is not a cosmetic step. It changes how Asylia decides who can see and operate a wallet.

Until now, the easiest mental model was still close to a normal web app: authenticate a user, show that user's wallets, and keep the self-custody rules inside the signing flow. That is a useful bridge while a product is young, but it is not the model Asylia should grow around.

Asylia is a multisig wallet. Access should be anchored in the wallet itself. The account session is still necessary, but it should not be mistaken for the custody identity.

That is the point of wallet-centric access.

Product access now follows the wallet

A Supabase Auth session is now treated as the browser session: the technical envelope that lets the app talk to the backend. Product access is resolved separately through an Asylia access session.

There are two ways to unlock wallet access:

• A hardware signer can prove control of a signer identity that belongs to one or more vaults.
• An email can unlock vaults where that normalized email is explicitly listed in the vault access settings.

That distinction matters. A signer access session unlocks the wallets where that signer participates. An email access session unlocks the wallets where the email was granted access. In the first version, both methods can operate the wallet workspace: view vaults, manage settings, prepare proposals, and submit validated PSBT updates.

Neither method can move Bitcoin by itself. Spending still needs the vault's multisig threshold, a valid PSBT, and physical hardware-wallet signatures. Access opens the workspace. The vault policy moves the funds.

Hardware-first sign-in

The sign-in screen now starts with hardware signer login. Trezor and Ledger can sign a one-time Asylia challenge, the Edge verification function checks the current browser session, consumes the challenge, verifies the signature, and creates a signer access session when the signer is eligible.

Email OTP remains available, but its role is clearer. It is not a universal "owner" key for every wallet ever touched by an account. It unlocks wallets that deliberately list that email. That makes email useful for recovery, operations, and shared access without pretending that an inbox is equivalent to a hardware signer.

The wallet UI follows the active access method. Email sessions keep the broader key registry at /app/keys. Signer sessions get a focused /app/key surface for the current hardware signer, including the wallets visible through that signer and blockers before destructive removal.

Shared vault access is explicit

Vault settings now include email access records. Adding an email means that address can unlock that vault through OTP. Revoking it removes that access without rewriting the Bitcoin policy.

This gives Asylia a practical operator model:

• a founder can keep signer access on a hardware device,
• a finance operator can be granted email access to coordinate proposals,
• a lost or retired email can be revoked at the vault level,
• and every spend still has to pass through the same multisig signing rules.

The release also introduces access-scoped profiles. Preferences such as currency, language, and timezone now belong to the active product identity: either the email user profile or the signer identity profile. That keeps the workspace coherent when a person arrives through different access paths.

Vault creation is less fragile

Vault identity writes are now routed through constrained RPCs instead of a browser stitching several database writes together. Creating a vault, attaching signers, finalizing descriptors, and recording audit context commit as one invariant.

This is one of the quiet changes that matters most. A multisig wallet should not half-create its identity. If a vault exists, its signer set, descriptor state, setup status, and access records need to agree.

The dashboard now understands setup-required vaults as a real state, not an awkward transient. That lets the product guide incomplete vaults back into the right setup flow instead of treating every wallet card as already operational.

Spend proposals are stricter

This branch also hardens the money-moving path around PSBT proposals.

The send flow has been split into focused configure, sign, and review steps. The refactor is not only for readability. It gives amount handling, fee math, custom fee interaction, PSBT review, signer status, and hardware-signing state their own testable boundaries.

Under that UI, proposal creation now stores the PSBT draft, recipient summary, fee and change metadata, selected input locks, and optional change reservation in one transaction. Active input locks are re-read before coin selection so two tabs do not silently build competing proposals against the same outpoint.

Signed PSBT updates go through the proposal-psbt Edge Function. The function loads the proposal through the caller's RLS-scoped session, checks the submitted PSBT against the stored proposal, runs the hardened @asylia/btc-core policy, derives whether the threshold is actually met, and advances state through service-role-only RPCs.

That policy checks the parts operators care about most:

• expected inputs,
• recipient and amount,
• exact change semantics,
• fee ceilings,
• signer fingerprints,
• threshold satisfaction,
• and final transaction output matching before broadcast.

No-change spends are now first-class. If a spend drains the selected output exactly, the proposal records no change address and the policy requires the PSBT to contain no wallet change output. If change exists, the metadata has to be complete.

Proposal state is auditable

The release adds a stricter transaction-state layer over the existing proposal status. Proposals can move through an explicit lifecycle: created, policy checked, signed, finalized, mempool accepted, broadcasted, confirmed, and reconciled.

Those transitions are recorded as append-only state events. Cancelling a draft or pending proposal is a terminal lifecycle decision, not a physical row delete. Broadcast recording stores the result instead of leaving the wallet to infer it from local UI state.

For a self-custody product, that audit trail is not bureaucracy. It is the difference between "the screen changed" and "we can explain what happened."

Live wallet data is more resilient

Wallet sync now uses a shared address-state cache instead of treating balance, transactions, receive addresses, and send preparation as separate discovery walks. The app tracks receive and change address state, balances, pending sats, transaction counts, scanned indexes, and short sync leases so multiple tabs do not waste provider budget on the same vault refresh.

Network fee and fiat-rate data are cached through Supabase and delivered to the wallet through Realtime. The Bitcoin chain-data package has better provider normalization, fallback handling, cooldowns, and rate limiting. Paid Blockstream routing is held behind Edge Functions so browser bundles never receive upstream credentials.

The result is less drama around the data layer: fewer duplicate scans, clearer failure states, and a controlled path when public providers are slow, rate limited, or inconsistent.

Billing is scoped to wallets

This branch also moves the active billing model closer to the product shape. Billing enrollment is now scoped to a vault, not just a generic user account. Vault settings include the subscription surface, and the send flow can show platform-fee previews as explicit proposal outputs when they apply.

The rule stays visible: below the free threshold there is no Asylia fee output. Above it, the fee is explicit, capped, and reviewable by every cosigner before hardware devices approve the spend.

Hardware flows share one foundation

Trezor and Ledger connection flows now share a common device-connect wizard. The vendor-specific wrappers still own their details, but the state machine for environment checks, connection phases, duplicate handling, retry states, live events, and diagnostics is unified.

That gives us less duplicate UI code in the exact place where duplicate logic usually becomes dangerous. Hardware flows should feel calm for users and boring for reviewers.

Ledger policy handling also received another pass. Policies can be stored per vault signer, signing rows stay disabled until the required policy is present, and returned signatures are checked against the expected cosigner before they enter the proposal.

The release gate got heavier on purpose

The branch adds public audit records, branch database tests, Supabase security checks, production configuration verification, browser gates, and stricter wallet production gates. The test stack is now explicitly mapped: release/test uses the test Supabase project and the wallet-t.asylia.io, test.asylia.io, design-t.asylia.io, and status-t.asylia.io hosts.

That matters because this release changes the authorization model. It is not enough for the interface to look correct on localhost. RLS policies, service role RPC grants, Edge Function boundaries, email templates, allowed origins, Vercel host mappings, and public audit manifests all have to agree before this goes to main.

The latest security audit found no critical, high, or medium severity issues. It did record one low-severity residual risk around the expanded service-role Edge Function boundary. That risk is accepted because the reviewed functions check authentication, session binding, challenge ownership and expiry, vault access, PSBT policy, and service-role-only RPC grants before writing sensitive state.

What this release is really shipping

The visible product improvements are easy to name: hardware-first sign-in, vault email access, clearer key navigation, a more structured send flow, live fee and rate data, wallet-scoped billing, stronger Ledger and Trezor flows, and a quieter workspace.

The deeper release is architectural. Asylia is moving from account-centric app access toward wallet-centric custody operations.

That is the right direction for a Bitcoin multisig wallet. People do not only operate wallets as individual SaaS users. They operate them as signers, cosigners, finance operators, families, founders, and recovery participants. The product should be able to represent that without weakening the rule that Bitcoin only moves when the vault policy is satisfied.

This release gives Asylia that foundation.

Access can now follow the signer or the vault email list. Proposals can move through an auditable lifecycle. PSBTs are checked before state changes. Vault identity writes are constrained. Provider data is calmer. Release gates are stricter.

That is a lot of work for one branch, but it all points at one product idea:

The wallet should be easier to operate without becoming easier to misuse.