How the inheritance vault works

Will & Key is a non-custodial smart contract. It does not detect death. It follows a timer, an heir's transaction and a challenge period in which the owner can still stop the claim.

By the Will & Key project team · Published 10 August 2026 · Updated 28 September 2026 · Security status

This page describes version 2 of the vault contract, live on Base since 28 September 2026 at 0xA07b59d9249A996604A5fF482f1E564EdeE3A774. Version 1 is retired; how it differs is at the end of the page.

The owner creates a vault

The owner connects a wallet, chooses an asset and names one beneficiary wallet, which cannot be the owner's own address. The owner also sets:

Inactivity period: how long the owner may go without checking in, from 7 days to 10 years. It can be changed later.
Challenge window: the minimum time between a beneficiary's claim and settlement, from 7 to 365 days, during which the owner can still stop the claim: with a veto before the horizon, and past it only by extending the horizon or withdrawing everything (see what cancels a claim). It is fixed at creation. We recommend at least 14 days, because a veto only counts once it is included on chain.
Absolute horizon: a long-stop date, at least one inactivity period and at most 100 years ahead. Check-ins can never push the deadline past it, which stops automated check-ins from extending the plan forever. It is not a guaranteed payout date; see the horizon below.

Each vault covers one asset and one beneficiary. An owner can keep up to 32 vaults open, for different assets or heirs, and refresh them all with one check-in. The contract does not receive or store a seed phrase.

Which tokens a vault can hold

ETH, and four ERC-20 tokens on Base:

Asset	Contract on Base	Issuer
ETH	the native coin	none
USDC	0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913	Circle
WETH	0x4200000000000000000000000000000000000006	none: wrapped ETH, with no administrator
cbBTC	0xcbB7C0000aB88B473b1f5aFd9ef808440eed33Bf	Coinbase
EURC	0x60a3E35Cc302bFA44Cb288Bc5a4F316Fdb1adb42	Circle

The list was written into the contract when it was deployed, and no function can change it: nobody, including the administrator, can add or remove a token. The contract refuses a vault in any other token. Each listed token lives at a single address, moves exactly the amount requested and never changes a holder's balance on its own. That is what keeps every vault balance out of the administrator's reach (see the administrator).

Issuer risk. USDC, EURC and cbBTC are upgradeable contracts whose issuers can pause all transfers, blocklist an address or change the token's code. All vaults in one token share one balance at the vault contract, so a single issuer action against that address would freeze the token for every vault at once. Claims still settle on schedule and payouts wait until a freeze lifts, but a wipe would be a loss the contract cannot prevent. ETH and WETH carry no issuer risk of this kind. If that matters to you, use ETH, or split an estate across assets.

A token outside the list that is sent to the contract directly is stranded: no function can move it, the administrator's included. NFTs (ERC-721 and ERC-1155), and more than one asset in a vault, are not supported.

The owner remains in control

While the vault is active, the owner can check in, add funds, withdraw part or all of the balance, change the beneficiary, change the inactivity period, extend the horizon, and install or disarm a check-in chain. Each of these actions, apart from adding funds, restarts the inactivity clock. Anyone may add funds to a vault, but a top-up never counts as a check-in, and it is refused while a claim is pending, so a gift cannot change the amount a pending claim settles.

A withdrawal records the amount as a credit for the address the owner chooses, which then withdraws it. Withdrawing the whole balance closes the vault. The app's Withdraw everything and close does this whatever the balance has become by the time the transaction is mined, so a last-second top-up cannot keep the vault open.

A wallet signature is the authority. A stolen owner key can therefore control the vault; the contract is designed for absence and key loss, not for recovering from key compromise.

Check-ins

A check-in moves the inactivity deadline to one inactivity period from now, but never past the horizon. In the last inactivity period before the horizon a check-in still succeeds, yet can move the deadline only as far as the horizon itself. From then on the deadline is pinned at the horizon: a check-in could move nothing, so the contract refuses it, and from the horizon itself it refuses every check-in. Extending the horizon is the remedy in both cases. A check-in is also refused while a claim is pending, because a check-in never cancels a claim (see what cancels a claim).

One batch transaction can refresh up to 32 of the owner's vaults. It does not fail because one vault cannot be refreshed: it skips that vault and records why. It fails only if it refreshed none, and the error then lists the reasons it saw. The app reports each skipped vault with its reason:

