reference contract

decessor.sol

The EIP-7702 delegate target behind Decessor, in Solidity ^0.8.24 with no dependencies. The sandbox runs js/sim.js, which mirrors it function by function and is unit tested against it.

Notice

Reference implementation, not audited. Do not delegate an address holding anything of value to this code. The production address and code hash will be announced only by @DecessorETH.

Decessor.sol README.md

Storage layout

Under EIP-7702 the code runs in your account's own storage, so Decessor keeps everything in one namespaced struct (ERC-7201) instead of low slots another delegate might use.

namespace  decessor.storage.v1
slot S     0xfa8125a9fac28d1f6f4b05fe454526c3d5323babf90eb8663d81994abd87e200

S                 successors.length
keccak256(S) + i  successors[i]
S + 1             silence (uint64) | lastSeen (uint64) | graceEnd (uint64) | claimant (uint8)
S + 2             controller (address, 0 until take())

The 7702 flow

  1. Decessor is deployed once. Its runtime code hash is what you verify.
  2. You sign an EIP-7702 authorization for it. Your account's code becomes 0xef0100 followed by the Decessor address.
  3. You call configure() on your own address: the call arrives with msg.sender == address(this), which is how the code knows it is you.
  4. Every owner call resets lastSeen and cancels any pending claim.
  5. After the silence, a successor calls claim(); after 30 days of grace, take().
  6. To leave, authorize the zero address. Your account becomes a plain EOA again.

Source

The complete file, exactly as shipped in contracts/Decessor.sol.

Loading Decessor.sol…