how decessor works.

Overview

Decessor lets an Ethereum address name a successor. It is a small piece of code that your existing account, an EOA, points to through EIP-7702. You keep your address and your keys. You name one or more successors, in order, and choose a silence period of at least 30 days.

As long as you keep using your address through the Decessor code, nothing happens. If you go quiet for longer than your silence period, your first successor can claim. A claim opens a 30-day grace period, and one transaction from you cancels it. If grace runs out, the successor takes control of the address.

No custody, no oracle, no death certificate, no KYC. The chain never needs to know you are gone, only that you went quiet. Decessor is a recovery tool first and an inheritance tool second.

The problem

Every address on Ethereum has one failure mode nobody designs for: silence.

Keys get lost. Hardware fails, seed phrases burn or were never written down. People go, and the people they leave behind rarely know where to look. The chain keeps the balance forever and gives it to no one.

The usual answers all add someone you must trust: a custodian holding your keys, an envelope with a seed phrase in someone's drawer, a multisig whose other signers must stay reachable for years. Each is a new way to lose, or to be robbed.

Decessor adds no one. It adds one rule to your own address: if I go quiet for long enough, this is who comes next.

How it works

1. Delegate. You sign an EIP-7702 authorization that points your EOA at the Decessor code. Your address and key stay the same.
2. Configure. You call configure() on your own address with your successors, in order, and your silence period.
3. Live normally. Every transaction you send through the delegated code resets your clock. pulse() resets it without doing anything else.
4. Silence. If no owner transaction arrives for the whole silence period, the first successor may claim().
5. Grace. A claim opens a 30-day grace period. Any owner transaction, or cancel(), ends it.
6. Pass on. After grace, the claimant calls take(). Control of the address passes to them and the fee is paid.

The whole mechanism, as implemented in contracts/Decessor.sol and mirrored in the sandbox:

configure(successors[], silence)        -> owner only ; silence >= 30 days
execute(to, value, data) / pulse()      -> owner only ; lastSeen = now
claim()                                 -> successor[i] only ; require now > lastSeen + silence + i * CASCADE_DELAY ; graceEnd = now + 30 days
cancel()                                -> owner only ; graceEnd = 0 (any owner transaction also cancels)
take()                                  -> claimant only ; require graceEnd != 0 && now > graceEnd ; control -> successor ; fee -> treasury

GRACE         = 30 days
CASCADE_DELAY = 90 days
FEE_BPS       = 50          // 0.5% of ETH passing at take(), nothing before
States        : ACTIVE, CLAIMABLE, IN_GRACE, PASSED

The clock

Your clock is a single number stored at your address: lastSeen, the time of your last owner transaction. Successor i (counting from zero) may claim once:

now > lastSeen + silence + i * CASCADE_DELAY

What resets it

Any call you send to your own address that runs the Decessor code: configure(), pulse(), execute() and cancel(). Each one also cancels a pending claim.

What does not

Incoming transfers, tokens or NFTs sent to you, signed messages, and transactions your key sends straight to another contract without going through the delegated code. The clock listens to you, not to the world around you.

pulse()

pulse() exists so you can say still here without moving anything. It is a transaction from your address to your address. The landing page has a button for it once the contract is live.

Choosing a silence

Long enough that a holiday, a hospital stay or a year of cold storage never trips it. Short enough that your successors are not left waiting a decade. Between six and twenty-four months suits most people. The minimum is 30 days; the reference implementation caps it at ten years.

Succession cascade

You can name up to three successors, in order. The first may claim as soon as the silence runs out. Each next one waits another 90 days, the CASCADE_DELAY.

If your first successor has lost their keys, or is gone too, the second can still claim. Earlier windows stay open: once the second may claim, the first still may as well. Whoever claims first starts the grace period, and only one claim can be pending at a time.

Recovery use case

Decessor is a recovery tool first. Name your own hardware wallet, kept somewhere safe, as successor 1, and use your everyday address as you always do.

If you ever lose its key: wait out the silence, claim from the hardware wallet, wait the 30 days of grace, then take(). From then on the same address, with the same history, ENS name and positions, is controlled by your hardware wallet through execute().

Behind it, add the people you trust as successors 2 and 3. If you and your hardware wallet are both gone, they come next.

configure([hardwareWallet, partner, sibling], 365 days)

// hardwareWallet may claim after 365 days of silence
// partner after 455 days, sibling after 545 days

Rehearse it first in the sandbox: it runs the same rules, with your own wallet as the owner.

EIP-7702 delegation

What is delegated