Reason	What it means	What to do
1. Unknown vault	You have no vault with that number	Check the number
2. Finished	The vault is settled or closed	Nothing
3. Claim pending	An heir's claim is pending, before the horizon	Veto the claim if it is wrong: a check-in never ends a claim
4. Horizon reached	No check-in can extend this vault any more	Extend the horizon
5. Pinned	The deadline already sits at the horizon	Extend the horizon
6. Already refreshed	The deadline already moved in this same second, for example a repeated vault number	Nothing
7. Claim pending past the horizon	A claim is pending and the horizon has been reached, where Veto is refused	Extend the horizon by at least one inactivity period, or withdraw everything

The deadline passes

Nothing moves automatically when the inactivity deadline passes. Funds remain in the contract. The named beneficiary must notice the condition and submit an on-chain claim from the nominated wallet address. A stranger cannot initiate the claim.

Nobody is watching for you. Will & Key sends no alerts of any kind: nobody will notify you if your timer expires or a claim is filed, and your wallet will not show a claim against your vault. Nobody notifies your heir either. The challenge window only helps an owner who looks during it, so size the inactivity period and the challenge window together to the longest time you might plausibly not open the app. The inactivity period can be changed later, but a longer period never moves the deadline past the horizon; the challenge window can never be changed.

The beneficiary initiates a claim

A valid claim changes the vault from active to claim-pending and starts the challenge window. It also locks the fee rate for the claim; see fees. The beneficiary names a payout address when starting the claim, and the contract refuses addresses that could never pass the funds on (see payout addresses). Check it before signing: only the heir's own cancel can change it, and only safely before the claim becomes finalizable (see the heir's cancel).

What cancels a claim

Before the horizon, each of these owner actions cancels a pending claim and restarts the clock: Veto claim (abortClaim), changing the heir, changing the inactivity period, installing, replacing or disarming a check-in chain, extending the horizon, or withdrawing any amount. Withdrawing everything also closes the vault.

These do not cancel a claim: a check-in (it is refused while a claim is pending), a batch check-in (it skips the vault), a paper-chain check-in (refused), a top-up (refused), and ordinary activity in your wallet such as a swap or a transfer. Only transactions sent to the vault contract count.

At or after the horizon, while a claim is pending, Veto claim, changing the heir, changing the inactivity period and any change to the check-in chain are refused, and a partial withdrawal still goes through but no longer cancels the claim: the heir simply inherits less. Only two things end a claim: extending the horizon to a date at least one full inactivity period after the moment the transaction is mined (and at most 100 years ahead), or withdrawing the entire balance, which closes the vault.

The heir can also withdraw their own claim; see the heir's cancel.

The challenge window protects against a mistaken or premature claim, while the horizon protects the heir against an unattended automation loop or a repeated last-second veto with no real extension.

A veto only counts once it is included in a block. On Base that depends on the network's sequencer: if it is down or ignoring a transaction, the transaction can still be forced in through Ethereum, which can take up to about 12 hours. On other chains it depends on that chain's validators. Do not leave a veto to the last day.

The heir's cancel, and its deadline

The current beneficiary can withdraw their own pending claim (Cancel my claim in the app), for example to correct a mistyped payout address. The vault returns to active with its deadline and horizon unchanged, so the beneficiary can file again at once, with a new payout address and a fresh, full challenge window.

The deadline for a correction is the moment the claim becomes finalizable, not settlement. From that second anyone may finalize the claim, and whichever finalize transaction is mined first settles it to the payout address recorded for the claim. A cancel is certain to work only if it is mined before that moment, which the app shows on the claim. After settlement the payout belongs to that address alone.

The cancel has costs, stated plainly:

The payout address is not frozen during a claim. Until a finalize transaction is mined, the beneficiary key alone can cancel and file again to any address. Someone who steals the heir's key during the challenge window can therefore redirect the payout, at the price of one more full window, in which a living owner can still stop the claim. Heirs should treat their key as exposed until settlement, and finalize promptly.
There is a gap. Cancelling and filing again are two transactions, and in between the vault is active with its deadline passed. Before the horizon the owner, the owner's automation or anyone holding an unused check-in-chain value can check in, which pushes the new claim back by up to a full inactivity period. Past the horizon the owner can name a new heir, who can claim at once.
The fee is locked again. The new claim locks the rate then in force, up to the vault's ceiling, which can be more than the cancelled claim had locked.

So an heir who cancels should file again straight away.

The horizon is a long-stop, not a payout date

The absolute horizon is the last date to which check-ins can push the deadline. Once the deadline has reached it, the heir can start a claim at the horizon however recently the owner checked in, and finalize no earlier than the horizon plus the challenge window. That date is the earliest inheritance if the heir claims exactly at the horizon, not a guarantee: the heir still has to start the claim and then finalize it. Only the named beneficiary can ever start a claim, so nothing opens at the horizon for anyone else.

