[{"data":1,"prerenderedAt":992},["ShallowReactive",2],{"story-wallet-centric-access-release":3},[4,172,460,728],{"id":5,"title":6,"body":7,"category":159,"date":160,"description":13,"extension":161,"featured":162,"locale":163,"meta":164,"navigation":162,"path":165,"readingTime":166,"seo":167,"slug":168,"stem":169,"summary":170,"__hash__":171},"stories\u002Fstories\u002Fthe-launch-wallet.md","The launch wallet: why Asylia starts with less",{"type":8,"value":9,"toc":149},"minimark",[10,14,17,20,25,32,35,38,42,45,61,68,71,75,78,81,84,103,106,110,113,116,119,123,126,129,132,135,138],[11,12,13],"p",{},"A launch wallet should not be judged by how much it tries to contain. It should\nbe judged by how clearly it defines what it will not compromise.",[11,15,16],{},"Asylia begins from that position. It is a Bitcoin multisig wallet built for\npeople who do not want their custody model to depend on one seed phrase, one\ndevice, one company, or one moment of perfect memory. The first public surface is\ndeliberately narrow: create a vault, keep private keys on hardware devices,\ncompose a PSBT, review intent, collect quorum, broadcast only when the policy is\nsatisfied, and leave with a portable backup if the user ever wants to move.",[11,18,19],{},"That may sound modest beside the usual language of wallet launches. It is not.\nFor custody software, restraint is a product feature.",[21,22,24],"h2",{"id":23},"the-smallest-surface-that-can-be-taken-seriously","The smallest surface that can be taken seriously",[11,26,27,28],{},"The industry has trained users to expect wallets that announce themselves with\nmore networks, more swaps, more dashboards, and more motion. Asylia is taking\nthe opposite path. The launch wallet is not trying to become a financial\nsuper-app. It is trying to make one custody decision legible: ",[29,30,31],"strong",{},"Bitcoin should\nnot move unless the required signers agree.",[11,33,34],{},"That decision shapes everything around it. The interface keeps the policy\nvisible. The signing flow treats hardware devices as the boundary for private\nkeys. The transaction path stays explicit enough that a user can understand what\nis being prepared before a signature exists. The export model keeps the vault\nportable instead of trapping it inside one interface.",[11,36,37],{},"This is not minimalism as decoration. It is minimalism as operational discipline.",[21,39,41],{"id":40},"from-wallet-prototype-to-final-public-surface","From wallet prototype to final public surface",[11,43,44],{},"Asylia started as a single Vue wallet application at the root of the project. It\nwas direct, focused, and close to the product problem: how to make serious\nself-custody feel understandable without weakening the custody model.",[11,46,47,48,52,53,56,57,60],{},"The work then moved into a broader architecture. The wallet became\n",[49,50,51],"code",{},"apps\u002Fwallet",". Shared interface foundations moved into ",[49,54,55],{},"@asylia\u002Fui",". Bitcoin\nlogic was separated into reviewable packages for descriptors, PSBT construction,\nchain data, and hardware-wallet integration. The public narrative moved into\n",[49,58,59],{},"apps\u002Fmarketing",". Capacitor shells were added for the future mobile surface.",[11,62,63,64,67],{},"That history matters because it shows the product did not become bigger for its\nown sake. It became more organized. The current ",[49,65,66],{},"asylia.io"," repository is the\nfinal public home for that structure: wallet, marketing site, design system,\nstatus surface, security documentation, and the auditable Bitcoin packages that\nsit beneath the interface.",[11,69,70],{},"A launch wallet should be able to explain where it came from. Asylia can: it\nstarted as a working wallet, then separated the parts that deserve separate\naccountability.",[21,72,74],{"id":73},"the-promise-is-not-convenience-the-promise-is-control","The promise is not convenience. The promise is control.",[11,76,77],{},"Convenience alone is a weak foundation for custody. It can make the first five\nminutes easier while making the next five years more fragile. Asylia is built\naround a different promise: the user should understand the rules before the\nsoftware asks them to trust the result.",[11,79,80],{},"That means no vague security theatre. No decorative confidence. No hidden\ncustody claim that cannot be tied back to code, policy, a device boundary, or a\ndocumented limitation.",[11,82,83],{},"The launch wallet focuses on the moments that matter:",[85,86,87,91,94,97,100],"ul",{},[88,89,90],"li",{},"Can the user see the vault policy before relying on it?",[88,92,93],{},"Can the user keep signing authority on hardware devices?",[88,95,96],{},"Can the user review transaction intent before signatures are collected?",[88,98,99],{},"Can the user export the policy and recover outside Asylia if needed?",[88,101,102],{},"Can an outside reviewer understand the Bitcoin surface without reading a\nmarketing slogan as a security proof?",[11,104,105],{},"Those questions are the product.",[21,107,109],{"id":108},"serious-custody-should-feel-calm","Serious custody should feel calm",[11,111,112],{},"Asylia is designed to feel quiet because the underlying rules are strict. Calm\ndoes not mean hiding risk. Calm means reducing surprise. It means fewer surfaces\ncompeting for attention when the user is making an irreversible decision. It\nmeans copy that names the boundary instead of selling around it. It means a\nwallet that can be attractive without becoming theatrical.",[11,114,115],{},"The launch wallet exists for people who want Bitcoin custody to feel mature:\nfounders protecting operating reserves, families planning redundancy, long-term\nholders replacing a single seed with a quorum, and technical users who care\nabout portable policy more than platform lock-in.",[11,117,118],{},"Those users do not need a louder wallet. They need one that respects the weight\nof the action.",[21,120,122],{"id":121},"launch-is-a-beginning-not-a-performance","Launch is a beginning, not a performance",[11,124,125],{},"Asylia is not launching as a claim that the work is finished. It is launching as\na public standard for how the work will continue: narrow policy, hardware-first\nsigning, explicit transaction intent, portable backups, public security posture,\nand a codebase organized so important boundaries can be reviewed.",[11,127,128],{},"More features can come later. The launch standard has to be right from day one.",[11,130,131],{},"Because the first version of a serious wallet should not ask for applause. It\nshould ask the harder question:",[11,133,134],{},"Can this product be trusted with less noise, more evidence, and a custody model\nthat remains understandable after the launch page is closed?",[11,136,137],{},"That is the bar Asylia is choosing.",[11,139,140,141,148],{},"Read the companion essay on Medium: ",[142,143,147],"a",{"href":144,"rel":145},"https:\u002F\u002Fmedium.com\u002F@asylian21\u002Fwe-didnt-start-with-a-product-a81a5b112e48",[146],"nofollow","We didn't start with a product",".",{"title":150,"searchDepth":151,"depth":151,"links":152},"",3,[153,155,156,157,158],{"id":23,"depth":154,"text":24},2,{"id":40,"depth":154,"text":41},{"id":73,"depth":154,"text":74},{"id":108,"depth":154,"text":109},{"id":121,"depth":154,"text":122},"Launch story","2026-05-04","md",true,"en",{},"\u002Fstories\u002Fthe-launch-wallet",5,{"title":6,"description":13},"the-launch-wallet","stories\u002Fthe-launch-wallet","Asylia is not launching by trying to look finished. It is launching by making the custody surface narrow, reviewable, and serious enough for real Bitcoin self-custody.","iXJ16O2ZTZlRpXbkDH5vSqwO7zydwXXJfQD8QEX1xqE",{"id":173,"title":174,"body":175,"category":450,"date":451,"description":179,"extension":161,"featured":162,"locale":163,"meta":452,"navigation":162,"path":453,"readingTime":454,"seo":455,"slug":456,"stem":457,"summary":458,"__hash__":459},"stories\u002Fstories\u002Fwallet-centric-access-release.md","Wallet-centric access: what this release changes",{"type":8,"value":176,"toc":437},[177,180,183,186,189,193,196,199,207,210,213,217,220,223,234,238,241,244,258,261,265,268,271,274,278,281,284,287,298,301,324,327,331,334,337,340,344,347,350,353,357,360,363,367,370,373,376,380,403,409,412,416,419,422,425,428,431,434],[11,178,179],{},"This release is not a cosmetic step. It changes how Asylia decides who can see\nand operate a wallet.",[11,181,182],{},"Until now, the easiest mental model was still close to a normal web app:\nauthenticate a user, show that user's wallets, and keep the self-custody rules\ninside the signing flow. That is a useful bridge while a product is young, but\nit is not the model Asylia should grow around.",[11,184,185],{},"Asylia is a multisig wallet. Access should be anchored in the wallet itself.\nThe account session is still necessary, but it should not be mistaken for the\ncustody identity.",[11,187,188],{},"That is the point of wallet-centric access.",[21,190,192],{"id":191},"product-access-now-follows-the-wallet","Product access now follows the wallet",[11,194,195],{},"A Supabase Auth session is now treated as the browser session: the technical\nenvelope that lets the app talk to the backend. Product access is resolved\nseparately through an Asylia access session.",[11,197,198],{},"There are two ways to unlock wallet access:",[85,200,201,204],{},[88,202,203],{},"A hardware signer can prove control of a signer identity that belongs to one\nor more vaults.",[88,205,206],{},"An email can unlock vaults where that normalized email is explicitly listed\nin the vault access settings.",[11,208,209],{},"That distinction matters. A signer access session unlocks the wallets where\nthat signer participates. An email access session unlocks the wallets where the\nemail was granted access. In the first version, both methods can operate the\nwallet workspace: view vaults, manage settings, prepare proposals, and submit\nvalidated PSBT updates.",[11,211,212],{},"Neither method can move Bitcoin by itself. Spending still needs the vault's\nmultisig threshold, a valid PSBT, and physical hardware-wallet signatures.\nAccess opens the workspace. The vault policy moves the funds.",[21,214,216],{"id":215},"hardware-first-sign-in","Hardware-first sign-in",[11,218,219],{},"The sign-in screen now starts with hardware signer login. Trezor and Ledger can\nsign a one-time Asylia challenge, the Edge verification function checks the\ncurrent browser session, consumes the challenge, verifies the signature, and\ncreates a signer access session when the signer is eligible.",[11,221,222],{},"Email OTP remains available, but its role is clearer. It is not a universal\n\"owner\" key for every wallet ever touched by an account. It unlocks wallets\nthat deliberately list that email. That makes email useful for recovery,\noperations, and shared access without pretending that an inbox is equivalent to\na hardware signer.",[11,224,225,226,229,230,233],{},"The wallet UI follows the active access method. Email sessions keep the broader\nkey registry at ",[49,227,228],{},"\u002Fapp\u002Fkeys",". Signer sessions get a focused ",[49,231,232],{},"\u002Fapp\u002Fkey"," surface\nfor the current hardware signer, including the wallets visible through that\nsigner and blockers before destructive removal.",[21,235,237],{"id":236},"shared-vault-access-is-explicit","Shared vault access is explicit",[11,239,240],{},"Vault settings now include email access records. Adding an email means that\naddress can unlock that vault through OTP. Revoking it removes that access\nwithout rewriting the Bitcoin policy.",[11,242,243],{},"This gives Asylia a practical operator model:",[85,245,246,249,252,255],{},[88,247,248],{},"a founder can keep signer access on a hardware device,",[88,250,251],{},"a finance operator can be granted email access to coordinate proposals,",[88,253,254],{},"a lost or retired email can be revoked at the vault level,",[88,256,257],{},"and every spend still has to pass through the same multisig signing rules.",[11,259,260],{},"The release also introduces access-scoped profiles. Preferences such as\ncurrency, language, and timezone now belong to the active product identity:\neither the email user profile or the signer identity profile. That keeps the\nworkspace coherent when a person arrives through different access paths.",[21,262,264],{"id":263},"vault-creation-is-less-fragile","Vault creation is less fragile",[11,266,267],{},"Vault identity writes are now routed through constrained RPCs instead of a\nbrowser stitching several database writes together. Creating a vault, attaching\nsigners, finalizing descriptors, and recording audit context commit as one\ninvariant.",[11,269,270],{},"This is one of the quiet changes that matters most. A multisig wallet should\nnot half-create its identity. If a vault exists, its signer set, descriptor\nstate, setup status, and access records need to agree.",[11,272,273],{},"The dashboard now understands setup-required vaults as a real state, not an\nawkward transient. That lets the product guide incomplete vaults back into the\nright setup flow instead of treating every wallet card as already operational.",[21,275,277],{"id":276},"spend-proposals-are-stricter","Spend proposals are stricter",[11,279,280],{},"This branch also hardens the money-moving path around PSBT proposals.",[11,282,283],{},"The send flow has been split into focused configure, sign, and review steps.\nThe refactor is not only for readability. It gives amount handling, fee math,\ncustom fee interaction, PSBT review, signer status, and hardware-signing state\ntheir own testable boundaries.",[11,285,286],{},"Under that UI, proposal creation now stores the PSBT draft, recipient summary,\nfee and change metadata, selected input locks, and optional change reservation\nin one transaction. Active input locks are re-read before coin selection so two\ntabs do not silently build competing proposals against the same outpoint.",[11,288,289,290,293,294,297],{},"Signed PSBT updates go through the ",[49,291,292],{},"proposal-psbt"," Edge Function. The function\nloads the proposal through the caller's RLS-scoped session, checks the submitted\nPSBT against the stored proposal, runs the hardened ",[49,295,296],{},"@asylia\u002Fbtc-core"," policy,\nderives whether the threshold is actually met, and advances state through\nservice-role-only RPCs.",[11,299,300],{},"That policy checks the parts operators care about most:",[85,302,303,306,309,312,315,318,321],{},[88,304,305],{},"expected inputs,",[88,307,308],{},"recipient and amount,",[88,310,311],{},"exact change semantics,",[88,313,314],{},"fee ceilings,",[88,316,317],{},"signer fingerprints,",[88,319,320],{},"threshold satisfaction,",[88,322,323],{},"and final transaction output matching before broadcast.",[11,325,326],{},"No-change spends are now first-class. If a spend drains the selected output\nexactly, the proposal records no change address and the policy requires the\nPSBT to contain no wallet change output. If change exists, the metadata has to\nbe complete.",[21,328,330],{"id":329},"proposal-state-is-auditable","Proposal state is auditable",[11,332,333],{},"The release adds a stricter transaction-state layer over the existing proposal\nstatus. Proposals can move through an explicit lifecycle: created, policy\nchecked, signed, finalized, mempool accepted, broadcasted, confirmed, and\nreconciled.",[11,335,336],{},"Those transitions are recorded as append-only state events. Cancelling a draft\nor pending proposal is a terminal lifecycle decision, not a physical row\ndelete. Broadcast recording stores the result instead of leaving the wallet to\ninfer it from local UI state.",[11,338,339],{},"For a self-custody product, that audit trail is not bureaucracy. It is the\ndifference between \"the screen changed\" and \"we can explain what happened.\"",[21,341,343],{"id":342},"live-wallet-data-is-more-resilient","Live wallet data is more resilient",[11,345,346],{},"Wallet sync now uses a shared address-state cache instead of treating balance,\ntransactions, receive addresses, and send preparation as separate discovery\nwalks. The app tracks receive and change address state, balances, pending sats,\ntransaction counts, scanned indexes, and short sync leases so multiple tabs do\nnot waste provider budget on the same vault refresh.",[11,348,349],{},"Network fee and fiat-rate data are cached through Supabase and delivered to the\nwallet through Realtime. The Bitcoin chain-data package has better provider\nnormalization, fallback handling, cooldowns, and rate limiting. Paid Blockstream\nrouting is held behind Edge Functions so browser bundles never receive upstream\ncredentials.",[11,351,352],{},"The result is less drama around the data layer: fewer duplicate scans, clearer\nfailure states, and a controlled path when public providers are slow, rate\nlimited, or inconsistent.",[21,354,356],{"id":355},"billing-is-scoped-to-wallets","Billing is scoped to wallets",[11,358,359],{},"This branch also moves the active billing model closer to the product shape.\nBilling enrollment is now scoped to a vault, not just a generic user account.\nVault settings include the subscription surface, and the send flow can show\nplatform-fee previews as explicit proposal outputs when they apply.",[11,361,362],{},"The rule stays visible: below the free threshold there is no Asylia fee output.\nAbove it, the fee is explicit, capped, and reviewable by every cosigner before\nhardware devices approve the spend.",[21,364,366],{"id":365},"hardware-flows-share-one-foundation","Hardware flows share one foundation",[11,368,369],{},"Trezor and Ledger connection flows now share a common device-connect wizard.\nThe vendor-specific wrappers still own their details, but the state machine for\nenvironment checks, connection phases, duplicate handling, retry states, live\nevents, and diagnostics is unified.",[11,371,372],{},"That gives us less duplicate UI code in the exact place where duplicate logic\nusually becomes dangerous. Hardware flows should feel calm for users and\nboring for reviewers.",[11,374,375],{},"Ledger policy handling also received another pass. Policies can be stored per\nvault signer, signing rows stay disabled until the required policy is present,\nand returned signatures are checked against the expected cosigner before they\nenter the proposal.",[21,377,379],{"id":378},"the-release-gate-got-heavier-on-purpose","The release gate got heavier on purpose",[11,381,382,383,386,387,390,391,394,395,398,399,402],{},"The branch adds public audit records, branch database tests, Supabase security\nchecks, production configuration verification, browser gates, and stricter\nwallet production gates. The test stack is now explicitly mapped:\n",[49,384,385],{},"release\u002Ftest"," uses the test Supabase project and the ",[49,388,389],{},"wallet-t.asylia.io",",\n",[49,392,393],{},"test.asylia.io",", ",[49,396,397],{},"design-t.asylia.io",", and ",[49,400,401],{},"status-t.asylia.io"," hosts.",[11,404,405,406,148],{},"That matters because this release changes the authorization model. It is not\nenough for the interface to look correct on localhost. RLS policies, service\nrole RPC grants, Edge Function boundaries, email templates, allowed origins,\nVercel host mappings, and public audit manifests all have to agree before this\ngoes to ",[49,407,408],{},"main",[11,410,411],{},"The latest security audit found no critical, high, or medium severity issues.\nIt did record one low-severity residual risk around the expanded service-role\nEdge Function boundary. That risk is accepted because the reviewed functions\ncheck authentication, session binding, challenge ownership and expiry, vault\naccess, PSBT policy, and service-role-only RPC grants before writing sensitive\nstate.",[21,413,415],{"id":414},"what-this-release-is-really-shipping","What this release is really shipping",[11,417,418],{},"The visible product improvements are easy to name: hardware-first sign-in,\nvault email access, clearer key navigation, a more structured send flow, live\nfee and rate data, wallet-scoped billing, stronger Ledger and Trezor flows, and\na quieter workspace.",[11,420,421],{},"The deeper release is architectural. Asylia is moving from account-centric app\naccess toward wallet-centric custody operations.",[11,423,424],{},"That is the right direction for a Bitcoin multisig wallet. People do not only\noperate wallets as individual SaaS users. They operate them as signers,\ncosigners, finance operators, families, founders, and recovery participants.\nThe product should be able to represent that without weakening the rule that\nBitcoin only moves when the vault policy is satisfied.",[11,426,427],{},"This release gives Asylia that foundation.",[11,429,430],{},"Access can now follow the signer or the vault email list. Proposals can move\nthrough an auditable lifecycle. PSBTs are checked before state changes. Vault\nidentity writes are constrained. Provider data is calmer. Release gates are\nstricter.",[11,432,433],{},"That is a lot of work for one branch, but it all points at one product idea:",[11,435,436],{},"The wallet should be easier to operate without becoming easier to misuse.",{"title":150,"searchDepth":151,"depth":151,"links":438},[439,440,441,442,443,444,445,446,447,448,449],{"id":191,"depth":154,"text":192},{"id":215,"depth":154,"text":216},{"id":236,"depth":154,"text":237},{"id":263,"depth":154,"text":264},{"id":276,"depth":154,"text":277},{"id":329,"depth":154,"text":330},{"id":342,"depth":154,"text":343},{"id":355,"depth":154,"text":356},{"id":365,"depth":154,"text":366},{"id":378,"depth":154,"text":379},{"id":414,"depth":154,"text":415},"Release story","2026-05-14",{},"\u002Fstories\u002Fwallet-centric-access-release",8,{"title":174,"description":179},"wallet-centric-access-release","stories\u002Fwallet-centric-access-release","This release turns Asylia's wallet access model into the product boundary: hardware signers and explicit vault email access unlock the workspace, while Bitcoin movement still requires multisig policy and device signatures.","xkaV_2Pl0NULWSu2lGDH09PnSMxwS_bHrkK2rXZLNK8",{"id":461,"title":462,"body":463,"category":450,"date":451,"description":467,"extension":161,"featured":162,"locale":721,"meta":722,"navigation":162,"path":723,"readingTime":454,"seo":724,"slug":456,"stem":725,"summary":726,"__hash__":727},"stories\u002Fstories\u002Fwallet-centric-access-release.cs.md","Wallet-centric access: co mění tohle vydání",{"type":8,"value":464,"toc":708},[465,468,471,474,477,481,484,487,495,498,501,503,506,509,518,522,525,528,542,545,549,552,555,558,562,565,568,571,580,583,604,607,611,614,617,620,624,627,630,633,637,640,643,647,650,653,656,660,675,680,683,687,690,693,696,699,702,705],[11,466,467],{},"Tohle vydání není kosmetická úprava. Mění způsob, jakým Asylia rozhoduje, kdo\nmůže peněženku vidět a používat.",[11,469,470],{},"Doteď se nejjednodušší mentální model stále podobal běžné webové aplikaci:\npřihlásí se uživatel, aplikace ukáže jeho wallety a self-custody pravidla se\nřeší hlavně při podpisu. Jako most během vývoje je to použitelné. Není to ale\nmodel, kolem kterého má Asylia růst.",[11,472,473],{},"Asylia je multisig wallet. Přístup má být ukotvený ve walletu samotném. Account\nsession je pořád nutná, ale nemá se zaměňovat za custody identitu.",[11,475,476],{},"Přesně o tom je wallet-centric access.",[21,478,480],{"id":479},"product-access-teď-následuje-wallet","Product access teď následuje wallet",[11,482,483],{},"Supabase Auth session je teď technická browser session: obálka, přes kterou\naplikace komunikuje s backendem. Produktový přístup se řeší samostatně přes\nAsylia access session.",[11,485,486],{},"Wallet access se dá odemknout dvěma způsoby:",[85,488,489,492],{},[88,490,491],{},"hardwarový signer prokáže kontrolu nad signer identitou, která patří do\njednoho nebo více vaultů,",[88,493,494],{},"email odemkne vaulty, ve kterých je tento normalizovaný email explicitně\nuvedený v přístupových nastaveních.",[11,496,497],{},"Ten rozdíl je důležitý. Signer access session odemkne wallety, kde daný signer\nparticipuje. Email access session odemkne wallety, kde byl emailu udělen\npřístup. V první verzi mají obě metody operátorská práva ve workspace: číst\nvaulty, spravovat nastavení, připravovat návrhy a odesílat validované PSBT\nupdaty.",[11,499,500],{},"Ani jedna metoda ale sama nepohne Bitcoinem. Spend pořád vyžaduje multisig\nthreshold vaultu, validní PSBT a fyzické podpisy hardwarových peněženek.\nPřístup otevře workspace. Prostředky posouvá až vault policy.",[21,502,216],{"id":215},[11,504,505],{},"Přihlašování teď začíná hardwarovým signerem. Trezor i Ledger umí podepsat\njednorázovou Asylia výzvu, Edge verification funkce zkontroluje aktuální browser\nsession, spotřebuje challenge, ověří podpis a vytvoří signer access session, když\nje signer oprávněný.",[11,507,508],{},"Email OTP zůstává k dispozici, ale jeho role je jasnější. Není to univerzální\n\"owner\" klíč ke každému walletu, kterého se účet někdy dotkl. Odemyká wallety,\nkteré tento email záměrně uvádějí. Email je tak praktický pro recovery, operace\na sdílený přístup bez předstírání, že inbox je stejná autorita jako hardwarový\nsigner.",[11,510,511,512,514,515,517],{},"Wallet UI sleduje aktivní metodu přístupu. Email sessions používají širší key\nregistry na ",[49,513,228],{},". Signer sessions dostávají soustředěný ",[49,516,232],{}," detail\naktuálního hardwarového signera včetně walletů, které jsou přes něj viditelné,\na blokátorů před destruktivním odstraněním.",[21,519,521],{"id":520},"sdílený-vault-access-je-explicitní","Sdílený vault access je explicitní",[11,523,524],{},"Nastavení vaultu teď obsahuje email access záznamy. Přidat email znamená, že\ntahle adresa může odemknout daný vault přes OTP. Revokovat email znamená\nodstranit tento přístup bez přepisování Bitcoin policy.",[11,526,527],{},"Asylia tím získává praktický operátorský model:",[85,529,530,533,536,539],{},[88,531,532],{},"founder může držet signer access na hardwarovém zařízení,",[88,534,535],{},"finance operátor může dostat email access pro koordinaci návrhů,",[88,537,538],{},"ztracený nebo bývalý email se dá revokovat na úrovni vaultu,",[88,540,541],{},"a každý spend i tak prochází stejnými multisig podpisovými pravidly.",[11,543,544],{},"Release přidává také access-scoped profily. Preference jako měna, jazyk a časová\nzóna patří aktivní produktové identitě: buď email user profilu, nebo signer\nidentity profilu. Workspace tak zůstává konzistentní i tehdy, když člověk přijde\nrůznými přístupovými cestami.",[21,546,548],{"id":547},"vault-creation-je-méně-křehký","Vault creation je méně křehký",[11,550,551],{},"Zápisy identity vaultu teď jdou přes omezená RPC místo toho, aby browser skládal\nvíc databázových zápisů s best-effort rollbackem. Vytvoření vaultu, připojení\nsignerů, finalizace descriptorů a audit kontext se commitnou jako jedna\ninvariantní operace.",[11,553,554],{},"Tohle je jedna z tichých změn, které jsou nejdůležitější. Multisig wallet nemá\nvytvářet svou identitu napůl. Když vault existuje, jeho signer set, descriptor\nstate, setup status a access záznamy musí souhlasit.",[11,556,557],{},"Dashboard teď rozumí setup-required vaultům jako reálnému stavu, ne jako\nnepohodlnému přechodnému momentu. Produkt tak umí nedokončené vaulty vrátit do\nsprávného setup flow místo toho, aby každou kartu bral jako hotový wallet.",[21,559,561],{"id":560},"spend-proposals-jsou-přísnější","Spend proposals jsou přísnější",[11,563,564],{},"Tahle větev zpevňuje také money-moving cestu okolo PSBT proposalů.",[11,566,567],{},"Send flow je rozdělený na samostatné configure, sign a review kroky. Refactor\nnení jen kvůli čitelnosti. Amount handling, fee matematika, custom fee\ninterakce, PSBT review, signer status a hardware signing state mají vlastní\ntestovatelné hranice.",[11,569,570],{},"Pod UI se při vytvoření proposalu ukládá PSBT draft, recipient summary, fee a\nchange metadata, vybrané input locky a volitelná change reservation v jedné\ntransakci. Aktivní input locky se znovu čtou před coin selection, aby dva taby\npotichu nepostavily konkurenční proposals na stejném outpointu.",[11,572,573,574,576,577,579],{},"Podepsané PSBT updaty jdou přes ",[49,575,292],{}," Edge Function. Funkce načte\nproposal přes RLS-scoped session volajícího, porovná odeslané PSBT s uloženým\nproposalem, spustí hardened ",[49,578,296],{}," policy, odvodí, jestli je\nthreshold opravdu splněný, a stav posune přes service-role-only RPC.",[11,581,582],{},"Policy kontroluje nejdůležitější části:",[85,584,585,588,591,594,596,598,601],{},[88,586,587],{},"očekávané inputs,",[88,589,590],{},"recipienta a amount,",[88,592,593],{},"přesnou change sémantiku,",[88,595,314],{},[88,597,317],{},[88,599,600],{},"splnění thresholdu,",[88,602,603],{},"a shodu finální transakce před broadcastem.",[11,605,606],{},"No-change spends jsou teď plnohodnotný případ. Když spend přesně vyčerpá vybraný\noutput, proposal neukládá change address a policy vyžaduje, aby PSBT neobsahoval\nžádný wallet change output. Pokud change existuje, metadata musí být kompletní.",[21,608,610],{"id":609},"proposal-state-je-auditovatelný","Proposal state je auditovatelný",[11,612,613],{},"Release přidává přísnější transaction-state vrstvu nad existující proposal\nstatus. Proposals můžou procházet explicitním lifecycle: created, policy\nchecked, signed, finalized, mempool accepted, broadcasted, confirmed a\nreconciled.",[11,615,616],{},"Tyhle přechody se zapisují jako append-only state events. Zrušení draftu nebo\npending proposalu je terminální lifecycle rozhodnutí, ne fyzické smazání řádku.\nBroadcast recording ukládá výsledek místo toho, aby wallet hádal stav z\nlokálního UI.",[11,618,619],{},"Pro self-custody produkt to není byrokracie. Je to rozdíl mezi \"obrazovka se\nzměnila\" a \"umíme vysvětlit, co se stalo\".",[21,621,623],{"id":622},"live-wallet-data-jsou-odolnější","Live wallet data jsou odolnější",[11,625,626],{},"Wallet sync teď používá společnou address-state cache místo toho, aby balance,\ntransactions, receive adresy a send preparation dělaly samostatné discovery\nwalky. Aplikace sleduje receive a change address state, balances, pending sats,\npočty transakcí, scanned indexes a krátké sync leases, aby víc tabů nemíjelo\nprovider budget na stejný refresh vaultu.",[11,628,629],{},"Network fee a fiat-rate data se cachují přes Supabase a do walletu přicházejí\npřes Realtime. Bitcoin chain-data package má lepší provider normalizaci,\nfallback handling, cooldowny a rate limiting. Paid Blockstream routing je držený\nza Edge Functions, takže browser bundle nikdy nedostane upstream credentials.",[11,631,632],{},"Výsledkem je klidnější data layer: méně duplicitních scanů, jasnější failure\nstates a kontrolovaná cesta, když jsou veřejní provideři pomalí, rate limited\nnebo nekonzistentní.",[21,634,636],{"id":635},"billing-je-scoped-na-wallety","Billing je scoped na wallety",[11,638,639],{},"Tahle větev posouvá aktivní billing model blíž k tvaru produktu. Billing\nenrollment je scoped na vault, ne jen na generický user účet. Vault settings\nobsahují subscription surface a send flow umí ukázat platform-fee preview jako\nexplicitní proposal output, když se fee aplikuje.",[11,641,642],{},"Pravidlo zůstává viditelné: pod free thresholdem neexistuje Asylia fee output.\nNad ním je fee explicitní, capped a zkontrolovatelné každým cosignerem předtím,\nnež hardwarová zařízení schválí spend.",[21,644,646],{"id":645},"hardware-flows-mají-společný-základ","Hardware flows mají společný základ",[11,648,649],{},"Trezor a Ledger connection flows teď sdílejí společný device-connect wizard.\nVendor-specific wrappery si nechávají svoje detaily, ale state machine pro\nenvironment checks, connection phases, duplicate handling, retry states, live\nevents a diagnostics je jednotný.",[11,651,652],{},"Je to méně duplicitního UI kódu právě na místě, kde duplicita snadno začne\nbolet. Hardware flows mají být klidné pro uživatele a nudné pro reviewery.",[11,654,655],{},"Ledger policy handling dostal další pass. Policies se dají ukládat per vault\nsigner, signing rows zůstávají disabled, dokud potřebná policy není přítomná, a\nvrácené podpisy se kontrolují vůči očekávanému cosignerovi předtím, než vstoupí\ndo proposalu.",[21,657,659],{"id":658},"release-gate-je-záměrně-těžší","Release gate je záměrně těžší",[11,661,662,663,665,666,394,668,390,670,672,673,148],{},"Branch přidává public audit records, branch database tests, Supabase security\nchecks, production configuration verification, browser gates a přísnější wallet\nproduction gates. Test stack je explicitně namapovaný: ",[49,664,385],{}," používá\ntest Supabase projekt a hosty ",[49,667,389],{},[49,669,393],{},[49,671,397],{}," a ",[49,674,401],{},[11,676,677,678,148],{},"Je to důležité, protože tohle vydání mění authorization model. Nestačí, aby UI\nvypadalo správně na localhostu. RLS policies, service-role RPC grants, Edge\nFunction boundaries, email templates, allowed origins, Vercel host mappings a\npublic audit manifests musí souhlasit předtím, než to půjde do ",[49,679,408],{},[11,681,682],{},"Nejnovější security audit nenašel žádné critical, high ani medium severity\nissues. Zaznamenal jeden low-severity residual risk okolo rozšířené service-role\nEdge Function hranice. Riziko je přijaté, protože kontrolované funkce ověřují\nauthentication, session binding, challenge ownership a expiry, vault access,\nPSBT policy i service-role-only RPC grants předtím, než zapisují citlivý stav.",[21,684,686],{"id":685},"co-tohle-vydání-opravdu-shipuje","Co tohle vydání opravdu shipuje",[11,688,689],{},"Viditelné produktové změny se pojmenovávají snadno: hardware-first sign-in,\nvault email access, jasnější key navigation, strukturovanější send flow, live\nfee a rate data, wallet-scoped billing, silnější Ledger a Trezor flows a\nklidnější workspace.",[11,691,692],{},"Hlubší změna je architektonická. Asylia se posouvá od account-centric app access\nk wallet-centric custody operations.",[11,694,695],{},"Pro Bitcoin multisig wallet je to správný směr. Lidé neoperují wallety jen jako\nindividuální SaaS uživatelé. Operují je jako signeri, cosigneri, finance\noperátoři, rodiny, foundeři a recovery participants. Produkt to má umět vyjádřit\nbez oslabení pravidla, že Bitcoin se pohne jen tehdy, když je splněná vault\npolicy.",[11,697,698],{},"Tohle vydání dává Asylii tento základ.",[11,700,701],{},"Access teď může následovat signera nebo email list ve vaultu. Proposals můžou\nprocházet auditovatelným lifecycle. PSBT se kontrolují před změnami stavu. Vault\nidentity writes jsou omezené. Provider data jsou klidnější. Release gates jsou\npřísnější.",[11,703,704],{},"Je to hodně práce na jednu větev, ale všechno míří k jedné produktové myšlence:",[11,706,707],{},"Wallet má být jednodušší na operování bez toho, aby byl jednodušší na špatné\npoužití.",{"title":150,"searchDepth":151,"depth":151,"links":709},[710,711,712,713,714,715,716,717,718,719,720],{"id":479,"depth":154,"text":480},{"id":215,"depth":154,"text":216},{"id":520,"depth":154,"text":521},{"id":547,"depth":154,"text":548},{"id":560,"depth":154,"text":561},{"id":609,"depth":154,"text":610},{"id":622,"depth":154,"text":623},{"id":635,"depth":154,"text":636},{"id":645,"depth":154,"text":646},{"id":658,"depth":154,"text":659},{"id":685,"depth":154,"text":686},"cs",{},"\u002Fstories\u002Fwallet-centric-access-release.cs",{"title":462,"description":467},"stories\u002Fwallet-centric-access-release.cs","Tohle vydání přesouvá přístup k peněžence na správnou produktovou hranici: workspace odemyká hardwarový signer nebo explicitní email ve vaultu, zatímco pohyb Bitcoinu dál vyžaduje multisig politiku a podpisy zařízení.","-JMXeEp8jMp7ptC6Cxy6Ke_ima_XIFxnd5kYRhcp3bY",{"id":729,"title":730,"body":731,"category":450,"date":451,"description":735,"extension":161,"featured":162,"locale":985,"meta":986,"navigation":162,"path":987,"readingTime":454,"seo":988,"slug":456,"stem":989,"summary":990,"__hash__":991},"stories\u002Fstories\u002Fwallet-centric-access-release.sk.md","Wallet-centric access: čo mení toto vydanie",{"type":8,"value":732,"toc":972},[733,736,739,742,745,749,752,755,763,766,769,771,774,777,786,790,793,796,810,813,817,820,823,826,830,833,836,839,848,851,871,874,878,881,884,887,891,894,897,900,902,905,908,912,915,918,921,925,939,944,947,951,954,957,960,963,966,969],[11,734,735],{},"Toto vydanie nie je kozmetická úprava. Mení spôsob, akým Asylia rozhoduje, kto\nmôže peňaženku vidieť a používať.",[11,737,738],{},"Doteraz sa najjednoduchší mentálny model stále podobal bežnej webovej aplikácii:\nprihlási sa používateľ, aplikácia ukáže jeho wallety a self-custody pravidlá sa\nriešia hlavne pri podpise. Ako most počas vývoja je to použiteľné. Nie je to\nvšak model, okolo ktorého má Asylia rásť.",[11,740,741],{},"Asylia je multisig wallet. Prístup má byť ukotvený vo wallete samotnom. Account\nsession je stále potrebná, ale nemá sa zamieňať za custody identitu.",[11,743,744],{},"Presne o tom je wallet-centric access.",[21,746,748],{"id":747},"product-access-teraz-nasleduje-wallet","Product access teraz nasleduje wallet",[11,750,751],{},"Supabase Auth session je teraz technická browser session: obálka, cez ktorú\naplikácia komunikuje s backendom. Produktový prístup sa rieši samostatne cez\nAsylia access session.",[11,753,754],{},"Wallet access sa dá odomknúť dvoma spôsobmi:",[85,756,757,760],{},[88,758,759],{},"hardvérový signer dokáže kontrolu nad signer identitou, ktorá patrí do jedného\nalebo viacerých vaultov,",[88,761,762],{},"email odomkne vaulty, v ktorých je tento normalizovaný email explicitne\nuvedený v prístupových nastaveniach.",[11,764,765],{},"Tento rozdiel je dôležitý. Signer access session odomkne wallety, kde daný\nsigner participuje. Email access session odomkne wallety, kde bol emailu udelený\nprístup. V prvej verzii majú obe metódy operátorské práva vo workspace: čítať\nvaulty, spravovať nastavenia, pripravovať návrhy a odosielať validované PSBT\nupdaty.",[11,767,768],{},"Ani jedna metóda však sama nepohne Bitcoinom. Spend stále vyžaduje multisig\nthreshold vaultu, validné PSBT a fyzické podpisy hardvérových peňaženiek.\nPrístup otvorí workspace. Prostriedky posúva až vault policy.",[21,770,216],{"id":215},[11,772,773],{},"Prihlasovanie teraz začína hardvérovým signerom. Trezor aj Ledger vedia podpísať\njednorazovú Asylia výzvu, Edge verification funkcia skontroluje aktuálnu browser\nsession, spotrebuje challenge, overí podpis a vytvorí signer access session, ak\nje signer oprávnený.",[11,775,776],{},"Email OTP ostáva k dispozícii, ale jeho rola je jasnejšia. Nie je to univerzálny\n\"owner\" kľúč ku každému walletu, ktorého sa účet niekedy dotkol. Odomyká\nwallets, ktoré tento email úmyselne uvádzajú. Email je tak praktický pre\nrecovery, operácie a zdieľaný prístup bez predstierania, že inbox je rovnaká\nautorita ako hardvérový signer.",[11,778,779,780,782,783,785],{},"Wallet UI sleduje aktívnu metódu prístupu. Email sessions používajú širší key\nregistry na ",[49,781,228],{},". Signer sessions dostávajú sústredený ",[49,784,232],{}," detail\naktuálneho hardvérového signera vrátane walletov, ktoré sú cez neho viditeľné,\na blokátorov pred deštruktívnym odstránením.",[21,787,789],{"id":788},"zdieľaný-vault-access-je-explicitný","Zdieľaný vault access je explicitný",[11,791,792],{},"Nastavenia vaultu teraz obsahujú email access záznamy. Pridať email znamená, že\ntáto adresa môže odomknúť daný vault cez OTP. Revokovať email znamená odstrániť\ntento prístup bez prepisovania Bitcoin policy.",[11,794,795],{},"Asylia tým získava praktický operátorský model:",[85,797,798,801,804,807],{},[88,799,800],{},"founder môže držať signer access na hardvérovom zariadení,",[88,802,803],{},"finance operátor môže dostať email access na koordináciu návrhov,",[88,805,806],{},"stratený alebo bývalý email sa dá revokovať na úrovni vaultu,",[88,808,809],{},"a každý spend aj tak prechádza tými istými multisig podpisovými pravidlami.",[11,811,812],{},"Release pridáva aj access-scoped profily. Preferencie ako mena, jazyk a časová\nzóna patria aktívnej produktovej identite: buď email user profilu, alebo signer\nidentity profilu. Workspace tak ostáva konzistentný aj vtedy, keď človek príde\nrôznymi prístupovými cestami.",[21,814,816],{"id":815},"vault-creation-je-menej-krehký","Vault creation je menej krehký",[11,818,819],{},"Zápisy identity vaultu teraz idú cez obmedzené RPC namiesto toho, aby browser\nskladal viac databázových zápisov s best-effort rollbackom. Vytvorenie vaultu,\npripojenie signerov, finalizácia descriptorov a audit kontext sa commitnú ako\njedna invariantná operácia.",[11,821,822],{},"Toto je jedna z tichých zmien, ktoré sú najdôležitejšie. Multisig wallet nemá\nvytvárať svoju identitu napoly. Ak vault existuje, jeho signer set, descriptor\nstate, setup status a access záznamy musia spolu súhlasiť.",[11,824,825],{},"Dashboard teraz rozumie setup-required vaultom ako reálnemu stavu, nie ako\nnepohodlnému prechodnému momentu. Produkt tak vie nedokončené vaulty vrátiť do\nsprávneho setup flow namiesto toho, aby každú kartu bral ako hotový wallet.",[21,827,829],{"id":828},"spend-proposals-sú-prísnejšie","Spend proposals sú prísnejšie",[11,831,832],{},"Táto vetva spevňuje aj money-moving cestu okolo PSBT proposalov.",[11,834,835],{},"Send flow je rozdelený na samostatné configure, sign a review kroky. Refactor\nnie je len kvôli čitateľnosti. Amount handling, fee matematika, custom fee\ninterakcia, PSBT review, signer status a hardware signing state majú vlastné\ntestovateľné hranice.",[11,837,838],{},"Pod UI sa pri vytvorení proposalu ukladá PSBT draft, recipient summary, fee a\nchange metadata, vybrané input locky a voliteľná change reservation v jednej\ntransakcii. Aktívne input locky sa znovu čítajú pred coin selection, aby dva\ntaby potichu nepostavili konkurenčné proposals na rovnakom outpointe.",[11,840,841,842,844,845,847],{},"Podpísané PSBT updaty idú cez ",[49,843,292],{}," Edge Function. Funkcia načíta\nproposal cez RLS-scoped session volajúceho, porovná odoslané PSBT s uloženým\nproposalom, spustí hardened ",[49,846,296],{}," policy, odvodí, či je threshold\nnaozaj splnený, a stav posunie cez service-role-only RPC.",[11,849,850],{},"Policy kontroluje najdôležitejšie časti:",[85,852,853,856,858,861,863,865,868],{},[88,854,855],{},"očakávané inputs,",[88,857,590],{},[88,859,860],{},"presnú change sémantiku,",[88,862,314],{},[88,864,317],{},[88,866,867],{},"splnenie thresholdu,",[88,869,870],{},"a zhodu finálnej transakcie pred broadcastom.",[11,872,873],{},"No-change spends sú teraz plnohodnotný prípad. Ak spend presne vyčerpá vybraný\noutput, proposal neukladá change address a policy vyžaduje, aby PSBT neobsahoval\nžiadny wallet change output. Ak change existuje, metadata musia byť kompletné.",[21,875,877],{"id":876},"proposal-state-je-auditovateľný","Proposal state je auditovateľný",[11,879,880],{},"Release pridáva prísnejšiu transaction-state vrstvu nad existujúci proposal\nstatus. Proposals môžu prechádzať explicitným lifecycle: created, policy\nchecked, signed, finalized, mempool accepted, broadcasted, confirmed a\nreconciled.",[11,882,883],{},"Tieto prechody sa zapisujú ako append-only state events. Zrušenie draftu alebo\npending proposalu je terminálne lifecycle rozhodnutie, nie fyzické zmazanie\nriadku. Broadcast recording ukladá výsledok namiesto toho, aby wallet hádal stav\nz lokálneho UI.",[11,885,886],{},"Pre self-custody produkt to nie je byrokracia. Je to rozdiel medzi \"obrazovka sa\nzmenila\" a \"vieme vysvetliť, čo sa stalo\".",[21,888,890],{"id":889},"live-wallet-data-sú-odolnejšie","Live wallet data sú odolnejšie",[11,892,893],{},"Wallet sync teraz používa spoločnú address-state cache namiesto toho, aby\nbalance, transactions, receive adresy a send preparation robili samostatné\ndiscovery walky. Aplikácia sleduje receive a change address state, balances,\npending sats, počty transakcií, scanned indexes a krátke sync leases, aby viac\ntabov nemíňalo provider budget na rovnaký refresh vaultu.",[11,895,896],{},"Network fee a fiat-rate dáta sa cachujú cez Supabase a do walletu prichádzajú\ncez Realtime. Bitcoin chain-data package má lepšiu provider normalizáciu,\nfallback handling, cooldowny a rate limiting. Paid Blockstream routing je držaný\nza Edge Functions, takže browser bundle nikdy nedostane upstream credentials.",[11,898,899],{},"Výsledkom je pokojnejšia data layer: menej duplicitných scanov, jasnejšie\nfailure states a kontrolovaná cesta, keď sú verejní provideri pomalí, rate\nlimited alebo nekonzistentní.",[21,901,636],{"id":635},[11,903,904],{},"Táto vetva posúva aktívny billing model bližšie k tvaru produktu. Billing\nenrollment je scoped na vault, nie iba na generický user účet. Vault settings\nobsahujú subscription surface a send flow vie ukázať platform-fee preview ako\nexplicitný proposal output, keď sa fee aplikuje.",[11,906,907],{},"Pravidlo ostáva viditeľné: pod free thresholdom neexistuje Asylia fee output.\nNad ním je fee explicitné, capped a skontrolovateľné každým cosignerom predtým,\nnež hardvérové zariadenia schvália spend.",[21,909,911],{"id":910},"hardware-flows-majú-spoločný-základ","Hardware flows majú spoločný základ",[11,913,914],{},"Trezor a Ledger connection flows teraz zdieľajú spoločný device-connect wizard.\nVendor-specific wrappery si nechávajú svoje detaily, ale state machine pre\nenvironment checks, connection phases, duplicate handling, retry states, live\nevents a diagnostics je jednotný.",[11,916,917],{},"Je to menej duplicitného UI kódu práve na mieste, kde duplicita ľahko začne\nbolieť. Hardware flows majú byť pokojné pre používateľov a nudné pre reviewerov.",[11,919,920],{},"Ledger policy handling dostal ďalší pass. Policies sa dajú ukladať per vault\nsigner, signing rows ostávajú disabled, kým potrebná policy nie je prítomná, a\nvrátené podpisy sa kontrolujú voči očakávanému cosignerovi predtým, než vstúpia\ndo proposalu.",[21,922,924],{"id":923},"release-gate-je-zámerne-ťažší","Release gate je zámerne ťažší",[11,926,927,928,930,931,394,933,390,935,672,937,148],{},"Branch pridáva public audit records, branch database tests, Supabase security\nchecks, production configuration verification, browser gates a prísnejšie wallet\nproduction gates. Test stack je explicitne namapovaný: ",[49,929,385],{}," používa\ntest Supabase projekt a hosty ",[49,932,389],{},[49,934,393],{},[49,936,397],{},[49,938,401],{},[11,940,941,942,148],{},"Je to dôležité, pretože toto vydanie mení authorization model. Nestačí, aby UI\nvyzeralo správne na localhoste. RLS policies, service-role RPC grants, Edge\nFunction boundaries, email templates, allowed origins, Vercel host mappings a\npublic audit manifests musia spolu súhlasiť predtým, než to pôjde do ",[49,943,408],{},[11,945,946],{},"Najnovší security audit nenašiel žiadne critical, high ani medium severity\nissues. Zaznamenal jeden low-severity residual risk okolo rozšírenej\nservice-role Edge Function hranice. Riziko je prijaté, pretože kontrolované\nfunkcie overujú authentication, session binding, challenge ownership a expiry,\nvault access, PSBT policy aj service-role-only RPC grants predtým, než zapisujú\ncitlivý stav.",[21,948,950],{"id":949},"čo-toto-vydanie-naozaj-shipuje","Čo toto vydanie naozaj shipuje",[11,952,953],{},"Viditeľné produktové zmeny sa pomenúvajú ľahko: hardware-first sign-in, vault\nemail access, jasnejšia key navigation, štruktúrovanejší send flow, live fee a\nrate dáta, wallet-scoped billing, silnejšie Ledger a Trezor flows a pokojnejší\nworkspace.",[11,955,956],{},"Hlbšia zmena je architektonická. Asylia sa posúva od account-centric app access\nk wallet-centric custody operations.",[11,958,959],{},"Pre Bitcoin multisig wallet je to správny smer. Ľudia neoperujú wallety iba ako\nindividuálni SaaS používatelia. Operujú ich ako signeri, cosigneri, finance\noperátori, rodiny, founderi a recovery participants. Produkt to má vedieť\nvyjadriť bez oslabenia pravidla, že Bitcoin sa pohne iba vtedy, keď je splnená\nvault policy.",[11,961,962],{},"Toto vydanie dáva Asylii tento základ.",[11,964,965],{},"Access teraz môže nasledovať signera alebo email list vo vaulte. Proposals môžu\nprechádzať auditovateľným lifecycle. PSBT sa kontrolujú pred zmenami stavu.\nVault identity writes sú obmedzené. Provider data sú pokojnejšie. Release gates\nsú prísnejšie.",[11,967,968],{},"Je to veľa práce na jednu vetvu, ale všetko smeruje k jednej produktovej myšlienke:",[11,970,971],{},"Wallet má byť jednoduchší na operovanie bez toho, aby bol jednoduchší na zlé\npoužitie.",{"title":150,"searchDepth":151,"depth":151,"links":973},[974,975,976,977,978,979,980,981,982,983,984],{"id":747,"depth":154,"text":748},{"id":215,"depth":154,"text":216},{"id":788,"depth":154,"text":789},{"id":815,"depth":154,"text":816},{"id":828,"depth":154,"text":829},{"id":876,"depth":154,"text":877},{"id":889,"depth":154,"text":890},{"id":635,"depth":154,"text":636},{"id":910,"depth":154,"text":911},{"id":923,"depth":154,"text":924},{"id":949,"depth":154,"text":950},"sk",{},"\u002Fstories\u002Fwallet-centric-access-release.sk",{"title":730,"description":735},"stories\u002Fwallet-centric-access-release.sk","Toto vydanie presúva prístup k peňaženke na správnu hranicu produktu: workspace odomyká hardvérový signer alebo explicitný email vo vaulte, zatiaľ čo pohyb Bitcoinu stále vyžaduje multisig politiku a podpisy zariadení.","hFF0Li-vRc7X9M-UwLnIqoC22xQBN1Wa9yP4QG7Qsm0",1778786665942]