Short terms of service
This is an experimental Bitcoin Layer 2 wallet with separate Signet and mainnet modes. Signet coins have no monetary value. Mainnet uses real bitcoin: use only an amount you can afford to lose. Satoshi.si does not receive, custody, control, insure, or recover funds. You are responsible for your recovery phrase, device, payments, taxes, legal compliance, and any loss caused by misuse, software defects, browser storage loss, an unavailable provider, or protocol failure.
The wallet depends on Second's Ark server and chain-data service. VTXOs expire and must be refreshed, spent, or exited in time. IndexedDB can be erased by the browser and is not a backup. With compatible Bark software, phrase recovery can restore spendable VTXOs that the selected server's mailbox still knows about. It does not restore payment history or reliably resume an unfinished exit. Emergency exits are multi-stage and require this wallet to keep progressing and finally claim the funds.
Ark is the protocol. Bark is the wallet.
Ark is a Bitcoin Layer 2 protocol. Bark is Second's open-source implementation running locally on this page. There is no Bark coin or wrapped token: the balance is bitcoin represented by VTXOs, and Bitcoin's blockchain is the final settlement layer.
Bitcoin UTXOShared transaction treeYour VTXO
A VTXO is a virtual transaction output: a claim in a tree of pre-signed Bitcoin transactions. Many users share one on-chain UTXO, so ordinary payments can be fast and the on-chain cost can be shared.
This wallet also has a separate native on-chain balance. Use Move to Ark to board confirmed on-chain funds, or Move on-chain to send Ark funds to a fresh Bitcoin address owned by this wallet. On-chain transfers need mining confirmations and fees.
What the Ark server does
The Ark Service Provider, or ASP, coordinates batches called rounds, supplies liquidity, co-signs instant Ark payments, forwards Lightning payments, and helps wallets refresh expiring VTXOs. The ASP holds a key used in the cooperative spending path: a VTXO leaf uses a 2-of-2 user-and-server path, while transaction-tree branches include the server in an n-of-n path. The ASP does not hold your private key and cannot spend an unexpired, non-forfeited VTXO without your signature.
Before expiry, an honest user can exit unilaterally. That protection no longer applies after the VTXO expires or after its old state has been forfeited. The ASP can also see connection and payment metadata, refuse service, censor new payments, or become unavailable.
An instant Ark payment is normally an out-of-round payment, also called arkoor. It arrives quickly, but until the receiver refreshes it in a round, security assumes the sender and ASP do not collude to double-spend it. Bark's background maintenance handles normal synchronization and refresh work while the wallet is running.
Rounds, refreshes, and expiry
A round replaces old VTXOs with new VTXOs inside a newly anchored shared UTXO. Users sign forfeits for the old state, while connector outputs make that exchange atomic: the old claim is forfeited only if the new round transaction exists.
VTXOs have a finite lifetime so the ASP's liquidity is not locked forever. Before expiry, the wallet must spend, refresh, cooperatively offboard, or begin an emergency exit. Refreshing renews the claim and may cost a fee. VTXOs received through Lightning can expire sooner and require timely wallet maintenance. Leaving a browser wallet unused is therefore different from leaving ordinary on-chain bitcoin in cold storage.
Second's liquidity research uses a typical 28-day VTXO lifetime as an example, but the connected server sets the actual lifetime. After opening a wallet, its current server value appears under Connected service below. Read Second's explanations of VTXO expiry timing and refresh and exit stages.
Cooperative withdrawal and emergency exit
A normal on-chain payment or cooperative offboard asks the ASP to move value from Ark to a Bitcoin address. This is generally simpler and cheaper, but needs the server. Bark uses the server's current offboard fee rate for this operation, so this wallet can show the fee but cannot replace it with a user-selected rate. Sending the entire Ark balance deducts that fee from the amount received.
A unilateral emergency exit uses the pre-signed transaction branch without ASP cooperation. It can require several on-chain transactions, confirmed on-chain funds for CPFP fees, waiting through confirmation and timelock stages, and then a final claim transaction. High fees or many simultaneous exits can make it expensive and slow.
The Danger zone can estimate, start, progress, and finally claim an emergency exit into this wallet's on-chain balance. Keep the wallet and its local database available throughout the process. Use an ordinary on-chain payment whenever the server is cooperating.
Ark and Lightning complement each other
Ark / BarkNo personal channelsNo inbound liquidity for the user to arrangeSingle ASP coordinates payments and roundsVTXOs require periodic refresh
LightningEstablished channel and routing ecosystemUsers or providers manage channel liquidityPayments route across many nodesBetter suited to very frequent routed payments
Bark lets one Ark balance pay Ark addresses, Lightning invoices, Lightning Addresses, and on-chain Bitcoin addresses. That makes Ark a useful onboarding and holding layer while Lightning remains the larger payment network. Neither design is simply better in every situation.
Connected service
NetworkBitcoin Signet
Ark serverark.signet.2nd.dev
Round intervalAvailable after wallet opens
VTXO lifetimeAvailable after wallet opens
Exit delayAvailable after wallet opens
These are read from the connected server rather than assumed from an article. Server policy and fees can change.
Recovery, password, and local storage
The pinned Bark WebAssembly engine stores changing wallet state in this site's IndexedDB. To reopen it without repeatedly exposing your recovery phrase, this page encrypts the phrase with AES-256-GCM using a key derived from your password with PBKDF2-SHA-256 and a random salt. The password is never stored. Use a long, unique password: an attacker who copies the encrypted profile can still attempt guesses offline.
The gear beside this help button controls automatic locking and can reveal the phrase only after the correct password decrypts it. The same lock delay is available in Wallet security settings. The phrase remains an essential safety net, but it is not a complete Bark backup. Phrase-only recovery depends on the ASP mailbox and restores only spendable VTXOs the mailbox still knows about. It does not restore payment history and is not a reliable unfinished-exit recovery workflow. IndexedDB and local storage can both be erased, so keep the paper recovery phrase safe.
This page does not offer a raw, unencrypted database download. Bark Web has no supported atomic database export-and-import format, and restoring a stale snapshot after spending can roll wallet state backward. Analytics and Synthetic Satoshi are disabled on this page.
Live and background payment alerts
While the wallet is open and unlocked, Bark keeps a live event channel and shows new Ark and Lightning receipts immediately. This uses Bark events rather than repeatedly polling the server.
Background alerts are optional. When enabled, the wallet sends a signed, read-only mailbox authorization to Satoshi.si's notification service. It lasts as long as you choose, from 24 hours up to a year, and cannot be revoked early at the Ark server. The push message deliberately says only that bitcoin arrived: no address, amount, or transaction content. To notice a payment the service reads the mailbox, and an incoming Lightning payment message there includes the amount; the service stores no amounts and redacts its logs.
A push wakes the installed PWA so you can open and synchronize the wallet, but it cannot unlock your encrypted wallet or complete a Lightning receive while the app is closed. Open the wallet promptly when waiting for Lightning. Browser and phone power-saving rules may delay notifications.
Brave users: Brave disables Google's push service by default, so background alerts cannot register until you turn on "Use Google services for push messaging" under Settings → Privacy and security (search the settings for "push"), then reload this page. Other browsers use their own push setup, whose availability still depends on the browser, operating system and network.