A living owner can still stop a claim past the horizon, in two logged ways only: by extending the horizon, or by withdrawing everything. An extension must reach at least one inactivity period ahead (the owner can first shorten the period to 7 days while no claim is pending) and at most 100 years, and it can be repeated. Naming a new heir past the horizon, which is allowed while no claim is pending, does not move the date: the new heir can claim at once. Never give horizon extensions to automation.

Anyone can finalize after the challenge

When the challenge window has run, anyone may call the finalization function. The heir does not depend on a Will & Key server or employee being available. Finalizing is not automatic, and the end of the window is not a veto deadline: until a finalize transaction is mined, the owner's key can still cancel the claim with the actions above. Heirs should finalize promptly. Settlement records the heir's entitlement as a credit, which the heir then withdraws.

Using credits rather than sending funds during the state transition prevents a hostile or incompatible recipient contract from blocking settlement through a failed callback.

Credits: how value leaves the contract

An owner withdrawal and a settlement move nothing yet. They record a credit for the chosen address (at settlement, also one for the fee recipient). Value leaves the contract only when a credit is paid out:

Withdraw a credit. The credited address withdraws it to any address it chooses, apart from the ones the contract refuses, all at once or in parts. Parts help with a token that limits the size of a single transfer; the rest stays credited.
Push a credit. A credit can also be paid to the credited address itself. That address can do so at any time; anyone else only 30 days after the credit was recorded, so the owner of the address can first route a new credit elsewhere, for example away from an address the token's issuer has blocklisted. The 30 days run per address and token: a new credit smaller than what the address is already owed joins the older clock and gets no grace of its own. So an heir whose payout address still holds an older credit should withdraw it before another claim settles into that address, or use a fresh payout address for each claim.
Payouts are measured. A token payout must reduce the contract's balance by exactly the amount paid. An ETH payout to an address with code must reduce the contract's ETH balance by exactly the amount paid and leave its token balances unchanged. An ETH payout to an address with no code, such as an ordinary wallet, runs nothing, so it cannot send anything back and is not measured. A payout that fails either test is refused and the credit stays, so it can be withdrawn to another address.

Payout addresses the contract refuses

These can never be a withdrawal or credit destination, a claim's payout address, the fee recipient or the target of the administrator's sweep: the vault contract itself; the four listed tokens, WETH included; Base's system contracts (the address range 0x4200000000000000000000000000000000000000 to 0x42000000000000000000000000000000000007FF); the four standard ERC-4337 EntryPoint contracts; and Venus vBNB, a BNB Chain contract. Value paid to any of them would be lost, or could come back to the vault as surplus that the administrator could sweep.

No rule can recognise every such address. A contract that books a payment to its sender, such as a staking, lending or deposit contract, keeps the payout: it is lost to whoever named it, and if that contract lets anyone release the booking, the value can come back to the vault as surplus that the administrator can sweep. Pay to an ordinary wallet address; the app warns before a payout to any address that holds code.

Fees

The global claim-settlement fee is 0.5%, and the bytecode caps it at 1%. It is taken only when an inheritance settles. Deposits, owner withdrawals, check-ins and credit payouts have no Will & Key service fee, although every on-chain transaction still pays the network's gas charge. The rate a claim pays is set in steps:

A ceiling at creation. Each vault records the global rate in force when its creation transaction is mined, and its fee can never exceed that ceiling. A raise that has only been announced does not count yet.
Raises wait 30 days; cuts do not. The administrator can cut the rate at once, and a cut cancels any pending raise. A raise takes effect exactly 30 days after it is announced on chain, whether or not anyone applies it, and a newer announcement replaces a pending one and starts its own 30 days. So no rate can be raised in the same block as, and just before, your transaction. The app shows a pending raise and when it takes effect.
Locked when the claim starts. Starting a claim locks the lower of the vault's ceiling and the rate in force at that moment, and the locked rate is visible on the claim. At settlement the lower of the locked rate and the rate then in force applies, so nothing can take the claim above its locked rate.
A cut helps only if it is still in force at settlement. The administrator can reverse a cut before a claim settles, with 30 days' notice, and with a challenge window longer than 30 days the reversal can take effect before the heir is able to finalize. An heir keeps a cut for good only by cancelling the claim and filing again while the cut is in force: that locks the lower rate, at the cost of a fresh challenge window and the other costs of the heir's cancel.
No fee recipient in force, no fee. If no fee recipient is in force when a claim settles, no fee is taken, and removing the recipient takes effect at once, for pending claims too. Setting a recipient again after a period with none counts as a raise: it takes effect 30 days later, and until then claims that start lock a zero fee, which they keep, and claims that settle pay none. Replacing one recipient with another changes no fee. The fee recipient is the administrator's hardware wallet.