EIP-7702, live on Ethereum mainnet since the Pectra upgrade in May 2025, lets an EOA sign an authorization that sets its code to a pointer: 0xef0100 followed by a contract address. Calls to your address then run that contract's code in the context of your account, with your address, your balance and your storage.

What you delegate is the code your address runs. Nothing is transferred. There is no deposit, no new account and no token approval to anyone.

What the owner keeps

• Your address, with its history, ENS name and positions.
• Your key. It can still sign everything it could before, including a new authorization that replaces or removes the delegation.
• Your assets, which never move unless you move them, until a successor has taken control.
• The last word. Any owner transaction cancels a claim, until take() has actually happened.

Decessor keeps its state in its own storage namespace at your address (ERC-7201), so it does not collide with storage written by other code you may have used before. The layout is documented in the reference contract.

How to verify the code hash

Phishing sites will ask you to delegate to their own contract, and a malicious delegate can empty an account in one transaction. Before you sign any authorization:

1. Check the delegate address against the one announced by @DecessorETH and shown below. Nowhere else is a source.
2. Check that the keccak256 hash of its runtime code matches the published code hash.
3. After delegating, check your own address: its code must be exactly 0xef0100 followed by the Decessor address, and nothing else.

# the delegate's runtime code hash (Foundry)
cast keccak $(cast code <DECESSOR_ADDRESS>)

# your address after delegation: 0xef0100 followed by the delegate address
cast code <YOUR_ADDRESS>

Many consumer wallets only let you delegate to their own smart-account code. To delegate to Decessor you need a wallet or tool that can sign an authorization for any contract, such as Foundry's cast. Instructions for wallets that support it will be published with the deployment.

# example: delegate and configure in one type-4 transaction, sent to yourself
cast send <YOUR_ADDRESS> "configure(address[],uint64)" "[<SUCCESSOR_1>,<SUCCESSOR_2>]" 31536000 \
  --auth <DECESSOR_ADDRESS> --account <your-keystore>

Commands are examples for Foundry users. Check them against the current Foundry documentation and rehearse on a testnet first.

How to revoke

Sign a new EIP-7702 authorization that delegates to the zero address. Your address goes back to being a plain EOA, with no code. Delegating to any other contract also replaces Decessor: an address points to one delegate at a time.

cast send <YOUR_ADDRESS> --auth 0x0000000000000000000000000000000000000000 --account <your-keystore>

Revoking does not erase Decessor's storage at your address. If you delegate to Decessor again later, make configure() your first call: it rewrites your successors and resets your clock, so an old silence can never count against you.

Guarantees

No custody

Your assets never leave your address until a successor has taken control. There is no vault, no pool and no Decessor account holding anything of yours.

No oracle

No outside data feeds the decision. The code compares one stored number, the time of your last owner transaction, with the block timestamp.

Cancel is always available to the owner

From the first second of a claim until take() is executed, one transaction from you ends it. Nobody, the Decessor team included, can stop you from cancelling.

Nothing moves before grace ends

claim() moves nothing. take() reverts until the grace period has fully elapsed. The fee is charged inside take() and nowhere else.

No admin keys

The code has no owner, no upgrade path and no pause switch. Your rules are the code you delegated to, and they change only when you change them.

require(msg.sender == address(this))      // only you configure, pulse, execute, cancel
require(graceEnd != 0 && now > graceEnd)  // nothing passes before grace ends
fee = balance * FEE_BPS / 10_000          // computed only inside take()

Security & risks

Silence is not death

Decessor cannot tell someone who is gone from someone who is quiet. Choose a long silence and a successor you trust: a silence you will never hit by accident, and successors you would trust with the address today.

Successors can lose keys too

That is why there is a cascade. Name more than one successor, and make sure each knows what they are and how to claim.

An EIP-7702 delegation is a phishing target

Signing an authorization for the wrong contract can empty your account. Verify the code hash and the delegate address, take them only from @DecessorETH announcements and this site, and never sign an authorization from a link someone sent you.

Experimental software, bugs are possible

The reference implementation has not been audited. Do not delegate an address holding anything you cannot afford to lose until an audited version is announced.

After take(), an old key still works

EIP-7702 cannot remove a key from an EOA. If the original key was not lost but merely unused, whoever holds it can still sign transactions directly. Decessor is built for keys that are gone and owners who are gone.

Privacy and inheritance rules differ by jurisdiction

Your successors, your silence and every claim are public on-chain. Passing an address on may have legal and tax consequences where you or your successors live. Decessor is not a will.

Nothing here is financial advice

Nothing on this site is financial, legal or tax advice. Decide for yourself, with your own advisers where it matters.