Bitcoin. It's your money!

New Address create a new address

Any keys used you will need to manually store safely as they will be needed later to redeem the bitcoins.

Address (Share) Public key (Share) Private key (WIF key)

Address Options

You can use the advanced options below to generate different kind of keys and addresses.

New SegWit Address Smaller & Faster Transactions

Any keys used you will need to manually store safely as they will be needed later to redeem the bitcoins.

SegWit Address (Share) RedeemScript Public key Private key (WIF key)

Address Options

You can use the advanced options below to generate different kind of keys and addresses.

New Multisig Address Secure multisig address

Enter the amount of signatures required to release the coins

New Time Locked Address Coins can be released only after a certain date

Enter the date and time or blockheight required to release the coins:

Inheritance Plan decide who gets what, and when

You are building a plan, not a blockchain transaction. When your plan is complete it is compiled into a transaction for you — using the same engine as the Transaction page, where every detail remains visible.

Vault — Address, WIF key or Redeem Script:

Loading retrieves your vault's unspent funds (network required). Working fully offline? Enter your inputs manually on the Transaction page — the plan picks them up automatically.

Starting from a plan you saved earlier? Load Plan… Reads INHERITANCE PACKAGE file.  ·  New Plan

When should this inheritance take effect?

Beneficiaries

Who should receive this inheritance?

Add a Beneficiary

Plan Overview List Timeline

New HD Address making bip32 even easier

Use the form below to generate a master hierarchical deterministic address.

xPub Address xPrv Address

Address Options

You can use the advanced options below to generate different kinds of master addresses.

Transaction Create a new transaction

Use this page to create a raw transaction

Address, WIF key or Redeem Script:

• Outputs (0.00000000)
• Inputs (0.00000000)

Bitcoin Fee Calculator

This page will give you a guide on the lowest fee to use to get your transaction included within the next few blocks. It works by predicting the size of a transaction and comparing it to another transaction in a recent block to determine an appropriate fee.

---

Verify transactions and other scripts

Sign Transaction once a transaction has been verified

Once you have verified a transaction you can sign and then broadcast it into the network.

Advanced Options

Broadcast Transaction into the bitcoin network

Enter your hex encoded bitcoin transaction

Development Javascript framework, API and more

About Will-Wallet

Will-Wallet is a self-custody Bitcoin wallet focused on inheritance and distribution planning. It runs entirely in your browser: your keys and transactions are generated and signed on your own device, and are never sent to us or to any server we operate.

What it does today

Will-Wallet builds on standard, well-established Bitcoin capabilities to let you:

• Generate and manage legacy, SegWit/Bech32, and HD (BIP32) addresses and keys.
• Construct, verify, sign, and broadcast raw Bitcoin transactions, including Replace-by-Fee (RBF).
• Create M-of-N multisignature addresses and redeem scripts.
• Create timelocked (CHECKLOCKTIMEVERIFY) addresses and transaction-level (nLockTime) locks, so funds cannot move before a chosen date or block height.
• Estimate network fees for a constructed transaction, using either a public data source or your own node (see Settings).
• Build an inheritance plan: describe beneficiaries, portions, and unlock dates in plain language, and have Will-Wallet compile that into a multisig, timelocked distribution transaction and a set of per-beneficiary packages — without any custodian ever holding a working key.

These are the features implemented in this application today; nothing here is a promise of future functionality.

Offline & local-first

Key generation, address derivation, transaction construction, timelocks, signing, fee calculation, and inheritance plan drafts all run locally in your browser and do not require an internet connection. Retrieving live blockchain data (balances, unspent outputs) and broadcasting a transaction do require network access to a Bitcoin data source — by default a public blockchain service, or optionally your own Bitcoin Core node, configurable on the Settings page. You can also save this page and run it from your own computer, entirely offline, using it purely to construct and sign transactions manually.

Privacy