What the administrator can and cannot do

The administrator of the vault contract, and its fee recipient, is a single Ledger hardware-wallet key, 0x883C821103B5415C53B11E584D3592205B5CdCA3. It is one key, not a multisig. Version 2 named it in its constructor, so it has held both roles since the deployment on 28 September 2026, and the key that sent the deployment never held either. This is the complete list:

Can do	Cannot do
Pause and unpause creation of new vaults (setCreationPaused)	Pause top-ups, check-ins, withdrawals, claims or payouts
Cut the global fee at once, or announce a raise that takes effect 30 days later, within the 1% hard cap (setClaimFee)	Raise a vault above its creation ceiling, or make a raise take effect sooner
Change the fee recipient (setFeeRecipient); switching fees back on after removing it waits 30 days	Change a vault's beneficiary or any of its settings
Sweep surplus in ETH or a listed token: value above the accounted vault balances and credits (sweepSurplus)	Withdraw a vault balance or a credit, or block an owner withdrawal or a claim settlement
Transfer administration to a new address, in two steps (transferOwnership, then acceptOwnership by the new address)	Add or remove a token, or renounce administration (renounceOwnership is disabled)

One more function, applyClaimFee, is housekeeping that anyone may call: it records a raise whose 30 days have passed, which counts from that moment either way. Surplus is value sent to the contract outside any vault; it can also include a payout that went to a contract which later handed it back (see payout addresses). "Cannot block" describes Will & Key, not token issuers: an issuer can still freeze its own token.

Failure modes to plan for

Owner key stolen: the attacker has the owner's authority.
Beneficiary key lost after the owner is gone: the entitlement becomes permanently inaccessible. Only the named heir can claim, nothing happens at the horizon, and no administrator rescue exists.
Beneficiary key stolen during a claim: the thief can cancel and file again to their own address (see the heir's cancel).
Nobody notices: Will & Key sends no alerts, so a claim or an expired timer goes unnoticed unless the owner or the heir checks. Heirs are not told when a vault becomes claimable.
Token issuer action: all vaults holding a token share one balance at the vault contract. The issuers of USDC, EURC and cbBTC can pause, blocklist or upgrade their tokens and could freeze every vault in that token at once. Claims still settle on schedule, and payouts wait until the freeze lifts. A wipe is a permanent loss the contract cannot prevent.
A payout address that cannot use the funds: withdraw the credit to another address within 30 days of it being recorded; after that anyone can push it to the recorded address.
Paper-seed check-in chain (advanced, no app support): an optional hash chain lets whoever holds a paper seed keep the vault alive after the owner loses their wallet. The app cannot install or use it; the construction is in the check-in chain specification. Every value is bound to this network, this contract, the owner, the vault and the installation, so a value revealed anywhere else is useless here, and installing a chain again never revives an old one. While the owner still holds the wallet key, and before the horizon, a chain can be disarmed at once. A chain check-in is safe only if it is mined strictly before the deadline: from the deadline on, the heir can start a claim first, and once a claim has started, chain values are refused until the claim ends and cannot stop it. Submit at least a day early. A value is used up only when it moves the deadline. Chain values are bearer credentials. They cannot withdraw, change the heir or veto a claim, but whoever holds the seed or any unused value can postpone the heir's claim by up to one inactivity period per value, never past the horizon, and that includes the gap after an heir cancels a claim. Use a fresh seed for every vault and every chain.
Contract defect: the deployment is immutable, so a serious defect requires a new contract and migration. The creation pause cannot stop top-ups into existing vaults; in a migration, owners should withdraw in full, which closes the vault.

Version 1, retired

Version 1 of the vault contract, 0xC821849A1D74959753450409b594b23eCE7fEe2f, ran on Base from 9 August 2026 until version 2 replaced it on 28 September 2026. Its new-vault creation is paused (transaction), and on 27 September 2026 it held no user funds. It cannot change, and it lacks the fixes described on this page: among the preliminary audit's findings, it accepts any token, applies fee changes at once, has no heir's cancel, pays a credit only in one piece, lets anyone push a credit at once, and binds a check-in chain to its vault only through how the chain was built. Do not send it funds. The security page has the details.

Verification before value: read the security and audit page and the preliminary audit, which was performed by AI auditing agents at our request and is not independent. Version 2 has not completed an independent third-party audit either: only AI agents of the same kind that wrote it have reviewed it. Inspect the deployed source and try the complete flow with a small amount.

For a broader planning workflow, continue with the crypto inheritance planning checklist or read the dead-man switch guide.