Will-Wallet does not require an account, does not collect analytics, and does not transmit your private keys or seed material anywhere. Inheritance plan drafts are saved only in your browser's local storage on your own device. If you choose to connect to your own Bitcoin Core node, its address and credentials stay in your browser and are sent only to the node you specify.

Responsibility

Bitcoin transactions are irreversible once confirmed, and self-custody means you are solely responsible for your keys and for the accuracy of any plan you build. Take time to understand what a transaction does — using the Verify page — before signing or broadcasting it. Will-Wallet does not provide legal, tax, or financial advice; an inheritance plan built here is a technical distribution mechanism and is not a substitute for a will, trust, or other legal instrument prepared with qualified advice.

Security & architecture

For a full plain-language explanation of how Will-Wallet actually handles keys, signing, timelocks, fees, and blockchain connectivity — including what it deliberately does not do — see Security & Architecture.

Open source

Will-Wallet is free and open source, released under the MIT license, which means it's free to use, audit, and modify. The client-side, no-server-custody design described above can be independently verified by reading the source code.

White paper

For the full design behind the inheritance plan builder — the multisig structure, timelocks, revocation, and threat model — see the Will-Wallet Inheritance Plan White Paper.

Will-Wallet Inheritance Plan White Paper

The full design behind the inheritance plan builder: the multisig structure, timelocks, revocation semantics, and threat model. You can read it below, or open it in a new tab.

Security & Architecture how Will-Wallet actually works

This page explains Will-Wallet's real architecture and security model in plain language — what it does, what it deliberately does not do, and where its guarantees end. It's written for both users and for anyone (including an AI coding assistant) reading or modifying this application's source.

What Will-Wallet is

A self-custody Bitcoin application, focused on transaction construction and inheritance planning, that runs as a single static page in your browser. There is no Will-Wallet account, no Will-Wallet server that holds or processes your keys, and no backend this application depends on to construct or sign a transaction.

What Will-Wallet does not do

• It does not custody your Bitcoin. Nothing here ever holds a working combination of keys except the addresses/scripts you and your co-signers control.
• It does not require a Will-Wallet account, login, or identity of any kind.
• It does not require a Will-Wallet backend for any offline functionality (see below) — and there is no Will-Wallet backend at all, online or offline.
• It does not ask you to give a private key or seed to a server. Every private-key field in this application (Sign, the wallet's open/spend flow, the Inheritance Plan builder's signing step) is read and used by JavaScript running in your own browser tab and is never included in any network request this application makes.
• It does not secretly store keys remotely. The only thing saved automatically is an Inheritance Plan draft (names, dates, amounts, public keys) in your browser's own local storage, on your own device — see Drafts & local storage below.

Hosted vs. downloaded — what actually changes

A common misconception is that loading Will-Wallet from will-wallet.com is less safe than downloading the page and running it locally because "the website" might see your keys. That's not how this application works, in either case: whether you load index.html from the live site or from a copy on your own disk, the exact same JavaScript runs, in the same way, entirely in your browser. Neither case sends a network request containing your private key, WIF, or seed — you can verify this yourself by reading the source or watching your browser's network tab while using it.

What genuinely differs between the two is narrower, but real:

• Supply-chain trust at load time. Loading the live page means trusting that that specific page load wasn't tampered with (a compromised server or CDN, a MITM on a connection without HTTPS). A copy you downloaded once and audited doesn't re-expose you to that risk on every subsequent use.
• Availability. A saved local copy keeps working if the domain, hosting, or maintainers of this project ever disappear. A plan's half-signed transactions and distribution packages are plain data (hex strings and text) that don't depend on this website at all once created — but the tool to construct, verify, and sign new ones does depend on having a copy of the app.

Neither point changes where your keys go during use. That's why "download and run locally" is a good practice for supply-chain and availability reasons, not because the hosted version is secretly less private.

Offline operation

Everything that doesn't inherently require current blockchain state works with no network connection at all:

• Generating keys and addresses (legacy, SegWit/Bech32, HD/BIP32, multisig)
• Constructing a raw transaction from inputs and outputs you provide
• Building timelocked outputs (CHECKLOCKTIMEVERIFY redeem scripts) and setting a transaction's nLockTime
• Signing a transaction with a private key
• Calculating an estimated fee from a chosen fee rate and the transaction's size
• Preparing a multisig transaction for additional signers
• Creating an Inheritance Plan, and viewing/editing a previously saved draft
• Generating the resulting transaction hex and distribution-package text

Only two kinds of operation inherently need network access: retrieving live blockchain data (an address's unspent outputs, current fee-rate estimates, a node's block height) and broadcasting a signed transaction to the network. Both are described next.

Blockchain connectivity: three distinct modes

Configurable on the Settings page, independently for "where to broadcast" and "where to read unspent outputs / fee data from":

• No connection. Leave inputs blank and construct a transaction manually (entering a known UTXO's txid/index/script/amount yourself), sign it, and export the hex to broadcast elsewhere.
• Public blockchain service. The default. This application queries a public API (currently coinb.in's, the project this app was originally forked from) for unspent outputs, fee estimates, and broadcasting. That service sees the Bitcoin address you're querying and the transaction you broadcast — ordinary, unavoidable metadata exposure for any wallet using a third-party data source — but never your private key.
• Your own Bitcoin Core node, via RPC. You control the node; queries and broadcasts go directly from your browser to the host and port you specify, with credentials that stay in this browser tab. See the next section for what this means for security.

Connecting to your own Bitcoin Core node

This is the strongest privacy option, but it comes with its own responsibilities that are different from using the public default:

• RPC credentials are highly sensitive — equivalent to a password that can move funds through your node's wallet or broadcast on your behalf. This application keeps them in browser memory for the current session only, sends them only in the Basic-Auth header of requests to the exact host/port you configured, and never writes them to local storage, a URL, or a log.
• Never expose your node's RPC port to the public internet. Bitcoin Core's own documentation warns against binding RPC to an untrusted network. Use 127.0.0.1 (this machine) or a private network you trust; if you need to reach a node elsewhere, use a VPN or SSH tunnel, not an open port.
• A remote node is a different trust boundary than a local one. Traffic to a non-local host, without HTTPS, can be observed by anyone on the network path between your browser and the node. The Settings page flags this explicitly when the configured host isn't localhost.
• Confirm you're on the network you think you're on. A node can be mainnet, testnet, signet, or regtest. The Settings page's "Test connection" button checks the node's actual chain against what this page is configured for, to catch that mismatch before it causes confusion at broadcast time.
• Because Bitcoin Core's RPC server doesn't send CORS headers by default, your browser may need to reach the node directly (same machine, local network, or a reverse proxy you control) for these requests to succeed at all — this is a browser security mechanism working as intended, not a bug in this application.

Keys and signing

Private keys are only ever entered into a password-type field, used immediately by client-side JavaScript to compute a signature (using RFC 6979 deterministic nonces, not less-predictable random ones), and then the field is cleared. A key you type is never included in a network request, never written to local storage, and never appears in this application's own drafts. Before you sign anything — on the Sign page or in the Inheritance Plan builder — the exact transaction is decoded and shown: its inputs, its outputs and their addresses and amounts, its locktime, and its RBF status, using the same decoder as the Verify page. What you see there is what you are about to sign, byte for byte.

Multisig

Will-Wallet does not require its multisig setups to be created here. A multisig address and redeem script can be produced by any compatible wallet or tool; this application only needs the redeem script (or the public keys and threshold) to construct outputs paying to it, and needs a private key matching one of its public keys to add a signature. Nothing in this application assumes a particular signer will provide the next signature in a multisig flow — any holder of a valid key for that script can complete it, in any order, using the same Sign mechanism throughout.

Timelocks

Two independent mechanisms are used, and they guarantee different things:

• nLockTime (a property of one specific transaction) prevents that transaction from being mined before a given date or block height. It does not restrict the coins themselves — a different transaction spending the same output is unaffected by it.
• CHECKLOCKTIMEVERIFY (compiled into an output's script) restricts the coins at that address: no spending path exists at all until the specified time, regardless of which transaction attempts it.

Neither guarantees that a beneficiary will actually be able to spend the moment the lock expires. A CLTV output can only be spent with the exact redeem script and a matching private key — both must still exist and be usable. A pre-signed, nLockTime-gated transaction depends on the specific unspent output it references still being unspent when the time comes; spending, consolidating, or sweeping that output beforehand (even accidentally, e.g. through routine wallet activity) invalidates it. Will-Wallet surfaces this explicitly in the Inheritance Plan builder and its distribution packages, but cannot prevent it, since it's a property of Bitcoin's UTXO model, not of this application.

Fees

You choose a fee rate (satoshis per virtual byte). This application estimates the constructed transaction's size (reusing the same estimator as the Fees page), multiplies the two to get the actual transaction fee, and rebuilds the transaction so that fee is exactly what the inputs exceed the outputs by. A rate chosen today is a guess about future network conditions; if it turns out too low by the time a delayed transaction is broadcast, the RBF flag (below) is what allows it to be corrected without re-signing from scratch.

Replace-By-Fee (RBF)

An RBF-flagged transaction (non-final sequence numbers) may be replaced in nodes' mempools by another transaction spending the same inputs with a higher fee, before it confirms. Will-Wallet enables this by default on inheritance-plan transactions specifically so a stale fee doesn't strand a distribution transaction years later. It does not change what the transaction pays once confirmed, and it does not help after confirmation — whoever eventually broadcasts the transaction still needs a wallet or tool capable of fee-bumping if the original rate is no longer sufficient.

Inheritance: artifacts, not custody

The Inheritance Plan builder produces data — a transaction (unsigned, then half-signed once you sign it) and a set of distribution packages containing that transaction plus the information each beneficiary needs. It does not hold, escrow, or transmit funds on your behalf, and no Will-Wallet service is involved in a beneficiary eventually completing and broadcasting that transaction. The artifacts are only as durable and correct as your own handling of them: keeping the vault's funding output unspent until release, distributing packages to the right people, and revoking (by spending the vault output yourself) if the plan ever needs to change. Will-Wallet is a technical distribution mechanism, not a will, trust, or other legal instrument — it does not address probate, contest risk, or tax treatment in any jurisdiction, and using it doesn't remove the value of also naming these arrangements in a legally binding document.

Drafts & local storage

An Inheritance Plan in progress is saved automatically to your browser's local storage so it survives closing the tab. That draft contains plan structure only — beneficiary labels, dates, amounts, and public keys — never a private key. It is local storage, not a Will-Wallet account: it lives only in that one browser, on that one device, and clearing site data removes it. Building a plan does not depend on this storage; drafts are a convenience, not the source of truth for a completed transaction.

Honest limitations

This section exists so nothing above reads as a stronger claim than it is:

• Browser-based JavaScript execution is not the same guarantee as an air-gapped, hardware-isolated signing device. Anyone who can run malicious code in the same browser context you use (a compromised extension, a tampered page load) could in principle interfere with a signing operation while it happens.
• Using the public blockchain service reveals the addresses you query and the transactions you broadcast to that service, the ordinary trade-off of not running your own node.
• Bitcoin's own protocol limitations apply regardless of this application: a pre-signed transaction can be invalidated by spending its input; a fixed fee can become insufficient; a lost key or lost redeem script is unrecoverable by design.
• Will-Wallet is not audited by a third-party security firm. It is open source specifically so it can be read and verified by anyone, including you.
• This application does not, and cannot, make Bitcoin self-custody risk-free. It aims to make the risks visible and to avoid adding risks of its own.

Settings making WILL-WALLET even better!

These simple settings below make will-wallet one of the most decentralized wallets in the world.

---

---